On Thu, 31 Jul 2008 14:54:52 -0400
Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
> > IOW, if the change responsible for this makes it to the mainline kernel, it
> > will be considered as a regression.
> >
>
> Like I said, I don't agree.
It really really doesn't matter what the causes are or which piece of
code is at fault or anything else like that.
What _does_ matter is that people's stuff will break. Apparently lots
of people's. That's a problem. A _practical_ problem. Can we
pleeeeeeze be practical and find some way of preventing it?
I assume this is the commit?
commit 03bac96fae0efdb25e2059e5accbe4f3ee6328dd
Author: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
Date: Mon Jun 23 10:47:34 2008 -0400
Input: expand keycode space
Expand the number of potential key codes from 512 to 768 since people
are coming up with more and more keys.
Signed-off-by: Dmitry Torokhov <dtor@xxxxxxx>
diff --git a/include/linux/input.h b/include/linux/input.h
index a5802c9..7fae1de 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -579,7 +579,7 @@ struct input_absinfo {
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTING KEY_MUTE
-#define KEY_MAX 0x1ff
+#define KEY_MAX 0x2ff
#define KEY_CNT (KEY_MAX+1)
/*
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index c4db582..0dddfa4 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -274,7 +274,7 @@ struct pcmcia_device_id {
/* Input */
#define INPUT_DEVICE_ID_EV_MAX 0x1f
#define INPUT_DEVICE_ID_KEY_MIN_INTERESTING 0x71
-#define INPUT_DEVICE_ID_KEY_MAX 0x1ff
+#define INPUT_DEVICE_ID_KEY_MAX 0x2ff
#define INPUT_DEVICE_ID_REL_MAX 0x0f
#define INPUT_DEVICE_ID_ABS_MAX 0x3f
#define INPUT_DEVICE_ID_MSC_MAX 0x07
I'm unable to work out how necessary this change is?
Please: what proportion of the existing X installations do you expect will
be affected by this?
--
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
