On Tue, 2007-08-28 at 18:07 +0200, Jiri Kosina wrote: > On Mon, 27 Aug 2007, Adrian McMenamin wrote: > > > The problem I have is that when I press a key, that key is continually > > output - eg pressing 'r' causes 'r' to echo on the screen more-or-less > > for ever more. > > The HID keyboard should send HID report on every keypress indicating the > usage code of the key and it's values (usually 1 when it is pressed, 0 > when it is released). Then you'd get automatically corrent behavior, as > you'd once issupe input_event(...., 1) for the keypress and > input_event(...., 0) for the release. Actually the behaviour you are describing doesn't work with my keyboard/bus combination - the keyboard has no idependent way of raising an interrupt and in fact has to be regularly polled by the bus. I figured out what was wrong and more or less got a working driver - but now I have another problem with it. The driver works like this: vblank interrupt on box -> send polling request via events/0 workqueue dma transfer finished interrupt -> poll keyboard via events/0 workqueue works fine for a minute or two with events/0 reporting, via top, CPU usage of about 0.3%. Then, without warning, events/0 whacks up to 99% and the system gets locked Any ideas as to what might be up? Is the network driver likely to be using events/0? -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
