linux-kernel - Re: Re (hello?): [PATCH] Let keyboard notifiers modify key codes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090113010613.GA23244@cisco.com>
Date:	Tue, 13 Jan 2009 01:06:13 +0000
From:	Derek Fawcus <dfawcus@...co.com>
To:	Samuel Thibault <samuel.thibault@...-lyon.org>,
	linux-kernel@...r.kernel.org, dmitry.torokhov@...il.com,
	linux-input@...r.kernel.org
Subject: Re: Re (hello?): [PATCH] Let keyboard notifiers modify key codes

On Mon, Jan 12, 2009 at 11:51:12PM +0100, Samuel Thibault wrote:
> 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.

reemit?  as in inject back to the kernel?  How does one prevent loops?

If one is able to in effect divert the event stream out of the kernel
and then back in to the normal evdev-> keyboard stream that would seem
a workable approach.

> > 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?
(Don't have source on this machine,  so can't easily check).

> 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.

Yup that is - my program for remapping affects all VTs - and more to
the point - X11 as well.

> > 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).

However,  having written a prog for some of the pty interaction,  it is
a lot larger that the diff you posted.

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.

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