Em 13-05-2011 01:48, Anssi Hannula escreveu: > On 12.05.2011 04:36, Mauro Carvalho Chehab wrote: >> Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: >>> Em 12-05-2011 02:37, Anssi Hannula escreveu: >> >>>> 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. >>> >> IMO, the enclosed patch should do a better job with repeat events, without >> needing to change rc-core/input/event logic. > > It will indeed reduce the amount of ghost events so it brings us in the > right direction. > > I'd still like to get rid of the ghost repeats entirely, or at least > some way for users to do it if we don't do it by default. > Maybe we could replace the kernel softrepeat with native repeats (for > those protocols/drivers that have them), while making sure that repeat > events before REP_DELAY are ignored and repeat events less than > REP_PERIOD since the previous event are ignored, so the users can still > configure them as they like? > This doesn't seem to be the right thing to do. If the kernel will accept 33 ms as the value or REP_PERIOD, but it will internally set the maximum repeat rate is 115 ms (no matter what logic it would use for that), Kernel (or X) shouldn't allow the user to set a smaller value. The thing is that writing a logic to block a small value is not easy, since the max value is protocol-dependent (worse than that, on some cases, it is device-specific). It seems better to add a warning at the userspace tools that delays lower than 115 ms can produce ghost events on IR's. > Or maybe just a module option that causes rc-core to use native repeat > events, for those of us that want accurate repeat events without ghosting? If the user already knows about the possibility to generate ghost effects, with low delays, he can simply not pass a bad value to the kernel, instead of forcing a modprobe parameter that will limit the minimal value. 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
