On 09/03/16 20:15, Frank Groeneveld wrote:
On Wed, Aug 10, 2016 at 03:42:34PM +0200, Martin Pieuchot wrote:
I'd ignore it as a first step, then revisit this later.
Attached a first stab at a seperate driver. Some points of interest:
- I've decided against using a custom hid descriptor, but instead define
the needed inputs in the driver. This seems more readable to me.
I agree.
- Driver attaches to one uhid, but there are three uhidev devices and
numerous uhids in this device, including a non-working uhid that ums
attaches to (ums0 in the attached dmesg output).
See below.
- 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.
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?
- 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?
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.
