On 26/02/18 11:13, Tomasz Kramkowski wrote:
On 2018-02-20 20:33, Mark Morgan Lloyd wrote:
He's also got an 0x00fd (EX-G M-XT4DR) which is the left-handed
equivalent of 0x00fc, we'd very much appreciate it if somebody could
add that ID to hid-ids.h, hid-elecom.c and hid-quirks.c.
I was made aware of this mouse only recently as well. I had plans to
submit a patch for it soon.
-- SNIP --
$ sudo lsusb -vd 056e:00fd
[sudo] password for markMLl:
Bus 001 Device 064: ID 056e:00fd Elecom Co., Ltd
-- SNIP --
This information seems correct and matches the data I recently
collected on reddit[1].
Please let me know if there's additional information I can provide
to help with this, and again I apologise for not providing a
correctly-formatted patch. Knowing the user's fondness for gadgets,
he'd not be averse to buying additional models for testing if he
spots any affordable.
The only thing I would like to ask is for help testing the patch when
I submit it since I do not own an M-XT4DRBK. I'll CC you on the patch
so that you're made aware of it when it's posted. If you're unsure of
what that would involve then don't worry, I have also found another
person willing to test this mouse.
I've merged the patch into a 4.14 kernel running on a Raspberry Pi
(which the user uses to drive a big display) here and added 0x00fd and
he reports himself happy. We should be able to test other mods, provided
that they aren't in some way incompatible with the not-quite-standard
RPi kernel. He's very resistant to the idea of surrendering a mouse so I
can test it here.
On list, cc not necessary.
The only thing I wanted to do before submitting a patch was to have a
look at how the ELECOM PID defines are named. As of this moment the
code has managed to skirt around the problem of having two mice of the
same series with incorrect button counts and different PIDs, but this
might not always be the case. However, there are also two models from
the same series of mice (DEFT) which share PIDs. So I was still trying
to work out how to deal with that in hid-ids.h but I think I'll post a
patch with what I think would be the best solution and then see what
Jiri or Benjamin say about it.
[1]: https://www.reddit.com/r/Trackballs/comments/7vqraz/
Looks pretty good to me but I'll run it past my colleague in case
there's anything else he's spotted. I've had to do an unpleasant amount
of LARTing to get him to appreciate the distinction between strings
reported by dmesg originating from the mouse and #defines in the kernel.
On a very slight tangent, over the last couple of weeks I've been
hacking together a GUI to reconfigure a Logitech G600 mouse on Linux,
which uses the hidraw interface. Using debugging built into this I've
taken a very brief look at one of the Elecoms and can see that it has
slight exposure as an hidraw device, but at the moment the only way of
setting it up for arbitrary Linux apps appears to be to use evdev/uevent
or X11 hacks.
(P.S. Apologies for any bizarre formatting in this message, web based
email clients are not my favourite.)
Formatting looked good here. I'm afraid that despite building kernels
and applying occasional patches etc. since the days when Yggdrassil LGX
was considered a novel innovation C is not my favourite, so please treat
any non-trivial contribution from me with caution :-)
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
