On 08/07/16 19:30, Frank Groeneveld wrote: > I recently acquired a new Wacom drawing tablet: an Intuos Draw, which > seems to be called an Intuos S 2 internally. I couldn't get this tablet > to work in OpenBSD. One of the HID descriptors describes a mouse, so > ums(4) attaches to it, but no data is ever registered. After digging > around in the Linux driver, it appears that the actual data is reported > in a different descriptor, one that is (possibly on purpose) incorrect. > > After writing a correct device descriptor I had to work around two other > problems: > > - X & Y data is reported in big endian format. > - Mouse button 1 data is flakey, the linux driver uses pressure to work > around this. > > To get the tablet to function correctly, I chose to implement quirks for > this in hidms(4). Attached patch makes the tablet function with mouse > movement and all three stylus events (tip touch and 2 buttons) without > any needed configuration. This is enough functionality for for me, I > just use it as a mouse replacement to avoid getting RSI. > > Example dmesg output on attachment: > > uhidev0 at uhub3 port 2 configuration 1 interface 0 "Wacom Co.,Ltd. > Intuos PS" rev 2.00/1.00 addr 3 > uhidev0: iclass 3/0, 192 report ids > ums0 at uhidev0 reportid 16: 3 buttons > wsmouse1 at ums0 mux 0 > uhid0 at uhidev0 reportid 192: input=4, output=0, feature=0 > uhidev1 at uhub3 port 2 configuration 1 interface 1 "Wacom Co.,Ltd. > Intuos PS" rev 2.00/1.00 addr 3 > uhidev1: iclass 3/0, 3 report ids > uhid1 at uhidev1 reportid 2: input=63, output=0, feature=0 > uhid2 at uhidev1 reportid 3: input=63, output=0, feature=0 > uhidev2 at uhub3 port 2 configuration 1 interface 2 "Wacom Co.,Ltd. > Intuos PS" rev 2.00/1.00 addr 3 > uhidev2: iclass 3/1, 1 report id > ums1 at uhidev2 reportid 1: 5 buttons > wsmouse2 at ums1 mux 0 > > The first tattached umse is the functioning one that is added by this > patch.
Nice. > Is the attached patch acceptable? Or would it be better to write a > seperate driver, such as uwacom, that does the same as ums, except that > it doesn't call hidms_input, but implements that itself? I believe that a new driver makes more sense. Because if one wants to extend your work to fully support the drawing table it won't be able to do it in ums(4). I afraid you'll need to match the two interfaces of your device, something which is not trivial with the current framework. Newer versions of libinput include some support for various Intuos devices, you might want to look at this if you haven't done it already.
