[9fans] getting rid of kernel kbd maps

[9fans] getting rid of kernel kbd maps

[Fco.J.Ballesteros]

We still have (at least) two keyboard drivers, and I
don't like that much.

Would everybody be happy if

1. the kernel included just the std kbd.c driver

2. A user level driver could be started by boot(8)
in those cases where kbd maps are wanted. This
driver could just put the native keyboard in raw mode
and translate runes as it wants (using the maps), then
service fake /dev/cons and /dev/consctl files to pretend
that they are the keyboard.

If everybode is happy with that, and therefore it would
save me from merging our local driver with the distributed
one everytime it changes, I'm willing to do the change.

I say this because I'm about to try what presotto suggested
for the usb keyboard driver (i.e. to bind a fake console file),
and I thought it could be also a way to go back and get
a single keyboard driver for all plan 9 sites.

let me know what you think.
thanks anyway.

Re: [9fans] getting rid of kernel kbd maps

[mirtchov]

> We still have (at least) two keyboard drivers, and I
> don't like that much.
>
> Would everybody be happy if

I'm all for it.  Especially if it'll appear in the default Plan 9
distribution on sources, and make it easier for people unfamiliar with
compiling Plan 9 kernels to start using.

Do you have a way of dynamically adding (switching) keyboard support,
or do you have all the keyboard maps compiled in the user-level
program?  Say I wanted to switch from Bulgarian to Spanish keyboards,
do I need to have both compiled in beforehand?

andrey

Re: [9fans] getting rid of kernel kbd maps

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

Well, to keep (almost? ;-)) all of us happy, we have
F1, F2, ... to activate keymap #1, #2, ...
also we have devkbmap to download/change even
more maps. The reason to have them compiled in
is that I wanted the spanish keymap in the password
prompt (at boot(8) time). The reason to add dynamic
ones is that there're 9fans that strongly asked for it,
IIRC their reason was to debug the addition of more
keymaps.

The plan I suggest is to move what we already have
into the user level keyboard driver (the usb one would
also do it) and remove it from the kernel. But I wouldn't
like to do that if it would not unify what we all do with
keyboards.

So, votes against?

[-- Attachment #2: Type: message/rfc822, Size: 2197 bytes --]

From: mirtchov@cpsc.ucalgary.ca
To: 9fans@cse.psu.edu
Subject: Re: [9fans] getting rid of kernel kbd maps
Date: Mon, 10 Nov 2003 10:26:22 -0700
Message-ID: <52bc3d0438a6b813c633cd561a8f134c@plan9.ucalgary.ca>

> We still have (at least) two keyboard drivers, and I
> don't like that much.
>
> Would everybody be happy if

I'm all for it.  Especially if it'll appear in the default Plan 9
distribution on sources, and make it easier for people unfamiliar with
compiling Plan 9 kernels to start using.

Do you have a way of dynamically adding (switching) keyboard support,
or do you have all the keyboard maps compiled in the user-level
program?  Say I wanted to switch from Bulgarian to Spanish keyboards,
do I need to have both compiled in beforehand?

andrey

Re: [9fans] getting rid of kernel kbd maps

[Dan Cross]

"Fco.J.Ballesteros" <nemo@plan9.escet.urjc.es> writes:
> let me know what you think.

I say go for it.  And pull latin1() up into the library while you're at it!

	- Dan C.

Re: [9fans] getting rid of kernel kbd maps

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 31 bytes --]

latin1() was already pulled :-)

[-- Attachment #2: Type: message/rfc822, Size: 2183 bytes --]

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] getting rid of kernel kbd maps
Date: Mon, 10 Nov 2003 13:36:34 -0500
Message-ID: <200311101836.hAAIaYl19249@augusta.math.psu.edu>

"Fco.J.Ballesteros" <nemo@plan9.escet.urjc.es> writes:
> let me know what you think.

I say go for it.  And pull latin1() up into the library while you're at it!

	- Dan C.

Re: [9fans] getting rid of kernel kbd maps

[Ramon]

I oppose that usage of keys. The user can change the keyboard mapping
using an application. For password prompt, I think that this part of
the boot process should be stored in a shell script, perhaps stored in
a virtual disk inside the kernel image. That is IHMO needed anyway, so
that the startup process can be customized without recompiling the
kernel.

Ramon

Re: [9fans] getting rid of kernel kbd maps

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 305 bytes --]

??
Don't understand.

Currently, the alternate driver services maps.
I'd like to get rid of it. THere's also a user level
(usb) driver that could be modified to operate
on cons(3) to translate keys (i.e. to implement
the keymaps without putting the burden in the
kernel).  That was the proposal.

[-- Attachment #2: Type: message/rfc822, Size: 2317 bytes --]

From: Ramon <ramon_gnews@terra.es>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] getting rid of kernel kbd maps
Date: Wed, 12 Nov 2003 09:38:33 GMT
Message-ID: <28601514.0311111235.5ffb44c@posting.google.com>

I oppose that usage of keys. The user can change the keyboard mapping
using an application. For password prompt, I think that this part of
the boot process should be stored in a shell script, perhaps stored in
a virtual disk inside the kernel image. That is IHMO needed anyway, so
that the startup process can be customized without recompiling the
kernel.

Ramon