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-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html