Messages in this thread | | | Date | Thu, 2 Apr 1998 15:42:31 +0200 (MET DST) | From | (Guest section DW) | Subject | Re: Lost keypresses [was Re: GGI and cli/sti in X] |
| |
From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
On Wed, 1 Apr 1998, Harald Koenig wrote: > On Mar 29, Pavel Machek wrote: > > Also, until X use medium raw mode & kernel is modified, shift state > > will be lost accross console switches. I'm thinking of forcing X into > > medium raw, but it is hard... > > > > Q: Do you think we can force X not to use full raw mode? > > IIRC, one argument against that was not to trap Alt-Fn in X so that > X applications can use those key sequences.
So in VC_MEDIUMRAW Alt_Fn will cause a VC switch under X? Hmmm...
One other problem I encountered yesterday...
XF68_FBDev asks the kernel for the keyboard mapping. This worked fine on Amiga/Atari/Apollo/Mac, and even on the PPC with ADB keyboard. All the keyboard drivers on those machines generate single scancodes, so scancodes are actually the same as keycodes.
However, now I switched to a PS/2 keyboard on my CHRP box (which has both ADB and PS/2 keyboard connectors), and now X has problems with the scancode prefixes. It just ignores the 0xe0 (unknown key) and interpretes the next scancode. For e.g. cursor up, this means I get a KP_2, since the scancodes for cursor up are 0xe0 followed by the scancode for KP_2.
So my questions are:
1. Will it work if I change the keyboard mode from VC_RAW to VC_MEDIUMRAW? AFAIK the only difference is that VC_MEDIUMRAW sends single keycodes, while VC_RAW sends scancodes, which may be prefixed. I haven't tried it yet, though.
2. Is there a good reason for keeping the scancode system? Life would be much easier if each key would generate a unique single keycode. (preferably even 16 bit, since 8 bit (7 bit plus up/down bit) is too limited for some keyboards)
Greetings,
Geert
Hmm lots of people writing about Lost Keypresses. Probably the only moment that is a concern is when one switches to X using Alt-Fn and decides that one wanted a different console, and immediately uses Alt-Fm without releasing Alt. Only a very minor nuisance, not worth starting major projects for.
About the difference between scancodes and keycodes: When you press a key the keyboard hardware generates a stream of between zero and six (on a PC) scancodes. An application just wants to see what key you pressed, so has to assemble these scancodes into the keycode, some arbitrary number attached to the keys. If the application does not use VC_RAW but VC_MEDIUMRAW then the kernel will do the assembling - that is better, this way the application does not need knowledge about the scancodes generated by various keyboards.
Linux uses the arbitrary numbering 1, 2, ... and reserves 0 for special purposes. The authors of the non-Intel keyboard drivers have not understood that keycodes are completely arbitrary and also produce keycode 0 (for scancode 0). *That is a bug.*
> Is there a good reason for keeping the scancode system?
On a kernel list this is a meaningless question. The hardware produces scancodes so the kernel has to deal with them. It is up to the application to request either scancodes or keycodes, so the above question is appropriate only on an X list.
> 16 bit keycodes?
We will probably need them sooner or later, but not sooner, so for the time being we might as well forget this idea. People do not have keyboards with 128 keys or more.
The disadvantage of 16-bit keycodes is that keymaps become sparse tables, both in the kernel and in the applications that do their own decoding. That is definitely inconvenient, and there is nothing we win.
Andries - who used to maintain the keyboard/console driver before the concept of maintainer was invented, and until 1.3.1 - typing from the keyboard of dwguest.
PS - I do not read linux-kernel, that is, only on April 1st. If you reply, please cc to aeb@cwi.nl (and not to dwguest).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |