On Mon, Jan 9, 2012 at 3:02 PM, Ping Cheng wrote:
> On Mon, Jan 9, 2012 at 7:22 AM, Chris Bagwell wrote:
>>
>>
>> I'd like to understand this better if ya don't mind.
>>
>> First up, is this usecase for absolute or relative mode?
>
>
> Very g
On Mon, Jan 9, 2012 at 7:51 AM, Ping Cheng wrote:
> On Sun, Jan 8, 2012 at 9:56 PM, Peter Hutterer
> wrote:
>>
>> On Sun, Jan 08, 2012 at 12:16:57AM -0800, Ping Cheng wrote:
>> > On Saturday, January 7, 2012, Chris Bagwell
>> > wrote:
>> > > Wh
ere is a bit that is common between all products that
we can use for in-proximity or if there is some kind of if() statement
we can add to work with multiple product types.
Chris
--
Ridiculously easy VDI. With Citrix VDI
moved
before committing.
Chris
On Fri, Jan 6, 2012 at 7:57 PM, Ping Cheng wrote:
> This property enables/disables multi-touch events on a multi-touch
> device. When MT is disabled, the device behaves like a single
> touch device. The corresponding xorg.conf option is also added.
>
>
I've already forgotten what your driver patch looks like... but this
shouldn't technically be needed, right? If the TPC's are still not
advertising BTN_TOOL_FINGER then there is code to auto add WCM_TPC in
wcmUSB.c
Anyways, its not like it hurts anything:
Reviewed-by: Chris B
Thanks Peter.
Reviewed-by: Chris Bagwell
On Thu, Jan 5, 2012 at 9:27 PM, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> ---
> Chris, this should do the trick provided the email client on the release
> manager's side honours Reply-To.
>
> release.sh | 2 +
that looks interesting).
Chris
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-
eck out
their uTouch stuff and any custom Qt patches they ship. They are
probably furthest along with exposing MT to toolkits although their
API's are likely to change in each release since they are not using
the above official plumbing yet.
https://wiki.ubuntu.com/Multitouch
Chris
--
Pushed. Thanks.
On Wed, Jan 4, 2012 at 2:16 PM, Ping Cheng wrote:
> Compiled on 2.6.36 and .37. So,
>
> Acked-by: Ping Cheng
>
> Ping
>
> On Thu, Dec 29, 2011 at 3:33 PM, wrote:
>>
>> From: Chris Bagwell
>>
>> Reported in bug tracker #3463769.
>
s original
Linux distro, you can monitor the USB packet it sends when you do a
rmmod followed by a insmod of their driver. Then we'd know what to
add to modern wacom drivers.
Without the info, I'm afraid we are at a dead end.
Chris
2012/1/4 Mike Rolland :
> well, i have no /sys/kernel/
On Tue, Jan 3, 2012 at 4:21 AM, Mike Rolland wrote:
> I was beginning to loose my self in all this advices.
> I had needs to clean my brain and go from start, so like suggest Chris, I
> revert all and change my kernel like this to separate multi device thing and
> clarify my-self
Thanks so much for the clean ups! The code flow from new patch does
seem aligned now.
For the whole series of your patches:
Reviewed-by: Chris Bagwell
Hopefully this will be accepted into the RC1 coming up. You may want
to send the whole series again to list so they all have a x/5 (or what
I've one comment below but other than that:
Reviewed-by: Chris Bagwell
If you make the modification suggested below, you can include my tag
in the next revision.
Chris
On Mon, Jan 2, 2012 at 11:58 AM, Alexey Osipov wrote:
> When touchpad is in Relative mode of operation, we need allo
ork with xf86-input-wacom though.
You will also need to revert and xorg.conf files so that the device is
correctly matched to xf86-input-evdev.
Chris
On Mon, Jan 2, 2012 at 11:10 AM, Chris Bagwell wrote:
> On Mon, Jan 2, 2012 at 3:13 AM, Mike Rolland wrote:
>> Ok, let's dance for
e sense? For example, drawing from top of screen to bottom of
screen do you see mostly only Y axis change values linearly?
>
>
> ### lsusb with module unload :
>
> [root@hpm mike]# lsusb -vvv -d 0b05:179f
>
OK. Good info in this lsusb. I'm not positive yet if this
see if anything is printed.
Note: X will grab the /dev/input/eventX device. When device is
grabbed, evtest will print the above header information but no events
will be generated. You can make X ungrab the device by either
stopping X or switching to a text console and running evtest from text
console.
t; Option "MaxX" "1" # "16480"
> Option "MaxY" "6250" # "12410"
> Option "Tilt" "on" # Inclinaison
> Option "Button1" "1&q
no PEN/STYLUS described which may or may not confuse
xf86-input-wacom (I forget were we are at there. I tried to make it
optional but do not remember if I was successful).
This proves you'll have to get a custom kernel driver handling this
device before it will work with xf86-input-*.
Ch
On Sat, Dec 31, 2011 at 2:16 AM, Alexey Osipov wrote:
> В Птн, 30/12/2011 в 13:54 -0600, Chris Bagwell пишет:
>> I'm glad someone decided to add this! I wanted to but been to busy.
>>
>> Similar to Peter's past comments on the file wcmTouchFilter.c, this
>>
On Sat, Dec 31, 2011 at 1:58 AM, Alexey Osipov wrote:
> В Птн, 30/12/2011 в 13:30 -0600, Chris Bagwell пишет:
>> The need for this makes sense (although I haven't tested it to much to
>> see the jump).
>>
>> Although absolute devices don't have the same delt
lowing thread
is someone that added support for non-standard buttons on tablet
itself to ISDV4 logic.
http://www.mail-archive.com/linuxwacom-devel@lists.sourceforge.net/msg03370.html
I never saw the code committed to xf86-input-wacom or linux kernel.
Chris
---
On Fri, Dec 30, 2011 at 2:21 PM, Mike Rolland wrote:
> Le vendredi 30 décembre 2011 à 11:37 -0600, Chris Bagwell a écrit :
>
>> * Run "dmesg | grep ASUSTek" and look for line telling if kernel
>> driver has been installed for this device.
>
> [root@hpm mike]
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston
dd the single if() inside
wcmSendEvents().
I'd also limit the wcmGestureMode to wcmSendNonPadEvents() since PAD
devices never have gestures.
Chris
On Sat, Dec 24, 2011 at 12:18 AM, Alexey Osipov wrote:
> When touchpad is in Relative mode of operation, we need allow driver
> upd
, this patch looks good to remove chance of second
unwanted click.
Reviewed-by: Chris Bagwell
Chris
On Sat, Dec 24, 2011 at 12:18 AM, Alexey Osipov wrote:
> As right click performed with second finger, then we only interested
> in second finger touch when trying to match 'right cli
sg | grep ASUSTek" and look for line telling if kernel
driver has been installed for this device.
I googled for this USB ID and got one result where it said its being
detected as a generic HID Mouse. This would not be a good t
ing the RC1 release on Saturday, so now's the time to
> submit/review/nominate anything you'd like to get into 0.13.
>
I do not have any work for 0.13 but I will try to finish up review of
gesture patches. I'm sure people would love to have tap-and-drag
From: Chris Bagwell
Reported in bug tracker #3463769.
Based on mini code review, I think this is only missing
symbol and 2.6.36/37 contain ABS_MT_FIRST and input_mt_slot
which this function depends on.
I'm unable to test this fix but its a copy&paste of
function from mt.h in late
xf86-input-synaptics to see how its
doing that. We could really stand to have similar logic in
xf86-input-wacom... but I've yet to find time to add this.
http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/tree/src/synaptics.c
Chris
On Sat, Dec 24, 2011 at 12:18 AM, Alexey Osip
On Wed, Dec 21, 2011 at 7:29 AM, Ping Cheng wrote:
> On Sun, Dec 18, 2011 at 7:28 PM, Chris Bagwell wrote:
>>
>> Hi all,
>>
>> I messed up in input-wacom 0.12.0 release. I said that it supported
>> 2nd gen Bamboo but it did not.
>>
>> Its just a
For the series:
Reviewed-by: Chris Bagwell
On Sun, Dec 18, 2011 at 9:37 PM, Peter Hutterer
wrote:
> We need a copy of it in the driver. This is just the one the driver uses for
> pre-ABI 14 compatibility, we don't need the server's exact copy since we're
> not test
Reviewed-by: Chris Bagwell
On Tue, Dec 13, 2011 at 3:59 PM, Jason Gerecke wrote:
> This patch expands the number of valuators reported by devices to
> seven. The new seventh valuator reports the raw value provided from
> the kernel for the second touch ring.
>
> Signed-off-by
I've finished reviewing this one and have no comments beyond Peter's.
Chris
On Sun, Dec 18, 2011 at 8:56 PM, Peter Hutterer
wrote:
> On Tue, Dec 13, 2011 at 01:59:00PM -0800, Jason Gerecke wrote:
>> Touch strips as well as the first touch ring are set up to emulate
>&
todays dtor-next branch which includes 2nd gen
Bamboo and for a bonus includes Jason's just committed Cintiq 24HD
support.
If no one objects, I'd like to plan on a new input-wacom-0.12.1
release that includes this 1 patch before next weekend.
Sound good?
Chris
On Sun, Dec 18, 2011
From: Chris Bagwell
Previous version was missing 2nd gen Bamboo support
even though git commit said it was supported.
Signed-off-by: Chris Bagwell
---
2.6.38/wacom_sys.c | 19 ++--
2.6.38/wacom_wac.c | 129 +--
2.6.38/wacom_wac.h |1
I've really been meaning to review these but to busy. So let me at
least nock some of easy ones out.
For 1st patch and v2 of 2nd patch:
Reviewed-by: Chris Bagwell
Since the ABS_THROTTLE is in dtor's next branch, I guess its safe to
add here as well.
I'll try to finish the oth
Makes sense for end-of-lifed product. You can disregard these patches.
I may still work on xf86-input-wacom issues I mentioned since they can
help future generic tables.
Chris
On Wed, Dec 7, 2011 at 4:45 PM, Ping Cheng wrote:
> Hi Chris,
>
> On Wed, Dec 7, 2011 at 1:39 PM, Chri
e and see what I can figure out.
This patch may be a little to aggressive to commit since I do not have
HW to test.
Chris
--
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to
s my best effort to try to solve that logic issue without
having a device at hand.
Chris
>
> Jason
>
> ---
> Day xee-nee-svsh duu-'ushtlh-ts'it;
> nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
> Huu-chan xuu naa~-gha.
>
>
>
> On Thu, Dec 1, 2011
u-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
> Huu-chan xuu naa~-gha.
>
>
>
> On Thu, Dec 1, 2011 at 8:02 PM, wrote:
>> From: Chris Bagwell
>>
>> Don't work so hard to not report events. Let input event
>> filtering do its thing for us. Mak
From: Chris Bagwell
This is standard concept for automake based systems but
kbuild doesn't support it. Add a work around to force
src to point to source directory while everything else
still points to buid directory.
This allows the very useful "make distcheck" to work. Tha
On Mon, Nov 28, 2011 at 11:27 AM, Ping Cheng wrote:
> On Sat, Nov 26, 2011 at 4:29 PM, wrote:
>> From: Chris Bagwell
>>
>> Hi all. maybe this will help out some users. I added a back port
>> of latest drivers to 2.6.38 kernel inside input-wacom package since
&g
From: Chris Bagwell
For graphire, the ABS_MISC was never sending any information
beyond what BTN_TOOL_* was providing. So remove sending
event.
Bamboo P&T and a left over send for the pen tool even though
capability wasn't declared. So remove as well.
Signed-off-by: Chri
From: Chris Bagwell
Graphire series stylus do not report serial #'s.
A fake serial # of 1 was sent for stylus and then changed to
fake new value of 0xf0 when pressing pad buttons even if stylus
was still in proximity.
This was to help out some internal xf86-input-wacom issues
but those i
From: Chris Bagwell
Don't work so hard to not report events. Let input event
filtering do its thing for us. Makes it easier to follow
data parsing vs. event sending features.
Left in event filtering for overlapping events and had
a purpose for preventing events.
Signed-off-by: Chris Ba
From: Chris Bagwell
Here are some patches related to recent thread. The
graphire devices were basically aligned with "generic"
protocol but sending MSC_SERIAL and ABS_MISC which was
confusing xf86-input-wacom into thinking it was sending
Protocol 4-style events. So removed those.
T
On Wed, Nov 30, 2011 at 6:54 PM, Ping Cheng wrote:
> On Mon, Nov 21, 2011 at 2:25 PM, Chris Bagwell wrote:
>> On Mon, Nov 21, 2011 at 3:44 PM, Przemo Firszt wrote:
>>> This patch adds parsing pad buttons for Intuos4. The change of "buttstate"
>>> type is req
er (pinch
gesture). Using cos() function is probably a little to expensive to
do every packet... but maybe not if we limit it to only when 2 fingers
are touching.
Switching to this type logic will help fix that lag and confusion that
is still occurring right at initial phase o
From: Chris Bagwell
Signed-off-by: Chris Bagwell
---
.gitignore | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..7f1517a
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,13
From: Chris Bagwell
Make use of Kbuild's clean since it knows bests what
to clean up.
Add a distclean target since we are confusing automake
with kbuild tricks and it wasn't working before.
Signed-off-by: Chris Bagwell
---
2.6.30/Makefile.in |8 +---
2.6.36/Makefile
From: Chris Bagwell
I mistakenly sent only 3 patches instead of 4. The first one
removes LIBTOOL support to speed configure up. Nothing else changed.
Also, I realized its better to include "input-wacom" in patch
titles to help guide which repo it goes to.
Chris Bagwell (4):
From: Chris Bagwell
This prevents libtool support from needlessing
being installed during autogen.sh.
Signed-off-by: Chris Bagwell
---
configure.ac |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9e88d66..4ec99cb 100644
--- a
The following changes since commit 31dbd9fc9fdd3691d9ef43c707ecc780e0c62d24:
xf86-input-wacom 0.12.0 (2011-11-15 11:21:46 -0800)
are available in the git repository at:
git://github.com/cbagwell/xf86-input-wacom.git gesture5
Chris Bagwell (3):
Break option parsing into two init phases
From: Chris Bagwell
Signed-off-by: Chris Bagwell
---
.gitignore | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..7f1517a
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,13
From: Chris Bagwell
Hi all. maybe this will help out some users. I added a back port
of latest drivers to 2.6.38 kernel inside input-wacom package since
that is first version that supports mt.h header file and related
internal multitouch functions.
By latest drivers, I mean the whole wacom
From: Chris Bagwell
Make use of Kbuild's clean since it knows bests what
to clean up.
Add a distclean target since we are confusing automake
with kbuild tricks and it wasn't working before.
Signed-off-by: Chris Bagwell
---
2.6.30/Makefile.in |8 +---
2.6.36/Makefile
cke
Thanks. I'm away from real computers until Friday so will upload it to
github then.
>
> Jason
>
> ---
> Day xee-nee-svsh duu-'ushtlh-ts'it;
> nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
> Huu-chan xuu naa~-gha.
>
>
>
> On Tue, Nov 2
From: Chris Bagwell
I had a NAK'ed patch related to improving 2 finger gestures by
making distance values relative to HW values. This is that
patch converted to roughly what we discussed at the time.
The biggest comment at the time was to make 2 functions related
to parsing options so
From: Chris Bagwell
2 finger Gestures will start working on a wider range of
hardware with different resolutions now.
Signed-off-by: Chris Bagwell
---
src/wcmCommon.c |4
src/wcmTouchFilter.c| 22 --
src/wcmValidateDevice.c | 20
From: Chris Bagwell
This is ground work to allow much easier overriding of
default values for case were exact default value is not
known until after init phase (for example, if default value
depends on resolution of hardware which is not known until
after init phase).
Signed-off-by: Chris
From: Chris Bagwell
Its not really needed anymore. The whole *Default variable concept is
at least partially related to historically the PAD device was Init'ed
before the TOUCH device on Bamboo's but that is no longer true.
And since the TOUCH device is now Init'ed before PA
nd
tablet buttons at same time. Come to think of it, we may should
modify xf86-input-wacom to stop basing Protocol 4 support based on
MSC_SERIAL and instead rely on hard coded list of tablet_id's.
So I'll leave it for you to decide how best to proceed and for this
patch you have my:
Reviewe
hat it matters much because both
xf86-input-evdev and xf86-input-wacom currently do not have knobs to
tweak in this area for touch.
For stylus touches, thats what the Threshold option is for in xf86-input-wacom.
Chris
--
A
On Fri, Nov 18, 2011 at 2:28 AM, Cedric Sodhi wrote:
> On Thu, Nov 17, 2011 at 06:26:04PM -0600, Chris Bagwell wrote:
>> On Thu, Nov 17, 2011 at 3:54 AM, Cedric Sodhi wrote:
>> >> > > I updated to GIT and it appears that the wacom now works both, clicks
>> >&
pen device. The current
code makes alot of assumptions on device creation order and
tablet_id's that need to be reworked for your case. We will need some
config option that lets you give the touch device name to bind to
instead of basing it only on matching tablet_ids.
Once that issue i
Now you've attached a new evtest_twofinger.log and its values look
good. So your saying this new log is from a version based on the
diff?
If so, I'll chalk it up to some debug issue and sounds like
ALWAYS_VALID is indeed the key to this.
Chris
On Wed, Nov 16, 2011 at 2:48 PM, Cedric Sodhi wr
ds 1
fingers worth of data per packet, you do not want that quirk.
I'll still hold off on xf86-input-wacom issues until the events coming
are sane. Your current events will cause xf86-input-wacom to do all
kinds of weird stuff thats not worth effort to weed threw.
Chris
-
aybe
> it helps.
I didn't compare line-by-line but looks cosmetic differences.
>
> But I don't get any events on 3.1.x either.
>
This part i don't understand. If your compiling 3.2-rc1
hid-multitouch against yo
On Mon, Nov 14, 2011 at 8:02 PM, Chris Bagwell wrote:
> On Mon, Nov 14, 2011 at 7:19 PM, Jason Gerecke wrote:
>> On Mon, Nov 14, 2011 at 4:28 PM, Jason Gerecke wrote:
>>>>
>>>> Looking at the usbInitTool function closer, it looks like there was a
>>>&
;>> found, return the previous value... Except in the special case were
>>> the previous value was zero. Then we can default to TOUCH_ID.
>>>
>>> Since BTN_TOOL_PEN doesn't have the same zero value issue as
>>> ABS_MT_SLOT_ID, I think its safe to defa
On Mon, Nov 14, 2011 at 4:40 PM, Chris Bagwell wrote:
> On Mon, Nov 14, 2011 at 3:48 PM, Jason Gerecke wrote:
>> On Sun, Jun 26, 2011 at 5:44 PM, Peter Hutterer
>> wrote:
>>> On Sun, Jun 26, 2011 at 07:40:35PM -0500, Chris Bagwell wrote:
>>>> On Sun, Jun
On Mon, Nov 14, 2011 at 3:48 PM, Jason Gerecke wrote:
> On Sun, Jun 26, 2011 at 5:44 PM, Peter Hutterer
> wrote:
>> On Sun, Jun 26, 2011 at 07:40:35PM -0500, Chris Bagwell wrote:
>>> On Sun, Jun 26, 2011 at 7:31 PM, Peter Hutterer
>>> wrote:
>>> > On
On Mon, Nov 14, 2011 at 1:13 AM, Cedric Sodhi wrote:
> On Sun, Nov 13, 2011 at 05:11:46PM -0600, Chris Bagwell wrote:
>> >
>> >>
>> >> I also find using the kernel hid debug features useful in
>> >> understanding whats going on:
>> >&g
On Sun, Nov 13, 2011 at 10:16 AM, Cedric Sodhi wrote:
> On Sun, Nov 13, 2011 at 09:21:20AM -0600, Chris Bagwell wrote:
>> On Sat, Nov 12, 2011 at 9:42 AM, Cedric Sodhi wrote:
>> > Chris, I just compiled from Torvalds' HEAD (adding MULTITOUCH5 as usual)
>>
On Sat, Nov 12, 2011 at 9:42 AM, Cedric Sodhi wrote:
> Chris, I just compiled from Torvalds' HEAD (adding MULTITOUCH5 as usual)
> and the clicking still jams.
>
Hmm, I just tried that version and its working with my touchscreen (I
got it back). I forget, what X input driver are
I only saw Peter's review of 2 patches. Here is one for this patch
just in case.
If you've got a wacom touchscreen, your ideal person to know if this
code works (its the main user of it). My changes in this area were
all done blind.
Reviewed-by: Chris Bagwell
On Wed, Nov 9, 2011
l in center of screen but the closer I got to
edges the it shifted away from were I was actually touching.
If they track similar under both OS's and your not happy, you may
consider taking it back. If the issue is under Linux only then I'm
sure we can fix it.
Chris
On Sun, Nov 6, 2011 at 3:21 PM, Sönke Schwardt-Krummrich
wrote:
> Hi Chris,
>
> Am Sonntag, 6. November 2011, 20:42:56 schrieb Chris Bagwell:
>> On Sun, Nov 6, 2011 at 11:00 AM, Sönke Schwardt-Krummrich
>>
>> wrote:
>> > I added a printk at the top of wacom_bp
://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Wacom_Protocol_Overview
Chris
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
__
urn 0;" at top of wacom_bpt_pen() routine.
I don't recall seeing those 0xC0 packets on 1st gen Bamboo. And I
guess I wasn't looking hard enough on the 3rd gen.
Do you two mind adding and testing that solution (and removing the
check for data[1] == 0)? I want to make sure there isn'
On Sun, Nov 6, 2011 at 10:00 AM, Chris Bagwell wrote:
> On Sun, Nov 6, 2011 at 3:32 AM, Alcides Viamontes Esquivel
> wrote:
> So to really see whats happening, you may need to write some debug
> code that does a printk() for 1st packet when data[1] == 0 and then
> also printk()
On Sun, Nov 6, 2011 at 3:32 AM, Alcides Viamontes Esquivel
wrote:
> Hi guys,
>
> I would like to say thanks for your wonderful job in supporting Wacom tablets.
>
> I got one CTH-470 yesterday and could get it cranking thanks to the
> work of Chris Bagwell
> (http://source
For both patches:
Reviewed-by: Chris Bagwell
On Fri, Nov 4, 2011 at 2:22 PM, Przemo Firszt wrote:
> This patch doesn't change the way driver works. Parsing logic is now in a
> separate function. It's a first step to add Intuos4 Wireless support to
> hid-wacom driver.
>
&
Looks good to me. One final hint, in case you haven't tried it yet.
Linux source ships with scripts/checkpatch.pl. You run it simple as
checkpatch.pl 000*" and it will report any possible style issue.
I didn't see any issue but sometimes they hid from ya.
Chris
On Wed, Nov 2,
. So that means you need to merge
patch 1 and 2 since it looks like 1 wont compile by itself.
Chris
On Wed, Nov 2, 2011 at 4:20 PM, Przemo Firszt wrote:
> It's a second step to add Intuos4 Wireless support to hid-wacom driver.
>
> Signed-off-by: Przemo Firszt
> ---
> driv
On Wed, Nov 2, 2011 at 9:42 AM, Cedric Sodhi wrote:
> On Wed, Nov 02, 2011 at 08:59:55AM -0500, Chris Bagwell wrote:
>> xsetwacom's TabletPCButton == xinput's "Wacom Hover Click".
>
> Well, I did try TabletPCButton before, and it did not work. After trying
xsetwacom's TabletPCButton == xinput's "Wacom Hover Click".
Agree it would be nice to include a xsetwacom to X properties
conversion table in man pages; similar to how "man synaptics" does it.
Patches welcome (since this is on the developers list)!
Chris
On Wed,
. I'm
> actually positive I did not.
>
> Any idea how to find out what's wrong? xsetwacom --get ... all returns
>
Do a "max wacom" and look at the TPCButton description. Is that the
behavior your seeing? Depending on xf86-input-
.ko /lib/modules/$(uname -r)/updates
sudo depmod -a
reboot
Note: As of yesterday, I was not going to submit a patch for eGalax
because Linux 3.2 had a patch to auto-detect multitouch touchscreens
based on its HID report and route to hid-multitouch. But as of today,
that patch is being reverted becaus
bly best to move the graphire parsing logic to
its own function; like you've done for I4. If you did that, then
there may not even be a whitespace change anymore showing up in diff
report and would be even easier to review.
4) wacom_input_mapped()
I'd break the removal of this fu
g ginn is an option, this is the best multitouch option now.
If its not so easy then you can also use xf86-input-wacom for
multitouch gestures. At least I do on my mosart touchscreen that uses
hid-multitouch. The wacom driver has many known gesture issues but
they are slooowly being worked o
d/hid-core.c;h=91adcc5bad284ea6cd28e301a237b554de959bb8;hb=refs/heads/for-next
>>
>> See around line 1407 where its blacklisting other eGalax touchscreens.
>> Add a line for yours.
>>
>> Chris
>
> That scored it! Do you still want me to try out the quirk method? I
&
On Fri, Oct 28, 2011 at 9:13 AM, Chris Bagwell wrote:
> On Fri, Oct 28, 2011 at 3:57 AM, Cedric Sodhi wrote:
>> On Thu, Oct 27, 2011 at 11:36:43AM -0500, Chris Bagwell wrote:
>>> Linux tends to require white lists for supported touchscreens. So it
>>> doesn't ma
On Fri, Oct 28, 2011 at 3:57 AM, Cedric Sodhi wrote:
> On Thu, Oct 27, 2011 at 11:36:43AM -0500, Chris Bagwell wrote:
>> Linux tends to require white lists for supported touchscreens. So it
>> doesn't matter what drivers you compile it... its OK to compile them
>> ALL
right button... which a touchscreen should not. That helps
validate that its probably the simple multi-input issue that past
eGalax's have had and that it should work with standard open source
kernel drivers once thats addressed.
Hopefully, we can defeat that evil desire for the
On Thu, Oct 27, 2011 at 10:50 AM, Cedric Sodhi wrote:
> On Thu, Oct 27, 2011 at 10:31:32AM -0500, Chris Bagwell wrote:
>> On Thu, Oct 27, 2011 at 10:01 AM, Cedric Sodhi wrote:
>> >
>> > HID_MULTITOUCH=N
>> > USB_HIDDEV=Y
>> > TOUCHSCREEN_
On Thu, Oct 27, 2011 at 10:01 AM, Cedric Sodhi wrote:
> Thanks Chris for replying, I knew I could rely on you guys :)
>
> On Thu, Oct 27, 2011 at 09:07:37AM -0500, Chris Bagwell wrote:
>> On Thu, Oct 27, 2011 at 7:25 AM, Cedric Sodhi wrote:
>> > I recently bought an AS
acts to
wholes in valuator ranges. Does it ignore them during Posts? If not
then we need to compact the valuator inits and then store a valuator
index when filling in these structures.
The next part is to verify apps don't get cranky when they see either
holes in valuators defined or if som
to
which X driver gets loaded. We'd need that info to go any further.
>
> Thanks for your help, I'm stuck
Good luck.
Chris
> --
> regards, ManDay
>
> --
> The demand for IT networking prof
On Fri, Oct 21, 2011 at 1:46 AM, Peter Hutterer
wrote:
> On Thu, Oct 20, 2011 at 12:44:40PM -0700, Ping Cheng wrote:
>> On Thu, Oct 20, 2011 at 8:03 AM, Chris Bagwell wrote:
>> > On Wed, Oct 19, 2011 at 9:10 PM, Chris Bagwell
>> > wrote:
>> >> On Wed, Oct
101 - 200 of 805 matches
Mail list logo
