* Sony Vaio Duo 11: getting middle mouse button to work @ 2014-01-23 16:21 Stephan Mueller 2014-01-25 3:17 ` Mattia Dongili 0 siblings, 1 reply; 17+ messages in thread From: Stephan Mueller @ 2014-01-23 16:21 UTC (permalink / raw) To: platform-driver-x86 Hi, I hope this is the right list for my question -- if not, please help me finding the right destination. I have a Sony Vaio Duo 11 where the middle mouse button does not work. The device in lsusb is listed as: Bus 001 Device 005: ID 26e1:c1a0 Greping through the kernel for device IDs I do not find a driver in the kernel that is explicitly written for that mouse. So, I expect the generic USB mouse picks this device up. The input framework knows the device as: /dev/input/event3: Crucialtek co.,LTD Optical Track Pad The problem now is that the middle mouse button does not seem to be activated at all: - xev does not record any events - playing around with debug modes of the sony_laptop does not indicate that it records any events for special keys - using usbmon to sniff the raw USB events does not show any events being communicated when pressing/releasing the middle mouse button Note, the right and left button work flawless. As I am out of ideas. Does anybody have an idea on how to identify where the problem is? Would I need to send some "enabling" events to the mouse before it activates the middle mouse button? Or is there anything in Linux that could help me debug the situation? As a side note: initially there was Windows on the box. And the middle mouse button worked on it. So, the hardware should have no problems. Thanks a lot Stephan -- | Cui bono? | ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-23 16:21 Sony Vaio Duo 11: getting middle mouse button to work Stephan Mueller @ 2014-01-25 3:17 ` Mattia Dongili 2014-01-25 4:51 ` Stephan Mueller 0 siblings, 1 reply; 17+ messages in thread From: Mattia Dongili @ 2014-01-25 3:17 UTC (permalink / raw) To: Stephan Mueller; +Cc: platform-driver-x86 On Thu, Jan 23, 2014 at 05:21:10PM +0100, Stephan Mueller wrote: ... > Bus 001 Device 005: ID 26e1:c1a0 Ciao! ... > - playing around with debug modes of the sony_laptop does not indicate that it > records any events for special keys I have never seen a vaio where touchpad buttons where dependent on the devices controlled with sony-laptop.ko. ... > As I am out of ideas. Does anybody have an idea on how to identify where the > problem is? Would I need to send some "enabling" events to the mouse before it > activates the middle mouse button? Or is there anything in Linux that could > help me debug the situation? 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. Hope this helps. -- mattia :wq! PS: Could you send me your laptop's DSDT off-list? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-25 3:17 ` Mattia Dongili @ 2014-01-25 4:51 ` Stephan Mueller 2014-01-29 14:53 ` Benjamin Tissoires 0 siblings, 1 reply; 17+ messages in thread From: Stephan Mueller @ 2014-01-25 4:51 UTC (permalink / raw) To: Mattia Dongili; +Cc: platform-driver-x86 Am Samstag, 25. Januar 2014, 12:17:13 schrieb Mattia Dongili: 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. The following did not help: 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 Ciao Stephan -- | Cui bono? | ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-25 4:51 ` Stephan Mueller @ 2014-01-29 14:53 ` Benjamin Tissoires 2014-01-29 14:59 ` Stephan Mueller 0 siblings, 1 reply; 17+ messages in thread From: Benjamin Tissoires @ 2014-01-29 14:53 UTC (permalink / raw) To: Stephan Mueller Cc: Mattia Dongili, platform-driver-x86, Jiri Kosina, linux-input On Fri, Jan 24, 2014 at 11:51 PM, Stephan Mueller <smueller@chronox.de> wrote: > Am Samstag, 25. Januar 2014, 12:17:13 schrieb Mattia Dongili: > > 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. > > The following did not help: > > 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/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-29 14:53 ` Benjamin Tissoires @ 2014-01-29 14:59 ` Stephan Mueller 2014-01-29 15:07 ` Benjamin Tissoires 0 siblings, 1 reply; 17+ messages in thread From: Stephan Mueller @ 2014-01-29 14:59 UTC (permalink / raw) To: Benjamin Tissoires Cc: Mattia Dongili, platform-driver-x86, Jiri Kosina, linux-input Am Mittwoch, 29. Januar 2014, 09:53:03 schrieb Benjamin Tissoires: Hi Benjamin, >On Fri, Jan 24, 2014 at 11:51 PM, Stephan Mueller <smueller@chronox.de> wrote: >> Am Samstag, 25. Januar 2014, 12:17:13 schrieb Mattia Dongili: >> >> 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. >> >> The following did not help: >> >> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-29 14:59 ` Stephan Mueller @ 2014-01-29 15:07 ` Benjamin Tissoires 2014-01-30 3:48 ` Stephan Mueller 0 siblings, 1 reply; 17+ messages in thread From: Benjamin Tissoires @ 2014-01-29 15:07 UTC (permalink / raw) To: Stephan Mueller Cc: Mattia Dongili, platform-driver-x86, Jiri Kosina, linux-input On Wed, Jan 29, 2014 at 9:59 AM, Stephan Mueller <smueller@chronox.de> wrote: > Am Mittwoch, 29. Januar 2014, 09:53:03 schrieb Benjamin Tissoires: > > Hi Benjamin, > >>On Fri, Jan 24, 2014 at 11:51 PM, Stephan Mueller <smueller@chronox.de> > wrote: >>> Am Samstag, 25. Januar 2014, 12:17:13 schrieb Mattia Dongili: >>> >>> 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. >>> >>> The following did not help: >>> >>> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-29 15:07 ` Benjamin Tissoires @ 2014-01-30 3:48 ` Stephan Mueller 2014-01-30 21:44 ` Benjamin Tissoires 0 siblings, 1 reply; 17+ messages in thread From: Stephan Mueller @ 2014-01-30 3:48 UTC (permalink / raw) To: Benjamin Tissoires Cc: Mattia Dongili, platform-driver-x86, Jiri Kosina, linux-input Am Mittwoch, 29. Januar 2014, 10:07:40 schrieb Benjamin Tissoires: Hi Benjamin, > On Wed, Jan 29, 2014 at 9:59 AM, Stephan Mueller <smueller@chronox.de> wrote: > > Am Mittwoch, 29. Januar 2014, 09:53:03 schrieb Benjamin Tissoires: > > > > Hi Benjamin, > > > >>On Fri, Jan 24, 2014 at 11:51 PM, Stephan Mueller <smueller@chronox.de> > >> > > wrote: > >>> Am Samstag, 25. Januar 2014, 12:17:13 schrieb Mattia Dongili: > >>> > >>> 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. > >>> > >>> The following did not help: > >>> > >>> 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 -- | Cui bono? | ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-30 3:48 ` Stephan Mueller @ 2014-01-30 21:44 ` Benjamin Tissoires 2014-01-30 22:07 ` Stephan Mueller 0 siblings, 1 reply; 17+ messages in thread From: Benjamin Tissoires @ 2014-01-30 21:44 UTC (permalink / raw) To: Stephan Mueller Cc: Mattia Dongili, platform-driver-x86, Jiri Kosina, linux-input 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 On Wed, Jan 29, 2014 at 10:48 PM, Stephan Mueller <smueller@chronox.de> wrote: > Am Mittwoch, 29. Januar 2014, 10:07:40 schrieb Benjamin Tissoires: > > Hi Benjamin, > >> On Wed, Jan 29, 2014 at 9:59 AM, Stephan Mueller <smueller@chronox.de> > wrote: >> > Am Mittwoch, 29. Januar 2014, 09:53:03 schrieb Benjamin Tissoires: >> > >> > Hi Benjamin, >> > >> >>On Fri, Jan 24, 2014 at 11:51 PM, Stephan Mueller <smueller@chronox.de> >> >> >> > wrote: >> >>> Am Samstag, 25. Januar 2014, 12:17:13 schrieb Mattia Dongili: >> >>> >> >>> 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. >> >>> >> >>> The following did not help: >> >>> >> >>> 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 > -- > | Cui bono? | ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-30 21:44 ` Benjamin Tissoires @ 2014-01-30 22:07 ` Stephan Mueller 2014-01-31 3:50 ` Benjamin Tissoires 0 siblings, 1 reply; 17+ messages in thread From: Stephan Mueller @ 2014-01-30 22:07 UTC (permalink / raw) To: Benjamin Tissoires Cc: Mattia Dongili, platform-driver-x86, Jiri Kosina, linux-input Am Donnerstag, 30. Januar 2014, 16:44:02 schrieb Benjamin Tissoires: Hi Benjamin, >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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-30 22:07 ` Stephan Mueller @ 2014-01-31 3:50 ` Benjamin Tissoires 2014-01-31 4:31 ` Stephan Mueller 0 siblings, 1 reply; 17+ messages in thread From: Benjamin Tissoires @ 2014-01-31 3:50 UTC (permalink / raw) To: Stephan Mueller Cc: Mattia Dongili, platform-driver-x86, Jiri Kosina, linux-input On Thu, Jan 30, 2014 at 5:07 PM, Stephan Mueller <smueller@chronox.de> wrote: > Am Donnerstag, 30. Januar 2014, 16:44:02 schrieb Benjamin Tissoires: > > Hi Benjamin, > >>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). > > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-31 3:50 ` Benjamin Tissoires @ 2014-01-31 4:31 ` Stephan Mueller 2014-01-31 16:20 ` Benjamin Tissoires 2014-01-31 21:02 ` Stephan Mueller 0 siblings, 2 replies; 17+ messages in thread From: Stephan Mueller @ 2014-01-31 4:31 UTC (permalink / raw) To: Benjamin Tissoires Cc: Mattia Dongili, platform-driver-x86, Jiri Kosina, linux-input [-- Attachment #1: Type: text/plain, Size: 1431 bytes --] Am Donnerstag, 30. Januar 2014, 22:50:25 schrieb Benjamin Tissoires: Hi Benjamin, > > 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. > > > 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 -- | Cui bono? | [-- Attachment #2: sony-vaio-duo-11-usbsniff.bz2 --] [-- Type: application/x-bzip, Size: 1338 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-31 4:31 ` Stephan Mueller @ 2014-01-31 16:20 ` Benjamin Tissoires 2014-01-31 21:02 ` Stephan Mueller 1 sibling, 0 replies; 17+ messages in thread From: Benjamin Tissoires @ 2014-01-31 16:20 UTC (permalink / raw) To: Stephan Mueller Cc: Mattia Dongili, platform-driver-x86, Jiri Kosina, linux-input On Thu, Jan 30, 2014 at 11:31 PM, Stephan Mueller <smueller@chronox.de> wrote: > Am Donnerstag, 30. Januar 2014, 22:50:25 schrieb Benjamin Tissoires: > > Hi Benjamin, > >> > 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. >> >> > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2014-01-31 4:31 ` Stephan Mueller 2014-01-31 16:20 ` Benjamin Tissoires @ 2014-01-31 21:02 ` Stephan Mueller 1 sibling, 0 replies; 17+ messages in thread From: Stephan Mueller @ 2014-01-31 21:02 UTC (permalink / raw) To: Benjamin Tissoires Cc: Mattia Dongili, platform-driver-x86, Jiri Kosina, linux-input 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 -- | Cui bono? | ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work @ 2016-08-11 21:27 Stefan Seidel 2016-08-12 9:29 ` Benjamin Tissoires 0 siblings, 1 reply; 17+ messages in thread From: Stefan Seidel @ 2016-08-11 21:27 UTC (permalink / raw) To: benjamin.tissoires, smueller, jkosina, linux-input [-- Attachment #1: Type: text/plain, Size: 978 bytes --] 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 [-- Attachment #2: crucialtek.pcapng --] [-- Type: application/octet-stream, Size: 2356 bytes --] [-- Attachment #3: ctek-tap-to-click.pcapng --] [-- Type: application/octet-stream, Size: 2228 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2016-08-11 21:27 Stefan Seidel @ 2016-08-12 9:29 ` Benjamin Tissoires 2016-08-12 19:41 ` Stefan Seidel 0 siblings, 1 reply; 17+ messages in thread From: Benjamin Tissoires @ 2016-08-12 9:29 UTC (permalink / raw) To: Stefan Seidel; +Cc: smueller, jkosina, linux-input 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2016-08-12 9:29 ` Benjamin Tissoires @ 2016-08-12 19:41 ` Stefan Seidel 2016-08-12 20:02 ` Stefan Seidel 0 siblings, 1 reply; 17+ messages in thread From: Stefan Seidel @ 2016-08-12 19:41 UTC (permalink / raw) To: Benjamin Tissoires; +Cc: smueller, jkosina, linux-input 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Sony Vaio Duo 11: getting middle mouse button to work 2016-08-12 19:41 ` Stefan Seidel @ 2016-08-12 20:02 ` Stefan Seidel 0 siblings, 0 replies; 17+ messages in thread From: Stefan Seidel @ 2016-08-12 20:02 UTC (permalink / raw) To: Benjamin Tissoires; +Cc: smueller, jkosina, linux-input 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 <lkml@stefanseidel.info> wrote: > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-08-12 20:02 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-01-23 16:21 Sony Vaio Duo 11: getting middle mouse button to work Stephan Mueller 2014-01-25 3:17 ` Mattia Dongili 2014-01-25 4:51 ` Stephan Mueller 2014-01-29 14:53 ` Benjamin Tissoires 2014-01-29 14:59 ` Stephan Mueller 2014-01-29 15:07 ` Benjamin Tissoires 2014-01-30 3:48 ` Stephan Mueller 2014-01-30 21:44 ` Benjamin Tissoires 2014-01-30 22:07 ` Stephan Mueller 2014-01-31 3:50 ` Benjamin Tissoires 2014-01-31 4:31 ` Stephan Mueller 2014-01-31 16:20 ` Benjamin Tissoires 2014-01-31 21:02 ` Stephan Mueller 2016-08-11 21:27 Stefan Seidel 2016-08-12 9:29 ` Benjamin Tissoires 2016-08-12 19:41 ` Stefan Seidel 2016-08-12 20:02 ` Stefan Seidel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.