Sony Vaio Duo 11: getting middle mouse button to work

[Benjamin Tissoires]

Hi Mattia,

I'd try with the input subsystem and the synaptics_usb driver first but
it's just a wild guess. Your kernel log should give you more hints about
which driver is bound to the device and the sysfs tree under
/sys/class/input/event*/device/* has all the capabilities and
identifiers.

modprobe synaptics_usb
cd /sys/bus/usb/drivers/usbhid
echo -n "1-1.3:1.0" > unbind
#now the mouse is without driver, does not move, and
#/sys/class/input/event2/device/device is without driver
cd /sys/bus/usb/drivers/synaptics_usb
echo -n "1-1.3:1.0" > bind
#error: no such device, mouse does not work, nothing in dmesg
cd /sys/bus/usb/drivers/usbhid
echo -n "1-1.3:1.0" > bind
#mouse works again without middle button

Hi Stephan,

in this case, you definitively want to talk to HID (and input) folks.
Adding Jiri, the HID maintainer in the discussion.

Your mouse does not seem to be handled properly by the hid subsystem
and needs quirks, or fix.

Can you send us some hid-recorder[1] traces of your device? We should
then be able to check what's wrong and hopefully fix the problem.

Cheers,
Benjamin

[1] http://bentiss.github.io/hid-replay-docs/
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Stephan Mueller]

Am Mittwoch, 29. Januar 2014, 09:53:03 schrieb Benjamin Tissoires:

Hi Benjamin,

Post by Benjamin Tissoires

Hi Mattia,

I'd try with the input subsystem and the synaptics_usb driver first
but it's just a wild guess. Your kernel log should give you more
hints about which driver is bound to the device and the sysfs tree
under
/sys/class/input/event*/device/* has all the capabilities and
identifiers.

modprobe synaptics_usb
cd /sys/bus/usb/drivers/usbhid
echo -n "1-1.3:1.0" > unbind
#now the mouse is without driver, does not move, and
#/sys/class/input/event2/device/device is without driver
cd /sys/bus/usb/drivers/synaptics_usb
echo -n "1-1.3:1.0" > bind
#error: no such device, mouse does not work, nothing in dmesg
cd /sys/bus/usb/drivers/usbhid
echo -n "1-1.3:1.0" > bind
#mouse works again without middle button

Hi Stephan,
in this case, you definitively want to talk to HID (and input) folks.
Adding Jiri, the HID maintainer in the discussion.
Your mouse does not seem to be handled properly by the hid subsystem
and needs quirks, or fix.
Can you send us some hid-recorder[1] traces of your device? We should
then be able to check what's wrong and hopefully fix the problem.

Thanks a lot for the helping hand. I will try your suggestion tonight
and report back.

But please allow me to point out that I have doubts that HID or input is
at fault, because when sniffing on the USB bus with usbmon, I do *not*
see any information transported when pressing the middle button.
Therefore, I would suspect it is rather the base USB driver that somehow
needs a quirk to access the mouse properly.

Thanks a lot
Stephan

[Benjamin Tissoires]

Post by Stephan Mueller
Hi Benjamin,

Post by Benjamin Tissoires

Hi Mattia,

I'd try with the input subsystem and the synaptics_usb driver first
but it's just a wild guess. Your kernel log should give you more
hints about which driver is bound to the device and the sysfs tree
under
/sys/class/input/event*/device/* has all the capabilities and
identifiers.

modprobe synaptics_usb
cd /sys/bus/usb/drivers/usbhid
echo -n "1-1.3:1.0" > unbind
#now the mouse is without driver, does not move, and
#/sys/class/input/event2/device/device is without driver
cd /sys/bus/usb/drivers/synaptics_usb
echo -n "1-1.3:1.0" > bind
#error: no such device, mouse does not work, nothing in dmesg
cd /sys/bus/usb/drivers/usbhid
echo -n "1-1.3:1.0" > bind
#mouse works again without middle button

Hi Stephan,
in this case, you definitively want to talk to HID (and input) folks.
Adding Jiri, the HID maintainer in the discussion.
Your mouse does not seem to be handled properly by the hid subsystem
and needs quirks, or fix.
Can you send us some hid-recorder[1] traces of your device? We should
then be able to check what's wrong and hopefully fix the problem.

Thanks a lot for the helping hand. I will try your suggestion tonight
and report back.
But please allow me to point out that I have doubts that HID or input is
at fault, because when sniffing on the USB bus with usbmon, I do *not*
see any information transported when pressing the middle button.
Therefore, I would suspect it is rather the base USB driver that somehow
needs a quirk to access the mouse properly.

Oh, then in this case it may be that your device needs to be put in a
special mode, and the report descriptors will show us some hints on
how to do it (maybe).
I strongly doubt that USB is in fault here. I can not see any reasons
why the USB or underlying driver would select which packets are
transmitted.

What you can also do is setup a windows virtual machine, assign the
usb device to it, and sniff through usbmon or wireshark what packets
are emitted from/to the mouse. Then, we will duplicate this behavior
in the hid driver, and you would be good to go. Still, having the
reports descriptors (which are provided by hid-recorder, or in
/sys/kernel/debug/hid/DEVICE/rdesc, or in lsusb -vv when the usbhid
driver is not bound) would help us to understand the mouse firmware.

Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Stephan Mueller]

Am Mittwoch, 29. Januar 2014, 10:07:40 schrieb Benjamin Tissoires:

Hi Benjamin,

Post by Benjamin Tissoires

Post by Stephan Mueller
Hi Benjamin,

Post by Benjamin Tissoires

Hi Mattia,

I'd try with the input subsystem and the synaptics_usb driver first
but it's just a wild guess. Your kernel log should give you more
hints about which driver is bound to the device and the sysfs tree
under
/sys/class/input/event*/device/* has all the capabilities and
identifiers.

modprobe synaptics_usb
cd /sys/bus/usb/drivers/usbhid
echo -n "1-1.3:1.0" > unbind
#now the mouse is without driver, does not move, and
#/sys/class/input/event2/device/device is without driver
cd /sys/bus/usb/drivers/synaptics_usb
echo -n "1-1.3:1.0" > bind
#error: no such device, mouse does not work, nothing in dmesg
cd /sys/bus/usb/drivers/usbhid
echo -n "1-1.3:1.0" > bind
#mouse works again without middle button

Hi Stephan,
in this case, you definitively want to talk to HID (and input) folks.
Adding Jiri, the HID maintainer in the discussion.
Your mouse does not seem to be handled properly by the hid subsystem
and needs quirks, or fix.
Can you send us some hid-recorder[1] traces of your device? We should
then be able to check what's wrong and hopefully fix the problem.

Thanks a lot for the helping hand. I will try your suggestion tonight
and report back.
But please allow me to point out that I have doubts that HID or input is
at fault, because when sniffing on the USB bus with usbmon, I do *not*
see any information transported when pressing the middle button.
Therefore, I would suspect it is rather the base USB driver that somehow
needs a quirk to access the mouse properly.

Oh, then in this case it may be that your device needs to be put in a
special mode, and the report descriptors will show us some hints on
how to do it (maybe).
I strongly doubt that USB is in fault here. I can not see any reasons
why the USB or underlying driver would select which packets are
transmitted.
What you can also do is setup a windows virtual machine, assign the
usb device to it, and sniff through usbmon or wireshark what packets
are emitted from/to the mouse. Then, we will duplicate this behavior
in the hid driver, and you would be good to go. Still, having the
reports descriptors (which are provided by hid-recorder, or in
/sys/kernel/debug/hid/DEVICE/rdesc, or in lsusb -vv when the usbhid
driver is not bound) would help us to understand the mouse firmware.
Cheers,
Benjamin

The device is 26E1:C1A0; when doing a cat
/sys/kernel/debug/hid/0003\:26E1\:C1A0.0003/events, I see the mouse movements
and the left and right mouse button, but not the middle one.

# cat /sys/kernel/debug/hid/0003\:26E1\:C1A0.0003/rdesc
05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03
81 02 95 05 81 01 05 01 15 81 25 7f 75 08 95 03 09 30 09 31 09 38 81 06 c0 c0
06 a0 ff 09 01 a1 01 85 02 09 02 a1 00 06 a1 ff 09 01 15 80 25 7f 35 00 45 ff
75 08 95 04 81 02 09 11 15 80 25 7f 35 00 45 ff 75 08 95 04 91 02 c0 c0

INPUT(1)[INPUT]
Field(0)
Physical(GenericDesktop.Pointer)
Application(GenericDesktop.Mouse)
Usage(3)
Button.0001
Button.0002
Button.0003
Logical Minimum(0)
Logical Maximum(1)
Report Size(1)
Report Count(3)
Report Offset(0)
Flags( Variable Absolute )
Field(1)
Physical(GenericDesktop.Pointer)
Application(GenericDesktop.Mouse)
Usage(3)
GenericDesktop.X
GenericDesktop.Y
GenericDesktop.Wheel
Logical Minimum(-127)
Logical Maximum(127)
Report Size(8)
Report Count(3)
Report Offset(8)
Flags( Variable Relative )
INPUT(2)[INPUT]
Field(0)
Physical(ffa0.0002)
Application(ffa0.0001)
Usage(4)
ffa1.0001
ffa1.0001
ffa1.0001
ffa1.0001
Logical Minimum(-128)
Logical Maximum(127)
Physical Minimum(0)
Physical Maximum(255)
Report Size(8)
Report Count(4)
Report Offset(0)
Flags( Variable Absolute )
OUTPUT(2)[OUTPUT]
Field(0)
Physical(ffa0.0002)
Application(ffa0.0001)
Usage(4)
ffa1.0011
ffa1.0011
ffa1.0011
ffa1.0011
Logical Minimum(-128)
Logical Maximum(127)
Physical Minimum(0)
Physical Maximum(255)
Report Size(8)
Report Count(4)
Report Offset(0)
Flags( Variable Absolute )

Button.0001 ---> Key.LeftBtn
Button.0002 ---> Key.RightBtn
Button.0003 ---> Key.MiddleBtn
GenericDesktop.X ---> Relative.X
GenericDesktop.Y ---> Relative.Y
GenericDesktop.Wheel ---> Relative.Wheel
ffa1.0001 ---> Absolute.Misc
ffa1.0001 ---> Absolute.?
ffa1.0001 ---> Absolute.?
ffa1.0001 ---> Absolute.?
ffa1.0011 ---> Sync.Report
ffa1.0011 ---> Sync.Report
ffa1.0011 ---> Sync.Report
ffa1.0011 ---> Sync.Report

Here is the hid-recorder output -- the mouse clicks are at the bottom. The
middle button did not generate anything:

hid-recorder /dev/hidraw0
R: 102 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01
95 03 81 02 95 05 81 01 05 01 15 81 25 7f 75 08 95 03 09 30 09 31 09 38 81 06
c0 c0 06 a0 ff 09 01 a1 01 85 02 09 02 a1 00 06 a1 ff 09 01 15 80 25 7f 35 00
45 ff 75 08 95 04 81 02 09 11 15 80 25 7f 35 00 45 ff 75 08 95 04 91 02 c0 c0
N: Crucialtek co.,LTD Optical Track Pad
P: usb-0000:00:1a.0-1.3/input0
I: 3 26e1 c1a0
E: 0.000000 5 01 00 00 01 00
E: 0.007998 5 01 00 00 01 00
E: 0.031999 5 01 00 01 00 00
E: 0.160003 5 01 00 01 fe 00
E: 0.167999 5 01 00 01 ff 00
E: 0.175997 5 01 00 01 fe 00
E: 0.191999 5 01 00 01 fe 00
E: 0.199948 5 01 00 01 fd 00
E: 0.215935 5 01 00 01 fe 00
E: 0.223858 5 01 00 01 fe 00
E: 0.231940 5 01 00 00 ff 00
E: 0.247945 5 01 00 00 ff 00
E: 0.295953 5 01 00 00 ff 00
E: 0.319953 5 01 00 01 fe 00
E: 0.335936 5 01 00 02 fe 00
E: 0.343944 5 01 00 01 fe 00
E: 0.359938 5 01 00 01 ff 00
E: 0.383963 5 01 00 ff 00 00
E: 2.407955 5 01 02 00 00 00
E: 2.623954 5 01 00 00 00 00
E: 5.024015 5 01 01 00 00 00
E: 5.320041 5 01 00 00 00 00


Ciao
Stephan

[Benjamin Tissoires]

Hi Stephan,

thanks for the traces.
Well, the device definitively presents an Output and an Input report
on the report ID 2. That means that the windows driver can send and
read configuration to the trackpoint through this report.

I think our best chance here is to capture the initialization protocol
from a Windows virtual machine, and then mimic the behavior under
Linux.

Cheers,
Benjamin

Post by Stephan Mueller
Hi Benjamin,

Post by Benjamin Tissoires

Post by Stephan Mueller
Hi Benjamin,

Post by Benjamin Tissoires

Hi Mattia,

I'd try with the input subsystem and the synaptics_usb driver first
but it's just a wild guess. Your kernel log should give you more
hints about which driver is bound to the device and the sysfs tree
under
/sys/class/input/event*/device/* has all the capabilities and
identifiers.

modprobe synaptics_usb
cd /sys/bus/usb/drivers/usbhid
echo -n "1-1.3:1.0" > unbind
#now the mouse is without driver, does not move, and
#/sys/class/input/event2/device/device is without driver
cd /sys/bus/usb/drivers/synaptics_usb
echo -n "1-1.3:1.0" > bind
#error: no such device, mouse does not work, nothing in dmesg
cd /sys/bus/usb/drivers/usbhid
echo -n "1-1.3:1.0" > bind
#mouse works again without middle button

Hi Stephan,
in this case, you definitively want to talk to HID (and input) folks.
Adding Jiri, the HID maintainer in the discussion.
Your mouse does not seem to be handled properly by the hid subsystem
and needs quirks, or fix.
Can you send us some hid-recorder[1] traces of your device? We should
then be able to check what's wrong and hopefully fix the problem.

Thanks a lot for the helping hand. I will try your suggestion tonight
and report back.
But please allow me to point out that I have doubts that HID or input is
at fault, because when sniffing on the USB bus with usbmon, I do *not*
see any information transported when pressing the middle button.
Therefore, I would suspect it is rather the base USB driver that somehow
needs a quirk to access the mouse properly.

Oh, then in this case it may be that your device needs to be put in a
special mode, and the report descriptors will show us some hints on
how to do it (maybe).
I strongly doubt that USB is in fault here. I can not see any reasons
why the USB or underlying driver would select which packets are
transmitted.
What you can also do is setup a windows virtual machine, assign the
usb device to it, and sniff through usbmon or wireshark what packets
are emitted from/to the mouse. Then, we will duplicate this behavior
in the hid driver, and you would be good to go. Still, having the
reports descriptors (which are provided by hid-recorder, or in
/sys/kernel/debug/hid/DEVICE/rdesc, or in lsusb -vv when the usbhid
driver is not bound) would help us to understand the mouse firmware.
Cheers,
Benjamin

The device is 26E1:C1A0; when doing a cat
/sys/kernel/debug/hid/0003\:26E1\:C1A0.0003/events, I see the mouse movements
and the left and right mouse button, but not the middle one.
# cat /sys/kernel/debug/hid/0003\:26E1\:C1A0.0003/rdesc
05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03
81 02 95 05 81 01 05 01 15 81 25 7f 75 08 95 03 09 30 09 31 09 38 81 06 c0 c0
06 a0 ff 09 01 a1 01 85 02 09 02 a1 00 06 a1 ff 09 01 15 80 25 7f 35 00 45 ff
75 08 95 04 81 02 09 11 15 80 25 7f 35 00 45 ff 75 08 95 04 91 02 c0 c0
INPUT(1)[INPUT]
Field(0)
Physical(GenericDesktop.Pointer)
Application(GenericDesktop.Mouse)
Usage(3)
Button.0001
Button.0002
Button.0003
Logical Minimum(0)
Logical Maximum(1)
Report Size(1)
Report Count(3)
Report Offset(0)
Flags( Variable Absolute )
Field(1)
Physical(GenericDesktop.Pointer)
Application(GenericDesktop.Mouse)
Usage(3)
GenericDesktop.X
GenericDesktop.Y
GenericDesktop.Wheel
Logical Minimum(-127)
Logical Maximum(127)
Report Size(8)
Report Count(3)
Report Offset(8)
Flags( Variable Relative )
INPUT(2)[INPUT]
Field(0)
Physical(ffa0.0002)
Application(ffa0.0001)
Usage(4)
ffa1.0001
ffa1.0001
ffa1.0001
ffa1.0001
Logical Minimum(-128)
Logical Maximum(127)
Physical Minimum(0)
Physical Maximum(255)
Report Size(8)
Report Count(4)
Report Offset(0)
Flags( Variable Absolute )
OUTPUT(2)[OUTPUT]
Field(0)
Physical(ffa0.0002)
Application(ffa0.0001)
Usage(4)
ffa1.0011
ffa1.0011
ffa1.0011
ffa1.0011
Logical Minimum(-128)
Logical Maximum(127)
Physical Minimum(0)
Physical Maximum(255)
Report Size(8)
Report Count(4)
Report Offset(0)
Flags( Variable Absolute )
Button.0001 ---> Key.LeftBtn
Button.0002 ---> Key.RightBtn
Button.0003 ---> Key.MiddleBtn
GenericDesktop.X ---> Relative.X
GenericDesktop.Y ---> Relative.Y
GenericDesktop.Wheel ---> Relative.Wheel
ffa1.0001 ---> Absolute.Misc
ffa1.0001 ---> Absolute.?
ffa1.0001 ---> Absolute.?
ffa1.0001 ---> Absolute.?
ffa1.0011 ---> Sync.Report
ffa1.0011 ---> Sync.Report
ffa1.0011 ---> Sync.Report
ffa1.0011 ---> Sync.Report
Here is the hid-recorder output -- the mouse clicks are at the bottom. The
hid-recorder /dev/hidraw0
R: 102 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01
95 03 81 02 95 05 81 01 05 01 15 81 25 7f 75 08 95 03 09 30 09 31 09 38 81 06
c0 c0 06 a0 ff 09 01 a1 01 85 02 09 02 a1 00 06 a1 ff 09 01 15 80 25 7f 35 00
45 ff 75 08 95 04 81 02 09 11 15 80 25 7f 35 00 45 ff 75 08 95 04 91 02 c0 c0
N: Crucialtek co.,LTD Optical Track Pad
P: usb-0000:00:1a.0-1.3/input0
I: 3 26e1 c1a0
E: 0.000000 5 01 00 00 01 00
E: 0.007998 5 01 00 00 01 00
E: 0.031999 5 01 00 01 00 00
E: 0.160003 5 01 00 01 fe 00
E: 0.167999 5 01 00 01 ff 00
E: 0.175997 5 01 00 01 fe 00
E: 0.191999 5 01 00 01 fe 00
E: 0.199948 5 01 00 01 fd 00
E: 0.215935 5 01 00 01 fe 00
E: 0.223858 5 01 00 01 fe 00
E: 0.231940 5 01 00 00 ff 00
E: 0.247945 5 01 00 00 ff 00
E: 0.295953 5 01 00 00 ff 00
E: 0.319953 5 01 00 01 fe 00
E: 0.335936 5 01 00 02 fe 00
E: 0.343944 5 01 00 01 fe 00
E: 0.359938 5 01 00 01 ff 00
E: 0.383963 5 01 00 ff 00 00
E: 2.407955 5 01 02 00 00 00
E: 2.623954 5 01 00 00 00 00
E: 5.024015 5 01 01 00 00 00
E: 5.320041 5 01 00 00 00 00
Ciao
Stephan
--
| Cui bono? |

[Stephan Mueller]

Am Donnerstag, 30. Januar 2014, 16:44:02 schrieb Benjamin Tissoires:

Hi Benjamin,

Post by Benjamin Tissoires
Hi Stephan,
thanks for the traces.
Well, the device definitively presents an Output and an Input report
on the report ID 2. That means that the windows driver can send and
read configuration to the trackpoint through this report.
I think our best chance here is to capture the initialization protocol
from a Windows virtual machine, and then mimic the behavior under
Linux.

Thanks.

Can you please help me how to do that? I install Windows in a KVM with
the mouse device as a USB-passthrough device -- shall I detach the Linux
USB driver?

Now, shall I use hid-recorder on that device or rather usbmon while
Windows is booting?

Thanks
Stephan

[Benjamin Tissoires]

Post by Stephan Mueller
Hi Benjamin,

Post by Benjamin Tissoires
Hi Stephan,
thanks for the traces.
Well, the device definitively presents an Output and an Input report
on the report ID 2. That means that the windows driver can send and
read configuration to the trackpoint through this report.
I think our best chance here is to capture the initialization protocol
from a Windows virtual machine, and then mimic the behavior under
Linux.

Thanks.
Can you please help me how to do that? I install Windows in a KVM with
the mouse device as a USB-passthrough device -- shall I detach the Linux
USB driver?

No, you don't have to detach the Linux USB driver (it's done for you
by KVM IIRC).

Post by Stephan Mueller
Now, shall I use hid-recorder on that device or rather usbmon while
Windows is booting?

usbmon is the tool you need. hid-recorder will not work because the
hid subsystem will be disconnected as the device is used by Windows.

You can even use wireshark now. It gives you a nice interface and
interpretation of the USB packets :)

Cheers,
Benjamin

[Stephan Mueller]

Am Donnerstag, 30. Januar 2014, 22:50:25 schrieb Benjamin Tissoires:

Hi Benjamin,

Post by Benjamin Tissoires

Post by Stephan Mueller
Can you please help me how to do that? I install Windows in a KVM with
the mouse device as a USB-passthrough device -- shall I detach the Linux
USB driver?

No, you don't have to detach the Linux USB driver (it's done for you
by KVM IIRC).

Correct, libvirtd is the one that detaches the driver when I start the VM.

Post by Benjamin Tissoires

Post by Stephan Mueller
Now, shall I use hid-recorder on that device or rather usbmon while
Windows is booting?

usbmon is the tool you need. hid-recorder will not work because the
hid subsystem will be disconnected as the device is used by Windows.
You can even use wireshark now. It gives you a nice interface and
interpretation of the USB packets :)

Please see attached for the USB sniffing on the USB bus with the Crucialtec
touch pad when Windows starts up and shuts down. To drive the device, Windows
uses the Crucialtec driver according to its device settings display.

The attached log contains the log information for the mouse (device 001:005)
and the USB bridge (device 001:002). I cut out the listing for the touch pad
which is also attached to that bridge.

The strange thing, however, is the following: the mouse works in Windows when
I do not sniff on the USB bus using usbmon. But as soon as I start sniffing,
it does not work any more.

Is that log helpful?

Ciao
Stephan

[Benjamin Tissoires]

Post by Stephan Mueller
Hi Benjamin,

Post by Benjamin Tissoires

Post by Stephan Mueller
Can you please help me how to do that? I install Windows in a KVM with
the mouse device as a USB-passthrough device -- shall I detach the Linux
USB driver?

No, you don't have to detach the Linux USB driver (it's done for you
by KVM IIRC).

Correct, libvirtd is the one that detaches the driver when I start the VM.

Post by Benjamin Tissoires

Post by Stephan Mueller
Now, shall I use hid-recorder on that device or rather usbmon while
Windows is booting?

usbmon is the tool you need. hid-recorder will not work because the
hid subsystem will be disconnected as the device is used by Windows.
You can even use wireshark now. It gives you a nice interface and
interpretation of the USB packets :)

Please see attached for the USB sniffing on the USB bus with the Crucialtec
touch pad when Windows starts up and shuts down. To drive the device, Windows
uses the Crucialtec driver according to its device settings display.
The attached log contains the log information for the mouse (device 001:005)
and the USB bridge (device 001:002). I cut out the listing for the touch pad
which is also attached to that bridge.
The strange thing, however, is the following: the mouse works in Windows when
I do not sniff on the USB bus using usbmon. But as soon as I start sniffing,
it does not work any more.
Is that log helpful?

Not really :(
I would have expected to see something like that:
XXXXXXXXXXXXXXXX XXXXXXXXXX S Co:1:XXX:0 s 21 09 0202 0002 0004 4 = XXXXXXXX
XXXXXXXXXXXXXXXX XXXXXXXXXX C Co:1:XXX:0 0 4 >

(SET_REPORT on the report ID 02 with a data length of 4)

The capture seems to confuse the windows driver and it is not
initialized correctly.

Long shot: maybe if you start the capture before attaching the device
to the Windows VM (or launching it) it will be in a better shape.

I would say that as long as the device do not work under the VM with
the capture, we are really screwed.

Cheers,
Benjamin

[Stephan Mueller]

Am Freitag, 31. Januar 2014, 05:31:53 schrieb Stephan Mueller:

Hi,

The middle mouse button works in Linux, but very differently than you may
expect: I still do not see any events when only pressing the middle mouse
button.

Out of luck, I pressed the middle button and moved the mouse. And there you
see, the mouse returns button 4 and 5.That means that pressing the middle
mouse button seems to morph the mouse into an implicit wheel.

Thus, when I press the middle button and move my mouse, X11 applies the zoom
in and zoom out operations.

I think I can remap the button 4 / 5 to button 2 for the middle mouse. But
then, the button 2 would only work when hitting the middle mouse button and
move the mouse pointer.

This is not what I want. Do you see any other way of turning the middle mouse
button into a real useful button?

Ciao
Stephan