Em 12-05-2011 02:37, Anssi Hannula escreveu: > 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; Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we should change it to something like 125ms, for example, as 33ms is too short, as it takes up to 114ms for a repeat event to arrive. The REP_PERIOD is adjusted, however, on several drivers. Also, RC core changes its default to 500ms, to avoid ghost keystrokes: dev->input_dev->rep[REP_DELAY] = 500; > >>> 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? I mean that the logic is ok. The timings may be not. The timings were not touched when we've ported the already supported IR's to the rc-core, except when we noticed some troubles with them. > 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. That's what we all expect to happen. >> 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? :) ). They share the same logic, but hardware decoders behave different than software ones. Mauro -- 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
