Re: KDSETKEYCODE work with new input layer?
Vojtech Pavlik (vojtech@suse.cz)
Tue, 1 Oct 2002 18:51:54 +0200
On Tue, Oct 01, 2002 at 12:49:08PM -0400, Skip Ford wrote:
> Vojtech Pavlik wrote:
> > On Tue, Oct 01, 2002 at 11:32:02AM -0400, Skip Ford wrote:
> > > Vojtech Pavlik wrote:
> > >
> > > setkeycodes rejects it.
> > >
> > > I changed setkeycodes.c to add 256 instead of 128 and bumped up the
> > > bounds checking, but it's still strange. It now works for e063, but
> > > still doesn't work for e05e. Many other keys in the same area as 0x5e
> > > don't work. The only one that does work that I tried is e063.
> >
> > There is another thing that has changed - the scancode numbers. So if
> > you're using the same commands as on 2.4, you're setting scancodes for
> > different keys. We now use 'at keyboard - set 2' scancodes as opposed to
> > 'xt keyboard - set 1' used by the older driver. See the 'dmesg' output
> > for keys ("unknown scancode ...") that are not known to the keyboard
> > driver.
>
> showkey is still showing me the same scancodes.
The raw mode showkey -s is now using to show scancodes is completely
simulated by the kernel.
> The new AT driver
> doesn't log any 'unknown scancode' messages for the same buttons the
> old XT driver did.
That means it understands them. If it did not, showkey -s wouldn't work.
> > > Will you be releasing an updated kbd package?
> >
> > Well, I'm not the maintainer of the kbd package, but I probably will
> > have to release a new tool to set the keycode table.
>
> Sorry about that. Didn't mean to volunteer you. Thanks for all your
> help. I'll try to verify the scancodes I'm using.
Just update the keymap - you don't need to change the scancode table if
the keys are working.
--
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/