On Tue, Mar 04, 2008 at 09:34:29PM +0000, Peter Stokes wrote: > On Tuesday 04 March 2008 20:38:22 Ville Syrjälä wrote: > > On Tue, Mar 04, 2008 at 06:55:49PM +0000, Peter Stokes wrote: > > > I am happy to produce a separate patch containing only the changes > > > necessary to switch the ati_remote2 driver over to use the > > > soft-autorepeat behavior, if that is indeed the consensus regarding the > > > best approach to take. > > > > Yes, I'd like one patch per feature. > > > > I'll do that (do need to sort out exactly how to implement it first though) Right. > > > As for ensuring that the mouse buttons on this device do not have > > > auto-repeat behavior applied to them. I was very unsure of my proposed > > > solution, as I attempted to express in my initial email on the subject. > > > It does however strike me that if mouse buttons (and perhaps other > > > button/key codes) should not be auto-repeated then these codes should be > > > excluded from the auto-repeat implementation within the input core. > > > Experimentation using my Microsoft Internet Keyboard appeared to indicate > > > that regular keys where repeated but the extra buttons (things like > > > launch email, launch web browser etc.) are not (my investigations > > > appeared to indicate, contrary to section 1.8 of the documentation quoted > > > above, that the repeat behavior was being performed by the hardware and > > > not by the input system's soft-autorepeat implementation). This behavior > > > appears to approximately coincide with the boundary described by the > > > KEY_MIN_INTERESTING define but I had no idea whether that was merely > > > coincidence. > > > > > > > > > > > > > > > I am happy to implement multiple input devices, one for the mouse, and > > > one for the keyboard. If my understanding is correct, this would break > > > backwards compatibility as the two devices would be exposed by the evdev > > > driver as two separate event devices? > > > > > > If anyone can suggest the best approach to this problem I would be happy > > > to develop the necessary patches to implement the chosen solution. > > > > Ah, the backwards compatibility angle. It would be rude of us to break > > the behaviour like that. It probably wouldn't affect my typical use case > > (MPlayer + DirectFB) since I typically only use the keyboard part of the > > remote. But if there are people using both "components" of the remote they > > would have to change their configuration or in the worst case their code to > > handle such a change. Not nice at all. > > > > The backwards compatibility wouldn't be a problem for me either (I'm using X > windows and MythTV). I felt that the original choice of keymappings > represents the closest match between the images physically printed on the > keys and the descriptions contained in the standard keycode defines but > unfortunately they result in some fairly crucial keys (like 'ok' for example) > being undetectable in X windows :-( > > I suspect that that very few people are currently using this driver for this > very reason, and upon that entirely unsubstantiated assumption I'd suggest > that if it is deemed that the best approach is to expose the mouse and > keyboard functionality as two separate devices then that would probably be > acceptable? > > My personal feeling is that, if mouse buttons (and other keycodes) should not > be repeated, then they should be excluded from the soft-autorepeat > functionality offered by the input core. I think that repeating buttons are a good thing in some cases (autofire in games for example). Then again such games could implement autofire themselves. However I don't see why the repeat vs. no repeat case should depend on the device reporting or not reporting keyboard keys. I don't see any real connection with a device having some keyboard keys and sending repeat events for buttons. Let's say you have a HID keyboard which does in fact have an integrated trackball/whatever (at least keyboard with scroll wheels exists so adding a complete trackball doesn't seem that far fetched) but instead of having separate end points for each "device" it would just have one endpoint. That device would experience the same problem that my HID mouse has. > > I think you could implement the multiple keymaps thing rather trivially > > in user space by having a small daemon listening on the event device and > > loading a new keymap when a mode key is pressed. That would limit the > > changes to the driver, and it would not require any kernel changes when > > if you would need to adapt it to a device that uses a different driver. > > > > I think the only problem is the grab thingy. I'm not sure if the Xorg > > evdev driver grabs the device, but if it does then the daemon wouldn't > > be able to see the events. DirectFB's input driver does grab the device > > to prevent events leaking to the console (ctrl-c combination was > > rather unpleasant without the grab). One solution would be a more > > light weight grab that would only prevent the console from receiving the > > events but would let other applications to see them. I remeber seeing > > some discussion around device grab in the past. I wonder if anything > > useful came of it... > > When I initially implemented the loadable keymap support using the input core > built in handling I hit the problem that I wanted to override the keys on the > remote control (the reason for looking into all of this) but some of the > scancode were taken by the standard PS2 keyboard driver. I reasoned that most > people wouldn't want to break their regular keyboard mappings so I then > implemented my own get/setkeycode functions in order to place the remote's > scancodes outside of the normal range produced by regular keyboards. Once I'd > had to implement my own versions of those functions it seemed trivial to > provide the 'layered' keyboard implementation. > > I must confess I don't have an immediate requirement for this functionality it > just seemed an easy and potentially useful thing to provide... > > My understanding of the X windows situation is that the X server protocol only > allows a single byte for keycodes,and as the server protocol is an network > standard it's not a case of changing some code it's a case of changing the > standard (something that isn't going to happen particularly quickly!). Hence > this seemed like a reasonable, if not entirely elegant, way around it... http://bugs.freedesktop.org/show_bug.cgi?id=11227 has some ideas about compressing the keycodes to the 8-255 range for each device by using device specific keymaps. However, since that seems unlikely to happen, and the input core already has support for keymaps I'm fine with adding the set/getkeycode stuff. What I'd like to drop is the support for five different keymaps since AFAICS that could be handled in a more generic way in user space. -- Ville Syrjälä syrjala@xxxxxx http://www.sci.fi/~syrjala/ -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
