From: Alan Stern <stern@rowland.harvard.edu> Date: 2011-05-02 21:06:21
On Mon, 2 May 2011, Adi J. Sieker wrote:
Attached is the usbmon trace when I plug the keyboard in.
lsusb shows the keyboard as:
Bus 002 Device 008: ID 060b:0230 Solid Year
Relevant section from /sys/kernel/debug/usb/devices
T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 8 Spd=1.5 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=060b ProdID=0230 Rev= 2.20
S: Manufacturer=KB
S: Product=USB Keyboard
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
Interestingly, the usbmon trace shows that the interrupt endpoint for
interface 1 isn't being used by usbhid. I don't know why, but it
shouldn't make much difference for your purposes since that interface
appears to be associated with the gaming interface. But maybe I'm
wrong and it is important somehow...
The other noticeable thing is that the keyboard didn't accept the
Set-Idle request for interface 1.
You said before that the keyboard worked okay when driven by a guest
Windows OS, right? Can you collect an equivalent usbmon trace for
that? Comparing the two traces may be instructive.
Alan Stern
From: Adi J. Sieker <hidden> Date: 2011-05-02 21:19:25
On 02/05/11 23:06, Alan Stern wrote:
On Mon, 2 May 2011, Adi J. Sieker wrote:
quoted
Attached is the usbmon trace when I plug the keyboard in.
lsusb shows the keyboard as:
Bus 002 Device 008: ID 060b:0230 Solid Year
Relevant section from /sys/kernel/debug/usb/devices
T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 8 Spd=1.5 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=060b ProdID=0230 Rev= 2.20
S: Manufacturer=KB
S: Product=USB Keyboard
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
Interestingly, the usbmon trace shows that the interrupt endpoint for
interface 1 isn't being used by usbhid. I don't know why, but it
shouldn't make much difference for your purposes since that interface
appears to be associated with the gaming interface. But maybe I'm
wrong and it is important somehow...
The other noticeable thing is that the keyboard didn't accept the
Set-Idle request for interface 1.
You said before that the keyboard worked okay when driven by a guest
Windows OS, right? Can you collect an equivalent usbmon trace for
that? Comparing the two traces may be instructive.
I hope this is what you meant. :)
Attached is a usbmon trace when I attach the keyboard to a VBox VM running a Windows XP guest. I have no idea how to get a USB trace from within Windows. The last block is when I pressed h twice in the Windows XP guest.
Cheers
Adi
From: Alan Stern <stern@rowland.harvard.edu> Date: 2011-05-02 22:29:10
On Mon, 2 May 2011, Adi J. Sieker wrote:
quoted
Interestingly, the usbmon trace shows that the interrupt endpoint for
interface 1 isn't being used by usbhid. I don't know why, but it
shouldn't make much difference for your purposes since that interface
appears to be associated with the gaming interface. But maybe I'm
wrong and it is important somehow...
The other noticeable thing is that the keyboard didn't accept the
Set-Idle request for interface 1.
You said before that the keyboard worked okay when driven by a guest
Windows OS, right? Can you collect an equivalent usbmon trace for
that? Comparing the two traces may be instructive.
I hope this is what you meant. :)
Attached is a usbmon trace when I attach the keyboard to a VBox VM
running a Windows XP guest. I have no idea how to get a USB trace from
within Windows. The last block is when I pressed h twice in the Windows
XP guest.
This is perfect. It shows that the H key is reported using the
interrupt endpoint on interface 1, which explains why it's not working
with usbhid. It also shows that the rejected Set-Idle request doesn't
matter.
At this point I don't know what the problem is, but now there's plenty
of information in the email thread for the people on linux-input to
debug this.
Alan Stern
From: Adi J. Sieker <hidden> Date: 2011-05-03 09:40:33
On 03/05/11 00:29, Alan Stern wrote:
On Mon, 2 May 2011, Adi J. Sieker wrote:
quoted
quoted
Interestingly, the usbmon trace shows that the interrupt endpoint for
interface 1 isn't being used by usbhid. I don't know why, but it
shouldn't make much difference for your purposes since that interface
appears to be associated with the gaming interface. But maybe I'm
wrong and it is important somehow...
The other noticeable thing is that the keyboard didn't accept the
Set-Idle request for interface 1.
You said before that the keyboard worked okay when driven by a guest
Windows OS, right? Can you collect an equivalent usbmon trace for
that? Comparing the two traces may be instructive.
I hope this is what you meant. :)
Attached is a usbmon trace when I attach the keyboard to a VBox VM
running a Windows XP guest. I have no idea how to get a USB trace from
within Windows. The last block is when I pressed h twice in the Windows
XP guest.
This is perfect. It shows that the H key is reported using the
interrupt endpoint on interface 1, which explains why it's not working
with usbhid. It also shows that the rejected Set-Idle request doesn't
matter.
Do you know of a way for me to tell the kernel/usbhid to use interface 1 and ignore interface 0?
Thanks
Adi
From: Alan Stern <stern@rowland.harvard.edu> Date: 2011-05-03 13:49:15
On Tue, 3 May 2011, Adi J. Sieker wrote:
Do you know of a way for me to tell the kernel/usbhid to use interface 1
and ignore interface 0?
Well, you can always unbind interface 0 from usbhid -- it corresponds
to the 2-1.1:1.0 file in /sys/bus/usb/drivers/usbhid/. If you do that,
you'll probably find the few keys which _do_ currently work suddenly
stop working.
But there's nothing to be done immediately about interface 1; usbhid is
_already_ using it. It just isn't using it correctly.
Alan Stern
Do you know of a way for me to tell the kernel/usbhid to use interface 1
and ignore interface 0?
Well, you can always unbind interface 0 from usbhid -- it corresponds
to the 2-1.1:1.0 file in /sys/bus/usb/drivers/usbhid/. If you do that,
you'll probably find the few keys which _do_ currently work suddenly
stop working.
But there's nothing to be done immediately about interface 1; usbhid is
_already_ using it. It just isn't using it correctly.
Adi,
could you please provide output of
cat /syse/kernel/debug/hid/<keyboard>/rdesc
anytime after the keyboard has been plugged, and
cat /syse/kernel/debug/hid/<keyboard>/events
from the time you press any of the working and non-working keys? (both
cases will be interesting).
Oh, and the above assumes that you have debugfs mounted under
/sys/kernel/debug.
Thanks,
--
Jiri Kosina
SUSE Labs
From: Adi J. Sieker <hidden> Date: 2011-05-06 13:59:44
On 06/05/11 14:58, Jiri Kosina wrote:
On Tue, 3 May 2011, Alan Stern wrote:
quoted
quoted
Do you know of a way for me to tell the kernel/usbhid to use interface 1
and ignore interface 0?
Well, you can always unbind interface 0 from usbhid -- it corresponds
to the 2-1.1:1.0 file in /sys/bus/usb/drivers/usbhid/. If you do that,
you'll probably find the few keys which _do_ currently work suddenly
stop working.
But there's nothing to be done immediately about interface 1; usbhid is
_already_ using it. It just isn't using it correctly.
Adi,
could you please provide output of
cat /syse/kernel/debug/hid/<keyboard>/rdesc
anytime after the keyboard has been plugged, and
in /sys/kernel/debug/hid I have two devices for the keyboard. One is 0003:060B:0230.0002 and the other 0003:060B:0230.0003
attached are the rdesc files for both devices.
cat /syse/kernel/debug/hid/<keyboard>/events
from the time you press any of the working and non-working keys? (both
cases will be interesting).
I only get events for the working keys on the *:0002 device.
All other files were empty after I pressed some keys.
The events for the working keys are attached in the *.events file.
I first pressed backspace and then the menu key.
Cheers
Adi
From: Christoph Fritz <hidden> Date: 2011-05-07 22:25:03
On Fri, 2011-05-06 at 15:59 +0200, Adi J. Sieker wrote:
On 06/05/11 14:58, Jiri Kosina wrote:
quoted
On Tue, 3 May 2011, Alan Stern wrote:
quoted
quoted
Do you know of a way for me to tell the kernel/usbhid to use interface 1
and ignore interface 0?
Well, you can always unbind interface 0 from usbhid -- it corresponds
to the 2-1.1:1.0 file in /sys/bus/usb/drivers/usbhid/. If you do that,
you'll probably find the few keys which _do_ currently work suddenly
stop working.
But there's nothing to be done immediately about interface 1; usbhid is
_already_ using it. It just isn't using it correctly.
Adi,
could you please provide output of
cat /syse/kernel/debug/hid/<keyboard>/rdesc
anytime after the keyboard has been plugged, and
in /sys/kernel/debug/hid I have two devices for the keyboard. One is
0003:060B:0230.0002 and the other 0003:060B:0230.0003
attached are the rdesc files for both devices.
quoted
cat /syse/kernel/debug/hid/<keyboard>/events
> from the time you press any of the working and non-working keys? (both
> cases will be interesting).
I only get events for the working keys on the *:0002 device.
All other files were empty after I pressed some keys.
The events for the working keys are attached in the *.events file.
I first pressed backspace and then the menu key.
Hi Adi,
I'm not sure about my patch below because of interface one, maybe you
can give it a try.
Thanks,
-- chf
---
Subject: [PATCH] HID: add quirk for Solid Year keyboard ACK231
This patch adds HID_QUIRK_MULTI_INPUT to Solid Year keyboard ACK231
which reports keystrokes from inside a firmware-configuration
interface instead of using its own interface.
From: Adi J. Sieker <hidden> Date: 2011-05-08 19:51:50
On 08/05/11 00:24, Christoph Fritz wrote:
On Fri, 2011-05-06 at 15:59 +0200, Adi J. Sieker wrote:
quoted
On 06/05/11 14:58, Jiri Kosina wrote:
quoted
On Tue, 3 May 2011, Alan Stern wrote:
quoted
quoted
Do you know of a way for me to tell the kernel/usbhid to use interface 1
and ignore interface 0?
Well, you can always unbind interface 0 from usbhid -- it corresponds
to the 2-1.1:1.0 file in /sys/bus/usb/drivers/usbhid/. If you do that,
you'll probably find the few keys which _do_ currently work suddenly
stop working.
But there's nothing to be done immediately about interface 1; usbhid is
_already_ using it. It just isn't using it correctly.
Adi,
could you please provide output of
cat /syse/kernel/debug/hid/<keyboard>/rdesc
anytime after the keyboard has been plugged, and
in /sys/kernel/debug/hid I have two devices for the keyboard. One is
0003:060B:0230.0002 and the other 0003:060B:0230.0003
attached are the rdesc files for both devices.
quoted
cat /syse/kernel/debug/hid/<keyboard>/events
> from the time you press any of the working and non-working keys? (both
> cases will be interesting).
I only get events for the working keys on the *:0002 device.
All other files were empty after I pressed some keys.
The events for the working keys are attached in the *.events file.
I first pressed backspace and then the menu key.
Hi Adi,
I'm not sure about my patch below because of interface one, maybe you
can give it a try.
What kernel version do I need? I'm running Ubuntu 10.04, so can I apply this to a 2.6.32 Ubuntu kernel or do I need a current 2.6.39?
Any ideas if I'll run into problems if I run Ubuntu 10.04 on a 2.6.39 kernel.
Cheers
Adi
From: Christoph Fritz <hidden> Date: 2011-05-08 21:34:27
On Sun, May 08, 2011 at 09:51:42PM +0200, Adi J. Sieker wrote:
On 08/05/11 00:24, Christoph Fritz wrote:
quoted
I'm not sure about my patch below because of interface one, maybe you
can give it a try.
What kernel version do I need? I'm running Ubuntu 10.04, so can I
apply this to a 2.6.32 Ubuntu kernel or do I need a current 2.6.39?
A current kernel is recommended.
bye,
-- chf
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Adi J. Sieker <hidden> Date: 2011-05-10 08:24:24
On 08/05/11 00:24, Christoph Fritz wrote:
On Fri, 2011-05-06 at 15:59 +0200, Adi J. Sieker wrote:
quoted
On 06/05/11 14:58, Jiri Kosina wrote:
quoted
On Tue, 3 May 2011, Alan Stern wrote:
quoted
quoted
Do you know of a way for me to tell the kernel/usbhid to use interface 1
and ignore interface 0?
Well, you can always unbind interface 0 from usbhid -- it corresponds
to the 2-1.1:1.0 file in /sys/bus/usb/drivers/usbhid/. If you do that,
you'll probably find the few keys which _do_ currently work suddenly
stop working.
But there's nothing to be done immediately about interface 1; usbhid is
_already_ using it. It just isn't using it correctly.
Adi,
could you please provide output of
cat /syse/kernel/debug/hid/<keyboard>/rdesc
anytime after the keyboard has been plugged, and
in /sys/kernel/debug/hid I have two devices for the keyboard. One is
0003:060B:0230.0002 and the other 0003:060B:0230.0003
attached are the rdesc files for both devices.
quoted
cat /syse/kernel/debug/hid/<keyboard>/events
> from the time you press any of the working and non-working keys? (both
> cases will be interesting).
I only get events for the working keys on the *:0002 device.
All other files were empty after I pressed some keys.
The events for the working keys are attached in the *.events file.
I first pressed backspace and then the menu key.
Hi Adi,
I'm not sure about my patch below because of interface one, maybe you
can give it a try.
Hi Christoph,
I haven't gotten around to compiling a new kernel yet.
Tzy-Jye Daniel Lin mentioned in a mail to me that adding
usbhid.quirks=0x060b:0x0230:0x0040 to the kernel command line
would achieve the same as the patch you posted.
I did try that on a 2.6.32 kernel and that didn't help.
I'll still generate a new kernel with your patch applied it's probably going to take a couple of days though.
Cheers
Adi
the suppllied patch
quoted hunk
Thanks,
-- chf
---
Subject: [PATCH] HID: add quirk for Solid Year keyboard ACK231
This patch adds HID_QUIRK_MULTI_INPUT to Solid Year keyboard ACK231
which reports keystrokes from inside a firmware-configuration
interface instead of using its own interface.