Re: keyboard problem with 2.6.6

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    Vojtech> On Fri, May 28, 2004 at 04:59:55PM +0300, Tuukka Toivonen
    Vojtech> wrote:
    >> Giuseppe Bilotta wrote: >The new system has some ups and
    >> downs. The biggest "down", >which is that of RAW mode not being
    >> available anymore (it's >emulated!) could be circumvented by
    >> having both the RAW and >translated codes move between layers.
    >> 
    >> Ouch! If the user asks for raw mode, he doesn't get it, but
    >> some emulated mode? To me this sounds like a big
    >> incompatibility.

    Vojtech> Q1: What would you do if the user has an USB keyboard?

If he was  raw mode from a  USB keyboard, he should get  the raw data.
Of course, he should know what he's doing.


    Vojtech> Q2: What application should be looking at the raw data
    Vojtech> outside the kernel and why?

What application should be looking at  the raw data from an RS232 port
outside the kernel and why?

Why do you  leave 'efax' in userspace, letting  it read/write raw data
to/from the modem via the RS232?


    >> Fortunately this patch (written together with Sau Dan Lee)
    >> should give _really_ raw mode in 2.6.x too (but it's not
    >> compatible with the raw mode in 2.4.x):
    >> 
    >> http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
 
In a nutshell, I hate to be restricted by YOUR own imaginations of how
people should hack  the system.

Raw keyboard  data, for  instance, can be  captured for  analyzing how
people use the  keyboard and coming up with  a more efficient keyboard
layout (c.f. Dvorak).  That's already beyond your imaginations.



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 12:39:40PM +0200, Sau Dan Lee wrote:

>     Vojtech> Q1: What would you do if the user has an USB keyboard?
> 
> If he was  raw mode from a  USB keyboard, he should get  the raw data.
> Of course, he should know what he's doing.

The USB communication is not byte-oriented, so that wouldn't work.
Anyway, if we could pass the USB data in some form through the console
in raw mode, this would of course break XFree86, as it wouldn't
understand it.

>     Vojtech> Q2: What application should be looking at the raw data
>     Vojtech> outside the kernel and why?
> 
> What application should be looking at  the raw data from an RS232 port
> outside the kernel and why?

Terminal. Terminals use the data directly. 

Actually it's pretty annoying there isn't a higher level abstraction of
modem than a RS232 port, because when you have a softmodem, the driver
needs to implement a fake RS232 port, including fake RTS/CTS, DSR/DTR
lines, and completely fake AT commands, so that applications that expect
to talk to a RS232 port work with it.

Anyway, the RS232 port is a multi purpose port, where you can attach
many different devices to it. For the keyboard port, there is only one
option, the keyboard. Of course, unless you create a device that can use
it, but in that case you can easily write a kernel driver for it.

> Why do you  leave 'efax' in userspace, letting it read/write raw data
> to/from the modem via the RS232?

Because I draw the line of what is supposed to be in the kernel and what
belongs to userspace on a different place than you. 

>     >> Fortunately this patch (written together with Sau Dan Lee)
>     >> should give _really_ raw mode in 2.6.x too (but it's not
>     >> compatible with the raw mode in 2.4.x):
>     >> 
>     >> http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
>  
> In a nutshell, I hate to be restricted by YOUR own imaginations of how
> people should hack  the system.

You're not. You're free to hack the kernel drivers. You can do whatever
you wish. But I also have the option to not use your creations in the
input system.

> Raw keyboard  data, for  instance, can be  captured for  analyzing how
> people use the  keyboard and coming up with  a more efficient keyboard
> layout (c.f. Dvorak).  That's already beyond your imaginations.

The raw data not what you want to use there. You want the keystroke
data, and for that you can use the /dev/input/event interface, where you
get them in a sane format (as opposed to the PS/2 rawmode, which can
send up ot 8 bytes for a single keystroke).

Then your statistic analyser will work just fine even on a Sun, Mac, or
with an USB keyboard.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    Vojtech> Q2: What application should be looking at the raw data
    Vojtech> outside the kernel and why?
    >>  What application should be looking at the raw data from an
    >> RS232 port outside the kernel and why?

    Vojtech> Terminal. Terminals use the data directly.

Now, what prevents people from  connecting terminals to a computer via
the PS/2 mouse port?

There are  mice which can be attached  to both the RS232  port AND the
PS/2 mouse port, needing only  an adaptor.  It should also be possible
to use  a similar technique  to connect a  terminal to the  PS/2 mouse
port.  This would be useful when you run out of RS232 ports.

Your  approach   in  the  input  system  completely   rules  out  this
possibility.


    Vojtech> Anyway, the RS232 port is a multi purpose port, where you
    Vojtech> can attach many different devices to it. For the keyboard
    Vojtech> port, there is only one option, the keyboard. 

What a big assumption.  Yes, I admit that I don't know of any hardware
implementations  that use  the PS/2  (or AT)  keyboard port  for other
purposes.  Maybe there are POS systems like that?


    Vojtech> Of course, unless you create a device that can use it,
    Vojtech> but in that case you can easily write a kernel driver for
    Vojtech> it.

How about  the PS/2 mouse  port?  It's not  just for mice.   There ARE
implementations using it for other things: touchpad, touchscreen, etc.
Your input  driver places that  stupid assumption that there  can't be
other devices  outside your support list  that may use  the PS/2 mouse
port, and  you make the  stupid assumption on  HOW the port  should be
used.  That's within your  imaginations.  You're limiting other people
to  your own  imaginations.   Worse still,  there  are ALREADY  things
beyond your imaginations.



    >> In a nutshell, I hate to be restricted by YOUR own imaginations
    >> of how people should hack the system.

    Vojtech> You're not. You're free to hack the kernel drivers. 

Not everyone using  Linux is patient enough to  explore the Wonderland
of kernel hacking.  Many immigrants from 2.4 are highly disappointed
by the new but incompatible mouse/keyboard behaviours.  Some of them
returned to their 2.4 homeland because of this.

Not every new immigrant are that devoted to make the new country good.
Many simply hop  back to the original country, or  hop to another that
_may_ suit them better.



    >> Raw keyboard data, for instance, can be captured for analyzing
    >> how people use the keyboard and coming up with a more efficient
    >> keyboard layout (c.f. Dvorak).  That's already beyond your
    >> imaginations.

    Vojtech> The raw data not what you want to use there. You want the
    Vojtech> keystroke data,

No.   I want  the  raw bytes.   (That's  also useful  for debugging  a
hardware,  in  case  people  are  making  or  experimenting  with  new
hardware.)


    Vojtech>  and for that you can use the /dev/input/event interface,

But that's polluted  with some (0,0,0) events.  In  some situations, I
NEED the raw, uninterpreted bytes,  much like people liking to watch a
film or read  a book in the *original* language  version, not a dubbed
or translated version.

    Vojtech> where you get them in a sane format (as opposed to the
    Vojtech> PS/2 rawmode, which can send up ot 8 bytes for a single
    Vojtech> keystroke).

Sane != helpful or more useful.

I could study the  I-Ching in English, but I would prefer  to do it in
Chinese.  Now, your  approach is forcing me to do  it in English.  And
you believe that's a good idea.



    Vojtech> Then your statistic analyser will work just fine even on
    Vojtech> a Sun, Mac, or with an USB keyboard.

But it will not be able  to handle the specifics.  (That's the problem
with  generic tools  in  general.  But  you  shouldn't be  restricting
people to only those tools.  Some people have specific needs, and they
should not be ignored.)



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Russell King]

On Sun, May 30, 2004 at 01:40:03PM +0200, Sau Dan Lee wrote:
> Now, what prevents people from  connecting terminals to a computer via
> the PS/2 mouse port?

Apart from electrically blowing the PS/2 port, the data format of PS/2
is well defined and fixed, whereas a UART (8250-based) port is more
flexible.  PS/2 also has the idea of acknowledgement from the peripheral
device for each byte transferred, and is synchronous, whereas UARTs
have no acknowledgement and are asyncrhonous.

So, any thought that the two ports are similar compatible with each other,
either from the electrical or protocol points of view is just a dead loss.

How do these mice work on both ports then?  They can detect which port
they're connected to and the electronics inside automatically configures
itself depending on which port they're connected to.

> Your  approach   in  the  input  system  completely   rules  out  this
> possibility.

As from above, its more than just the input system - its the protocol
and electrical characteristics which completely rules out the
possibility - which in turn makes it nonsensible to support such an
idea in software.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 01:40:03PM +0200, Sau Dan Lee wrote:
> >>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
> 
>     Vojtech> Q2: What application should be looking at the raw data
>     Vojtech> outside the kernel and why?
>     >>  What application should be looking at the raw data from an
>     >> RS232 port outside the kernel and why?
> 
>     Vojtech> Terminal. Terminals use the data directly.
> 
> Now, what prevents people from  connecting terminals to a computer via
> the PS/2 mouse port?

Their sanity.

Anyway, I don't oppose having the raw data available.

> There are  mice which can be attached  to both the RS232  port AND the
> PS/2 mouse port, needing only  an adaptor.  It should also be possible
> to use  a similar technique  to connect a  terminal to the  PS/2 mouse
> port.  This would be useful when you run out of RS232 ports.

Go ahead and try it. You'll fry your KBD port.

> Your  approach   in  the  input  system  completely   rules  out  this
> possibility.

Not such a big loss.

>     Vojtech> Anyway, the RS232 port is a multi purpose port, where you
>     Vojtech> can attach many different devices to it. For the keyboard
>     Vojtech> port, there is only one option, the keyboard. 
> 
> What a big assumption.  Yes, I admit that I don't know of any hardware
> implementations  that use  the PS/2  (or AT)  keyboard port  for other
> purposes.  Maybe there are POS systems like that?

No. The KBD interface is asymetric, only works on short distances, is
slow, cannot pass arbitrary data through, as it's by default translated
by the keyboard contoller, already assuming it's sending keyboard data,
all in all, it's completely unsuitable for anything else than a
keyboard.

You even cannot connect a mouse over it in the default mode of the port.

>     Vojtech> Of course, unless you create a device that can use it,
>     Vojtech> but in that case you can easily write a kernel driver for
>     Vojtech> it.
> 
> How about  the PS/2 mouse  port?  It's not  just for mice.   There ARE
> implementations using it for other things: touchpad, touchscreen, etc.

All simulate a mouse. Some have somewhat extended protocols, but those
protocols are still bound by mouse packet constraints, because the
controllers tend to do nasty things to the data passing through, like
merging input from multiple devices together into one stream by summing
the packets, etc.

> Your input  driver places that  stupid assumption that there  can't be
> other devices  outside your support list  that may use  the PS/2 mouse
> port, and  you make the  stupid assumption on  HOW the port  should be
> used.  That's within your  imaginations.  You're limiting other people
> to  your own  imaginations.   Worse still,  there  are ALREADY  things
> beyond your imaginations.

No. I'm just saying - if you want something that's not in the kernel
drivers, just write a driver for it. But the driver must be able to
coexist with the other drivers.

Your psaux/userspace serio driver is fine, except it cannot coexist with
the other drivers.

> Not everyone using  Linux is patient enough to  explore the Wonderland
> of kernel hacking.  Many immigrants from 2.4 are highly disappointed
> by the new but incompatible mouse/keyboard behaviours.  Some of them
> returned to their 2.4 homeland because of this.

Life's a change.

Anyway, at least 99% setups just keep working in 2.6.

> Not every new immigrant are that devoted to make the new country good.
> Many simply hop  back to the original country, or  hop to another that
> _may_ suit them better.

That's their freedom to do.

>     >> Raw keyboard data, for instance, can be captured for analyzing
>     >> how people use the keyboard and coming up with a more efficient
>     >> keyboard layout (c.f. Dvorak).  That's already beyond your
>     >> imaginations.
> 
>     Vojtech> The raw data not what you want to use there. You want the
>     Vojtech> keystroke data,
> 
> No.   I want  the  raw bytes.   (That's  also useful  for debugging  a
> hardware,  in  case  people  are  making  or  experimenting  with  new
> hardware.)

Sure. For debugging purposes, yes. But for analyzing the typing
behavior, the abstract data is better.

>     Vojtech>  and for that you can use the /dev/input/event interface,
> 
> But that's polluted  with some (0,0,0) events.  In  some situations, I
> NEED the raw, uninterpreted bytes,  much like people liking to watch a
> film or read  a book in the *original* language  version, not a dubbed
> or translated version.

Polluted. ;) Sorry, they're intentional. They're EV_SYN, SYN_REPORT
events, as you can find in input.h. They inform you that this is the end
of the whole report, which is useful for example for mice, where you
have more than one event (REL_X, REL_Y) per a report. 

The application reading the device is supposed to queue all events up to
the SYN_REPORT event, and then process them, so that a mouse pointer
will move diagonally instead of following the sides of a rectangle,
which would be very annoying.

> 
>     Vojtech> where you get them in a sane format (as opposed to the
>     Vojtech> PS/2 rawmode, which can send up ot 8 bytes for a single
>     Vojtech> keystroke).
> 
> Sane != helpful or more useful.
> 
> I could study the  I-Ching in English, but I would prefer  to do it in
> Chinese.  Now, your  approach is forcing me to do  it in English.  And
> you believe that's a good idea.

In your example, you wanted to study the frequency of keypresses, and
their relations. For that, it's best to ask the kernel to report
keypresses to you.

Should you want to analyze the keyboard protocol, the raw data is the
way to go. But that's been done many times before anyway.

>     Vojtech> Then your statistic analyser will work just fine even on
>     Vojtech> a Sun, Mac, or with an USB keyboard.
> 
> But it will not be able  to handle the specifics.  (That's the problem
> with  generic tools  in  general.  But  you  shouldn't be  restricting
> people to only those tools.  Some people have specific needs, and they
> should not be ignored.)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    >>  How about the PS/2 mouse port?  It's not just for mice.  There
    >> ARE implementations using it for other things: touchpad,
    >> touchscreen, etc.

    Vojtech> All simulate a mouse. 

Yeah.  All can fall back to  PS/2 mouse emulation mode.  But to enable
the extended features,  you need to write to the  port to enable them,
and then interpret the extended data formats.



    Vojtech> No. I'm just saying - if you want something that's not in
    Vojtech> the kernel drivers, just write a driver for it. But the
    Vojtech> driver must be able to coexist with the other drivers.

It's easier to write a mouse  driver in userspace than in kernel.  But
with the  input system  in 2.6, I  am *forced*  to write it  in kernel
space, and  reboot and  reboot and reboot  when it oops.   Writing the
driver in kernel  space, I at most get a segfault.   Plus I cannot use
everything from glibc.  It simply  takes more time and energy to write
a kernel space driver.


    Vojtech> Your psaux/userspace serio driver is fine, except it
    Vojtech> cannot coexist with the other drivers.

That's why I've abandoned it.  It's obsolete.

Our (Tuukka and I) SERIO_USERDEV  patch does work with kernel drivers,
and allow  both kernel  and userland drivers  to coexist.   Again, I'm
disappointed that you still haven't discovered this.


Now, it's time  for you to try our SERIO_USERDEV  patch, plus my crude
userspace atkbd.c and psmouse drivers.


    Vojtech> Anyway, at least 99% setups just keep working in 2.6.

But  not 100%  compatibly.   Mouse  moving twice  as  fast, mouse  not
accelerating, etc.  And  tp4d not working any more.   And touch screen
not working. ...


    Vojtech> The raw data not what you want to use there. You want the
    Vojtech> keystroke data,
    >>  No.  I want the raw bytes.  (That's also useful for debugging
    >> a hardware, in case people are making or experimenting with new
    >> hardware.)

    Vojtech> Sure. For debugging purposes, yes. But for analyzing the
    Vojtech> typing behavior, the abstract data is better.

It depends on  what level I want  to analyze at.  How come  you have a
crystal ball telling you that you know what I want?



    >> I could study the I-Ching in English, but I would prefer to do
    >> it in Chinese.  Now, your approach is forcing me to do it in
    >> English.  And you believe that's a good idea.

    Vojtech> In your example, you wanted to study the frequency of
    Vojtech> keypresses, and their relations. For that, it's best to
    Vojtech> ask the kernel to report keypresses to you.

No.  The kernel has already translated the data.



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

SERIO_USERDEV patch for 2.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 03:25:10PM +0200, Sau Dan Lee wrote:
 
>     Vojtech> Your psaux/userspace serio driver is fine, except it
>     Vojtech> cannot coexist with the other drivers.
> 
> That's why I've abandoned it.  It's obsolete.
> 
> Our (Tuukka and I) SERIO_USERDEV  patch does work with kernel drivers,
> and allow  both kernel  and userland drivers  to coexist.   Again, I'm
> disappointed that you still haven't discovered this.

The newest I could find:

linux-2.6.5-userdev.20040507.patch

Known problems:
	- The kernel internal psmouse driver should not be loaded when using
	  user space driver, otherwise the drivers may try to initialize the
	  device into incompatible state.

That's what I call 'cannot coexist with other kernel drivers'.
Coexisting would mean that when someone wants to open the raw device,
the serio layer would disconnect the psmouse driver, and give control to
the raw device instead. I believe that could work.

Anyway, looking at the patch, it's not bad, and it's quite close to what
I was considering to write. I'd like to keep it separate from the
serio.c file, although it's obvious it'll require to be linked to it
statically, because it needs hooks there - it cannot be a regular serio
driver.

> Now, it's time  for you to try our SERIO_USERDEV  patch, plus my crude
> userspace atkbd.c and psmouse drivers.

It's indeed time for me to examine the SERIO_USERDEV patch, and I
should've examined it earlier than now, sorry for that, but I don't need
to test your userspace drivers, as I'm not interested in those.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SERIO_USERDEV patch for 2.6

[Dmitry Torokhov]

On Sunday 30 May 2004 08:42 am, Vojtech Pavlik wrote:
> 
> Anyway, looking at the patch, it's not bad, and it's quite close to what
> I was considering to write. I'd like to keep it separate from the
> serio.c file, although it's obvious it'll require to be linked to it
> statically, because it needs hooks there - it cannot be a regular serio
> driver.
> 

Do we really have to have this stuff directly in serio? How about being able
to mark some serio ports as working in raw mode (i8042.raw=0,1,1,0) and have
separate (serio_raw?) module bind to such ports

Warning - the patch below is not really tested and may not apply to Linus'
tree. 

-- 
Dmitry


===================================================================


ChangeSet@1.1743.7.10, 2004-05-29 22:19:16-05:00, dtor_core@ameritech.net
  Input: i8042 - add kernel parameter to allow mark some of AUX ports
         as raw (SERIO_8042_RAW). This will cause psmouse module ignore
         these ports and will allow bytestream driver serve data to the
         userspace.


 Documentation/kernel-parameters.txt |    2 ++
 drivers/input/serio/i8042.c         |   15 +++++++++++++--
 include/linux/serio.h               |    1 +
 3 files changed, 16 insertions(+), 2 deletions(-)


===================================================================



diff -Nru a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt	2004-05-30 10:08:34 -05:00
+++ b/Documentation/kernel-parameters.txt	2004-05-30 10:08:34 -05:00
@@ -464,6 +464,8 @@
 	i8042.noaux	[HW] Don't check for auxiliary (== mouse) port
 	i8042.nomux	[HW] Don't check presence of an active multiplexing
 			     controller
+	i8042.raw	[HW] Specifies which AUX ports should be marked as raw
+			Format: <aux1>,<aux2>,<aux3>,<aux4>
 	i8042.reset	[HW] Reset the controller during init and cleanup
 	i8042.unlock	[HW] Unlock (ignore) the keylock
 
diff -Nru a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
--- a/drivers/input/serio/i8042.c	2004-05-30 10:08:34 -05:00
+++ b/drivers/input/serio/i8042.c	2004-05-30 10:08:34 -05:00
@@ -52,6 +52,11 @@
 module_param_named(dumbkbd, i8042_dumbkbd, bool, 0);
 MODULE_PARM_DESC(dumbkbd, "Pretend that controller can only read data from keyboard");
 
+static unsigned int i8042_aux_raw[4];
+static unsigned int i8042_aux_raw_nargs;
+module_param_array_named(raw, i8042_aux_raw, bool, i8042_aux_raw_nargs, 0);
+MODULE_PARM_DESC(raw, "Specifies which AUX ports should be marked as RAW");
+
 __obsolete_setup("i8042_noaux");
 __obsolete_setup("i8042_nomux");
 __obsolete_setup("i8042_unlock");
@@ -651,8 +656,9 @@
 		return -1;
 	}
 
-	printk(KERN_INFO "serio: i8042 %s port at %#lx,%#lx irq %d\n",
+	printk(KERN_INFO "serio: i8042 %s port %s at %#lx,%#lx irq %d\n",
 	       values->name,
+	       port->type == SERIO_8042_RAW ? "(raw)" : "",
 	       (unsigned long) I8042_DATA_REG,
 	       (unsigned long) I8042_COMMAND_REG,
 	       values->irq);
@@ -936,6 +942,8 @@
 	sprintf(i8042_mux_names[index], "i8042 Aux-%d Port", index);
 	sprintf(i8042_mux_phys[index], I8042_MUX_PHYS_DESC, index + 1);
 	sprintf(i8042_mux_short[index], "AUX%d", index);
+	if (i8042_aux_raw[index])
+		port->type = SERIO_8042_RAW;
 	port->name = i8042_mux_names[index];
 	port->phys = i8042_mux_phys[index];
 	port->driver = values;
@@ -970,8 +978,11 @@
 				i8042_init_mux_values(i8042_mux_values + i, i8042_mux_port + i, i);
 				i8042_port_register(i8042_mux_values + i, i8042_mux_port + i);
 			}
-		else
+		else {
+			if (i8042_aux_raw[0])
+				i8042_aux_port.type = SERIO_8042_RAW;
 			i8042_port_register(&i8042_aux_values, &i8042_aux_port);
+		}
 	}
 
 	i8042_port_register(&i8042_kbd_values, &i8042_kbd_port);
diff -Nru a/include/linux/serio.h b/include/linux/serio.h
--- a/include/linux/serio.h	2004-05-30 10:08:34 -05:00
+++ b/include/linux/serio.h	2004-05-30 10:08:34 -05:00
@@ -108,6 +108,7 @@
 #define SERIO_PC9800	0x04000000UL
 #define SERIO_PS_PSTHRU	0x05000000UL
 #define SERIO_8042_XL	0x06000000UL
+#define SERIO_8042_RAW	0x07000000UL
 
 #define SERIO_PROTO	0xFFUL
 #define SERIO_MSC	0x01

Re: SERIO_USERDEV patch for 2.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 10:09:18AM -0500, Dmitry Torokhov wrote:

> On Sunday 30 May 2004 08:42 am, Vojtech Pavlik wrote:
> > 
> > Anyway, looking at the patch, it's not bad, and it's quite close to what
> > I was considering to write. I'd like to keep it separate from the
> > serio.c file, although it's obvious it'll require to be linked to it
> > statically, because it needs hooks there - it cannot be a regular serio
> > driver.
> > 
> 
> Do we really have to have this stuff directly in serio? How about being able
> to mark some serio ports as working in raw mode (i8042.raw=0,1,1,0) and have
> separate (serio_raw?) module bind to such ports

We don't have to. But it'd be rather convenient to have it. It would
work for all serio ports, not just i8042, etc, etc.

And if kept in a separate file (serio-dev.c), it wouldn't mess up things
too much.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SERIO_USERDEV patch for 2.6

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 10:09:18AM -0500, Dmitry Torokhov wrote:
> 
> > On Sunday 30 May 2004 08:42 am, Vojtech Pavlik wrote:
> > > 
> > > Anyway, looking at the patch, it's not bad, and it's quite close to what
> > > I was considering to write. I'd like to keep it separate from the
> > > serio.c file, although it's obvious it'll require to be linked to it
> > > statically, because it needs hooks there - it cannot be a regular serio
> > > driver.
> > > 
> > 
> > Do we really have to have this stuff directly in serio? How about being able
> > to mark some serio ports as working in raw mode (i8042.raw=0,1,1,0) and have
> > separate (serio_raw?) module bind to such ports
> 
> We don't have to. But it'd be rather convenient to have it. It would
> work for all serio ports, not just i8042, etc, etc.
> 
> And if kept in a separate file (serio-dev.c), it wouldn't mess up things
> too much.

I'm starting to get nervous about testing this stuff ... do you 
think it will it make to 2.6.7? :)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: SERIO_USERDEV patch for 2.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 06:10:52PM +0200, Giuseppe Bilotta wrote:
> Vojtech Pavlik wrote:
> > On Sun, May 30, 2004 at 10:09:18AM -0500, Dmitry Torokhov wrote:
> > 
> > > On Sunday 30 May 2004 08:42 am, Vojtech Pavlik wrote:
> > > > 
> > > > Anyway, looking at the patch, it's not bad, and it's quite close to what
> > > > I was considering to write. I'd like to keep it separate from the
> > > > serio.c file, although it's obvious it'll require to be linked to it
> > > > statically, because it needs hooks there - it cannot be a regular serio
> > > > driver.
> > > > 
> > > 
> > > Do we really have to have this stuff directly in serio? How about being able
> > > to mark some serio ports as working in raw mode (i8042.raw=0,1,1,0) and have
> > > separate (serio_raw?) module bind to such ports
> > 
> > We don't have to. But it'd be rather convenient to have it. It would
> > work for all serio ports, not just i8042, etc, etc.
> > 
> > And if kept in a separate file (serio-dev.c), it wouldn't mess up things
> > too much.
> 
> I'm starting to get nervous about testing this stuff ... do you 
> think it will it make to 2.6.7? :)
 
No way. ;)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SERIO_USERDEV patch for 2.6

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 06:10:52PM +0200, Giuseppe Bilotta wrote:
> > I'm starting to get nervous about testing this stuff ... do you 
> > think it will it make to 2.6.7? :)
>  
> No way. ;)

Damn! :)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: SERIO_USERDEV patch for 2.6

[Dmitry Torokhov]

On Sunday 30 May 2004 10:58 am, Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 10:09:18AM -0500, Dmitry Torokhov wrote:
> 
> > On Sunday 30 May 2004 08:42 am, Vojtech Pavlik wrote:
> > > 
> > > Anyway, looking at the patch, it's not bad, and it's quite close to what
> > > I was considering to write. I'd like to keep it separate from the
> > > serio.c file, although it's obvious it'll require to be linked to it
> > > statically, because it needs hooks there - it cannot be a regular serio
> > > driver.
> > > 
> > 
> > Do we really have to have this stuff directly in serio? How about being able
> > to mark some serio ports as working in raw mode (i8042.raw=0,1,1,0) and have
> > separate (serio_raw?) module bind to such ports
> 
> We don't have to. But it'd be rather convenient to have it. It would
> work for all serio ports, not just i8042, etc, etc.
> 
> And if kept in a separate file (serio-dev.c), it wouldn't mess up things
> too much.
> 

Well, my argument is that we only have immediate need for raw access to 
PC-style AUX ports because of wide variety of connected devices. Serial
ports have other historical means of accessing them, busmice ports have
well known devices attached.

Once we have sysfs integration in place I imagine we will be able to
implement dynamic binding of serio drivers and ports, atkbd and psmouse
being default ones and user will be able to rebind a specific port to
let's say serio-raw or some other driver that does not have automatic
hardware detection yet.

But in the meantime marking several ports raw will allow most of the users
use old means of communicating with their pointing devices without too
much effort.
 
-- 
Dmitry

Re: SERIO_USERDEV patch for 2.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 11:16:31AM -0500, Dmitry Torokhov wrote:

> Well, my argument is that we only have immediate need for raw access to 
> PC-style AUX ports because of wide variety of connected devices. Serial
> ports have other historical means of accessing them, busmice ports have
> well known devices attached.

Busmice don't even have a byte-oriented protocol, so they're not
relevant here, and indeed for serial ports we can use ttyS.

Now there are a few drivers for the KBD/AUX interface that are not
i8042-based - most drivers in the serio directory. Those all would need
to be patched for enabling raw mode.

> Once we have sysfs integration in place I imagine we will be able to
> implement dynamic binding of serio drivers and ports, atkbd and psmouse
> being default ones and user will be able to rebind a specific port to
> let's say serio-raw or some other driver that does not have automatic
> hardware detection yet.

If we can do that reasonably easily via sysfs, then I'm all for that
route.

> But in the meantime marking several ports raw will allow most of the users
> use old means of communicating with their pointing devices without too
> much effort.

It'd be good to find out what devices we don't support yet (I know of
ALPS, which we have a patch pending for and IBM TouchPoints), too. 

As an interim solution, your patch plus a simple serio->userspace driver
would work, too.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SERIO_USERDEV patch for 2.6

[Dmitry Torokhov]

On Sunday 30 May 2004 03:51 pm, Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 11:16:31AM -0500, Dmitry Torokhov wrote:
> 
> > But in the meantime marking several ports raw will allow most of the users
> > use old means of communicating with their pointing devices without too
> > much effort.
> 
> It'd be good to find out what devices we don't support yet (I know of
> ALPS, which we have a patch pending for and IBM TouchPoints), too. 
> 

Sau Dan Lee's Lifebook touchscreen ;) The data processing seems to be
trivial, but I don't have any idea how to detect it. And without being
able to explicitly control binding for a specific serio port its hard
to do drivers for hardware that we can't autodetect. We just have to
assume that device behind a port is of specific type and when there
are many ports its usually wrong.
 
> As an interim solution, your patch plus a simple serio->userspace driver
> would work, too.
> 

-- 
Dmitry

Re: SERIO_USERDEV patch for 2.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 06:50:48PM -0500, Dmitry Torokhov wrote:

> > > But in the meantime marking several ports raw will allow most of the users
> > > use old means of communicating with their pointing devices without too
> > > much effort.
> > 
> > It'd be good to find out what devices we don't support yet (I know of
> > ALPS, which we have a patch pending for and IBM TouchPoints), too. 
> > 
> 
> Sau Dan Lee's Lifebook touchscreen ;) The data processing seems to be
> trivial, but I don't have any idea how to detect it. And without being
> able to explicitly control binding for a specific serio port its hard
> to do drivers for hardware that we can't autodetect. We just have to
> assume that device behind a port is of specific type and when there
> are many ports its usually wrong.

Conclusion: We need sysfs, and we need it soon.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SERIO_USERDEV patch for 2.6

[Tuukka Toivonen]

On Sun, 30 May 2004, Vojtech Pavlik wrote:

>The newest I could find:
>linux-2.6.5-userdev.20040507.patch

Yes, it's still the newest. Applies cleanly against 2.6.6 too.
I didn't want to add features before getting some feedback.

>Coexisting would mean that when someone wants to open the raw device,
>the serio layer would disconnect the psmouse driver, and give control to
>the raw device instead. I believe that could work.

If the user is careful, in practice both kernel and userspace drivers
can work simultaneously with the current code. But if you prefer otherwise,
I'll change it, no problem. However, this could take a few days
or so (busy with real work).

Dmitry suggested adding a kernel parameter to specify which ports would
allow to be read in raw mode and which would be handled by kernel drivers.
In my opinion, almost the same is achieved more conveniently by handling
in raw mode simply exactly those ports that are opened from userspace
(ie. "cat serio1" would disconnect kernel driver), and everything else by
kernel drivers.
No additional parameters would be then necessary, nor module reloads
to change anything.

The only exception I can see is if the kernel driver is loaded first
and its autodetection confuses a device. Or, for example, kernel
driver sets Touchpad into its custom mode, but then user wants to run
standard PS/2 mouse driver in user space. I don't know if the latter
driver could reset the Touchpad back into PS/2 mouse emulation mode.

>I'd like to keep it separate from the
>serio.c file, although it's obvious it'll require to be linked to it
>statically, because it needs hooks there

Agreed. I'll do that (serio-dev.c). Disadvantage: the functions
can not be anymore inline (unless I put lots of stuff into header
file) which may make code less efficient. Hopefully not significantly.

Also, I have to rename serio.c into serio-core.c so that it can be linked
into serio.o with serio-dev.o. The diff will be a bit ugly.

>It's indeed time for me to examine the SERIO_USERDEV patch, and I

Thanks for that :)

>I don't need to test your [San Dan Lee's] userspace drivers,
>as I'm not interested in those.

Fair enough. Just provide a mechanism that allows user space
protocol drivers, and let other people do them if they insist ;)

[PATCH] Re: SERIO_USERDEV patch for 2.6

[Tuukka Toivonen]

New version released which addresses the issues you mentioned:
wget \
http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.6-userdev.20040603.patch

>On Sun, 30 May 2004, Vojtech Pavlik wrote:
>>Coexisting would mean that when someone wants to open the raw device,
>>the serio layer would disconnect the psmouse driver, and give control to
>>the raw device instead. I believe that could work.

Done, with slight modification: if the device is opened in read-only mode,
the kernel drivers are not disconnected. This way the serio port could be
controlled via IOCTL even when assigned to kernel drivers, if it ever
becomes useful. Useful also for debugging etc.

>>I'd like to keep it separate from the
>>serio.c file, although it's obvious it'll require to be linked to it
>>statically, because it needs hooks there

Done. It's now in serio-dev.c. I also added serio-dev.h, which
unfortunately is slightly messy so that I was able to inline some
functions. It would be trivial to clean it up, if I wouldn't inline
those functions.

I also had to rename serio.c into serio-core.c, which makes the actual
changes into the file unobvious from the patch above. I made a separate
diff about that, shown below (just for easy comparison).

The last change I made converts slashes '/' into underscores '_' (so
eg. isa0060/serio0 is changed to isa0060_serio0 in /proc/misc, /dev
with devfs, and /sys) because Sau Dan Lee reported that slashes don't work
well with sysfs.

I tested the patch in a couple of machines, especially the new features.
Seems to work finely.

Compared to Dmitry's rawdev patch, this has a number of advantages:

- Supports all serio ports without any additional
  kernel parameters. Binding between kernel/user driver is done
  automatically.

- Supports multiple drivers on the same port, unlike Dmitry's rawdev,
  which works just similarly as 2.4.x psaux which didn't work with e.g.
  X11 and gpm together without a repeater feed, because multiple
  drivers are fighting for the byte streams.
  (Doesn't still allow multiple kernel drivers nor a kernel driver
  with a complete user drivers with write access since the required
  infrastructure is missing in serio.c aka serio-core.c: kernel internal
  drivers can't lock a port).

- Dmitry's rawdev appears to assign port numbers quite randomly. If some
  changes in i8042.c are done which register the ports in different order,
  rawdev would give ports different numbers, and since it doesn't appear
  to otherwise be possible to detect from userland which is which, drivers
  would use bad ports.
  It's even worse if also other port drivers than i8042.c would support
  raw devices, because then the module loading order would matter.
  (or so it looks from the code, I didn't actually try it).

[Do not apply the patch below, apply the complete patch given above]

--- linux-2.6.6/drivers/input/serio/serio.c	Wed Jun  2 20:23:11 2004
+++ linux-2.6.6userdev/drivers/input/serio/serio-core.c	Wed Jun  2 23:30:21 2004
@@ -30,6 +30,8 @@
  * Changes:
  * 20 Jul. 2003    Daniele Bellucci <bellucda@tiscali.it>
  *                 Minor cleanups.
+ * 31  May  2004   Tuukka Toivonen <tuukkat@ee.oulu.fi>
+ *                 Added hooks for serio-dev.c, renamed from serio.c.
  */

 #include <linux/stddef.h>
@@ -43,6 +45,10 @@
 #include <linux/suspend.h>
 #include <linux/slab.h>

+#ifdef CONFIG_SERIO_USERDEV
+#include "serio-dev.h"
+#endif
+
 MODULE_AUTHOR("Vojtech Pavlik <vojtech@ucw.cz>");
 MODULE_DESCRIPTION("Serio abstraction core");
 MODULE_LICENSE("GPL");
@@ -67,16 +73,20 @@
 	struct list_head node;
 };

-static DECLARE_MUTEX(serio_sem);
-static LIST_HEAD(serio_list);
+DECLARE_MUTEX(serio_sem);
+LIST_HEAD(serio_list);
 static LIST_HEAD(serio_dev_list);
 static LIST_HEAD(serio_event_list);
 static int serio_pid;

-static void serio_find_dev(struct serio *serio)
+void serio_find_dev(struct serio *serio)
 {
 	struct serio_dev *dev;

+#ifdef CONFIG_SERIO_USERDEV
+	if (serio_userdev_writers(serio) > 0)
+		return;
+#endif
 	list_for_each_entry(dev, &serio_dev_list, node) {
 		if (serio->dev)
 			break;
@@ -189,18 +199,25 @@
 irqreturn_t serio_interrupt(struct serio *serio,
 		unsigned char data, unsigned int flags, struct pt_regs *regs)
 {
-	irqreturn_t ret = IRQ_NONE;
+	irqreturn_t r, ret = IRQ_NONE;
+	int rescan = 1;

-        if (serio->dev && serio->dev->interrupt) {
-                ret = serio->dev->interrupt(serio, data, flags, regs);
-	} else {
-		if (!flags) {
-			if ((serio->type == SERIO_8042 ||
-				serio->type == SERIO_8042_XL) && (data != 0xaa))
-					return ret;
-			serio_rescan(serio);
-			ret = IRQ_HANDLED;
-		}
+#ifdef CONFIG_SERIO_USERDEV
+	ret = serio_userdev_newbyte(serio, data);
+	if (ret == IRQ_HANDLED)
+		rescan = 0;
+#endif
+	if (serio->dev && serio->dev->interrupt) {
+		r = serio->dev->interrupt(serio, data, flags, regs);
+		if (ret == IRQ_NONE) ret = r;
+		rescan = 0;
+	}
+	if (rescan && !flags) {
+		if ((serio->type == SERIO_8042 ||
+			serio->type == SERIO_8042_XL) && (data != 0xaa))
+				return ret;
+		serio_rescan(serio);
+		ret = IRQ_HANDLED;
 	}
 	return ret;
 }
@@ -231,6 +248,9 @@
 {
 	list_add_tail(&serio->node, &serio_list);
 	serio_find_dev(serio);
+#ifdef CONFIG_SERIO_USERDEV
+	serio_userdev_init(serio);
+#endif
 }

 void serio_unregister_port(struct serio *serio)
@@ -257,6 +277,11 @@
  */
 void __serio_unregister_port(struct serio *serio)
 {
+#ifdef CONFIG_SERIO_USERDEV
+	/* Here we assume that the interrupt handler is not anymore
+	 * called and is not still executing from previous call */
+	serio_userdev_cleanup(serio);
+#endif
 	serio_invalidate_pending_events(serio);
 	list_del_init(&serio->node);
 	if (serio->dev && serio->dev->disconnect)
@@ -268,9 +293,14 @@
 	struct serio *serio;
 	down(&serio_sem);
 	list_add_tail(&dev->node, &serio_dev_list);
-	list_for_each_entry(serio, &serio_list, node)
+	list_for_each_entry(serio, &serio_list, node) {
+#ifdef CONFIG_SERIO_USERDEV
+		if (serio_userdev_writers(serio) > 0)
+			continue;
+#endif
 		if (!serio->dev && dev->connect)
 			dev->connect(serio, dev);
+	}
 	up(&serio_sem);
 }

@@ -293,6 +323,12 @@
 int serio_open(struct serio *serio, struct serio_dev *dev)
 {
 	serio->dev = dev;
+#ifdef CONFIG_SERIO_USERDEV
+	/* When there are processes having the userdev open,
+	 * the port is already open and needs not to be re-opened. */
+	if (serio_userdev_users(serio) > 0)
+		return 0;
+#endif
 	if (serio->open(serio)) {
 		serio->dev = NULL;
 		return -1;
@@ -303,7 +339,11 @@
 /* called from serio_dev->connect/disconnect methods under serio_sem */
 void serio_close(struct serio *serio)
 {
-	serio->close(serio);
+#ifdef CONFIG_SERIO_USERDEV
+	/* Close only if the port is not open by userspace drivers */
+	if (serio_userdev_users(serio) <= 0)
+#endif
+		serio->close(serio);
 	serio->dev = NULL;
 }

Re: [PATCH] Re: SERIO_USERDEV patch for 2.6

[Sau Dan Lee]

>>>>> "Tuukka" == Tuukka Toivonen <tuukkat@ee.oulu.fi> writes:


    >> On Sun, 30 May 2004, Vojtech Pavlik wrote:
    >>> Coexisting would mean that when someone wants to open the raw
    >>> device, the serio layer would disconnect the psmouse driver,
    >>> and give control to the raw device instead. I believe that
    >>> could work.

    Tuukka> Done, with slight modification: if the device is opened in
    Tuukka> read-only mode, the kernel drivers are not
    Tuukka> disconnected. This way the serio port could be controlled
    Tuukka> via IOCTL even when assigned to kernel drivers, if it ever
    Tuukka> becomes useful. Useful also for debugging etc.

Thanks for the great work, Tuukka!  :)

I've  just   tried  it.   I   loaded  'psmouse'  and   'mousedev'  and
/proc/bus/input/devices does show the PS/2 AUX port being treated as a
mouse  device,   handled  by  'mousedev'.    Then,  I  start   gpm  on
/dev/misc/isa0060_serio1, and it works successfully.  The mouse device
disappears from /proc/bus/input/devices.  When  I kill gpm, the kernel
gets  control   again  and  the   mouse  device  shows  up   again  in
/proc/.../devices.



    Tuukka> The last change I made converts slashes '/' into
    Tuukka> underscores '_' (so eg. isa0060/serio0 is changed to
    Tuukka> isa0060_serio0 in /proc/misc, /dev with devfs, and /sys)
    Tuukka> because Sau Dan Lee reported that slashes don't work well
    Tuukka> with sysfs.

It now works in sysfs.

        $ cat /sys/class/misc/psaux/dev 
        10:1
        $ cat /sys/class/misc/isa0060_serio1/dev 
        10:63


    Tuukka> I tested the patch in a couple of machines, especially the
    Tuukka> new features.  Seems to work finely.

Works fine on mine, too.



    Tuukka> Compared to Dmitry's rawdev patch, this has a number of
    Tuukka> advantages:

    Tuukka> - Supports all serio ports without any additional kernel
    Tuukka> parameters. Binding between kernel/user driver is done
    Tuukka> automatically.

This is wonderful!  Or consider  my serio_switch patch.  We don't need
to want for  2.6.10 when they would eventually  add that together with
the sysfs interface.


    Tuukka> - Supports multiple drivers on the same port, unlike
    Tuukka> Dmitry's rawdev, which works just similarly as 2.4.x psaux
    Tuukka> which didn't work with e.g.  X11 and gpm together without
    Tuukka> a repeater feed, because multiple drivers are fighting for
    Tuukka> the byte streams.

On my system X and gpm do live with each other without conflicts, both
accessing  /dev/psaux  (either  on  2.4 or  2.6+SERIO_USERDEV).   Both
programs  can detect  VT  switching  and close  the  port when  losing
"focus".


    Tuukka> (Doesn't still allow multiple kernel drivers nor a kernel
    Tuukka> driver with a complete user drivers with write access
    Tuukka> since the required infrastructure is missing in serio.c
    Tuukka> aka serio-core.c: kernel internal drivers can't lock a
    Tuukka> port).

That's a part of the design  of the whole serio subsystem.  Unless the
design is reworked, you can't  do much about it.  The basic assumption
is: each port can be connected  to only one device, whether the device
is in kernel  or userland.  That our SERIO_USERDEV  allows userland to
overhear (O_RDONLY) the traffic is a special bonus feature.



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: [PATCH] Re: SERIO_USERDEV patch for 2.6

[Luciano Moreira - igLnx]

unsubscribe linux-kernel

>  
>

Re: [PATCH] Re: SERIO_USERDEV patch for 2.6

[Vojtech Pavlik]

On Thu, Jun 03, 2004 at 01:21:21PM +0300, Tuukka Toivonen wrote:
> New version released which addresses the issues you mentioned:
> wget \
> http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.6-userdev.20040603.patch
> 
> >On Sun, 30 May 2004, Vojtech Pavlik wrote:
> >>Coexisting would mean that when someone wants to open the raw device,
> >>the serio layer would disconnect the psmouse driver, and give control to
> >>the raw device instead. I believe that could work.
> 
> Done, with slight modification: if the device is opened in read-only mode,
> the kernel drivers are not disconnected. This way the serio port could be
> controlled via IOCTL even when assigned to kernel drivers, if it ever
> becomes useful. Useful also for debugging etc.
> 
> >>I'd like to keep it separate from the
> >>serio.c file, although it's obvious it'll require to be linked to it
> >>statically, because it needs hooks there
> 
> Done. It's now in serio-dev.c. I also added serio-dev.h, which
> unfortunately is slightly messy so that I was able to inline some
> functions. It would be trivial to clean it up, if I wouldn't inline
> those functions.
> 
> I also had to rename serio.c into serio-core.c, which makes the actual
> changes into the file unobvious from the patch above. I made a separate
> diff about that, shown below (just for easy comparison).
> 
> The last change I made converts slashes '/' into underscores '_' (so
> eg. isa0060/serio0 is changed to isa0060_serio0 in /proc/misc, /dev
> with devfs, and /sys) because Sau Dan Lee reported that slashes don't work
> well with sysfs.
> 
> I tested the patch in a couple of machines, especially the new features.
> Seems to work finely.

I like it. Give me a while to evaluate your and Dmitry's approach in
relation to future ...

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SERIO_USERDEV patch for 2.6

[Sau Dan Lee]

    Tuukka> Dmitry suggested adding a kernel parameter to specify
    Tuukka> which ports would allow to be read in raw mode and which
    Tuukka> would be handled by kernel drivers.

That means changes have to be made to ALL drivers.  That looks "ugly".


    Tuukka> In my opinion, almost the same is achieved more
    Tuukka> conveniently by handling in raw mode simply exactly those
    Tuukka> ports that are opened from userspace (ie. "cat serio1"
    Tuukka> would disconnect kernel driver), and everything else by
    Tuukka> kernel drivers.  No additional parameters would be then
    Tuukka> necessary, nor module reloads to change anything.

I have a suggestion using sysfs or procfs:

In some directory (e.g. /proc/input/serio):

        unbound_ports/  (contains a pseudo file for each serio port
                         that is not attached to any device yet)
        keyboards/      (contains a pseudo file for each serio port
                         that is attached to the keyboard device)
        mice/           (contains a pseudo file for each serio port
                         attached to mousedev.ko)
        touchscreens/   (contains a pseudo file for each serio port
                         attached to tsdev.ko)
        direct/         (contains a pseudo file for each serio port
                         that is exposed to userland (currently via "misc")
                         directly, RAW)
etc.  The contents of the pseudo files are unimportant.  (We could use
it to show useful info, though.)

Initially,  all  serio  ports  have  their  corresponding  pseudofiles
created   under   "unbound_ports".   When   a   serio  device   module
(e.g. mousedev) is loaded,  the module, in the current implementation,
will attach all mouse device  to it.  So, the corresponding entries in
"unbound_ports/" will be moved to "mice/".

If we now  want the PS AUX port  to be accessed directly, we  do a "mv
unbound_ports/isa0060.serio1 direct/".   The serio port isa0060/serio1
will   then   be  detached   from   mousedev.ko   and  reattached   to
SERIO_USERDEV,  which then  creates  /dev/misc/isa0060.serio1 for  raw
access.   Similarly,  the  user  can  "mv" any  device  between  these
directories.  Moving  it to "unbound_ports" disconnects  the port from
any device.  This userland interface should be doable!

If  I   try  to  "mv   unbound_ports/isa0060.serio1  keyboards/",  the
operation should fail because  the keyboard device cannot handle ports
connected  to  mice.  An  "rm  mice/isa0060.serio1"  should either  be
forbidden, or  be automatically translated  to "mv mice/isa0060.serio1
unbound_ports/".


Advantage: currently, the  binding of serio ports to  serio devices is
basically hardcoded  into the serio  device modules.  The  user cannot
override anything.  This is very  inflexible.  (It'd be nice it add an
option so  that they don't  attach to any  ports, leaving the  task to
some start-up scripts, which do "mv" in that proc directory.)  Suppose
that  tomorrow, someone  comes  up with  a  mousedev2.ko with  special
features that  mousedev.ko doesn't provide.  Moreover, he  has 2 mice,
and wants to attach one  to mousedev.ko and the other to mousedev2.ko.
Now,  using this  proc/sysfs  interface, he  has  complete freedom  to
attach any mouse to any serio device module.  (Without this, he has to
write mousedev2.ko  in a way  so that it  only attaches to one  of his
mice, and load this moudle before mousedev.ko, so that mousedev2 grabs
the desired mouse before mousedev steals all the two mice.)

A  similar  interface  can  also  be  used  for  fine-controlling  the
connection between input devices and input handlers.




    >> I'd like to keep it separate from the serio.c file, although
    >> it's obvious it'll require to be linked to it statically,
    >> because it needs hooks there

    Tuukka> Agreed. I'll do that (serio-dev.c). Disadvantage: the
    Tuukka> functions can not be anymore inline (unless I put lots of
    Tuukka> stuff into header file) which may make code less
    Tuukka> efficient. Hopefully not significantly.

I've also  though about separating SERIO_USERDEV into  a separate file
during the development and testing of that patch.  Like both of you, I
realized that  it is difficult to  do, because it  requires many hooks
deep into the  guts of serio.c.  Moreover, we  would need the #ifdef's
anyway,  if we  want  to  make the  USERDEV  an optional  compile-time
feature.  So, ...

The separate file doesn't have  to be linked statically.  We could use
function pointer  (i.e. hooks) variables,  or a SINGLE pointer  to one
structure  containing  func.   pointers  to  all  required  functions.
Initially, these are NULL, and serio.c would check this before calling
the hooks.  After loading the "serio_userdev" module, the module would
set these  pointers to its  functions.  Then, serio.c will  call these
functions.  These function pointers can  be removed with #if's to save
space when we  don't want the USERDEV feature  during compilation.  Of
course, the  world is not  that ideal.  There are  concurrency issues,
and we need  to keep track of which  _existing_ ports are userdev-ized
and  which aren't.   Moreover,  one more  level  of indirection  means
reduced efficiency.  I don't think it worths these complications.



BTW,   Tuukka,   I   suggest   renaming   the   "isa0060/serio?"    to
"isa0060.serio?".  The  reason is that the old  names are incompatible
with  sysfs.  I  just played  around with  sysfs, and  found something
funny:  

        $ ls /sys/class/misc
        isa0060/serio0  isa0060/serio1

        $ ls /sys/class/misc/isa0060
        ls: /sys/class/misc/isa0060: No such file or directory

This is  due to  a "/" in  the filename "isa0060/serio0",  which rests
under /sys/class/misc/.

(Should  this be  considered  a  sysfs bug?   Anyway,  renaming it  to
"isa0060.serio0" can avoid the problem.)



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: SERIO_USERDEV patch for 2.6

[Dmitry Torokhov]

On Tuesday 01 June 2004 11:50 am, Sau Dan Lee wrote:
> 
>     Tuukka> Dmitry suggested adding a kernel parameter to specify
>     Tuukka> which ports would allow to be read in raw mode and which
>     Tuukka> would be handled by kernel drivers.
> 
> That means changes have to be made to ALL drivers.  That looks "ugly".

That is only an interim solution that will be used until we have proper
sysfs support and are able to re-bind a specific driver to a specific
port. And it seems that only i8042 needs to be changed. As I said before
serial ports still accessible via /dev/ttySx, and other architectures that
provide access to SERIO_8042 type ports have much less diverse set of
peripherials... The changes can be made on as-needed basis.

So the cons of my proposal:
- Drivers need to be modified but changes are very limited.

Pros of my proposal:
- Completely non-intrusive as far as serio subsystem goes.
- The rawdev serio driver can still be used later when we have sysfs.

> 
> 
>     Tuukka> In my opinion, almost the same is achieved more
>     Tuukka> conveniently by handling in raw mode simply exactly those
>     Tuukka> ports that are opened from userspace (ie. "cat serio1"
>     Tuukka> would disconnect kernel driver), and everything else by
>     Tuukka> kernel drivers.  No additional parameters would be then
>     Tuukka> necessary, nor module reloads to change anything.
>
> I have a suggestion using sysfs or procfs:
> 
> In some directory (e.g. /proc/input/serio):
> 
>         unbound_ports/  (contains a pseudo file for each serio port
>                          that is not attached to any device yet)
>         keyboards/      (contains a pseudo file for each serio port
>                          that is attached to the keyboard device)
>         mice/           (contains a pseudo file for each serio port
>                          attached to mousedev.ko)
>         touchscreens/   (contains a pseudo file for each serio port
>                          attached to tsdev.ko)
>         direct/         (contains a pseudo file for each serio port
>                          that is exposed to userland (currently via "misc")
>                          directly, RAW)
> etc.  The contents of the pseudo files are unimportant.  (We could use
> it to show useful info, though.)
> 
> Initially,  all  serio  ports  have  their  corresponding  pseudofiles
> created   under   "unbound_ports".   When   a   serio  device   module
> (e.g. mousedev) is loaded,  the module, in the current implementation,
> will attach all mouse device  to it.  So, the corresponding entries in
> "unbound_ports/" will be moved to "mice/".
> 
> If we now  want the PS AUX port  to be accessed directly, we  do a "mv
> unbound_ports/isa0060.serio1 direct/".   The serio port isa0060/serio1

Using mv would be implementation trouble, i would rahter do:

echo "rawdev" > /sys/bus/serio/devices/serio0/driver

or something alont these lines. At least that's my grand plan ;)

-- 
Dmitry

Re: SERIO_USERDEV patch for 2.6

[Giuseppe Bilotta]

Dmitry Torokhov wrote:
> echo "rawdev" > /sys/bus/serio/devices/serio0/driver
> 
> or something alont these lines. At least that's my grand plan ;)

I like this kind of idea. Many options should be settable this 
way (think for example about Synaptics and ALPS touchpad 
configurations: whether to use multipointers separately or 
together, (de)activation of tapping, button remapping etc).

Yes, we need sysfs ...

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: SERIO_USERDEV patch for 2.6

[Dmitry Torokhov]

On Tuesday 01 June 2004 05:23 pm, Giuseppe Bilotta wrote:
> Dmitry Torokhov wrote:
> > echo "rawdev" > /sys/bus/serio/devices/serio0/driver
> > 
> > or something alont these lines. At least that's my grand plan ;)
> 
> I like this kind of idea. Many options should be settable this 
> way (think for example about Synaptics and ALPS touchpad 

Yes, exactly, it will allow much more flexible option handling. Still,
as far as your examples go: 

> configurations: whether to use multipointers separately or 
> together,
- userspace task - always persent separate devices and have application
  (GPM or X) multiplex data together.

> (de)activation of tapping,
- may be userspace task - i.e can be done in userspace if device can
  report BTN_TOUCH event. If not then kernel has to toggle it.

> button remapping etc).  
- userspace task

-- 
Dmitry

Re: SERIO_USERDEV patch for 2.6

[Giuseppe Bilotta]

Dmitry Torokhov wrote:
> On Tuesday 01 June 2004 05:23 pm, Giuseppe Bilotta wrote:
> > Dmitry Torokhov wrote:
> > > echo "rawdev" > /sys/bus/serio/devices/serio0/driver
> > > 
> > > or something alont these lines. At least that's my grand plan ;)
> > 
> > I like this kind of idea. Many options should be settable this 
> > way (think for example about Synaptics and ALPS touchpad 
> 
> Yes, exactly, it will allow much more flexible option handling. Still,
> as far as your examples go: 
> 
> > configurations: whether to use multipointers separately or 
> > together,
> - userspace task - always persent separate devices and have application
>   (GPM or X) multiplex data together.

Ok, in this case your ALPS patch need a little working ;) (Last 
time I saw it it ORed the touchpad and stick values.)

> > (de)activation of tapping,
> - may be userspace task - i.e can be done in userspace if device can
>   report BTN_TOUCH event. If not then kernel has to toggle it.

> > button remapping etc).  
> - userspace task

When you say "userspace task", are you saying that the 
filtering out of, say, BTN_TOUCH events should happen at a 
higher level than the kernel driver not reporting them at all? 
Say, in gpm?

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: keyboard problem with 2.6.6

[jsimmons]

>     Vojtech> No. I'm just saying - if you want something that's not in
>     Vojtech> the kernel drivers, just write a driver for it. But the
>     Vojtech> driver must be able to coexist with the other drivers.
> 
> It's easier to write a mouse  driver in userspace than in kernel.  But
> with the  input system  in 2.6, I  am *forced*  to write it  in kernel
> space, and  reboot and  reboot and reboot  when it oops.   Writing the
> driver in kernel  space, I at most get a segfault.   Plus I cannot use
> everything from glibc.  It simply  takes more time and energy to write
> a kernel space driver.

Why not use UML (user mode linux). Jon Smirl was using it to work on fbdev 
drivers in userland. Interrupts where tricky to handle but it might 
work fine now. I have to give it a try again. Once it is setup you can 
develope kernel driver in userland.

Re: keyboard problem with 2.6.6

[Valdis.Kletnieks]

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

On Tue, 01 Jun 2004 22:01:10 BST, jsimmons@pentafluge.infradead.org said:

> Why not use UML (user mode linux). Jon Smirl was using it to work on fbdev 
> drivers in userland. Interrupts where tricky to handle but it might 
> work fine now. I have to give it a try again. Once it is setup you can 
> develope kernel driver in userland.

UML helps the "boot/crash/reboot" cycle (and that sort of debugging was in
fact one of the early design goals of IBM's CP/67 and VM/370 systems). but
it doesn't help the fact that the infrastructure provided to kernel functions
is vastly different than the glibc-based infrastructure available in userspace....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: keyboard problem with 2.6.6

[Eduard Bloch]

Moin Vojtech!
Vojtech Pavlik schrieb am Sonntag, den 30. Mai 2004:

> >     Vojtech> Of course, unless you create a device that can use it,
> >     Vojtech> but in that case you can easily write a kernel driver for
> >     Vojtech> it.
> > 
> > How about  the PS/2 mouse  port?  It's not  just for mice.   There ARE
> > implementations using it for other things: touchpad, touchscreen, etc.
> 
> All simulate a mouse. Some have somewhat extended protocols, but those
> protocols are still bound by mouse packet constraints, because the
> controllers tend to do nasty things to the data passing through, like
> merging input from multiple devices together into one stream by summing
> the packets, etc.

Who says that merging (as it is currently done) is the best way to do?
For examle, I wish to create two terminals with my system, using two
monitors (on dual-head video card), two keyboards and two mices. I can
do the first part (X manages it well) but not beeing able to use
different input devices for different users simply SUCKS.
But http://linuxconsole.sourceforge.net/ lets me hope.

Regards,
Eduard.
-- 
Wenn ein Mensch ein Loch sieht, hat er das Bestreben, es auszufüllen.
Dabei fällt er meistens hinein.
		-- Kurt Tucholsky

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 03:54:45PM +0200, Eduard Bloch wrote:

> Moin Vojtech!
>
> Vojtech Pavlik schrieb am Sonntag, den 30. Mai 2004:
> 
> > >     Vojtech> Of course, unless you create a device that can use it,
> > >     Vojtech> but in that case you can easily write a kernel driver for
> > >     Vojtech> it.
> > > 
> > > How about  the PS/2 mouse  port?  It's not  just for mice.   There ARE
> > > implementations using it for other things: touchpad, touchscreen, etc.
> > 
> > All simulate a mouse. Some have somewhat extended protocols, but those
> > protocols are still bound by mouse packet constraints, because the
> > controllers tend to do nasty things to the data passing through, like
> > merging input from multiple devices together into one stream by summing
> > the packets, etc.
> 
> Who says that merging (as it is currently done) is the best way to do?

I definitely don't. But many notebooks do that in hardware.
My point was that it's not always possible to transfer arbitrary data
over the PS/2 port - it's not a general purpose serial port.

> For examle, I wish to create two terminals with my system, using two
> monitors (on dual-head video card), two keyboards and two mices. I can
> do the first part (X manages it well) but not beeing able to use
> different input devices for different users simply SUCKS.
> But http://linuxconsole.sourceforge.net/ lets me hope.

I wrote most of the input handling in that project. It's what is in 2.6 now.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[jsimmons]

> > For examle, I wish to create two terminals with my system, using two
> > monitors (on dual-head video card), two keyboards and two mices. I can
> > do the first part (X manages it well) but not beeing able to use
> > different input devices for different users simply SUCKS.
> > But http://linuxconsole.sourceforge.net/ lets me hope.
> 
> I wrote most of the input handling in that project. It's what is in 2.6 now.

Yeap. The majority of the fbdev stuff went in from this project as well. 
The linuxconsole project is using the current input layer with multiple 
users with no problems.

Re: keyboard problem with 2.6.6

[Pavel Machek]

Hi!

>     >> In a nutshell, I hate to be restricted by YOUR own imaginations
>     >> of how people should hack the system.
> 
>     Vojtech> You're not. You're free to hack the kernel drivers. 
> 
> Not everyone using  Linux is patient enough to  explore the Wonderland
> of kernel hacking.  Many immigrants from 2.4 are highly disappointed
> by the new but incompatible mouse/keyboard behaviours.  Some of them
> returned to their 2.4 homeland because of this.

How can you propose moving keyboard handling to userland in one thread
and complain about 2.4-vs-2.6 incompatibility of inputs in another?!

2.4-vs-2.6 broke few strange keyboards. What you are proposing would
break everyone who has a keyboard.

								Pavel
-- 
934a471f20d6580d5aad759bf0d97ddc

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:

    Valdis> The whole 'init=/bin/bash' style of recovery has been
    Valdis> widely documented and often used (for instance, it's
    Valdis> covered in the RHCE class and used in one of the hands-on
    Valdis> labs to recover a non-booting system).  That's a lot of
    Valdis> people to retrain, and a lot of systems that need
    Valdis> changing...

    Valdis> (Trust me - if it's 3AM, and you type 'init=/bin/sh' and
    Valdis> it outputs the '#' but won't take input, you WONT think of
    Valdis> that kernel and initscripts change from 3 months ago...)

Explain to me how a kernel compiled with
        CONFIG_SERIO=m
        CONFIG_KEYBOARD_ATKBD=m
would be able to boot with "init=/bin/sh" and still have the keyboard
working.

I've just verified that "make allmodconfig", which is what many people
are tempted  to do once they've  learnt about it, will  produce such a
.config.




-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Valdis.Kletnieks]

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

On Wed, 09 Jun 2004 10:17:04 +0200, Sau Dan Lee said:

> Explain to me how a kernel compiled with
>         CONFIG_SERIO=m
>         CONFIG_KEYBOARD_ATKBD=m
> would be able to boot with "init=/bin/sh" and still have the keyboard
> working.

Explain to me why you think that example is a good reason why
a kernel compiled with

CONFIG_SERIO=y
CONFIG_KEYBOARD_ATKBD=y

should *NOT* be able to boot with 'init=/bin/sh'.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:

    Valdis> On Wed, 09 Jun 2004 10:17:04 +0200, Sau Dan Lee said:
    >> Explain to me how a kernel compiled with CONFIG_SERIO=m
    >> CONFIG_KEYBOARD_ATKBD=m would be able to boot with
    >> "init=/bin/sh" and still have the keyboard working.

    Valdis> Explain to me why you think that example is a good reason
    Valdis> why a kernel compiled with

    Valdis> CONFIG_SERIO=y 
    Valdis> CONFIG_KEYBOARD_ATKBD=y

    Valdis> should *NOT* be able to boot with 'init=/bin/sh'.

"make help" shows:

    ...
    Configuration targets:
      oldconfig       - Update current config utilising a line-oriented program
      menuconfig      - Update current config utilising a menu based program
      xconfig         - Update current config utilising a QT based front-end
      gconfig         - Update current config utilising a GTK based front-end
      defconfig       - New config with default answer to all options
      allmodconfig    - New config selecting modules when possible
      allyesconfig    - New config where all options are accepted with yes
      allnoconfig     - New minimal config


A person trying to upgrade from 2.4 would suppose that the 2.4 .config
won't work and  would likely start with "make  allmodconfig", and then
"make {menu/x}config".   With 100s (or 1000s)  of configuration items,
it is not easy for a 2.4-er to discover that one now has to explicitly
enable i8042 and atkbd.  So, it is likely for him to have:

        CONFIG_SERIO=m
        CONFIG_KEYBOARD_ATKBD=m



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Valdis.Kletnieks]

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

On Wed, 09 Jun 2004 19:12:09 +0200, Sau Dan Lee said:

> A person trying to upgrade from 2.4 would suppose that the 2.4 .config
> won't work and  would likely start with "make  allmodconfig", and then
> "make {menu/x}config".   With 100s (or 1000s)  of configuration items,
> it is not easy for a 2.4-er to discover that one now has to explicitly
> enable i8042 and atkbd.  So, it is likely for him to have:
> 
>         CONFIG_SERIO=m
>         CONFIG_KEYBOARD_ATKBD=m

*plonk* <add to killfile>

OK. You proved that it's possible to create a kernel configuration that won't
boot on your hardware (hey, people who boot off IDE or SCSI and build those
drivers as modules have to play initrd games too).

Let me know when you actually answer the question - which was "Why does that
mean it's OK to break users who *do* answer with 'y' for those options?" (An
alternate way of looking at it is that you will mandate a situation where the
only *useful* values are equivalent to 'm' and 'n' - either you don't have it
at all (n) or you need userspace assistance before you have it (m).


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:

    Valdis> On Fri, 04 Jun 2004 22:33:41 +0300, Denis Vlasenko said:
    >> Using shell scripts instead of 'standard' init etc is way more
    >> configurable. As an example, my current setup at home:
    >> 
    >> My kernel params are:

    Valdis> Yes. Those are *YOUR* config setup parameters, that happen
    Valdis> to work with *your* specific configuration when everything
    Valdis> is operational. Some problems:

    Valdis> 1) Not all the world uses initrd....

Does ever /etc/rcS.d/* require initrd?

Moreover, not all the world uses a keyboard, either.



    Valdis> 2) I hope your /script/mount_root will Do The Right Thing
    Valdis> if the mount fails because it needs an fsck, for example.
    Valdis> Answering those 'y' and 'n' prompts can be a problem if
    Valdis> your keyboard isn't working yet..

Things even worse  can happen, too, such as  harddisk dying.  In those
problematic situations,  you'd rather boot a failsafe  partition, or a
rescue floppy, or Knoppix CD.


    Valdis> 3) Bonus points if you can explain how to, *without* a
    Valdis> working keyboard, modify that /linuxrc on your initrd to
    Valdis> deal with the situation where your keyboard setup is wrong
    Valdis> (think "booting with borrowed keyboard because your usual
    Valdis> one just suffered a carbonated caffeine overdose")...

How  do you  do the  same if  you had  only SCSI  disks, but  the SCSI
modules are not loaded or compiled in?


    Valdis> There's a *BASIC* bootstrapping problem here - if you move
    Valdis> "initialize and handle the keyboard" into userspace, you
    Valdis> then *require* that a significantly larger chunk of
    Valdis> userspace be operational in order to be able to even type
    Valdis> at the machine.  If you're trying to recover a *broken*
    Valdis> userspace, it gets a lot harder.


    Valdis> And the embedded people who use
    Valdis> "init=/onlyprogramthateverruns" are going to have a
    Valdis> significant collective cow about this....

Does embedded systems always have a keyboard?




-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:

    >> You don't tell any kernel about that... it is the bootloader
    >> you are talking to. And that one may very well have integrated
    >> kbd support.

    Valdis> So GRUB knows about keyboards, lets you type in the
    Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
    Valdis> init, /bin/bash gets loaded 

If  init can  launch /bin/bash  (actually,  it lauches  getty in  most
setups), why can't it start the userland keyboard driver daemon?

Back  in the  old days  before the  introduction of  /etc/rc.d/, every
daemon was started from by init.


    Valdis> - and /bin/bash can't talk to the keyboard because the
    Valdis> userspace handler hasn't happened.  

As soon as the daemon is  running, /bin/bash can talk to the keyboard.
There is not much concurrency problems here.  The current input system
makes  it possible  for /bin/bash  to start  opening the  keyboard and
waiting for input before the userspace handler is ready.


    Valdis> At that point you're stuck...

I  can't see  how stuck  it is.   And if  you fear  that  the userland
keyboard driver  would crash  (maybe due to  bugs), use  the 'respawn'
option in /etc/inittab.



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Martin Schlemmer]

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

On Sun, 2004-06-06 at 11:37, Sau Dan Lee wrote:
> >>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
> 
>     >> You don't tell any kernel about that... it is the bootloader
>     >> you are talking to. And that one may very well have integrated
>     >> kbd support.
> 
>     Valdis> So GRUB knows about keyboards, lets you type in the
>     Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
>     Valdis> init, /bin/bash gets loaded 
> 
> If  init can  launch /bin/bash  (actually,  it lauches  getty in  most
> setups), why can't it start the userland keyboard driver daemon?
> 
> Back  in the  old days  before the  introduction of  /etc/rc.d/, every
> daemon was started from by init.
> 
> 
>     Valdis> - and /bin/bash can't talk to the keyboard because the
>     Valdis> userspace handler hasn't happened.  
> 
> As soon as the daemon is  running, /bin/bash can talk to the keyboard.
> There is not much concurrency problems here.  The current input system
> makes  it possible  for /bin/bash  to start  opening the  keyboard and
> waiting for input before the userspace handler is ready.
> 
> 
>     Valdis> At that point you're stuck...
> 
> I  can't see  how stuck  it is.   And if  you fear  that  the userland
> keyboard driver  would crash  (maybe due to  bugs), use  the 'respawn'
> option in /etc/inittab.

The point is that 'init=/bin/bash' is usually used as a method to
do some _unexpected_ rescue work - meaning you usually do not think
about it (or write a shell script to start a keyboard daemon) until
you need it.  Thats it - a rescue method - and its got nothing to do
with what is in inittab, or if getty's are started or not.  Some
distro's even have sash installed by default (statically linked) in
case your glibc is borked or such, and you need to cp/mv/gunzip things.

Anyhow, the other point that should be made, is that your are really
getting boring/annoying.  Please face the fact that many of us (most?)
do not want a silly daemon for keyboard, but an in-kernel driver.
Guess what else ... Valdis, etc do not even argue with you for wanting
this silliness (besides not wanting to get rid of the in-kernel driver),
but are prepared to add raw access, so that you can go and code/use your
daemon (Ok, so maybe the raw access is for more than what you want, but
anyhow ...).

So please stop being selfish and continuing to spam the list.


Thanks,

-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, Jun 06, 2004 at 11:37:41AM +0200, Sau Dan Lee wrote:
> >>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
> 
>     >> You don't tell any kernel about that... it is the bootloader
>     >> you are talking to. And that one may very well have integrated
>     >> kbd support.
> 
>     Valdis> So GRUB knows about keyboards, lets you type in the
>     Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
>     Valdis> init, /bin/bash gets loaded 
> 
> If  init can  launch /bin/bash  (actually,  it lauches  getty in  most
> setups), why can't it start the userland keyboard driver daemon?
> 
> Back  in the  old days  before the  introduction of  /etc/rc.d/, every
> daemon was started from by init.

At the risk of being flamed, here is an explanation.

If you, at the kernel command line, type "init=/bin/bash", the bash
shell will be used _instead_ of the regular init program. This is very
useful when you made a mistake in the inittab, something deleted your
root entry in passwd/shadow, your filesystem is in trouble and in many
other cases.

This also means that there will be no other program run before or after
bash. All you get is a prompt.

This means the keyboard will have to work without any setup - or you
won't be able to type in anything, like a command to run the daemon, or
a command to insert a module.


-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Dmitry Torokhov]

On Sunday 06 June 2004 04:37 am, Sau Dan Lee wrote:
> >>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
> 
>     >> You don't tell any kernel about that... it is the bootloader
>     >> you are talking to. And that one may very well have integrated
>     >> kbd support.
> 
>     Valdis> So GRUB knows about keyboards, lets you type in the
>     Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
>     Valdis> init, /bin/bash gets loaded 
> 
> If  init can  launch /bin/bash  (actually,  it lauches  getty in  most
> setups), why can't it start the userland keyboard driver daemon?
>

Init does not start bash, in the case above bash started by the kernel
_instead_ of init. The only thing you have is bash. No regular init scripts
will be executed, nothing.
 
 > Back  in the  old days  before the  introduction of  /etc/rc.d/, every
> daemon was started from by init.
> 
> 
>     Valdis> - and /bin/bash can't talk to the keyboard because the
>     Valdis> userspace handler hasn't happened.  
> 
> As soon as the daemon is  running, /bin/bash can talk to the keyboard.

But nothing has started driver (no scriprs were run, remember?) so it's not
running and bash can't get keyboard input.
 
-- 
Dmitry

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:

    >>  If init can launch /bin/bash (actually, it lauches getty in
    >> most setups), why can't it start the userland keyboard driver
    >> daemon?
    >> 

    Dmitry> Init does not start bash, in the case above bash started
    Dmitry> by the kernel _instead_ of init. The only thing you have
    Dmitry> is bash. No regular init scripts will be executed,
    Dmitry> nothing.

If you  can launch /bin/bash  using init= from  GRUB or LILO,  you can
equally lauch a bash script  that starts the userspace keyboard driver
daemon before and then "exec /bin/bash".

Of course, you can argue that this daemon may rest on a fs that hasn't
be mounted yet,  or on a fs  that has been corrupted.  But  so can the
/bin/bash executable!

Moreover,  I  can also  argue  the kernel  image  may  also have  been
corrupted due  to disk  errors, and the  keyboard driver code  lies in
those corrupted sectors, unfortunately.



Further, a  kernel keyboard driver  can coexist with a  userspace one.
The  kernel one can  be made  simpler, providing  only the  very basic
needs.   Once the userspace  daemon starts  successfully, it  can take
over.  Programs like  X11 may drive the keyboard  directly and provide
many  sophisticated  features  that  a simple  kernel  driver  doesn't
provide.  Take a look at xkb.


-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:

    Dmitry> Here you are talking about regular startup procedure for a
    Dmitry> very special setup - yours. We were talking about
    Dmitry> emergency recovery of a "standard" Linux box.

Well... it'd be a long thread to discuss what constitutes a "standard"
Linux box, let alone what "emergency situation" should mean.


As a matter of fact, more and more people are using a Knoppix CD as an
emergency recovery boot disk, not  only for repairing Linux boxes, but
also for repairing Windows boxes.



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    Vojtech> On Sun, May 30, 2004 at 12:50:05PM +0200, Sau Dan Lee
    Vojtech> wrote:
    >> >> But apart from such debugging use, there is also the more 
    >> >> direct use: in order to assign a keycode to an unusual key one
    >> >> first asks for the scancode using scancode -s, and then
    >> >> assigns the keycode using setkeycodes. If scancode -s lies,
    >> >> this fails.
    >> 
    Vojtech> That's a good reason. I'll implement true rawmode
    Vojtech> support.

    >>  How about mouse?

    Vojtech> Not planned yet. If you can modify your driver to be able
    Vojtech> to coexist with the kernel mouse drivers, like for
    Vojtech> example SCSI drivers can, then I can include it as
    Vojtech> well. But I've not yet found a simple way to do that.

My driver (psmouse.tgz) can already  coexist with the kernel one.  The
SERIO_USERDEV patch  is also  designed to work  _hands in  hands_ with
your kernel-space drivers.

I'm quite disappointed that you are still not aware of that.  Sigh...



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 01:43:24PM +0200, Sau Dan Lee wrote:

> My driver (psmouse.tgz) can already  coexist with the kernel one.  The
> SERIO_USERDEV patch  is also  designed to work  _hands in  hands_ with
> your kernel-space drivers.
> 
> I'm quite disappointed that you are still not aware of that.  Sigh...

The last time I saw it, it wasn't able of that. Where I can find the
updated version?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    Vojtech> On Sun, May 30, 2004 at 01:43:24PM +0200, Sau Dan Lee
    Vojtech> wrote:
    >> My driver (psmouse.tgz) can already coexist with the kernel
    >> one.  The SERIO_USERDEV patch is also designed to work _hands
    >> in hands_ with your kernel-space drivers.
    >> 
    >> I'm quite disappointed that you are still not aware of that.
    >> Sigh...

    Vojtech> The last time I saw it, it wasn't able of that. Where I
    Vojtech> can find the updated version?

See the previous  mails on this thread.  I've been  giving URLs of the
SERIO_USERDEV patch as well as my userspace drivers a few times.



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Giuseppe" == Giuseppe Bilotta <bilotta78@hotpop.com> writes:

    Giuseppe> So, while we wait for complete support, at the kernel
    Giuseppe> level, for all the multimedia keyboards supported by X,
    Giuseppe> we *need* proper raw mode.

My question is: why do everything inside the kernel?


Even  'khttpd' has  been removed  from  the kernel,  because the  same
efficiency has been achieved in  the *userland* apache module.  Why is
the input layer moving _backwards_?

I  don't think  converting  between keyboard/mouse  protocols and  the
input   system's  "struct   input_event"  has   a   tighter  real-time
requirement  than a  heavily loaded  web  server.  How  many keys  per
second can  you type  at?  (Even  if you type  extremely fast  and the
hardware constraints  (velocity, etc.) are  not reached yet,  there is
still  a  limit that  the  keyboard  controller,  e.g.  i8042,  cannot
exceed.)  How  many mouse movements are  you making per  second?  Is a
userland driver unable  to handle that data rate?   (I don't think so.
I believe enve a 386-DX 33MHz  can handle it with ease.)  If not, then
please do it  in userland, so as not to waste  kernel memory (which is
*NON-swappable*).




-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Pavel Machek]

Hi!

> >>>>> "Giuseppe" == Giuseppe Bilotta <bilotta78@hotpop.com> writes:
> 
>     Giuseppe> So, while we wait for complete support, at the kernel
>     Giuseppe> level, for all the multimedia keyboards supported by X,
>     Giuseppe> we *need* proper raw mode.
> 
> My question is: why do everything inside the kernel?
> 
> 
> Even  'khttpd' has  been removed  from  the kernel,  because the  same
> efficiency has been achieved in  the *userland* apache module.  Why is
> the input layer moving _backwards_?
> 
> I  don't think  converting  between keyboard/mouse  protocols and  the
> input   system's  "struct   input_event"  has   a   tighter  real-time
> requirement  than a  heavily loaded  web  server.  How  many keys  per
> second can  you type  at?  (Even  if you type  extremely fast  and the
> hardware constraints  (velocity, etc.) are  not reached yet,  there is
> still  a  limit that  the  keyboard  controller,  e.g.  i8042,  cannot
> exceed.)  How  many mouse movements are  you making per  second?  Is a
> userland driver unable  to handle that data rate?   (I don't think so.
> I believe enve a 386-DX 33MHz  can handle it with ease.)  If not, then
> please do it  in userland, so as not to waste  kernel memory (which is
> *NON-swappable*).

It would be nice to have keyboard in kernel because that means
keyboard works even on heavilly overloaded system, in case of oops
etc. (Unfortunately steps back were already taken; console switching
is no longer so robust w.r.t. kernel crashes :-( ).

Are you able to provide accurate timestamps for input events from
userland?
								Pavel
-- 
934a471f20d6580d5aad759bf0d97ddc

Re: keyboard problem with 2.6.6

[John Bradford]

Quote from Pavel Machek <pavel@ucw.cz>:
> Hi!
> 
> > >>>>> "Giuseppe" == Giuseppe Bilotta <bilotta78@hotpop.com> writes:
> > 
> >     Giuseppe> So, while we wait for complete support, at the kernel
> >     Giuseppe> level, for all the multimedia keyboards supported by X,
> >     Giuseppe> we *need* proper raw mode.
> > 
> > My question is: why do everything inside the kernel?
> > 
> > 
> > Even  'khttpd' has  been removed  from  the kernel,  because the  same
> > efficiency has been achieved in  the *userland* apache module.  Why is
> > the input layer moving _backwards_?
> > 
> > I  don't think  converting  between keyboard/mouse  protocols and  the
> > input   system's  "struct   input_event"  has   a   tighter  real-time
> > requirement  than a  heavily loaded  web  server.  How  many keys  per
> > second can  you type  at?  (Even  if you type  extremely fast  and the
> > hardware constraints  (velocity, etc.) are  not reached yet,  there is
> > still  a  limit that  the  keyboard  controller,  e.g.  i8042,  cannot
> > exceed.)  How  many mouse movements are  you making per  second?  Is a
> > userland driver unable  to handle that data rate?   (I don't think so.
> > I believe enve a 386-DX 33MHz  can handle it with ease.)  If not, then
> > please do it  in userland, so as not to waste  kernel memory (which is
> > *NON-swappable*).
> 
> It would be nice to have keyboard in kernel because that means
> keyboard works even on heavilly overloaded system, in case of oops
> etc. (Unfortunately steps back were already taken; console switching
> is no longer so robust w.r.t. kernel crashes :-( ).

I think it's nice to have input handling for the _console_ in the kernel
for the above reasons.  In most cases a PS/2 keyboard and mouse are the
console input devices, but where they aren't, userspace processing might
be more logical.

I think that Vojtech mentioned at some time that the in-kernel PS/2 emulation
was mostly a workaround for X until X was capable of accessing the keyboard
directly.  Well, I would take this one stage further and say that the way I
see it, in normal use, an X-based system shouldn't need a console configured
in the kernel at all.

Of course, I probably wouldn't use a system like that, it wouldn't be likely
to interest me at all, but I can see that it might suit normal desktop
machines quite well.

So, in my opinion, it's all about X, and nothing about the kernel.

However, I don't even have much interest in X itself these days, prefering
to work on the console :-).

John.

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    On Sat, May 29, 2004 at 03:23:20PM +0200, Andries Brouwer
    >> Thanks for the report. It shows that resurrecting raw mode is
    >> even more desirable than I thought at first.

    Vojtech> What for?

For more imaginative innovations.

e.g. try my keyboard driver across 2 machines (using the SERIO_USERDEV
patch from Tuukka Toivonen and me):

    master$ cat /dev/misc/isa0060/serio0 | ssh slave atkbd /proc/self/fd/0

The patch is here:
    http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch

The driver is here:
    http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/atkbd.c

(I haven't  tried this, as  I don't have  2 machines under  my control
(==root) to try it out.  Please tell me the results.)



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 12:45:02PM +0200, Sau Dan Lee wrote:

> For more imaginative innovations.
> 
> e.g. try my keyboard driver across 2 machines (using the SERIO_USERDEV
> patch from Tuukka Toivonen and me):
> 
>     master$ cat /dev/misc/isa0060/serio0 | ssh slave atkbd /proc/self/fd/0
> 
> The patch is here:
>     http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
> 
> The driver is here:
>     http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/atkbd.c
> 
> (I haven't  tried this, as  I don't have  2 machines under  my control
> (==root) to try it out.  Please tell me the results.)
 
You can do this trivially without any patches, just by forwarding the
input events between the machines, reading evdev on one and using uinput
on the other. It will work without modification for mice, joysticks,
whatever you wish.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Tuukka Toivonen]

Giuseppe Bilotta wrote:
>The new system has some ups and downs. The biggest "down",
>which is that of RAW mode not being available anymore (it's
>emulated!) could be circumvented by having both the RAW and
>translated codes move between layers.

Ouch! If the user asks for raw mode, he doesn't get it, but some emulated
mode? To me this sounds like a big incompatibility. Fortunately this patch
(written together with Sau Dan Lee) should give _really_ raw mode in 2.6.x
too (but it's not compatible with the raw mode in 2.4.x):

http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Fri, May 28, 2004 at 04:59:55PM +0300, Tuukka Toivonen wrote:
> Giuseppe Bilotta wrote:
> >The new system has some ups and downs. The biggest "down",
> >which is that of RAW mode not being available anymore (it's
> >emulated!) could be circumvented by having both the RAW and
> >translated codes move between layers.
> 
> Ouch! If the user asks for raw mode, he doesn't get it, but some emulated
> mode? To me this sounds like a big incompatibility.

Q1: What would you do if the user has an USB keyboard?

Q2: What application should be looking at the raw data outside the
    kernel and why?

> Fortunately this patch
> (written together with Sau Dan Lee) should give _really_ raw mode in 2.6.x
> too (but it's not compatible with the raw mode in 2.4.x):
> 
> http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
 

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Tuukka Toivonen]

On Sat, 29 May 2004, Vojtech Pavlik wrote:

>On Fri, May 28, 2004 at 04:59:55PM +0300, Tuukka Toivonen wrote:
>> Giuseppe Bilotta wrote:
>> >The new system has some ups and downs. The biggest "down",
>> >which is that of RAW mode not being available anymore (it's
>> >emulated!) could be circumvented by having both the RAW and
>> >translated codes move between layers.
>> Ouch! If the user asks for raw mode, he doesn't get it, but some emulated
>> mode? To me this sounds like a big incompatibility.
>
>Q1: What would you do if the user has an USB keyboard?

If an application wants to access directly the keyboard, and the keyboard
happens to be USB, it should use other means to access it. I believe usbfs
provides some kind of interface for driving directly USB devices.

>Q2: What application should be looking at the raw data outside the
>    kernel and why?

If there are no such programs, why the raw mode emulation is there then?
And if there are such programs, you should ask from those who have made
the programs. But I'll give here couple of possible reasons.

One reason is that someone wants to use the kernel in a
microkernel-like fashion, implementing keyboard driver in userspace.
Keyboards sound like a good candidate for userspace because they are
low-speed. Yeah, I agree there are also reasons why they should not be driven in
userspace, but don't want to argue now which is better.

Another reason is that previously Linux didn't offer event-based
interface to keyboards without raw mode. So, if some program needed to know
all keypress and release events, the only choice might have been the raw
mode. For these programs emulation makes perfect sense for backwards
compatibility.

I was thinking the first reason when I said the above, but the second
is likely more important in practice.

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Fri, Jun 04, 2004 at 05:54:10PM +0300, Tuukka Toivonen wrote:

> >> Giuseppe Bilotta wrote:
> >> >The new system has some ups and downs. The biggest "down",
> >> >which is that of RAW mode not being available anymore (it's
> >> >emulated!) could be circumvented by having both the RAW and
> >> >translated codes move between layers.
> >> Ouch! If the user asks for raw mode, he doesn't get it, but some emulated
> >> mode? To me this sounds like a big incompatibility.
> >
> >Q1: What would you do if the user has an USB keyboard?
> 
> If an application wants to access directly the keyboard, and the keyboard
> happens to be USB, it should use other means to access it. I believe usbfs
> provides some kind of interface for driving directly USB devices.

Yes, sure, if an application wants to access the USB keyboard directly,
it can use usbfs. But if it asks for rawmode on the console, it needs to
be given PS/2 rawmode. And that inevitably means emulation in this case.

> >Q2: What application should be looking at the raw data outside the
> >    kernel and why?
> 
> If there are no such programs, why the raw mode emulation is there then?

Backward compatibility, namely with X. But even X doesn't have a good
reason using PS/2 protocol to talk to the kernel.

> And if there are such programs, you should ask from those who have made
> the programs. But I'll give here couple of possible reasons.
> 
> One reason is that someone wants to use the kernel in a
> microkernel-like fashion, implementing keyboard driver in userspace.
> Keyboards sound like a good candidate for userspace because they are
> low-speed. Yeah, I agree there are also reasons why they should not be driven in
> userspace, but don't want to argue now which is better.

For this purpose is console rawmode (the thing this thread was about) is
completely useless, because you cannot feed the data to the console
again.

For that, you need the exported serio interface. [Which means it wasn't
possible on 2.4] I agree exporting serio's as char devices is useful.

> Another reason is that previously Linux didn't offer event-based
> interface to keyboards without raw mode. So, if some program needed to know
> all keypress and release events, the only choice might have been the raw
> mode.

The "medium raw" mode exists since ages, provides keycodes (as opposed
to scancodes), and is used even for X on many non-386 architectures.
This IMO was the right choice. 

> For these programs emulation makes perfect sense for backwards
> compatibility.

Indeed. That's why it's there.

> I was thinking the first reason when I said the above, but the second
> is likely more important in practice.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

keyboard problem with 2.6.6

[Chris Osicki]

Hi

I recently moved to kernel 2.6.6 from 2.4.26 and noticed that four keys
on my keyboard stopped working.
The kernel reports:

	keyboard: unrecognized scancode (XX) - ignored

Where XX is 71, 72, 74, 75.

My setup is quite unusual as I'm using Sun type 5 keyboard on my
PC with a self-made adapter. However, this setup has worked for at 
least six years with different kernel versions.
The four keys which don't work anymore are from the function-key-set
on the left hand side of the keyboard, if you know what a Sun
keyboard looks like.

I tried to solve my problem using setkeycodes and tried:

setkeycodes 71 101

as 101 was unused keycode (according to getkeycodes)

getkeycodes reported after that:

# getkeycodes | grep 0x70
 0x70:   93 101   0  89   0   0  85  91

But showkeys -s shows 0x5b when the key in question is pressed
(and no release event!!??)
Which is what I don't understand but what probably is out of the scope
of this list.

Under XFree86 this key is then keycode 99 and keysym ff55 which
confuses me totally, but the question "why" belongs probably not to
this list either.

All mentioned keyboard related programs come from the latest
kbd-package - kbd-1.12.

I would be very thankful if somebody could help me to understand
what's going on and how can I get my keys working again.
There must be a good reason for the change from 2.4.x to 2.6.x
which escapes me.

Thanks for your time.

Regards,
Chris

PS Please Cc: me if possible
-- 

Chris Osicki osk@osk.ch
Dipl. Informatik-Ing. HTL

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Chris" == Chris Osicki <osk@osk.ch> writes:

    Chris> Hi

    Chris> I recently moved to kernel 2.6.6 from 2.4.26 and noticed
    Chris> that four keys on my keyboard stopped working.

Congratulations, you've  hit the most  annoying (IMO) part of  the new
'features' in 2.6.6: the new input subsystem.


    Chris> The kernel reports:

    Chris> 	keyboard: unrecognized scancode (XX) - ignored

    Chris> Where XX is 71, 72, 74, 75.

They  have rewritten the  kernel keyboard  and mouse  drivers, causing
lots of problems  to people who switch from  2.4.  What's worse: there
is no way back.  No backward-compatibility to 2.4 behaviours have been
provided, because some kernel  developers believe the new input system
is "perfect",  so perfect  that no one  would want the  old behaviours
anymore.
See also: http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/




    Chris> I tried to solve my problem using setkeycodes and tried:

    Chris> setkeycodes 71 101

    Chris> as 101 was unused keycode (according to getkeycodes)

I don't think you should invent your own keycodes, given that the
following appears in linux-2.6.*/include/linux/input.h

        #define KEY_STOP                128
        #define KEY_AGAIN               129
        #define KEY_PROPS               130
        #define KEY_UNDO                131
        #define KEY_FRONT               132
        #define KEY_COPY                133
        #define KEY_OPEN                134
        #define KEY_PASTE               135
        #define KEY_FIND                136
        #define KEY_CUT                 137
        #define KEY_HELP                138
        #define KEY_MENU                139
        #define KEY_CALC                140

I'm not sure if the configs of XFree86 need any further adjustments.


    Chris> I would be very thankful if somebody could help me to
    Chris> understand what's going on

The keyboard driver has changed, and hence the behaviour.

It also affects my notebook: The SysRq key activated by some [Fn]- key
combo does not work  anymore.  It DID work in 2.4.  On  2.6, I have to
use  Alt-PrintScreen  instead.  The  atkbd  keyboard  driver seems  to
assume that  SysRq ==  Alt-PrintScreen in all  cases, which  is simply
wrong!


    Chris> and how can I get my  keys working again.  

Lobby the input system developers, emphasizing that COMPATIBILITY with
2.4 behaviours is desired  and important.  Without a smooth transition
path, people will be reluctant to migrate to 2.6.


    Chris> There must be a good reason for the change from 2.4.x to
    Chris> 2.6.x which escapes me.

Yeah.   They   say  the  input  system  "unifies"   the  interface  to
keyboard/mouse  devices.   They're   also  proud  that  the  in-kernel
keyboard/mouse drivers  are supporting more and more  devices.  But at
the same  time, they're sacrificing  flexibility by moving  many codes
into kernel.   (GPM supports more  mouse types!)  The new  system also
breaks backward compatibility.



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Giuseppe Bilotta]

Sau Dan Lee wrote:
> Yeah.   They   say  the  input  system  "unifies"   the  interface  to
> keyboard/mouse  devices.   They're   also  proud  that  the  in-kernel
> keyboard/mouse drivers  are supporting more and more  devices.  But at
> the same  time, they're sacrificing  flexibility by moving  many codes
> into kernel.   (GPM supports more  mouse types!)  The new  system also
> breaks backward compatibility.

The new system has some ups and downs. The biggest "down", 
which is that of RAW mode not being available anymore (it's 
emulated!) could be circumvented by having both the RAW and 
translated codes move between layers.

Concerning GPM vs kernel support for mice, maybe we can hope 
for a merging of the efforts and a reduction of code 
duplication, if there is any?

Overall, I think that the new system *could* be a good starting 
point, but it still needs a *lot* of work.

(Now, if we could have any reply from the maintainers?)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Giuseppe" == Giuseppe Bilotta <bilotta78@hotpop.com> writes:

    Giuseppe> Concerning GPM vs kernel support for mice, maybe we can
    Giuseppe> hope for a merging of the efforts and a reduction of
    Giuseppe> code duplication, if there is any?

I'm trying to port the kernel's psmouse.c to userspace, exploiting the
SERIO_USERDEV patch that Tuukka  Toivonen and I developed.  That patch
provided a  direct path  from the  PC keyboard and  PS2 mouse  port to
userspace programs.  I've been using it so as to use my legacy XFree86
driver for my touch screen for many weeks.

I've just had some success porting atkbd.c to userspace.  Running this
userspace  program and  unloading the  'atkbd' module,  I can  type as
usual.  It works like this:


        userland          atkbd.c --------+             apps
                               ^          |              ^
                               |3         |4             |7
        module           'serio' with     |              |
                        SERIO_USERDEV     v        {input system}
                               ^        uinput           |
                               |2         |              |
        module              'i8042'       |5             |6
                               ^          |              |
                               |          |              |
        virtual device         |          +---> "AT keyboard"
                               |1
                               |
        hardware           i8042 chip

Data abstraction:
  (1) electronic signals
  (2), (3) byte stream
  (4), (5), (6), (7) a stream of struct input_event

By moving  the translation from  byte-stream to input events,  we have
more  flexibilities.  E.g.,  I've imagined  using SSH  to pipe  (3) to
another machine,  where my atkbd.c userland program  can then continue
converting to (4) and feeding that to the *remote* system.  This means
it's  possible  to  Alt-F1,  SysRq-*, ctrl-alt-delete  from  a  REMOTE
machine!   It's also  possible to  replace atkbd.c  above with  an X11
client that gives a virtual keyboard.  Again, this can be exploited to
do remote controlling.

Right now, my  atkbd.c doesn't hand the LEDs.  I get  stuck with a bug
with  'uinput',  which  oops   upon  select()  and  poll(),  which  is
necessary.  I've posted this bug,  which has been entered into buzilla
as bug #2786.

        http://bugzilla.kernel.org/show_bug.cgi?id=2786

As soon  as this  bug is fixed,  the userland  atkbd.c can be  made to
support the keyboard LEDs.



    Giuseppe> Overall, I think that the new system *could* be a good
    Giuseppe> starting point, but it still needs a *lot* of work.

I also agree the  new system has its merits.  What I  hate is only the
part  where  mouse/keyboard drivers  are  now  in  kernel space.   The
translation of  raw byte  streams into input  events should  be better
done in userland.  One important  argument is: userland program may be
swapped out.  Kernel modules can't.




--
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ)

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Fri, May 28, 2004 at 07:37:57PM +0200, Sau Dan Lee wrote:

> I also agree the  new system has its merits. 

Thanks.

> What I  hate is only the
> part  where  mouse/keyboard drivers  are  now  in  kernel space.   The
> translation of  raw byte  streams into input  events should  be better
> done in userland.  One important  argument is: userland program may be
> swapped out.  Kernel modules can't.

Well, keyboard support was always in the kernel - you need it there,
because you need the keyboard always to work - even in the case of a
crash, when all userspace programs may already be dead.

That's also the reason why keyboard processing is done in the interrupt
context - even if nothing else works in the kernel but interrupts, you
still can get a register dump for example, using the keyboard.

Regarding mice: Yes, PS/2 and serial mice can be in userspace, as is
proven by reality. With USB mice it's much tougher, and busmice and
many other mice on non-PC platforms need their drivers to be in the
kernel, as they access hardware directly and not via a byte stream
abstraction.

Although PS/2 mice are very common, they're just one case in many. Thus
it was easier to put the processing of them in the kernel, too. It gives
us good advantages, like the support for AUX multiplexing (where you
have more mice connected to one system), synaptics passthrough (where
you have a mouse connected to a touchpad, with the data being embedded
in the touchpad protocol), and other stuff.

For serial mice, doing the processing in the kernel brought us a 4 times
better response rate for the mousesystems kind of them and 2 times
better for microsoft mice. That actually makes both useable.

And here are the two main reasons to keep mouse and keyboard processing
in the kernel:

1) Latency. The time it takes from keypress to giving it to an
application. Adding intermediate programs inbetween doesn't help this at
all.

2) Unified interface. If an application (X, QtEmbedded, SDL ...) needs
to talk to a mouse or keyboard, it can use the event interface instead
of knowing a gazillion of different protocols. This is a kernel job.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    >> What I hate is only the part where mouse/keyboard drivers are
    >> now in kernel space.  The translation of raw byte streams into
    >> input events should be better done in userland.  One important
    >> argument is: userland program may be swapped out.  Kernel
    >> modules can't.

    Vojtech> Well, keyboard support was always in the kernel - you
    Vojtech> need it there, because you need the keyboard always to
    Vojtech> work

No.   That's not the  case (at  least beginning  from 2.6.6).   If you
assume the keyboard is always there, they why make 'i8042' and 'atkbd'
modules?

I like the fact that 2.6.6 no longer assumes that the keyboard must be
there (and thanks  for your work to modularize  those pieces of code).
This assumption doesn't hold,  for instance, in some embedded systems,
which has  no keyboard  controller and can  only be controlled  via an
RS232 port.


    Vojtech>  - even in the case of a crash, when all userspace
    Vojtech> programs may already be dead.

There are still RS232 ports and the network.


    Vojtech> That's also the reason why keyboard processing is done in
    Vojtech> the interrupt context - even if nothing else works in the
    Vojtech> kernel but interrupts, you still can get a register dump
    Vojtech> for example, using the keyboard.

Can't SysRq  be triggered from a  program now, in addition  to using a
keyboard?


    Vojtech> Regarding mice: Yes, PS/2 and serial mice can be in
    Vojtech> userspace, as is proven by reality. With USB mice it's
    Vojtech> much tougher, and busmice and many other mice on non-PC
    Vojtech> platforms need their drivers to be in the kernel, as they
    Vojtech> access hardware directly and not via a byte stream
    Vojtech> abstraction.

A kernel driver can turn it into a byte stream.  What does 'evdev' do,
then?   Isn't  it  turning  those  events into  a  stream  of  "struct
input_event"s?  That's a byte stream,  although you have to be careful
to call read()/write() with a suitable size parameter.


    Vojtech> For serial mice, doing the processing in the kernel
    Vojtech> brought us a 4 times better response rate for the
    Vojtech> mousesystems kind of them and 2 times better for
    Vojtech> microsoft mice. That actually makes both useable.

Is that  "improvement" significant for  1200 baud devices?  Even  on a
386DX-33?


    Vojtech> And here are the two main reasons to keep mouse and
    Vojtech> keyboard processing in the kernel:

    Vojtech> 1) Latency. The time it takes from keypress to giving it
    Vojtech> to an application. Adding intermediate programs inbetween
    Vojtech> doesn't help this at all.

Well... I believe 'pppd' is more sensitive to latencies problems (when
talking to the RS232 port) than a mouse driver.  Why don't you migrate
pppd into the kernel, then?   Remember, we have 56kbps modems (at 2400
baud?).  I believe pppd should be kernelized before the mouse drivers.
Making pppd a kernel module  also eliminates the current need for pppd
to  communicate  with  a  kernel  driver to  create  the  ppp0,  ppp1,
... interfaces, too.

Actually, as long as the low-level byte-stream module has a big enough
buffer to handle the bursts of  data, and the userland driver is quick
enough (on average) to consume the incoming data, what's the problem?


    Vojtech> 2) Unified interface. If an application (X, QtEmbedded,
    Vojtech> SDL ...) needs to talk to a mouse or keyboard, it can use
    Vojtech> the event interface instead of knowing a gazillion of
    Vojtech> different protocols. 

I've demonstrated how a unified interface can be done using my atkbd.c
and psmouse userland drivers.  These useland drivers translate the raw
byte stream,  convert them into "struct input_event",  and then refeed
them into the input system.  It works!


    Vojtech> This is a kernel job.

No.  This can be done in userspace.  We should keep the kernel code to
a  minimal size.   Most other  "drivers" in  Linux has  a  kernel half
(a.k.a. bottom-half?) and  a userland half.  The kernel  half is to do
what  must  be  done  in   kernel:  creating  a  device,  reacting  to
interrupts, putting  the stream  of data in  a buffer.   Mostly simple
tasks that  must be  done quickly.  The  userland half, which  is more
computation-intensitive,  gets   the  data  and   do  the  complicated
processing.


If you  think those  are kernel  jobs, then you  have an  argument for
implementing  Ghostscript completely  in kernel,  so that  we  can cat
mythesis.ps  >  /dev/psprinter,  whether   or  not  my  printer  is  a
Postscript  printer, and  whether or  not it  is connected  locally or
remotely, right?



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 11:45:02AM +0200, Sau Dan Lee wrote:
> >>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
> 
>     >> What I hate is only the part where mouse/keyboard drivers are
>     >> now in kernel space.  The translation of raw byte streams into
>     >> input events should be better done in userland.  One important
>     >> argument is: userland program may be swapped out.  Kernel
>     >> modules can't.
> 
>     Vojtech> Well, keyboard support was always in the kernel - you
>     Vojtech> need it there, because you need the keyboard always to
>     Vojtech> work
> 
> No.   That's not the  case (at  least beginning  from 2.6.6).   If you
> assume the keyboard is always there, they why make 'i8042' and 'atkbd'
> modules?
> 
> I like the fact that 2.6.6 no longer assumes that the keyboard must be
> there (and thanks  for your work to modularize  those pieces of code).
> This assumption doesn't hold,  for instance, in some embedded systems,
> which has  no keyboard  controller and can  only be controlled  via an
> RS232 port.

I meant that keyboard handling was never done in userspace. Of course it
is modular now, but that still counts as 'in the kernel'. ;) On embedded
systems, or when you have an USB keyboard, you can leave the whole PS/2
stuff out.

But still, if you have a working keyboard, the handling is done in the
kernel, and you can do a register dump, process listing, etc, even when
the system is crashed. You wouldn't be able to do that if the processing
of the byte stream was done in an userspace program.

>     Vojtech>  - even in the case of a crash, when all userspace
>     Vojtech> programs may already be dead.
> 
> There are still RS232 ports and the network.

Sure. How convenient it is to have to find an RS232 cable, when your
keyboard is just next to you on the table? I don't advocate _always_
having keyboard support, just the fact that if you have it, that it
should work regardless of system state.

>     Vojtech> That's also the reason why keyboard processing is done in
>     Vojtech> the interrupt context - even if nothing else works in the
>     Vojtech> kernel but interrupts, you still can get a register dump
>     Vojtech> for example, using the keyboard.
> 
> Can't SysRq  be triggered from a  program now, in addition  to using a
> keyboard?

It can. But if your userspace is dead, you cannot run that program. And
that's usually when you need sysrq.

>     Vojtech> Regarding mice: Yes, PS/2 and serial mice can be in
>     Vojtech> userspace, as is proven by reality. With USB mice it's
>     Vojtech> much tougher, and busmice and many other mice on non-PC
>     Vojtech> platforms need their drivers to be in the kernel, as they
>     Vojtech> access hardware directly and not via a byte stream
>     Vojtech> abstraction.
> 
> A kernel driver can turn it into a byte stream.

Sure. You can turn anything into a byte stream. But you already have to
process it in the kernel. There is no point in creating a device
specific bytestream and then disassembling it again in userspace only to
again create a generic format bytestream.

>  What does 'evdev' do,
> then?  Isn't  it  turning  those  events into  a  stream  of  "struct
> input_event"s?  That's a byte stream,  although you have to be careful
> to call read()/write() with a suitable size parameter.

Sure. But it's a generic one, that's able to cover _any_ device. And all
with the same format. That's why it's much better to export this to
userspace than the raw mouse data.

>     Vojtech> For serial mice, doing the processing in the kernel
>     Vojtech> brought us a 4 times better response rate for the
>     Vojtech> mousesystems kind of them and 2 times better for
>     Vojtech> microsoft mice. That actually makes both useable.
> 
> Is that  "improvement" significant for  1200 baud devices?  Even  on a
> 386DX-33?

Yes. Very much significant. Exactly because they're running at 1200
baud, you need get most of that little data they're sending to you. With
the new kernel driver, MouseSystems mice are actually nice to work with,
and not the pain they used to be. Even on 386SX-16.

>     Vojtech> And here are the two main reasons to keep mouse and
>     Vojtech> keyboard processing in the kernel:
> 
>     Vojtech> 1) Latency. The time it takes from keypress to giving it
>     Vojtech> to an application. Adding intermediate programs inbetween
>     Vojtech> doesn't help this at all.
> 
> Well... I believe 'pppd' is more sensitive to latencies problems (when
> talking to the RS232 port) than a mouse driver.  Why don't you migrate
> pppd into the kernel, then?   Remember, we have 56kbps modems (at 2400
> baud?).  I believe pppd should be kernelized before the mouse drivers.
> Making pppd a kernel module  also eliminates the current need for pppd
> to  communicate  with  a  kernel  driver to  create  the  ppp0,  ppp1,
> ... interfaces, too.

Surprise: PPP handling _is_ in the kernel. pppd does the initial
handshaking, and then switches the kernel line discipline, and then the
characters are going straight from the port to the kernel, and then
they're packetized and appear in the ppp0 interface. No pppd interaction
inbetween at all.

> Actually, as long as the low-level byte-stream module has a big enough
> buffer to handle the bursts of  data, and the userland driver is quick
> enough (on average) to consume the incoming data, what's the problem?

The problem is that you get jerky mouse movement. It stays for a while
on one place (when the buffer is filled), and then jumps elsewhere (when
it's processed). You need to do the processing byte by byte, as they
arrive.

>     Vojtech> 2) Unified interface. If an application (X, QtEmbedded,
>     Vojtech> SDL ...) needs to talk to a mouse or keyboard, it can use
>     Vojtech> the event interface instead of knowing a gazillion of
>     Vojtech> different protocols. 
> 
> I've demonstrated how a unified interface can be done using my atkbd.c
> and psmouse userland drivers.  These useland drivers translate the raw
> byte stream,  convert them into "struct input_event",  and then refeed
> them into the input system.  It works!

Yes, it does. Because it uses the _kernel_ input system to do the
interfacing work. But I don't see any benefit of having to go to
userspace and back again into the kernel.

>     Vojtech> This is a kernel job.
> 
> No.  This can be done in userspace.  We should keep the kernel code to
> a  minimal size.   Most other  "drivers" in  Linux has  a  kernel half
> (a.k.a. bottom-half?) and  a userland half.  The kernel  half is to do
> what  must  be  done  in   kernel:  creating  a  device,  reacting  to
> interrupts, putting  the stream  of data in  a buffer.   Mostly simple
> tasks that  must be  done quickly.  The  userland half, which  is more
> computation-intensitive,  gets   the  data  and   do  the  complicated
> processing.

Care to name any? Everything from raw SCSI handling to presenting files
to processes is done in the kernel. Everything from talking to Ethernet
HW to processing IP and TCP and routing and firewalling to presenting
read()able sockets to applications is done in the kernel. No userspace
support there.

> If you  think those  are kernel  jobs, then you  have an  argument for
> implementing  Ghostscript completely  in kernel,  so that  we  can cat
> mythesis.ps  >  /dev/psprinter,  whether   or  not  my  printer  is  a
> Postscript  printer, and  whether or  not it  is connected  locally or
> remotely, right?

Good argument. There are limits of what makes sense to do in the kernel.
Ghostscript is easier to do in userspace, because it needs access to
fonts, has a nontrivial configuration, isn't time critical, etc. Good
candidate for userspace.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    >> >> What I hate is only the part where mouse/keyboard drivers
    >> >> are now in kernel space.  The translation of raw byte
    >> >> streams into input events should be better done in userland.
    >> >> One important argument is: userland program may be swapped
    >> >> out.  Kernel modules can't.
    >> 

    Vojtech> Well, keyboard support was always in the kernel

Once in kernel space, forever in kernel space?  What's the logic?

Where  it is  now possible  to  move it  out of  kernel space  WITHOUT
performance problems, why not move it out?


    Vojtech>  - you need it there, because you need the keyboard
    Vojtech> always to work

Then, why make 'i8042' and  'atkbd' modules?  I still remember reading
web pages  that early  pioneers who migrated  from 2.4  to 2.6.0-test*
encountered a problem: they didn't compile-in these modules, and hence
the system boot  up without a responding keyboard.   Despite that, the
system does work and daemons are running!

So, why is a the keyboard need to always work?


I've  been  testing  'i8042'  module  and my  atkbd  driver  (and  the
SERIO_USERDEV  patch) through  the  network.  I've  been doing  'rmmod
i8042' many many times.  The system DOES work without that module (and
keyboard  functionality).   Why are  you  saying  that  "you need  the
keyboard  always  to  work"?   Again,   is  that  the  limit  of  your
imagination?

Are you aware of the i8042_shutdown bug, which I discovered and fixed?
How could I have found such a bug, if "keyboard has to always work"?


And  how about  mouse  drivers?  They  used  to be  in userland  (gpm,
XFree86 3.x -- 4.x, etc.)  Why move it into the kernel?




    >> I like the fact that 2.6.6 no longer assumes that the keyboard
    >> must be there (and thanks for your work to modularize those
    >> pieces of code).  This assumption doesn't hold, for instance,
    >> in some embedded systems, which has no keyboard controller and
    >> can only be controlled via an RS232 port.

    Vojtech> I meant that keyboard handling was never done in
    Vojtech> userspace. 

OK.  Then, it's time to consider moving it to userspace.


    Vojtech> Of course it is modular now, but that still counts as 'in
    Vojtech> the kernel'.

How about my atkbd.c?



    Vojtech> ;) On embedded systems, or when you have an USB
    Vojtech> keyboard, you can leave the whole PS/2 stuff out.

Is  it impossible  to run  daemons driving  the keyboard  (my atkbd.c,
should  be invoked  from inittab)  and mouse  (e.g.  gpm)  on embedded
systems?  I mean, why MUST the keyboard and mouse drivers be in kernel
space?


    Vojtech> But still, if you have a working keyboard, the handling
    Vojtech> is done in the kernel, and you can do a register dump,
    Vojtech> process listing, etc, even when the system is
    Vojtech> crashed.

Why just  the keyboard?  For that  purpose, we can  use mouse buttons,
the  power button,  a joystick  button, or  even a  home-brewed button
connected to the RS232 port or parallel port.  Why *limit* that to the
keyboard?


    Vojtech> You wouldn't be able to do that if the processing of the
    Vojtech> byte stream was done in an userspace program.

Isn't it  possible to monitor  the kernel via  a tty connected  to the
serial line?


    Vojtech> - even in the case of a crash, when all userspace
    Vojtech> programs may already be dead.
    >>  There are still RS232 ports and the network.

    Vojtech> Sure. How convenient it is to have to find an RS232
    Vojtech> cable, when your keyboard is just next to you on the
    Vojtech> table?

The keyboard should be made an *option*, not a *requirement* for that.
As an optional feature, yo shouldn't assume it for granted.



    >>  Can't SysRq be triggered from a program now, in addition to
    >> using a keyboard?

    Vojtech> It can. But if your userspace is dead, you cannot run
    Vojtech> that program. And that's usually when you need sysrq.

So, why limit that to the  keyboard only?  Why can't my LED lid switch
do it?


    >>  Is that "improvement" significant for 1200 baud devices?  Even
    >> on a 386DX-33?

    Vojtech> Yes. Very much significant. Exactly because they're
    Vojtech> running at 1200 baud, you need get most of that little
    Vojtech> data they're sending to you. 

I don't  understand this.  The slower  a device is, the  lesser is the
need to handle the incoming  data in kernel space.  I can't understand
how 1200baud is  fast enough to cause significant  delays.  Maybe, you
can enlighten me on that?


    Vojtech> The problem is that you get jerky mouse movement. It
    Vojtech> stays for a while on one place (when the buffer is
    Vojtech> filled), and then jumps elsewhere (when it's
    Vojtech> processed). You need to do the processing byte by byte,
    Vojtech> as they arrive.

Yeah.  At  what rate  are they arriving?   1200baud.  Let's  say that'
9600bps.   So,   1200  bytes  per   second.   1  byte  in   every  833
microseconds.  How  come a processor at 33MHz  (0.030 microseconds per
clock cycle) cannot  cope with that?  Assuming that  the processing of
the  data  plus  context  switching  plus  other  overhead  taks  1000
microseconds, that still shouldn't be felt by a HUMAN user.  Who has a
reaction time of less than 100 _milli_seconds?



    Vojtech> Yes, it does. Because it uses the _kernel_ input system
    Vojtech> to do the interfacing work. But I don't see any benefit
    Vojtech> of having to go to userspace and back again into the
    Vojtech> kernel.

Flexibility.  The  keyboard driver can  talk to another machine  via a
TCP  connection, for  instance.   The keyboard  driver  can be  easily
modified  and debugged --  all in  user space  -- without  hanging the
kernel due to  stupid bugs (e.g. NULL pointers).   The keyboard driver
could be prototyped  in Perl, C++, or any  other high-level languages.
(It'd be possible  to design a specific language to  make it easier to
describe the state machine, than in a general purpose language like C,
making it possible to  less programming-proficient users to change the
keyboard behaviours.)



    Vojtech> Care to name any? Everything from raw SCSI handling to
    Vojtech> presenting files to processes is done in the
    Vojtech> kernel. 

So,  raw access  is  still available,  just  in case  the kernel  code
developers' imaginations are exceeded in some applications.


    >> If you think those are kernel jobs, then you have an argument
    >> for implementing Ghostscript completely in kernel, so that we
    >> can cat mythesis.ps > /dev/psprinter, whether or not my printer
    >> is a Postscript printer, and whether or not it is connected
    >> locally or remotely, right?

    Vojtech> Good argument. There are limits of what makes sense to do
    Vojtech> in the kernel.  Ghostscript is easier to do in userspace,
    Vojtech> because it needs access to fonts, has a nontrivial
    Vojtech> configuration, isn't time critical, etc. Good candidate
    Vojtech> for userspace.

Keyboard and mouse drivers are also easier to do in userspace, because
that  makes access to  keymaps, mouse  protocol modules,  etc. easier.
Neither do I think keyboard/mouse  drivers are time critical enough to
be absolutely  placed in  kernel space.  Human  beings do not  work in
units of milliseconds.


-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Brad Campbell]

Sau Dan Lee wrote:
> 
> Once in kernel space, forever in kernel space?  What's the logic?
> 
> Where  it is  now possible  to  move it  out of  kernel space  WITHOUT
> performance problems, why not move it out?

I'd just like to comment on this particular point.

One application I have used utilises the keyboard as a trigger for audio processing and lighting
control. Having the keyboard processed in the kernel gives me pretty precise timing and low latency.
(Think setting CUE points in audio tracks. 10ms matters!). I'm not going to get that with a
userspace keyboard driver. Timing is still a little jittery, but then Linux is not a RTOS, but with
the driver in userspace I'm going to get a whole lot worse response for input events.

If you want to move the keyboard processing in userspace, why not just start with a microkernel.
There has to be a kernel/user line somewhere, and the grey areas are always going to be subject to
discussion.

Brad

Re: keyboard problem with 2.6.6

[Oliver Neukum]

Am Sonntag, 30. Mai 2004 13:25 schrieb Sau Dan Lee:
> >>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
> 
>     >> >> What I hate is only the part where mouse/keyboard drivers
>     >> >> are now in kernel space.  The translation of raw byte
>     >> >> streams into input events should be better done in userland.
>     >> >> One important argument is: userland program may be swapped
>     >> >> out.  Kernel modules can't.
>     >> 
> 
>     Vojtech> Well, keyboard support was always in the kernel
> 
> Once in kernel space, forever in kernel space?  What's the logic?
> 
> Where  it is  now possible  to  move it  out of  kernel space  WITHOUT
> performance problems, why not move it out?

Two reasons: security and robustness.

1. sysreq must work, always work. Ideally you even do the dump
in hard irq. USB has been modified to support this.

2. A true SAK key must be processed in kernel space

There are additional reasons that make it nice to have a kernel driver,
but these reasons make it necessary.

>     Vojtech>  - you need it there, because you need the keyboard
>     Vojtech> always to work
> 
> Then, why make 'i8042' and  'atkbd' modules?  I still remember reading
> web pages  that early  pioneers who migrated  from 2.4  to 2.6.0-test*
> encountered a problem: they didn't compile-in these modules, and hence
> the system boot  up without a responding keyboard.   Despite that, the
> system does work and daemons are running!
> 
> So, why is a the keyboard need to always work?
> 
> 
> I've  been  testing  'i8042'  module  and my  atkbd  driver  (and  the
> SERIO_USERDEV  patch) through  the  network.  I've  been doing  'rmmod
> i8042' many many times.  The system DOES work without that module (and
> keyboard  functionality).   Why are  you  saying  that  "you need  the
> keyboard  always  to  work"?   Again,   is  that  the  limit  of  your
> imagination?

It does not support all features it is supposed to without that module.
There's nothing preventing you from using uinput if you want to. But full
function needs a kernel driver, either statically compiled or as a loaded
module.

	Regards
		Oliver

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Oliver" == Oliver Neukum <oliver@neukum.org> writes:

    >> Where it is now possible to move it out of kernel space WITHOUT
    >> performance problems, why not move it out?

    Oliver> Two reasons: security and robustness.

    Oliver> 1. sysreq must work, always work. Ideally you even do the
    Oliver> dump in hard irq. USB has been modified to support this.

It  doesn't  always work.   Try  to  compile  'i8042' and  'atkbd'  as
modules.  rmmod one of them, and voila: SysRq doesn't work anymore.



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Oliver Neukum]

Am Sonntag, 30. Mai 2004 14:22 schrieb Sau Dan Lee:
> >>>>> "Oliver" == Oliver Neukum <oliver@neukum.org> writes:
> 
>     >> Where it is now possible to move it out of kernel space WITHOUT
>     >> performance problems, why not move it out?
> 
>     Oliver> Two reasons: security and robustness.
> 
>     Oliver> 1. sysreq must work, always work. Ideally you even do the
>     Oliver> dump in hard irq. USB has been modified to support this.
> 
> It  doesn't  always work.   Try  to  compile  'i8042' and  'atkbd'  as
> modules.  rmmod one of them, and voila: SysRq doesn't work anymore.

Yes. Remove the driver for your root fs and, lo, the kernel will panic.
You must not confuse kernel and user space. The notion that drivers
can be compiled into modules is not exactly new. In which context they
run is the all important question.

	Oliver

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 01:25:24PM +0200, Sau Dan Lee wrote:

>     Vojtech> Well, keyboard support was always in the kernel
> 
> Once in kernel space, forever in kernel space?  What's the logic?
> 
> Where  it is  now possible  to  move it  out of  kernel space  WITHOUT
> performance problems, why not move it out?

Because it just works.

1) Upgrading the kernel will make your keyboard stop working. Noone has
installed your userspace daemons on the system.

2) The keyboard (and other input devices, so that you don't complain
about limiting this to the keyboard) should work without requiring
userspace to be running.

And, it works just fine in the kernel, doesn't take up any more space
than as a program, so why to move it out?

>     Vojtech>  - you need it there, because you need the keyboard
>     Vojtech> always to work
> 
> Then, why make 'i8042' and  'atkbd' modules?  I still remember reading
> web pages  that early  pioneers who migrated  from 2.4  to 2.6.0-test*
> encountered a problem: they didn't compile-in these modules, and hence
> the system boot  up without a responding keyboard.   Despite that, the
> system does work and daemons are running!
> 
> So, why is a the keyboard need to always work?

This is getting really annoying. Let me rephrase it again:

I don't have a keyboard on every of my systems. But when I have it and I
have the driver running, I expect it to work. Regardless of what
happened to the system. Regardless of userspace programs dying. Just
work.

> I've  been  testing  'i8042'  module  and my  atkbd  driver  (and  the
> SERIO_USERDEV  patch) through  the  network.  I've  been doing  'rmmod
> i8042' many many times.  The system DOES work without that module (and
> keyboard  functionality).   Why are  you  saying  that  "you need  the
> keyboard  always  to  work"?   Again,   is  that  the  limit  of  your
> imagination?

Yes. The system doesn't need the keyboard drivers to function. The user
does.

> Are you aware of the i8042_shutdown bug, which I discovered and fixed?
> How could I have found such a bug, if "keyboard has to always work"?

Thanks for the fix.

> And  how about  mouse  drivers?  They  used  to be  in userland  (gpm,
> XFree86 3.x -- 4.x, etc.)  Why move it into the kernel?

You wanted to use a mouse click to dump registers?

>     Vojtech> I meant that keyboard handling was never done in
>     Vojtech> userspace. 
> 
> OK.  Then, it's time to consider moving it to userspace.

I'm not interested.

I'd have an interesting idea for you, though: If you want moving stuff
to userspace, move the whole console there. The font handling, the
keymap handling, colors, resolution, all that.

Just a simple program that uses the evdev interface to get the keyboard
data for input, the fbdev interface for output, and the pty interface to
communicate with the system.

Now *that* would be a great project moving stuff to userspace.

>     Vojtech> Of course it is modular now, but that still counts as 'in
>     Vojtech> the kernel'.
> 
> How about my atkbd.c?

It's in userspace. It's not running in the kernel space. It's subject to
the scheduler and swapping. It doesn't react to interrupts immediately.
I think that's quite clear.

>     Vojtech> ;) On embedded systems, or when you have an USB
>     Vojtech> keyboard, you can leave the whole PS/2 stuff out.
> 
> Is  it impossible  to run  daemons driving  the keyboard  (my atkbd.c,
> should  be invoked  from inittab)  and mouse  (e.g.  gpm)  on embedded
> systems?  I mean, why MUST the keyboard and mouse drivers be in kernel
> space?

Of course it's possible. There is not much that'd be impossible in
operating systems. It's not convenient, that's all. 

>     Vojtech> But still, if you have a working keyboard, the handling
>     Vojtech> is done in the kernel, and you can do a register dump,
>     Vojtech> process listing, etc, even when the system is
>     Vojtech> crashed.
> 
> Why just  the keyboard?  For that  purpose, we can  use mouse buttons,
> the  power button,  a joystick  button, or  even a  home-brewed button
> connected to the RS232 port or parallel port.  Why *limit* that to the
> keyboard?

Use whatever device you wish. I don't restrict you to just the keyboard.
The above argument works for a mouse, for a joystick, for an infrared
remote all the same.

>     Vojtech> You wouldn't be able to do that if the processing of the
>     Vojtech> byte stream was done in an userspace program.
> 
> Isn't it  possible to monitor  the kernel via  a tty connected  to the
> serial line?

It is. Surprise, the SAK and SysRq handling for that is done
_in_the_kernel_, because it doesn't want to depend on userspace.

>     Vojtech> - even in the case of a crash, when all userspace
>     Vojtech> programs may already be dead.
>     >>  There are still RS232 ports and the network.
> 
>     Vojtech> Sure. How convenient it is to have to find an RS232
>     Vojtech> cable, when your keyboard is just next to you on the
>     Vojtech> table?
> 
> The keyboard should be made an *option*, not a *requirement* for that.
> As an optional feature, yo shouldn't assume it for granted.

It IS an option, not a requirement. But I WANT THE OPTION. If the
keyboard handling is in userspace, I don't have the option of pressing a
key combination and getting a register dump, because the daemon doing
the processing may be dead already.

>     Vojtech> It can. But if your userspace is dead, you cannot run
>     Vojtech> that program. And that's usually when you need sysrq.
> 
> So, why limit that to the  keyboard only?  Why can't my LED lid switch
> do it?

Go ahead. It's just a matter of adding a few lines to the ACPI drivers,
registering the lid switch as an input device.

>     >>  Is that "improvement" significant for 1200 baud devices?  Even
>     >> on a 386DX-33?
> 
>     Vojtech> Yes. Very much significant. Exactly because they're
>     Vojtech> running at 1200 baud, you need get most of that little
>     Vojtech> data they're sending to you. 
> 
> I don't  understand this.  The slower  a device is, the  lesser is the
> need to handle the incoming  data in kernel space.  I can't understand
> how 1200baud is  fast enough to cause significant  delays.  Maybe, you
> can enlighten me on that?

> Yeah.  At  what rate  are they arriving?   1200baud.  Let's  say that'
> 9600bps.   So,   1200  bytes  per   second.   1  byte  in   every  833
> microseconds.  How  come a processor at 33MHz  (0.030 microseconds per
> clock cycle) cannot  cope with that?  Assuming that  the processing of
> the  data  plus  context  switching  plus  other  overhead  taks  1000
> microseconds, that still shouldn't be felt by a HUMAN user.  Who has a
> reaction time of less than 100 _milli_seconds?

Can you say swap?

>     Vojtech> Yes, it does. Because it uses the _kernel_ input system
>     Vojtech> to do the interfacing work. But I don't see any benefit
>     Vojtech> of having to go to userspace and back again into the
>     Vojtech> kernel.
> 
> Flexibility.  The  keyboard driver can  talk to another machine  via a
> TCP  connection, for  instance.   The keyboard  driver  can be  easily
> modified  and debugged --  all in  user space  -- without  hanging the
> kernel due to  stupid bugs (e.g. NULL pointers).   The keyboard driver
> could be prototyped  in Perl, C++, or any  other high-level languages.
> (It'd be possible  to design a specific language to  make it easier to
> describe the state machine, than in a general purpose language like C,
> making it possible to  less programming-proficient users to change the
> keyboard behaviours.)

Go play with microkernel systems. You'll meet people with similar views
there. Linux is not a microkernel, though.

>     Vojtech> Care to name any? Everything from raw SCSI handling to
>     Vojtech> presenting files to processes is done in the
>     Vojtech> kernel. 
> 
> So,  raw access  is  still available,  just  in case  the kernel  code
> developers' imaginations are exceeded in some applications.

Yes, and it's good. And I don't object to having raw access available. I
really don't. I just want to have it done in a sane way that doesn't
conflict with the kernel drivers. Like in SCSI.

>     Vojtech> Good argument. There are limits of what makes sense to do
>     Vojtech> in the kernel.  Ghostscript is easier to do in userspace,
>     Vojtech> because it needs access to fonts, has a nontrivial
>     Vojtech> configuration, isn't time critical, etc. Good candidate
>     Vojtech> for userspace.
> 
> Keyboard and mouse drivers are also easier to do in userspace, because
> that  makes access to  keymaps, mouse  protocol modules,  etc. easier.
> Neither do I think keyboard/mouse  drivers are time critical enough to
> be absolutely  placed in  kernel space.  Human  beings do not  work in
> units of milliseconds.

The keyboard and mouse drivers don't handle keymaps. Those are handled
in the console. The keyboard/mouse drivers are not necessarily _time_
critical, but they're critical. When your keyboard stops working, this
often means your system is dead. (Think a laptop on an airplane.)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    >> Where it is now possible to move it out of kernel space WITHOUT
    >> performance problems, why not move it out?

    Vojtech> Because it just works.

    Vojtech> 1) Upgrading the kernel will make your keyboard stop
    Vojtech> working. Noone has installed your userspace daemons on
    Vojtech> the system.

Many people has already fallen  into this trap with YOUR input system:
they didn't know they had  to enable the 'i8042' and 'atkbd' features,
or they did  but made them modules and didn't have  any clue to insmod
them in the bootup scripts.

Most package  maintainers put dependencies  in their 2.6  kernel image
packages to force the user to also install module-init-tools.  I can't
see why that couldn't be done for userspace daemons.


    Vojtech> 2) The keyboard (and other input devices, so that you
    Vojtech> don't complain about limiting this to the keyboard)
    Vojtech> should work without requiring userspace to be running.

Is a network interface an input device?  Or do you just mean HID?

USB devices  (including USB keyboards  and mice) require  hot-plug (or
similar mechanisms) to load  the corresponding modules before they can
work.   Both  /sbin/hotplug  and   /sbin/modprobe  on  my  system  are
userspace programs.


    Vojtech> And, it works just fine in the kernel, doesn't take up
    Vojtech> any more space than as a program, so why to move it out?

To leave more *swappable* RAM to userspace.



    Vojtech> This is getting really annoying. Let me rephrase it
    Vojtech> again:

    Vojtech> I don't have a keyboard on every of my systems. But when
    Vojtech> I have it and I have the driver running, I expect it to
    Vojtech> work.

So, you  need to have a  DRIVER running.  How does  putting the driver
into kernel space make it different (for this argument)?


    Vojtech> Regardless of what happened to the system. Regardless of
    Vojtech> userspace programs dying. Just work.

Userspace  programs can  die.  Kernelspace  code can  Oops.   Which is
easier to recover?   What happens when getty dies  and how to recover?
What happens  when some kernel code  oops?  Do you lose  data (held in
RAM by other apps) in these cases?


    Vojtech> Yes. The system doesn't need the keyboard drivers to
    Vojtech> function. The user does.

I don't, when I'm accessing via means other than a keyboard.


    >> Are you aware of the i8042_shutdown bug, which I discovered and
    >> fixed?  How could I have found such a bug, if "keyboard has to
    >> always work"?

    Vojtech> Thanks for the fix.

I've been  reporting this  bug for 2.6.6  and 2.6.7-rc1, and  it still
hasn't been included in 2.6.7-rc2.  What's happening?  Should I report
it again for 2.6.7-rc2?


    >> And how about mouse drivers?  They used to be in userland (gpm,
    >> XFree86 3.x -- 4.x, etc.)  Why move it into the kernel?

    Vojtech> You wanted to use a mouse click to dump registers?

GPM can be  configured to do it, given that the  SysRq feature can now
be triggered from userland.


    Vojtech> I'd have an interesting idea for you, though: If you want
    Vojtech> moving stuff to userspace, move the whole console
    Vojtech> there. The font handling, the keymap handling, colors,
    Vojtech> resolution, all that.

    Vojtech> Just a simple program that uses the evdev interface to
    Vojtech> get the keyboard data for input, the fbdev interface for
    Vojtech> output, and the pty interface to communicate with the
    Vojtech> system.

I've  never  used fbdev.   I  don't  plan to  use  it  on any  PC-type
machines.   It's  so  slow.   I  prefer  the  (S)VGA  text  modes  and
accelerated X11 drivers.



    Vojtech> Now *that* would be a great project moving stuff to
    Vojtech> userspace.

But that restricts to fbdev.


    Vojtech> It's in userspace. It's not running in the kernel
    Vojtech> space. It's subject to the scheduler and swapping. It
    Vojtech> doesn't react to interrupts immediately.  I think that's
    Vojtech> quite clear.

Swappable is one of the features that I want.  I often use my machines
via X11  from one desktop computer.   If the keyboard  driver has been
dormant for  a long time, I'd  prefer it to  be swapped out, so  as to
free up some RAM for other programs.

If you don't want it to  be swappable, you can add some mlock() calls.
You don't have this *choice* for the kernel-space drivers.


    Vojtech> Of course it's possible. There is not much that'd be
    Vojtech> impossible in operating systems. It's not convenient,
    Vojtech> that's all.

Now, it becomes a convenience issue, rather than a necessity issue.



    Vojtech> It IS an option, not a requirement. But I WANT THE
    Vojtech> OPTION. If the keyboard handling is in userspace, I don't
    Vojtech> have the option of pressing a key combination and getting
    Vojtech> a register dump,

Why not?


    Vojtech> because the daemon doing the processing may be dead
    Vojtech> already.

"may be".  So, it's not always.


    >>  I don't understand this.  The slower a device is, the lesser
    >> is the need to handle the incoming data in kernel space.  I
    >> can't understand how 1200baud is fast enough to cause
    >> significant delays.  Maybe, you can enlighten me on that?

    >> Yeah.  At what rate are they arriving?  1200baud.  Let's say
    >> that' 9600bps.  So, 1200 bytes per second.  1 byte in every 833
    >> microseconds.  How come a processor at 33MHz (0.030
    >> microseconds per clock cycle) cannot cope with that?  Assuming
    >> that the processing of the data plus context switching plus
    >> other overhead taks 1000 microseconds, that still shouldn't be
    >> felt by a HUMAN user.  Who has a reaction time of less than 100
    >> _milli_seconds?

    Vojtech> Can you say swap?

Can you say mlock()?



    Vojtech> The keyboard and mouse drivers don't handle
    Vojtech> keymaps. Those are handled in the console. The
    Vojtech> keyboard/mouse drivers are not necessarily _time_
    Vojtech> critical, but they're critical. When your keyboard stops
    Vojtech> working, this often means your system is dead. (Think a
    Vojtech> laptop on an airplane.)

I've used  my laptop  in an airplane,  and it works  without problems.
What would make the keyboard stop working in an airplane?



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 02:40:31PM +0200, Sau Dan Lee wrote:

>  > The keyboard/mouse drivers are not necessarily _time_ critical, but
>  > they're critical. When your keyboard stops working, this often
>  > means your system is as good as dead. (Think a laptop on an
>  > airplane.)
> 
> I've used  my laptop  in an airplane,  and it works  without problems.
> What would make the keyboard stop working in an airplane?

This discussion is futile. Bye.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Stefan Seyfried]

On Sun, May 30, 2004 at 12:43:26PM +0000, Sau Dan Lee wrote:
 
> Now, it becomes a convenience issue, rather than a necessity issue.
 
> Why not?
 
> "may be".  So, it's not always.

>     Vojtech> Can you say swap?
> 
> Can you say mlock()?

can you say "troll"?

> I've used  my laptop  in an airplane,  and it works  without problems.
> What would make the keyboard stop working in an airplane?

-- 
seife

"Any ideas, John?"
"Well, surrounding thems out."

Re: keyboard problem with 2.6.6

[Dmitry Torokhov]

On Sunday 30 May 2004 07:40 am, Sau Dan Lee wrote:
> >>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
> 
>     >> Where it is now possible to move it out of kernel space WITHOUT
>     >> performance problems, why not move it out?
> 
>     Vojtech> Because it just works.
> 
>     Vojtech> 1) Upgrading the kernel will make your keyboard stop
>     Vojtech> working. Noone has installed your userspace daemons on
>     Vojtech> the system.
> 
> Many people has already fallen  into this trap with YOUR input system:
> they didn't know they had  to enable the 'i8042' and 'atkbd' features,
> or they did  but made them modules and didn't have  any clue to insmod
> them in the bootup scripts.

This was in development series (2.5) and was resolved by the time 2.6 came
out so I really do not think it's a valid complaint.
 
>     Vojtech> 2) The keyboard (and other input devices, so that you
>     Vojtech> don't complain about limiting this to the keyboard)
>     Vojtech> should work without requiring userspace to be running.
> 
> Is a network interface an input device?  Or do you just mean HID?
> 
> USB devices  (including USB keyboards  and mice) require  hot-plug (or
> similar mechanisms) to load  the corresponding modules before they can
> work.   Both  /sbin/hotplug  and   /sbin/modprobe  on  my  system  are
> userspace programs.
> 
> 

>     Vojtech> And, it works just fine in the kernel, doesn't take up
>     Vojtech> any more space than as a program, so why to move it out?
> 
> To leave more *swappable* RAM to userspace.
> 

On average it will take much more considering that you better have your
keyboard daemon linked statically and residing.. umm.. initrd?  initramfs?
as you want your keyboard working very early.

>     >> Yeah.  At what rate are they arriving?  1200baud.  Let's say
>     >> that' 9600bps.  So, 1200 bytes per second.  1 byte in every 833
>     >> microseconds.  How come a processor at 33MHz (0.030
>     >> microseconds per clock cycle) cannot cope with that?  Assuming
>     >> that the processing of the data plus context switching plus
>     >> other overhead taks 1000 microseconds, that still shouldn't be
>     >> felt by a HUMAN user.  Who has a reaction time of less than 100
>     >> _milli_seconds?
> 
>     Vojtech> Can you say swap?
> 
> Can you say mlock()?
> 

I though you wanted the thing to be swapped out? Btw, what are you going
to mlock? Entirety of glibc?

-- 
Dmitry

Re: keyboard problem with 2.6.6

[Pavel Machek]

Hi!

>     >> >> What I hate is only the part where mouse/keyboard drivers
>     >> >> are now in kernel space.  The translation of raw byte
>     >> >> streams into input events should be better done in userland.
>     >> >> One important argument is: userland program may be swapped
>     >> >> out.  Kernel modules can't.
>     >> 
> 
>     Vojtech> Well, keyboard support was always in the kernel
> 
> Once in kernel space, forever in kernel space?  What's the logic?
> 
> Where  it is  now possible  to  move it  out of  kernel space  WITHOUT
> performance problems, why not move it out?

You get pretty nasty managment problems. How do you do init=/bin/bash
if your keyboard is userspace?

>     Vojtech> But still, if you have a working keyboard, the handling
>     Vojtech> is done in the kernel, and you can do a register dump,
>     Vojtech> process listing, etc, even when the system is
>     Vojtech> crashed.
> 
> Why just  the keyboard?  For that  purpose, we can  use mouse buttons,
> the  power button,  a joystick  button, or  even a  home-brewed button
> connected to the RS232 port or parallel port.  Why *limit* that to the
> keyboard?

Keyboard is historically used for that. It seems to work, no reason to
change it.

								Pavel
-- 
934a471f20d6580d5aad759bf0d97ddc

Re: keyboard problem with 2.6.6

[Horst von Brand]

Pavel Machek <pavel@suse.cz> said:

[...]

> You get pretty nasty managment problems. How do you do init=/bin/bash
> if your keyboard is userspace?

You don't tell any kernel about that... it is the bootloader you are
talking to. And that one may very well have integrated kbd support.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: keyboard problem with 2.6.6

[Valdis.Kletnieks]

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

On Fri, 04 Jun 2004 14:17:14 EDT, Horst von Brand said:
> Pavel Machek <pavel@suse.cz> said:

> > You get pretty nasty managment problems. How do you do init=/bin/bash
> > if your keyboard is userspace?
> 
> You don't tell any kernel about that... it is the bootloader you are
> talking to. And that one may very well have integrated kbd support.

So GRUB knows about keyboards, lets you type in the "init=/bin/bash", it loads
the kernel, the kernel launches init, /bin/bash gets loaded - and /bin/bash
can't talk to the keyboard because the userspace handler hasn't happened.  At
that point you're stuck...


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: keyboard problem with 2.6.6

[Denis Vlasenko]

On Friday 04 June 2004 21:37, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 04 Jun 2004 14:17:14 EDT, Horst von Brand said:
> > Pavel Machek <pavel@suse.cz> said:
> > > You get pretty nasty managment problems. How do you do init=/bin/bash
> > > if your keyboard is userspace?
> >
> > You don't tell any kernel about that... it is the bootloader you are
> > talking to. And that one may very well have integrated kbd support.
>
> So GRUB knows about keyboards, lets you type in the "init=/bin/bash", it
> loads the kernel, the kernel launches init, /bin/bash gets loaded - and
> /bin/bash can't talk to the keyboard because the userspace handler hasn't
> happened.  At that point you're stuck...

Using shell scripts instead of 'standard' init etc is
way more configurable. As an example, my current setup
at home:

My kernel params are:

root=/dev/ram
init=/linuxrc
devfs=mount
ROOTFS=/dev/ide/host0/bus0/target0/lun0/part7
IPCFG=mac,100mbit
INIT=/init



/linuxrc (in initrd):

#!/bin/sh

export PATH=/bin:/usr/bin

cd /
mount -n -t devfs none /dev
mount -n -t proc none /proc
#mount -n -t sysfs none /sys

echo "# Configuring interfaces"
# Optional, for NFS happiness
ip l set dev lo up
ip a add 127.0.0.1/8 dev lo

/script/cfg_ip

echo "# Mounting root fs"
/script/mount_root

# Clean up
#umount /sys
umount /proc

echo "# Chrooting into root fs"
mount -n -t devfs none /new_root/dev
cd /new_root
# making sure we dont keep /dev busy
exec <dev/console >dev/console 2>&1
# proc/ in new root is used here as a temp mountpoint
pivot_root . proc

echo "# Exec'ing init"
if ! test "$INIT"; then
    INIT=/init
fi

exec \
    chroot . \
    sh -c \
    'umount -n /proc/dev; umount -n /proc; exec /bin/env - $INIT'

echo "Error in 'exec chroot . sh': exit code $?"
while true; do
    sleep 32000
done



And, finally, /init:

#!/bin/sh

fileprefix=/etc/rc.d
bootprog=3.runlevel

unset HOSTNAME
unset devfs
unset MACHTYPE
unset SHLVL
unset SHELL
unset HOSTTYPE
unset OSTYPE
unset HOME
unset TERM

export PATH=/bin:/usr/bin

exec >/dev/console
exec 2>&1
exec </dev/null

(
cd "$fileprefix"
env - PATH="$PATH" "$fileprefix/$bootprog" start
)

# Close all descriptors
exec >&-
exec 2>&-
exec <&-

while true; do
    env - sleep 32000
done

--
vda

Re: keyboard problem with 2.6.6

[Valdis.Kletnieks]

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

On Fri, 04 Jun 2004 22:33:41 +0300, Denis Vlasenko said:

> Using shell scripts instead of 'standard' init etc is
> way more configurable. As an example, my current setup
> at home:
> 
> My kernel params are:

Yes. Those are *YOUR* config setup parameters, that happen to work with *your*
specific configuration when everything is operational. Some problems:

1) Not all the world uses initrd....

2) I hope your /script/mount_root will Do The Right Thing if the mount fails
because it needs an fsck, for example.  Answering those 'y' and 'n' prompts can
be a problem if your keyboard isn't working yet..

3) Bonus points if you can explain how to, *without* a working keyboard,  modify
that /linuxrc on your initrd to deal with the situation where your keyboard
setup is wrong (think "booting with borrowed keyboard because your usual one
just suffered a carbonated caffeine overdose")...

There's a *BASIC* bootstrapping problem here - if you move "initialize and
handle the keyboard" into userspace, you then *require* that a significantly
larger chunk of userspace be operational in order to be able to even type at
the machine.  If you're trying to recover a *broken* userspace, it gets a lot
harder.

And the embedded people who use "init=/onlyprogramthateverruns" are going
to have a significant collective cow about this....



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: keyboard problem with 2.6.6

[Denis Vlasenko]

On Friday 04 June 2004 22:50, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 04 Jun 2004 22:33:41 +0300, Denis Vlasenko said:
> > Using shell scripts instead of 'standard' init etc is
> > way more configurable. As an example, my current setup
> > at home:
> >
> > My kernel params are:
>
> Yes. Those are *YOUR* config setup parameters, that happen to work with
> *your* specific configuration when everything is operational. Some
> problems:

In *any* setup, kernelspace or userspace, it's typically possible
to find some silly way to break boot sequence. Unplugging
keyboard and removing (unneded for server) videocard are my
favorites ;)

> 1) Not all the world uses initrd....

I stayed away from it too, but I always knew I'll need it sooner
or later.

> 2) I hope your /script/mount_root will Do The Right Thing if the mount
> fails because it needs an fsck, for example.  Answering those 'y' and 'n'
> prompts can be a problem if your keyboard isn't working yet..

My init scripts are (trying to) recover from any failure.
They ignore non-fatal error conditions.
I'll fix your fsck example like this: make script check
FSCK_ACTION env var for N (never do fsck), ASK (ask user
if serious trouble), and AUTO (fix automagically without
user). Set FSCK_ACTION as needed per box via kernel command line.

Fixing/tailoring init written in C is harder (more time-consuming).

Fixing/tailoring kernel bootstrap sequence is harder still.
As an example, NFS boot. How can you force your ethernet into,
say, 100 Mbit FDX _before_ kernel do DHCP thing via ip= kernel
parameter?

That's one of reasons why moving to userspace might be a good idea.

> 3) Bonus points if you can explain how to, *without* a working keyboard, 
> modify that /linuxrc on your initrd to deal with the situation where your
> keyboard setup is wrong (think "booting with borrowed keyboard because your
> usual one just suffered a carbonated caffeine overdose")...

I just did that yesterday when I needed to make USB keyboard to
work on my box, first time ever for me. I let it boot, ssh'ed in,
and built new kernel. I could modify my initrd too, but that wasn't
needed.

> There's a *BASIC* bootstrapping problem here - if you move "initialize and
> handle the keyboard" into userspace, you then *require* that a
> significantly larger chunk of userspace be operational in order to be able
> to even type at the machine.  If you're trying to recover a *broken*
> userspace, it gets a lot harder.

Bootstrapping problem exist no matter how you are bootstrapping.

When something is broken, difficulty of repairs cannot be estimated
that simple. I don't think "you are using intird -> fixing will be hard"
always holds true.

BTW, in my case, booting my box was not just hard, it was impossible.
It had broken PS2 ports. I needed to "only" enter BIOS setup and tell
it to ignore keyboard errors on boot, but I couldn't enter it
without keyboard! But I digress...
--
vda

Re: keyboard problem with 2.6.6

[Pavel Machek]

Hi!

> [...]
> 
> > You get pretty nasty managment problems. How do you do init=/bin/bash
> > if your keyboard is userspace?
> 
> You don't tell any kernel about that... it is the bootloader you are
> talking to. And that one may very well have integrated kbd support.

I know bootloader will hae its own kbd driver.

But when kernel boots, you'll not be able to enter commands into the bash.
-- 
934a471f20d6580d5aad759bf0d97ddc

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Pavel" == Pavel Machek <pavel@suse.cz> writes:

    Pavel> I know bootloader will hae its own kbd driver.

    Pavel> But when kernel boots, you'll not be able to enter commands
    Pavel> into the bash.

Funny.  How did you type the command to start bash?

If you can  arrange bash to be  run, then why is it  that difficult to
arrange "modprobe atkbd; modprobe i8042" to be executed?


Some distros even have the disk  driver and filesystem for the root fs
compiled as modules.  They do  manage to load those modules correct to
mount the rootfs.  How come it  is so hard to imagine that 'i8042' and
'atkbd' can somehow be loaded without user attention at boot time?



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Pavel Machek]

Hi!

>     Pavel> I know bootloader will hae its own kbd driver.
> 
>     Pavel> But when kernel boots, you'll not be able to enter commands
>     Pavel> into the bash.
> 
> Funny.  How did you type the command to start bash?

That was in comment you stripped.

> If you can  arrange bash to be  run, then why is it  that difficult to
> arrange "modprobe atkbd; modprobe i8042" to be executed?

It would not be "modprobe atkbd" but "my-keyboard-daemon &". And AFAIK
you can't add that to "init=" commandline.
								Pavel
-- 
934a471f20d6580d5aad759bf0d97ddc

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Pavel" == Pavel Machek <pavel@suse.cz> writes:

    >> If you can arrange bash to be run, then why is it that
    >> difficult to arrange "modprobe atkbd; modprobe i8042" to be
    >> executed?

    Pavel> It would not be "modprobe atkbd" but "my-keyboard-daemon
    Pavel> &". 

What's the  difference?  Both  are commands.  Commands  can be  put in
shell scripts, which can be put in shell scripts, ...  Eventually, you
only need one root script to spawn all the offsprings.



    Pavel> And AFAIK you can't add that to "init=" commandline.

That's  getting  funny.   You  can't   start  6  copies  of  getty  on
/dev/tty[1-6] on "init=", can you?


-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Pavel Machek]

Hi!

>     Pavel> And AFAIK you can't add that to "init=" commandline.
> 
> That's  getting  funny.   You  can't   start  6  copies  of  getty  on
> /dev/tty[1-6] on "init=", can you?

No, but you can do init=/bin/bash. [Are you reading my mails at all?!]
And init=/bin/bash is enough to recover broken system.

What you are proposing is incompatible update that would break 99% of
all systems, for gain of 8K of unswappable memory or something like
that. That's no-no in 2.6 series, and probably bad idea for 2.7, too.

Now, can we end the thread here? Userland keyboard driver is not going
to happen in 2.6.X.
								Pavel
-- 
934a471f20d6580d5aad759bf0d97ddc

Re: keyboard problem with 2.6.6

[Andries Brouwer]

Sau Dan Lee wrote:

> Actually, I have a side issue with input/i8042 related things: The
> keyboard on my laptop worked slightly different: On 2.4.*, SysRq is
> activated using a [Fn] key-combo, which agrees with the keycap labels
> on the laptop keyboard. After upgrading to 2.6, that key-combo no
> longer works. Instead, I must use Alt-PrintScreen as the key for
> SysRq. (And unfortunately, PrintScreen is a [Fn] combo on the laptop,
> thus requiring press 3 keys at the same time for SysRq, and a fourth
> key to use the various SysRq features. Very inconvenient.) Is this
> again due to some dirty translation processes down in the input layer?
> Is the input layer always assuming that Alt-PrintScreen == SysRq?
> This is not always true. Can the input layer be so configured that it
> never tries to interpret the scancodes, but pass them to the upper
> layers?

So, what scancodes do you get in 2.4? And in 2.6? (Use scancode -s.)

Andries

Re: keyboard problem with 2.6.6

[Andries Brouwer]

On Tue, May 25, 2004 at 10:16:16PM +0200, Chris Osicki wrote:

> I recently moved to kernel 2.6.6 from 2.4.26 and noticed that four keys
> on my keyboard stopped working.
> The kernel reports:
> 
> 	keyboard: unrecognized scancode (XX) - ignored
> 
> Where XX is 71, 72, 74, 75.

Hmm. This message seems to be from arch/arm26/lib/kbd.c
Is this message from 2.6.6? Is this an ARM?

> My setup is quite unusual as I'm using Sun type 5 keyboard on my
> PC with a self-made adapter. However, this setup has worked for at 
> least six years with different kernel versions.
> The four keys which don't work anymore are from the function-key-set
> on the left hand side of the keyboard, if you know what a Sun
> keyboard looks like.
> 
> I tried to solve my problem using setkeycodes and tried:
> 
> setkeycodes 71 101
> 
> as 101 was unused keycode (according to getkeycodes)
> 
> getkeycodes reported after that:
> 
> # getkeycodes | grep 0x70
>  0x70:   93 101   0  89   0   0  85  91

Your report is a bit messy. You change things for scancode 0x71 and then
expect the keycode for 0x70 to be changed?

> But showkeys -s shows 0x5b when the key in question is pressed
> (and no release event!!??)

Given a careful and precise report, no doubt it will be clear
what your situation is. Mention architecture, scancodes under 2.4,
scancodes under 2.6.

Andries


[The situation with arch/arm26/lib/kbd.c is funny.
That is the old keyboard code that was removed from
the general kernel code. No doubt it should be updated.]

Re: keyboard problem with 2.6.6

[Andries Brouwer]

On Fri, May 28, 2004 at 09:41:36PM +0200, Andries Brouwer wrote:

> > setkeycodes 71 101
> > 
> > # getkeycodes | grep 0x70
> >  0x70:   93 101   0  89   0   0  85  91
> 
> Your report is a bit messy. You change things for scancode 0x71 and then
> expect the keycode for 0x70 to be changed?

Sorry - replied too quickly.
Yes, so your setkeycodes worked fine.

> > But showkeys -s shows 0x5b when the key in question is pressed
> > (and no release event!!??)

Now you told the kernel that scancode 0x71 belongs to keycode 101.

Do you say that your key does not have scancode 0x71, but 0x5b?
The question remains: what is it under 2.4? what under 2.6?

Andries

Re: keyboard problem with 2.6.6

[Andries Brouwer]

On Fri, May 28, 2004 at 11:46:20PM +0200, Chris Osicki wrote:

>>> I tried to solve my problem using setkeycodes and tried:
>>> 
>>> setkeycodes 71 101
>>> 
>>> getkeycodes reported after that:
>>> 
>>> # getkeycodes | grep 0x70
>>>  0x70:   93 101   0  89   0   0  85  91

Yes, fine.

>>> But showkeys -s shows 0x5b when the key in question is pressed
>>> (and no release event!!??)

0x5b is 91 which is x86_keycodes[101].

Yes, so all is clear:
The 2.6 kernel no longer has a raw mode - it has a simulated raw mode
that is not very raw. When you updated the table used for the
scancode->keycode translation, the table used to reconstruct what
might have been the original scancode was not changed accordingly.
Thus, showkeys -s gave a garbage answer.

Thanks for the report. It shows that resurrecting raw mode is even
more desirable than I thought at first.

Andries

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sat, May 29, 2004 at 03:23:20PM +0200, Andries Brouwer wrote:

> >>> But showkeys -s shows 0x5b when the key in question is pressed
> >>> (and no release event!!??)
> 
> 0x5b is 91 which is x86_keycodes[101].
> 
> Yes, so all is clear:
> The 2.6 kernel no longer has a raw mode - it has a simulated raw mode
> that is not very raw. When you updated the table used for the
> scancode->keycode translation, the table used to reconstruct what
> might have been the original scancode was not changed accordingly.
> Thus, showkeys -s gave a garbage answer.
> 
> Thanks for the report. It shows that resurrecting raw mode is even
> more desirable than I thought at first.

What for?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Andries Brouwer]

On Sat, May 29, 2004 at 03:46:14PM +0200, Vojtech Pavlik wrote:

> > Thus, showkeys -s gave a garbage answer.
> > 
> > Thanks for the report. It shows that resurrecting raw mode is even
> > more desirable than I thought at first.
> 
> What for?

As you know, the keyboard/mouse situation in 2.6 is unfortunate.

I get a steady stream with letters from people complaining about
the keyboard utilities under 2.6. How can I answer and tell them
what the problem is? I need facts - raw data, so that I can
trace the path of this raw data through the kernel.

That is my reason I want a raw mode. Often I have to ask them
to boot 2.4 first to get reality, so that one afterwards is
in a better position to understand the fake reality of 2.6.

But apart from such debugging use, there is also the more
direct use: in order to assign a keycode to an unusual key
one first asks for the scancode using scancode -s, and then
assigns the keycode using setkeycodes. If scancode -s lies,
this fails.

Andries

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sat, May 29, 2004 at 04:30:43PM +0200, Andries Brouwer wrote:

> On Sat, May 29, 2004 at 03:46:14PM +0200, Vojtech Pavlik wrote:
> 
> > > Thus, showkeys -s gave a garbage answer.
> > > 
> > > Thanks for the report. It shows that resurrecting raw mode is even
> > > more desirable than I thought at first.
> > 
> > What for?
> 
> As you know, the keyboard/mouse situation in 2.6 is unfortunate.
> 
> I get a steady stream with letters from people complaining about
> the keyboard utilities under 2.6. How can I answer and tell them
> what the problem is? I need facts - raw data, so that I can
> trace the path of this raw data through the kernel.
> 
> That is my reason I want a raw mode. Often I have to ask them
> to boot 2.4 first to get reality, so that one afterwards is
> in a better position to understand the fake reality of 2.6.
> 
> But apart from such debugging use, there is also the more
> direct use: in order to assign a keycode to an unusual key
> one first asks for the scancode using scancode -s, and then
> assigns the keycode using setkeycodes. If scancode -s lies,
> this fails.

That's a good reason. I'll implement true rawmode support.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> On Sat, May 29, 2004 at 03:23:20PM +0200, Andries Brouwer wrote:
> 
> > >>> But showkeys -s shows 0x5b when the key in question is pressed
> > >>> (and no release event!!??)
> > 
> > 0x5b is 91 which is x86_keycodes[101].
> > 
> > Yes, so all is clear:
> > The 2.6 kernel no longer has a raw mode - it has a simulated raw mode
> > that is not very raw. When you updated the table used for the
> > scancode->keycode translation, the table used to reconstruct what
> > might have been the original scancode was not changed accordingly.
> > Thus, showkeys -s gave a garbage answer.
> > 
> > Thanks for the report. It shows that resurrecting raw mode is even
> > more desirable than I thought at first.
> 
> What for?

One for all: X. Especially with multimedia keyboards. X has a 
very exhaustive set of keyboard definitions for the many 
multimedia keyboards. Each of them has multimedia keys in a 
very wide and diverse range of strange scancodes. They all get 
standard keysyms (XF86VolumeUp, etc).

Yes, the 'proper' solution would be to have the kernel provide 
the abstraction layer: let the kernel have standard keycodes 
for all the multimedia functions, and know, for the various 
keyboard model, which scancodes generate them. And then have X 
work on the keycodes.

But:

1. the Linux kernel does not (yet) have such an exhaustive 
mapping as the xkbd models
2. the Linux kernel does not (yet) have any knowledge at all of 
multimedia keys, for what I can see.
3. X works on non-Linux kernels and on older Linux kernels

The time to bring the new system to the same functionality 
level as the old one is not short. The time to implement a 
proper raw mode (e.g. by bleeding, see other post) would be 
much shorter.

So, while we wait for complete support, at the kernel level, 
for all the multimedia keyboards supported by X, we *need* 
proper raw mode.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)