Messages in this thread | | | Date | Mon, 7 Oct 2002 15:39:24 +0200 | From | Vojtech Pavlik <> | Subject | Re: KDSETKEYCODE work with new input layer? |
| |
On Mon, Oct 07, 2002 at 09:23:26AM -0400, Skip Ford wrote: > Vojtech Pavlik wrote: > > On Tue, Oct 01, 2002 at 06:29:55PM +0200, Andries Brouwer wrote: > > > > > > In kbd-1.06. It is from May 2001, and I have been planning kbd-1.07 > > > for a while but there were no urgent changes, just more fonts and > > > keymaps and the like. When you are done it is a good occasion for > > > kbd-1.07. > > > > Ok, here is a patch that should make it work correctly on all existing > > kernels. > > > > You may want to check that loadkeys supports keycodes over 127 (and for > > future, over 255), too. I updated only getkeycodes/setkeycodes. > > loadkeys and the kernel itself both reject attempts to set keycodes with > a value >= NR_KEYS (128). > > In kbd-1.06/src/loadkeys.y::addkey() > > if (index < 0 || index >= NR_KEYS) > lkfatal0(_("addkey called with bad index %d"), index); > > And inside linux/drivers/char/vt_ioctl.c::do_kdsk_ioctl() > > if (i >= NR_KEYS || s >= MAX_NR_KEYMAPS) > return -EINVAL; > > I had to change each of those to KEY_MAX. Both files use NR_KEYS in > other places so I don't what the correct fix is. I guess NR_KEYS is > still correct for some keyboards?
Ok, I fixed it now in the kernel [#define NR_KEYS (KEY_MAX+1)]. I think the loadkeys source probably shouldn't check for the limit (as that can change between kernels), and instead rely on the kernel rejecting invalid values.
-- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |