Derek Fawcus, le Mon 12 Jan 2009 22:36:21 +0000, a écrit : > On Fri, Jan 09, 2009 at 11:23:41PM +0100, Samuel Thibault wrote: > > Alan Cox, le Fri 09 Jan 2009 22:01:44 +0000, a écrit : > > > > > Surely that is just a new keymap ? > > > > > > > > No. That would mean a lot of keymapSSS. Doing it the keymap way > > > > > > Why - its an algorithmic question about how to edit them - remember you > > > can edit keymaps in programs at runtime and live. > > > > Right. I'm still afraid by that: we'd need to know how to remap the > > various keycodes (amiga, atari, i386, mc, sun). > > Err - just use EVIOCSKEYCODE to swap the keycodes around, this works > in terms of the evdev keycodes. I use it in a small program to swap > around a bunch of keys. > > A bit more of a challange would be listening to evdev, and when > detecting the 'swap' keycode, doing the reload with the actual swaps. Yes, that seems a bit unsafe to me. Another solution is to just grab all the keyboard devices, and reemit the wanted evdev keycodes. Quite clumsy. > I'm not sure w/o reading the code if the kernel will allow this to be > shared between the tty and evdev on the same vt, What do you mean by "this"? The raw keycode -> input keycode translation? My guess is that it is recorded for the device itself, not related to things like VTs, and thus is global. > but then one could run a controller program talking through a pty and > direct to the keyboard. Ugh. I'd prefer grabing evdev rather that using a pty. Samuel -- 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
