Re: keyboard problem with 2.6.6

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]

>>>>> "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]

>>>>> "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

[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

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

[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)