On Mon, Jul 18, 2011 at 2:55 PM, Roald Frederickx <[email protected]> wrote: > Ok, I think I got it to work. > > I've currently hardcoded the vendor and product ID to the values for a > USB tablet. This made it switch into protocol 5 mode. > > The jumping of the cursor was due to the fact that I also reset the > tool id (which gets sent by the ABS_MISC event). The following code in > wcmUSB.c thus caused the proximity to get set when it shouldn't have > been set: > > 1048 case ABS_MISC: > 1049 ds->proximity = (event->value != 0); > > Not resetting the tool id in my code fixed the behaviour. > > Now, when both a stylus and mouse are in proximity, moving the stylus > makes the mouse pointer move accordingly. Moving the mouse makes the > mouse pointer quickly jump in the corresponding relative direction > (when a mouse packet is received), after which it immediately gets > "pulled back" to the position of the stylus (when a stylus packet is > received). I assume that this is the behaviour we expect, given that > the X server isn't quite aware of the concept of multiple > 'independent' input devices.
Yep, thats expected behaviour. For testing purposes, you can switch your stylus tool to relative mode with "xinput set-mode stylus_name RELATIVE". Then the absolute-ness of the stylus won't hide mouse movement and you can look for unwanted jumps that need debugging. To be honest, I'm not really sure how useful the 2 channel feature of protocol 5 devices is. But since it is there, something has to be done to deal with it. The protocol 5 route your doing right now is at least well debugged on USB/xf86-input-wacom versions. The other easy route is probably similar to what you did at first and to convert it to a generic protocol and ignore one of the two channels (preferably ignore mouse over stylus). > > > Lastly, I noticed that the xf86-intput-wacom doesn't seem to check the > reported min and max values for the x and y absolute tilt axes. I > originally sent a 'centered' value where 0 means vertical and 'min x > tilt' (= -64) means 'horizontal to the left', and 'max x tilt' (= +63) > means 'horizontal to the right'. > The minimum tilt value seems to be hardcoded to 0 and the maximum tilt > value to 128. I fixed the behaviour of my driver by sending a value > from 0 to 127 instead of -64 to 63. > Is this hardcoded behaviour intentional? Isn't it better and safer to > look at the actual reported min/max tilt values (and have the > hardcoded values as a fall back for when we can't read the reporded > min/max values, or when they don't make sense)? > I could try to write a patch to change this behaviour, if that is desirable. I don't know this area of code well but if its not looking at min/max then it probably should. I've seen a few of these updated in last year or so as something broke or someone was working on new drivers like you are. I'm sure patches to xf86-input-wacom in this area would be most welcome. Chris > > > Roald > ------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
