On Mon, Apr 21, 2014 at 4:40 PM, Benjamin Tissoires <[email protected]> wrote: > Hi Carlos, > > [Adding a few people to the conversation] > > I am working a little bit on the wacom.ko kernel driver and I can give > you some hints on the oddness around the events. > > On Mon, Apr 21, 2014 at 1:11 PM, Carlos Garnacho <[email protected]> wrote: >> Hey there!, >> >> Here's a few patches to have libinput handle events from tablets, >> these devices are basically pointer devices, with a varying range >> of extra buttons (either stylus or "pad" buttons), and extra ABS_* >> axes. These devices also often offer information about the stylus >> in use, and its BTN_TOOL_* codes. >> >> So I've gone for reusing and extending libinput_event_pointer, adding >> extra libinput_pointer_axis values, and adding an "axis_frame" event >> to mark the end of a set of simultaneous axis changes, and a "tool_update" >> event to mark tool changes (and delimit proximity). These features are >> only triggered if a new LIBINPUT_DEVICE_CAP_STYLUS capability is set. >> >> Caveats: >> >> * Many of these devices have also tactile strips or wheels, but these are >> unhandled so far... On the devices I've got available for testing, current >> kernel support seems varyingly inconsistent: >> >> - One device has 2 strips, which report on ABS_RX/RY (radial??). Min/max > > yep :( > I guess this was a bad attempt to reuse the existing definitions, and > now, you have the left strip with RX and the right with RY... > >> are 0..4096, but the reported values are 1,2,4,8,16... So effectively >> a log2 scale, or more graphically a bit shifting over a bunch of 0s, >> which is somewhat more resembling to the physical action on the strip. > > That's how the device sends the data. Unfortunately, the kernel first > implemented this that way, and the xorg driver knows how to handle it. > And now, we are stuck because the kernel can not break user-space :(
We can change the implementation if it makes sense for future. But, please keep in mind that adding new definitions to kernel takes time. >> - Another device has one wheel, reported through ABS_WHEEL. Even though >> min/max are reported as [0..1023], on interaction it goes [0..71] (funky >> range too) > > The ring strips have a logical range of 0..71. But the ABS_WHEEL is > also shared by the wheel on the airsbrush pen, which can report either > 1024 or 2048 values depending on the tablet generation. And since this > axis is shared by two different sources, only one range can be sent (I > am saying that on top of my head, I may be wrong, this seems a little > bit ugly). Airbrush wheel is always 0 to 1024. Touch ring on tablet is 0 to 71. Both are in absolute values. Maybe we can add ABS_WHEEL2 for touch ring. Then we'll at least need ABS_WHEEL3 for Cintiq 24HD since it has two touch rings.... >> We could just forward this as-is, but seems hindering enough to do anything >> useful with those unless that behavior is corrected. > > I somewhat managed to convince Wacom to clean up the kernel driver for > Wayland. > So I would say that we should implement a proper thing in Wayland, or > at least discuss all together to redefine the kernel protocol used by > those tablets. Yes, we are willing to work on a clean solution for Wayland. >> >> When supported, IMO it'd make sense to have those axes behave similar to >> scroll axes, so the axis value increments or decrements depending on the >> direction. I'm not sure if there would be cases where the absolute value >> matters here? >> > > I am sure there are. I remember an application which controlled the > transparency of a layer in the background depending on the position of > the finger on the strip. But believe me, this application used to do a > lot of things we do not commonly do in a Linux desktop. Still, we > should ask Wacom how their customers use the strips. Benjamin is right. Those are absolute values. Most Linux applications do not use those extra values. But, there are in-house applications need those values. I'll have to ask around to give you some use cases if you are interested. Ping > > Cheers, > Benjamin > > >> * One thing worth noting is that axes are currently normalized, to [-1..1] >> for stylus tilt, and [0..1] for everything else. I remember Peter's >> tablet wayland protocol proposal basically forwarded input_absinfo, this >> might not be fully compatible with that, although TBH I'm unsure >> clamping/normalization should take place so high in the stack... >> >> * No filtering/hysteresis of coords is done yet. >> >> Cheers, >> Carlos >> >> _______________________________________________ >> wayland-devel mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
