On Tue, May 28, 2002 at 03:05:55PM +0200, Alexander Neundorf wrote: > On Tuesday 28 May 2002 14:27, Brad Hards wrote: > > On Tue, 28 May 2002 21:57, Alexander Neundorf wrote: > > <snip> > > > > > When pressing one of the "known" keys, data appears on /dev/input/event0, > > > when pressing one of the other keys, data appears on /dev/input/event1 . > > > I wouldn't have expected this different behaviour for the different > > > buttons. > > > > I would have. You said it emulates a keyboard and a mouse. That is two > > quite different devices, hence two interfaces with difference Application > > identifiers. > > I mean, there are buttons, which generate key events with key codes less than > 128, they do autorepeat, and there are buttons which generate key events with > key codes above 128, these don't autorepeat. I used xev for testing. > The buttons <128 generate data on event0, the buttons >128 on event1.
That's to be expected. Autorepeat is only enabled for 'keys' (<256) by default but not for buttons (>=256). You wouldn't be happy if your mouse button started autorepeating. This is all done in software and can be set using the EVIOCSREP ioctl. > The mouse is working without problems. > > > > Any idea how to get the other group of keys to do auto-repeating or how > > > to find out where the problem lies ? > > > > USB keys and buttons don't autorepeat at the device level. You have to > > Sure ? Yes. The protocol can't transmit that without doing some ugly tricks. > There is a led in the ir receiver which lights if it receives something ( at > least I get this impression). > When pressing and holding a button (i.e. key) on the remote control, then > this led flashes once, then one moment pause, and then it starts to flicker. > This "feels" like the behaviour of a usualy keyboard with delay and > auto-repeat. This is because if 'release' IR data is lost, it wouldn't be good for your keys to become stuck. So it only sends 'press' data, and has to do that repeatedly. > Is looking at the output of event0 and event1 the right way to find out more ? Yes, it is the right way. > Or how can I find out more ? You can enable DEBUG in hid-core.c and hid-input.c > > handle it in the driver. There are ioctls for the input event device to get > > and set this. > > I will have a look. Any example sources anywhere ? -- Vojtech Pavlik SuSE Labs _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
