On Mon, Jul 16, 2007 at 06:54:07PM +1200, Sam Banks wrote: > Hey all, > > I have been having a problem with my particular usb keyboard > (0x03 was always being written into the first element of > ukbd_data->keycode basically). I have tracked it down to a > problem somewhere in between the uhci chipset (same problem > with other cuts of uhci chipset), the uhci and/or ukbd > drivers and the keyboard. > > A fix to the problem is to reorder members of the struct > ukbd_data. Originally, the members are ordered as modifiers, > reserved and keycode[6] (minus a bunch of #define's). If I > change this order to reserved, modifiers and keycode[6], my > keyboard starts to function as it should (minus lighting up > the LED's but that's another email all together :)). With > this reordering, it stops other usb keyboards which function > with the original code from working. Can you give a diff so people can see the different order. > > I'm wanting submit a patch for this fix (as other people are > experiencing the same problems) but I'm not sure how to do > this. I was thinking along the lines of the usb quirks > function but it appears outside of a function body, you > cannot have the normal if() type statements, only the > preprocessor #ifdef types. To me, having a kernel config > option for a single keyboard on a single driver seems quite > overkill. > > Does anyone have any suggestions on what I should do or can > anyone point me to some code that deals with a similar > problem? > > On a side note, is anyone able to shed any light into why > they think the above fix works? I am drawing a bit of a > blank to be honest. Is it possible that my fix is only > masking the problem? cheers, AndrewReceived on Mon Jul 16 2007 - 05:52:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:14 UTC