All of lore.kernel.org
 help / color / mirror / Atom feed
* KDGKBENT and unicode
@ 2008-09-24 13:25 tike64
  0 siblings, 0 replies; only message in thread
From: tike64 @ 2008-09-24 13:25 UTC (permalink / raw)
  To: linux-kernel

Dear linux-kernel,

I am trying to read keyboard in raw mode (K_MEDIUMRAW, to be exact). I 
hope to avoid reading all the keymaps from the kernel to the application 
for keycode translation. Therefore I call KDGKBENT ioctl for every 
keycode I get from the tty. Basically this works except, when the 
translation result is an unicode keysym or should I say the unicode 
value happens to be greater than 0xFF, I get K_HOLE.

This observation seems to be in harmony with the drivers/char/vt_ioctl.c 
code. There I learned that, if I had the keyboard in the K_UNICODE mode, 
I could get directly the 16 bit unicode values.

So I have two options:

1) Read the keymaps in K_UNICODE mode and do the translations myself 
while in K_MEDIUMRAW mode

2) For each keycode switch to K_UNICODE mode, ask the translation from 
kernel, switch back to K_MEDIUMRAW mode and read the next keycode (the 
continuous switching might have severe side effects).

The question is am I correct so far or am I miserably confused? Aren't 
there any smarter ways to do the translation?

The next question probably must be how do I handle CAPS with kernel 
keymaps? As the CAPS sensitivity is encoded in the type field of keysym 
value, it is lost when the value is 16 bit unicode. I am seeing this 
phenomenon in ordinary VT when I manage to load some keysyms as 16 bit 
unicode.

--

Timo

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2008-09-24 13:59 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-24 13:25 KDGKBENT and unicode tike64

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.