Hi Peter, On Tuesday 05 January 2010 at 07:09:26, Peter Hutterer wrote: > On Tue, Jan 05, 2010 at 11:49:41AM +1000, Peter Hutterer wrote: > > On Sat, Jan 02, 2010 at 11:52:43PM +0100, Oldřich Jedlička wrote: > > > Hi, > > > > > > I have a problem with PAD buttons (Wacom Intuos 3). When I have one PAD > > > button configured as a key (`xsetwacom --set "Wacom Intuos3 6x8 pad" > > > Button1 "key c"` - doesn't matter which one and which key is emitted), > > > the following sequence moves the cursor to [0, 0] (sometimes to a > > > different x location): > > > > > > 1. Press a key on keyboard (doesn't matter which one). > > > 2. Press a button on PAD that is mapped to some key. > > > 3. Press a button on PAD that is not mapped (pure button click). > > > > > > I've tracked the problem down to XInput. This is what `xinput test > > > -proximity 12` gives on my system (12 is the ID of the PAD device): > > > > > > <pure PAD button click> > > > proximity in > > > button press 3 a[0]=2816 a[1]=20449 a[2]=0 a[3]=0 a[4]=0 a[5]=0 > > > button release 3 a[0]=2816 a[1]=20449 a[2]=0 a[3]=0 a[4]=0 a[5]=0 > > > proximity out > > > <now I pressed the key on keyboard> > > > <mapped PAD button click> > > > proximity in > > > key press 50 > > > key release 50 > > > proximity out > > > <pure PAD button click> > > > proximity in > > > button press 3 a[0]=0 a[1]=0 a[2]=0 a[3]=0 a[4]=0 a[5]=0 > > > button release 3 a[0]=0 a[1]=0 a[2]=0 a[3]=0 a[4]=0 a[5]=0 > > > proximity out > > > > > > The position is now a[0]=0 and a[1]=0. I don't know where the problem > > > could be, but I think it is not in Wacom driver (I've added logging to > > > event posting and the calls have the same arguments). I would like to > > > at least verify that I'm not the only one having the same problem. > > > > > > Can anyone reproduce the problem? Can anyone point me where to look > > > next (also source code)? > > > > this is an X server bug, I can reproduce the same thing with my keyboard > > at home. I should be able to look into this arvo. > > See the thread on xorg-devel for a patch. > http://lists.freedesktop.org/archives/xorg-devel/2010-January/004617.html
I've applied the second version of the patch. The mouse movement to [0, 0] has gone, but I still see the mouse button click "freeze". It now happens without former step 2: 1. Press a key on normal keyboard 2. Double-click pad key 2 (emits twice button number 2). When I do this in KDE's Konsole, the right-click menu is opened and mouse input "freezes": 1. The pen movement and ordinary mouse (Logitech) movement is OK. 2. The hover isn't seen by any application (even by the menu itself). 3. Any click (pen/mouse/pad) isn't delivered. Looks like the application grabbed mouse input (for some reason), but doesn't know what to do. To come out from this situation I have to press Escape. Huge thanks for your effort and help! Should we move to xorg-devel list? I can register there (hopefully). Cheers, Oldřich. > > Cheers, > Peter > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
