On Fri, Mar 25, 2011 at 01:58:24PM -0500, Seth Forshee wrote: > On Fri, Mar 25, 2011 at 10:03:33AM -0700, Dmitry Torokhov wrote: > > > So, would the following make sense (KEY_TBD is may abbreviation for "key > > > to be determinded"): > > > > > > - On press (0xe4), send KEY_TBD, value = 1 > > > - On hold (0xea), send KEY_TBD, value = 2 > > > - On release (0xe5), send KEY_TBD, value = 0 > > > > Yes. > > There's a little problem with this. The driver uses sparse-keymap, which > calls input_report_key(), which is doing this: > > input_event(dev, EV_KEY, code, !!value);
Ah, right, it really did not have in mind passing on auto-repeating keys as is when it was written. > > I don't see the hold events in userspace, so they must be getting > dropped as duplicates as you suggested. > > I'm not sure who is at fault here. Should input_report_key() not be > forcing value to 0 or 1? Or should sparse-keymap be calling > input_event() directly? Or is sparse-keymap the wrong tool for handling > keys this way? I do not thik we shoudl burden sparse-keymap with handling repeats. Just mark the device as auto-repeating (by setting EV_REP bit) and let input core autorepeat logic do it for you. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
