On Tuesday 04 March 2008 12:47:15 Ville Syrjälä wrote: > On Sat, Feb 16, 2008 at 04:22:43PM +0000, Peter Stokes wrote: > > The attached patch reconfigures the ati_remote2 driver to use > > soft-autorepeat functionality and adds support for loadable key maps. > > Why was this submitted (and even accepted) without cc:ing me? > I am very sorry, that was my fault, I should have cc'd you on the original mail. > > I have reconfigure the driver to use the input system's built-in > > autorepeat functionality as the device only appears to be able to produce > > key repeat notifications at a fixed period. Switching to the software > > autorepeat functionality provides more precise configuration of the > > timings requested for repeat-delay and repeat-rate. > > The soft-autorepeat support should be split into a separate patch. I don't > need such fast repeat but if it helps people I'm fine with it. > My reasoning behind modifying the ati_remote2 driver to use the soft-autorepeat implementation provided by the core input system was based upon the following: * It states, in section 1.8 of "Documentation/input/input-programming.txt", the following: 1.8 Key autorepeat ~~~~~~~~~~~~~~~~~~ ... is simple. It is handled by the input.c module. Hardware autorepeat is not used, because it's not present in many devices and even where it is present, it is broken sometimes (at keyboards: Toshiba notebooks). To enable autorepeat for your device, just set EV_REP in dev->evbit. All will be handled by the input system. * Using soft-autorepeat provides a more accurate behavior (the initial delay and the repeat rate behave as configured, as opposed to being rounded up to the nearest multiple of the hardware's, apparently fixed, repeat notifications (the hardware based repeat behavior also introduces timing aliasing where the actual interval between successive repeats is inconsistent). * Using soft-autorepeat makes the code in ati_remote2 slightly simpler. 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. 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. > > As this device is exposed as a combined keyboard and mouse, this change > > somewhat depends upon the suggested modification to the core > > soft-autorepeat functionality as outlined in my previous post to the > > linux-input mailing list (on 12th Feb 2008 entitled "Soft-autorepeat > > functionality"), without that modification, the mouse buttons are > > autorepeated :-( > > > > The loadable keymap support exposes the ability to map 5 separate > > keycodes to each key (depending on which "mode" the remote control is > > currently in). Additionally, I have attempted to ensure that the > > scancodes used to map keycodes to the keys lie outside of the range > > normally covered by regular keyboards so as to avoid requests to remap > > the keys on the remote from being intercepted by a normal keyboard. > > I thought the idea of input devices was to reflect the hardware and the > keymaps should be handled in userspace. If that's not the case then I think > the keymap support code should not be inside the driver but instead inside > the input core. We don't want such invasive changes in every driver do > we? If I may explain my reasoning behind proposing the changes associated with the loadable keymap support. I would welcome any feedback on my reasoning and approach. My initial problem was that some of the keycodes mapped in the ati_remote2 driver have values greater than 255 and as such I am unable to obtain the input from pressing those keys in X windows (perhaps I'm missing some required configuration of X windows somewhere?). Upon further investigation into this I noticed that the input core provides a mechanism for altering the keymap configuration but the ati_remote2 driver is not compatible with it. Initially I simply modified the ati_remote2 to use the mechanism provided by the input core. Having done that, it occurred to me that the mode buttons of of the remote could be employed to effectively provide five sets of key mappings and I thought that this might be of some use to someone somewhere... I appreciate that the implementation I have suggested is probably not in line with the original intended functionality of the loadable keymap support in the input system. But it does get round my issue with X windows.... It also occurred to me that perhaps the multiple-keyboards should be exposed as separate input devices, but again, if my understanding is correct, that would break backwards compatibility. Any suggestions on better approaches would certainly be greatfully relieved. Thank you for taking the time to read my rather long-winded email ;-) Best regards Peter Stokes -- 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
