On 12.05.2011 02:52, Mauro Carvalho Chehab wrote: > 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. I don't see any other places: $ git grep 'REP_PERIOD' . dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval; >> 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. The above is the only place where the repeat period is set in the drivers/media tree, and it is not an rc-core device. Other devices therefore use the 33ms kernel default. Maybe I am missing something? > 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. I probably forgot to mention it, but I'm not suggesting removal of the repetition delay (500ms), it can stay for this reason exactly. >> 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. Does "doing the right job" mean that you are getting zero repeat (2) events after releasing a remote button? Because that is what I expect to happen, and that is what e.g. LIRC (which most people seem to still use with HTPC software - like XBMC which I'm a developer of) does. > Anssi, what's the hardware that you're using? I'm using ati_remote ported to rc-core (don't know yet if it makes any sense, though). However, as noted, reading ir-main.c I fail to see why this wouldn't happen with all rc-core devices, as all devices seem to use same IR_KEYPRESS_TIMEOUT and REP_PERIOD (though you seem to suggest otherwise above, maybe you can show me wrong? :) ). -- Anssi Hannula -- 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
