Re: [PATCH] Fix NR_KEYS off-by-one error

[Vojtech Pavlik]

Hi!

Let me summarize.

In the past, the kernel had various different values of NR_KEYS, in this
order: 128, 512, 256, 255.

128 was not enough, 512 didn't fit in a byte (while allowed to address
all keycodes the input layer uses), 256 broke some apps that relied on
unsigned char counters, and thus we ended up with the maximum value that
kept all software happy.

Now somewhere in the process (I assume in the 512 stage, but could be
the 256 stage as well), the kernel produced warnings about impossible
comparisons.

Thus the comparison(s) were dropped, by Andrew.

Then we finalized on 255, and the comparison is needed again to prevent
overflowing the keymap arrays.

BUT some binaries are still compiled with 256 and try to set up a
mapping for keycode 255 (although there is _no_ such keycode), and
break. IMO it's a bug in the app.

Now I believe that simply adding the check back by reverting the old
Andrew's patch and recompiling/fixing what breaks is the right way to
go.

Any comments?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/