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