Em 11-05-2011 19:59, Anssi Hannula escreveu: >> No. It actually depends on what driver you're using. For example, for most dvb-usb >> devices, this is given by the logic bellow: >> >> if (d->props.rc.legacy.rc_interval < 40) >> d->props.rc.legacy.rc_interval = 100; /* default */ >> >> input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval; >> input_dev->rep[REP_DELAY] = d->props.rc.legacy.rc_interval + 150; >> >> where the rc_interval defined by device entry at the dvb usb drivers. > > Isn't that function only called for DVB_RC_LEGACY mode? I just picked one random piece of the code that covers several RC remotes (most dvb-usb drivers are still using the legacy mode). Similar code are there for other devices. > Maybe I wasn't clear, but I'm talking only about the devices handled by > rc-core. With just a few exceptions, the repeat period/delay that were there before porting to rc-core were maintained. There are space for adjustments, as we did on a few cases. Em 11-05-2011 22:53, Dmitry Torokhov escreveu: > On Wed, May 11, 2011 at 08:59:16PM +0300, Anssi Hannula wrote: >> >> I meant replacing the softrepeat with native repeat for such devices >> that have native repeats but no native release events: >> >> - keypress from device => keydown + keyup >> - repeat from device => keydown + keyup >> - repeat from device => keydown + keyup >> >> This is what e.g. ati_remote driver now does. >> >> Or alternatively >> >> - keypress from device => keydown >> - repeat from device => repeat >> - repeat from device => repeat >> - nothing for 250ms => keyup >> (doing it this way requires some extra handling in X server to stop its >> softrepeat from triggering, though, as previously noted) >> >> With either of these, if one holds down volumeup, the repeat works, and >> stops volumeup'ing immediately when user releases the button (as it is >> supposed to). >> > > Unfortunately this does not work for devices that do not have hardware > autorepeat and also stops users from adjusting autorepeat parameters to > their liking. Yes. A solution like the above would limit the usage. There are some remotes (like for example, the Hauppauge Grey remotes I have here) that a simple keypress generates, in general, up to 3 scancodes (the normal keypress and up to two "bounced" repeat keycodes). So, the software key delay also serves as a way to de-bounce the keypress. > It appears that the delay to check whether the key has been released is > too long (almost order of magnitude longer than our typical autorepeat > period). Yes, because, for example, with NEC and RC-5 protocols, one keystroke or one repeat event takes 110/114 ms to be transmitted. The delay actually varies from protocol to protocol, so it is possible to do some adjustments, based on the protocol type, but it is an order of magnitude longer than a keyboard or mouse. > I think we should increase the period for remotes (both in > kernel and in X, and also see if the release check delay can be made > shorter, like 50-100 ms. Some adjustments like that can be made, but they are device-driver specific. For example, some in-hardware IR decoders with KS007 micro-controller just removes all repeat keycodes and replace them with new keystrokes. There are some shipped remotes that don't support the RC-5 or NEC key repeat event. So, on those, if you keep a key pressed, you just receive the same scancode several times. The last time I double checked all remotes I have here, on all cases the auto-repeat logic were doing the right job, but I won't doubt that we need to add some additional adjustments for some boards/devices. Anssi, what's the hardware that you're using? Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
