On Fri, Dec 25, 2009 at 11:38:12AM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 24 Dec 2009, Dmitry Torokhov wrote:
> > On Thu, Dec 24, 2009 at 07:01:46PM -0200, Henrique de Moraes Holschuh wrote:
> > > On Thu, 24 Dec 2009, Dmitry Torokhov wrote:
> > > > + for (i = 0; i < ARRAY_SIZE(sony_laptop_input_keycode_map); i++)
> > > > + __set_bit(sony_laptop_input_keycode_map[i], key_dev->keybit);
> > > > + __clear_bit(KEY_RESERVED, key_dev->keybit);
> > >
> > > Maybe:
> > >
> > > for (i = 0; i < ARRAY_SIZE(sony_laptop_input_keycode_map); i++) {
> > > if (sony_laptop_input_keycode_map[i] != KEY_RESERVED) {
> > > input_set_capability(key_dev, EV_KEY,
> > > sony_laptop_input_keycode_map[i]);
> > > }
> > > }
> > >
> > > would be better, as it means the driver doesn't poke into the inputdev
> > > struct innards directly?
> >
> > Given that you have to still poke there to set up open, close, name,
> > phys, id and so on and so forth I think the original is fine and that is
> > what most of keyboard-like drivers do.
>
> Never liked that much, either :-)
>
> > The reason I came up with input_set_capability is because gpio-keys
> > wanted to set up siwtches and keys based on platform data so doing;
> >
> > for(...)
> > input_set_capability(dev, pdata->type, pdata->code);
> >
> > looked nice.
>
> I see. Well, it is a matter of differing tastes I think (none of them bad,
> just different).
>
> That said, is KEY_RESERVED bit left set a common error? If it is, maybe it
> make sense to __clear_bit it inside of input_register_device() just in case?
>
Something like below?
--
Dmitry
Input: automatically reset KEY_RESERVED bit for all input devices
KEY_RESERVED is not supposed to be reported to userspace but rather to
mark unused entries in keymaps.
Signed-off-by: Dmitry Torokhov <dtor@xxxxxxx>
---
drivers/input/input.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index ab06071..910d7be 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -613,12 +613,12 @@ static int input_default_setkeycode(struct input_dev *dev,
}
}
- clear_bit(old_keycode, dev->keybit);
- set_bit(keycode, dev->keybit);
+ __clear_bit(old_keycode, dev->keybit);
+ __set_bit(keycode, dev->keybit);
for (i = 0; i < dev->keycodemax; i++) {
if (input_fetch_keycode(dev, i) == old_keycode) {
- set_bit(old_keycode, dev->keybit);
+ __set_bit(old_keycode, dev->keybit);
break; /* Setting the bit twice is useless, so break */
}
}
@@ -676,6 +676,9 @@ int input_set_keycode(struct input_dev *dev, int scancode, int keycode)
if (retval)
goto out;
+ /* Make sure KEY_RESERVED did not get enabled. */
+ __clear_bit(KEY_RESERVED, dev->keybit);
+
/*
* Simulate keyup event if keycode is not present
* in the keymap anymore
@@ -1513,13 +1516,16 @@ int input_register_device(struct input_dev *dev)
const char *path;
int error;
+ /* Every input device generates EV_SYN/SYN_REPORT events. */
__set_bit(EV_SYN, dev->evbit);
+ /* KEY_RESERVED is not supposed to be transmitted to userspace. */
+ __clear_bit(KEY_RESERVED, dev->keybit);
+
/*
* If delay and period are pre-set by the driver, then autorepeating
* is handled by the driver itself and we don't do it in input.c.
*/
-
init_timer(&dev->timer);
if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD]) {
dev->timer.data = (long) dev;
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
