Just a remark on your use of the wsmouse interface (which isn't well
known and documented yet): wsmouse_set is a function for uncommon
cases. To report a pair of absolute coordinates use wsmouse_position,
that is, instead of
wsmouse_set(ms->sc_wsmousedev, WSMOUSE_ABS_X, x, 0);
wsmouse_set(ms->sc_wsmousedev, WSMOUSE_ABS_Y, y, 0);
you should use
wsmouse_position(ms->sc_wsmousedev, x, y);
Likewise, for reporting the button state there is
wsmouse_buttons(ms->sc_wsmousedev, buttons);
There is no need for the WSMOUSE_INPUT macro here.
On 09/05/2016 09:04 PM, Frank Groeneveld wrote:
> On Sun, Sep 04, 2016 at 02:25:06PM +0200, Martin Pieuchot wrote:
>>> - One bug still left: when the device is attached after X has started,
>>> it seems the scaling is done wrongly. I had this problem with the
>>> hacked ums driver as well. Most of the time it is fixed by switching
>>> between console and X.
>
> Correction: the problem can only be fixed by making sure the device is
> plugged in before starting X. After suspend a restart of X is needed to
> make scaling work again.
>
>>
>> This is a common problem for drivers needing calibration. Does the X driver
>> opens your device through /dev/wsmouseN or does it uses the mux?
>
> I think that's weird for this device tough: input is always report from
> zero till the maximum values in the driver. No matter how or when you
> attach it.
> I'm not sure how the X driver opens the device. I've based it off ums(4)
> mostly, so it will probably be the same as ums(4) does.
>
>>> - Documentation is still absent, I'll gladly write it when you guys
>>> apporve of the code I wrote.
>>
>> I'll be happy to do so, could you provide a man page for this driver?
>
> Attached a new diff with documentation.
>
>>> What do you guys think? Any comments or suggestions? Any ideas on how to
>>> attach to all three uhidevs?
>>
>> Yes, you have to match the device id. uhidev(4) attaches to the 3 first
>> interfaces of your first configuration. And you want a single piece of code
>> driving all these interfaces. Do you have some documentation for the device
>> you're hacking on? Do you know what you can do with these interfaces? It's
>> important to know otherwise you
>> might spend as much work refactoring the driver to extend it than you
>> spent in the beginning.
>
> Unfortunately I couldn't find any documentation except for the Linux
> device driver implementation (but it supports all kinds of Wacom
> tablets, so it isn't exactly readable).
> I've written this driver by using the broken device descriptor
> and reverse-engeneering with commands such as:
>
> cat /dev/uhid6 | hexdump -e '9/1 "%02x " "\n"'
>
> And just moving the pen and seeing which bytes change.
>
> It seems only the first uhidev device actually reports inputs. The last
> uhidev device seems to have the most correct descriptor, but never
> reports any data. My guess is that it's there for Windows users without
> the driver: they can recognize the tablet as a reported generic mouse.
>
> As far as I can understand the Linux driver, they only use the data from
> the reportid that my driver uses. For completeness I've attached lsusb
> output from a Linux computer as well.
>
> Frank
>
