lkml.org 
[lkml]   [1998]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.836 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site