Derek Fawcus, le Tue 13 Jan 2009 01:06:13 +0000, a écrit : > > 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. > > reemit? as in inject back to the kernel? Through uinput, yes. > How does one prevent loops? By not grabbing the evdev corresponding to your own uinput dev. IIRC it can even work with several daemons doing so, the last being only able to grab the last uinput's evdev. If a daemon hangs, no luck, however. > > > 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"? > > I was referring to being able to read the evdev data from the keyboard > while still allowing the vt to consume the data. Can one filter out > just keys of interest, or will reading the /dev/input/eventX prevent > the keys being fed to the vt and hence to /dev/ttyXX? Grabbing does prevent it yes. But feeding through uinput puts it back to the console. > > > 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. > > Well using the pty is not too bad, and some stuff seems unhappy unless > fed from a tty of some form (default line buffering for stdin/stdout, > job control with bash). The problem with ptys too is that they manipulate letters, not physical key position, thus loosing keyboard mapping independence. > Anyway, wouldn't this all be easier with a app running on X and > XKEYBOARD/XKB manipulations? Have the key that does left/right > swapping simply be a group toggle action in the definition file. Sure, but sometimes you're left without X, and that's not a reason for suddenly completely loose typing speed. 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
