Hi,
I'm hijacking on that very old conversation you had here:
http://linux-input.vger.kernel.narkive.com/78cpvzuC/sony-vaio-duo-11-getting-middle-mouse-button-to-work
I took Wireshark dumps of the USB traffic when the Windows
configuration tools switches between "use middle button for scroll"
and "send middle button as button 2" (they're not named like this, but
that's what they do).
I also have a second dump of enabling and disabling "touch trackpoint
to send mouse button 1". I can see that there is a clear key/value
mapping. I don't know anything about HID or USB (or Wireshark), but it
seems like the *device* is sending different values back to the *host*
when these settings are changed.
Anyway, is there a way I can "decrypt" this and write either a
usespace helper or write or amend a kernel driver to be able to switch
those two options in Linux? Or did I miss something in my capture?
Those were taken with Wireshark 2.0.
Thanks,
Stefan
Hi Stefan,
On Aug 11 2016 or thereabouts, Stefan Seidel wrote:
Hi,
I'm hijacking on that very old conversation you had here:
http://linux-input.vger.kernel.narkive.com/78cpvzuC/sony-vaio-duo-11-getting-middle-mouse-button-to-work
I took Wireshark dumps of the USB traffic when the Windows configuration
tools switches between "use middle button for scroll" and "send middle
button as button 2" (they're not named like this, but that's what they do).
I also have a second dump of enabling and disabling "touch trackpoint to
send mouse button 1". I can see that there is a clear key/value mapping. I
don't know anything about HID or USB (or Wireshark), but it seems like the
*device* is sending different values back to the *host* when these settings
are changed.
Anyway, is there a way I can "decrypt" this and write either a usespace
helper or write or amend a kernel driver to be able to switch those two
options in Linux? Or did I miss something in my capture? Those were taken
with Wireshark 2.0.
If you can manage to get the beginning of the enumeration of the USB
device, Wireshark will decrypt most of the informations for you (if the
commands are SET_FEATURE or GET_FEATURE, etc...).
It's unclear to me which settings triggers the change, but it's clear
that when the host does a Set_Report Request on the Output 2:
- bmRequestType: 0x21 -> Set_Report Request
- bRequest: 9 -> SET_REPORT
- wValue: 0x0202 -> Report Type Output, Report ID 02
- wIndex: 0 -> Interface 0
- wLength: 5 -> Report Length
- Data: ???
(see http://www.usb.org/developers/hidpage/HID1_11.pdf section 7.2.2 to
decrypt the raw USB events)
The answer is different in the first case and 7 seconds after (I assume
you toggled the setting there) -> frame 16 and 33 in the first log.
I'd say the first log would be:
- 1. -> SET_IDLE (you can ignore it)
- 3. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 4. -> 02 04 02 00 00
- 5. -> SET CONFIGURATION Status (ignore this as well I think)
- 6. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 7. -> 02 06 00 00 00
- 9. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 10. -> 02 05 01 00 00
- 12. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 13. -> 02 02 01 00 00
- 16. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 14. -> 02 03 01 00 00
The second sequence (frames 18 to 34) provides the same output except
for the last answer 02 03 00 00 00.
The "no data" part seems weird, but there is a chance if you output a
report with 02 03 00 00 00 or 02 03 01 00 00, this toggles the behavior.
I'll let you decrypt the second log :)
Anyway, once you got enough information, you can either directly work in
kernel space, in a driver, or in userspace, using hidraw.
If you start working in kernel space, start with a small hid driver and
in .probe() try accessing the device with the event sequences you got.
If you start working with hidraw, there is an example in the kernel
tree: samples/hidraw/hid-example.c.
Cheers,
Benjamin
Hi Benjamin,
thanks.
The answer is different in the first case and 7 seconds after (I assume
you toggled the setting there) -> frame 16 and 33 in the first log.
I'd say the first log would be:
- 1. -> SET_IDLE (you can ignore it)
- 3. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 4. -> 02 04 02 00 00
- 5. -> SET CONFIGURATION Status (ignore this as well I think)
- 6. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 7. -> 02 06 00 00 00
- 9. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 10. -> 02 05 01 00 00
- 12. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 13. -> 02 02 01 00 00
- 16. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 14. -> 02 03 01 00 00
The second sequence (frames 18 to 34) provides the same output except
for the last answer 02 03 00 00 00.
Yes, that was my analysis as well. Thanks for confirming this.
The "no data" part seems weird, but there is a chance if you output a
report with 02 03 00 00 00 or 02 03 01 00 00, this toggles the behavior.
Yes, I was wondering about exactly that, maybe I need to read up on
the limitations of USBPcap to find out why apparently no outgoing data
is reported. But I will try sending it as you suggest.
If you start working in kernel space, start with a small hid driver and
in .probe() try accessing the device with the event sequences you got.
If you start working with hidraw, there is an example in the kernel
tree: samples/hidraw/hid-example.c.
Thanks for these hints! I realized I already did work on HID stuff
once when I amended a userspace program for a USB FM transmitter that
registered as HID device. I will try your suggestions.
Stefan
Hi,
after a little trial an error, I found out that the hidraw interface
simplifies/abstracts a couple of things, and that the USB report
return data included the report number (02), so all that is needed to
switch between middle button = scroll and middle button = button2 is
echo -ne "\x02\x03\x00\x00\x00" | sudo tee /dev/hidraw1
and
echo -ne "\x02\x03\x01\x00\x00" | sudo tee /dev/hidraw1
Same would be
echo -ne "\x02\x06\x00\x00\x00" | sudo tee /dev/hidraw1
and
echo -ne "\x02\x06\x01\x00\x00" | sudo tee /dev/hidraw1
to toggle between tap-to-click and not. The device /dev/hidraw1 is from
dmesg | grep Crucialtek | grep hid
Thanks!!!
Stefan
On Fri 12 Aug 2016 09:41:25 PM CEST, Stefan Seidel
[off-list ref] wrote:
Hi Benjamin,
thanks.
quoted
The answer is different in the first case and 7 seconds after (I assume
you toggled the setting there) -> frame 16 and 33 in the first log.
I'd say the first log would be:
- 1. -> SET_IDLE (you can ignore it)
- 3. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 4. -> 02 04 02 00 00
- 5. -> SET CONFIGURATION Status (ignore this as well I think)
- 6. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 7. -> 02 06 00 00 00
- 9. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 10. -> 02 05 01 00 00
- 12. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 13. -> 02 02 01 00 00
- 16. -> SET_REPORT on OUTPUT 2, length 5 no data
-> answer in 14. -> 02 03 01 00 00
The second sequence (frames 18 to 34) provides the same output except
for the last answer 02 03 00 00 00.
Yes, that was my analysis as well. Thanks for confirming this.
quoted
The "no data" part seems weird, but there is a chance if you output a
report with 02 03 00 00 00 or 02 03 01 00 00, this toggles the behavior.
Yes, I was wondering about exactly that, maybe I need to read up on
the limitations of USBPcap to find out why apparently no outgoing
data is reported. But I will try sending it as you suggest.
quoted
If you start working in kernel space, start with a small hid driver and
in .probe() try accessing the device with the event sequences you got.
If you start working with hidraw, there is an example in the kernel
tree: samples/hidraw/hid-example.c.
Thanks for these hints! I realized I already did work on HID stuff
once when I amended a userspace program for a USB FM transmitter
that registered as HID device. I will try your suggestions.
Stefan