[PATCH] SERIO_USERDEV: direct userspace access to mouse/keyboard psaux serial ports

[PATCH] SERIO_USERDEV: direct userspace access to mouse/keyboard psaux serial ports

[Tuukka Toivonen]

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

This is the first public release of the patch, but it has been already
tested by a few people, so it should be stable.

I hope to get some more testers, and if no serious bugs are found, I really
would like this to get included into the mainstream kernel.

Snippet from the documentation:

SERIO_USERDEV - Direct serial input device access for userspace

This driver provides direct access from usespace into PS/2 (or psaux)
serial ports used usually for input devices such as mouses and keyboards.

The code is part of the serio module. It can be enabled or disabled
from kernel configuration
    Device Drivers -> Input device support -> User space driver support
if serial i/o support is enabled.

All available devices will be registered as miscellaneous
devices with major 10, minor dynamically allocated. The devices
with their minors will be listed in /proc/misc with isa0060/serio0
for keyboard and the rest for pointing devices. If devfs is enabled,
the device files will be created as /dev/misc/isa0060/serio*.

The created devices which are connected to a mouse can be usually
used in place of /dev/psaux which was used in 2.4.x kernels.
Therefore, you could do (if devfs is enabled):
    ln -s /dev/misc/isa0060/serio1 /dev/psaux
(or some other device) and run mouse drivers such as gpm and XFree86
just as with 2.4.x kernel.

Features:
- Both read and write support to all PS/2 ports. With active multiplexing,
  there will be five serial ports up to isa0060/serio4.
- Multiple readers supported, each reader will get copy of the complete stream.
  Write locking supported via special ioctl calls.

Re: [PATCH] SERIO_USERDEV: direct userspace access to mouse/keyboard psaux serial ports

[Andrew Morton]

Tuukka Toivonen <tuukkat@ee.oulu.fi> wrote:
>
> SERIO_USERDEV - Direct serial input device access for userspace
> 
>  This driver provides direct access from usespace into PS/2 (or psaux)
>  serial ports used usually for input devices such as mouses and keyboards.

I must say that last time this went around, the arguments which were made
in its favour made sense.  Let me recap:

At present, the kernel decodes the external device into logical "events"
and, if someone wants access to the raw device bitstream the kernel will
synthesize that bitstream from the decoded event stream.

But if, for example, the kernel doesn't have a decoder for the external
device, we're out of luck.

And given that the external device generates a stream of bits, the kernel
should provide some way for applications to directly access that stream
without the intervening interpretation.


Is that a decent summary of the situation?

If so then yeah, I think the kernel should have a driver which does all of
this.

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

2.6.* useland replacements of the atkbd and psmouse modules

[Sau Dan Lee]

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


http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/#userdrivers

These userspace  drivers are ported  from kernel code based  on 2.6.6.
They are  still in  alpha stage.  Some  "difficult features"  (or code
that I don't understand) are dropped.

However, they  do demonstrate that using the  SERIO_USERDEV patch (see
message   <Pine.GSO.4.58.0405072348120.21057@stekt37>,   available  at
http://lkml.org/lkml/2004/5/7/143), it is really possible to implement
the PS2 mouse/keyboard drivers in user space.


[-- Attachment #2: atkbd.c --]
[-- Type: text/plain, Size: 24576 bytes --]

/*
 * AT and PS/2 keyboard driver
 *
 * Copyright (c) 1999-2002 Vojtech Pavlik
 * Copyright (c) 2004 Sau Dan LEE
 */

/*
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 as published by
 * the Free Software Foundation.
 */

/*
  This program is based on linux-2.6.6/drivers/input/serio/atkbd.c
  The difference is that this program now runs in user-space (swappable),
  while the kernel driver runs in kernel-space.

  Usage: atkbd /dev/misc/isa0060/serio0

  Prerequisites:
     1) 'uinput' module loaded or compiled in
         If not using 'devfs', you have to create the /dev/uinput char
         device with major 10.  The minor number can be found in
	 "cat /proc/misc" after loading the 'uinput' module.
     2) 'serio' module with SERIO_USERDEV patch loaded or compiled in
     3) 'i8042' module loaded or compiled in
     4) 'atkbd' module UNloaded and NOT compiled in
        Note: if you're accessing from console, keyboard will be disabled
        when 'atkbd' is unloaded.  It's more convenient to connect from
	remote to do this.  Alternatively, write some shell scripts
	to invoke unload 'atkbd' and activate this program at once.

  TODO:
     - this program current ignore LED events -- BUG
     - options parsing should be added to allow user to
       specify the module parameters.
     - daemonize this program, so as to make it easy to run from /etc/inittab
     - soft_repeat is not supported yet.  (How useful is this?)
*/

/*
 * This driver can handle standard AT keyboards and PS/2 keyboards in
 * Translated and Raw Set 2 and Set 3, as well as AT keyboards on dumb
 * input-only controllers and AT keyboards connected over a one way RS232
 * converter.
 */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <linux/input.h>
#include <linux/uinput.h>

/* older kernel headers lack the following two key codes */

#ifndef KEY_HANGUEL
#define KEY_HANGUEL             122
#endif

#ifndef KEY_HANJA
#define KEY_HANJA               123
#endif


#define module_param_named(name,var,type,defl) struct dummy
#define MODULE_PARM_DESC(name,desc) struct dummy


#define warn(...) fprintf(stderr, "atkbd: (warning) " __VA_ARGS__)
#define err(...)  fprintf(stderr, "atkbd: ERROR " __VA_ARGS__)
#define info(...) printf("atkbd: " __VA_ARGS__)
#define perr(msg)  do{fprintf(stderr, "atkbd: ERROR: "); perror(msg);}while(0)
#define perrx(msg) do{perr(msg); exit(1);}while(0)
#define pferrx() perrx(__FUNCTION__)


static int atkbd_set = 2;
module_param_named(set, atkbd_set, int, 0);
MODULE_PARM_DESC(set, "Select keyboard code set (2 = default, 3 = PS/2 native)");

#if defined(__i386__) || defined(__x86_64__) || defined(__hppa__)
static int atkbd_reset;
#else
static int atkbd_reset = 1;
#endif
module_param_named(reset, atkbd_reset, bool, 0);
MODULE_PARM_DESC(reset, "Reset keyboard during initialization");

static int atkbd_softrepeat;
module_param_named(softrepeat, atkbd_softrepeat, bool, 0);
MODULE_PARM_DESC(softrepeat, "Use software keyboard repeat");

static int atkbd_scroll;
module_param_named(scroll, atkbd_scroll, bool, 0);
MODULE_PARM_DESC(scroll, "Enable scroll-wheel on MS Office and similar keyboards");

static int atkbd_extra;
module_param_named(extra, atkbd_extra, bool, 0);
MODULE_PARM_DESC(extra, "Enable extra LEDs and keys on IBM RapidAcces, EzKey and similar keyboards");

/*
 * Scancode to keycode tables. These are just the default setting, and
 * are loadable via an userland utility.
 */

#if defined(__hppa__)
#include "hpps2atkbd.h"
#else

static unsigned char atkbd_set2_keycode[512] = {

	  0, 67, 65, 63, 61, 59, 60, 88,  0, 68, 66, 64, 62, 15, 41,117,
	  0, 56, 42, 93, 29, 16,  2,  0,  0,  0, 44, 31, 30, 17,  3,  0,
	  0, 46, 45, 32, 18,  5,  4, 95,  0, 57, 47, 33, 20, 19,  6,183,
	  0, 49, 48, 35, 34, 21,  7,184,  0,  0, 50, 36, 22,  8,  9,185,
	  0, 51, 37, 23, 24, 11, 10,  0,  0, 52, 53, 38, 39, 25, 12,  0,
	  0, 89, 40,  0, 26, 13,  0,  0, 58, 54, 28, 27,  0, 43,  0, 85,
	  0, 86, 91, 90, 92,  0, 14, 94,  0, 79,124, 75, 71,121,  0,  0,
	 82, 83, 80, 76, 77, 72,  1, 69, 87, 78, 81, 74, 55, 73, 70, 99,

	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	217,100,255,  0, 97,165,  0,  0,156,  0,  0,  0,  0,  0,  0,125,
	173,114,  0,113,  0,  0,  0,126,128,  0,  0,140,  0,  0,  0,127,
	159,  0,115,  0,164,  0,  0,116,158,  0,150,166,  0,  0,  0,142,
	157,  0,  0,  0,  0,  0,  0,  0,155,  0, 98,  0,  0,163,  0,  0,
	226,  0,  0,  0,  0,  0,  0,  0,  0,255, 96,  0,  0,  0,143,  0,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,107,  0,105,102,  0,  0,112,
	110,111,108,112,106,103,  0,119,  0,118,109,  0, 99,104,119,  0,

	  0,  0,  0, 65, 99,
};


static unsigned char atkbd_set3_keycode[512] = {

	  0,  0,  0,  0,  0,  0,  0, 59,  1,138,128,129,130, 15, 41, 60,
	131, 29, 42, 86, 58, 16,  2, 61,133, 56, 44, 31, 30, 17,  3, 62,
	134, 46, 45, 32, 18,  5,  4, 63,135, 57, 47, 33, 20, 19,  6, 64,
	136, 49, 48, 35, 34, 21,  7, 65,137,100, 50, 36, 22,  8,  9, 66,
	125, 51, 37, 23, 24, 11, 10, 67,126, 52, 53, 38, 39, 25, 12, 68,
	113,114, 40, 43, 26, 13, 87, 99, 97, 54, 28, 27, 43, 43, 88, 70,
	108,105,119,103,111,107, 14,110,  0, 79,106, 75, 71,109,102,104,
	 82, 83, 80, 76, 77, 72, 69, 98,  0, 96, 81,  0, 78, 73, 55,183,

	184,185,186,187, 74, 94, 92, 93,  0,  0,  0,125,126,127,112,  0,
	  0,139,150,163,165,115,152,150,166,140,160,154,113,114,167,168,
	148,149,147,140
};

static unsigned char atkbd_unxlate_table[128] = {
          0,118, 22, 30, 38, 37, 46, 54, 61, 62, 70, 69, 78, 85,102, 13,
         21, 29, 36, 45, 44, 53, 60, 67, 68, 77, 84, 91, 90, 20, 28, 27,
         35, 43, 52, 51, 59, 66, 75, 76, 82, 14, 18, 93, 26, 34, 33, 42,
         50, 49, 58, 65, 73, 74, 89,124, 17, 41, 88,  5,  6,  4, 12,  3,
         11,  2, 10,  1,  9,119,126,108,117,125,123,107,115,116,121,105,
        114,122,112,113,127, 96, 97,120,  7, 15, 23, 31, 39, 47, 55, 63,
         71, 79, 86, 94,  8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 87,111,
         19, 25, 57, 81, 83, 92, 95, 98, 99,100,101,103,104,106,109,110
};

#define ATKBD_CMD_SETLEDS	0x10ed
#define ATKBD_CMD_GSCANSET	0x11f0
#define ATKBD_CMD_SSCANSET	0x10f0
#define ATKBD_CMD_GETID		0x02f2
#define ATKBD_CMD_SETREP	0x10f3
#define ATKBD_CMD_ENABLE	0x00f4
#define ATKBD_CMD_RESET_DIS	0x00f5
#define ATKBD_CMD_SETALL_MBR	0x00fa
#define ATKBD_CMD_RESET_BAT	0x02ff
#define ATKBD_CMD_RESEND	0x00fe
#define ATKBD_CMD_EX_ENABLE	0x10ea
#define ATKBD_CMD_EX_SETLEDS	0x20eb
#define ATKBD_CMD_OK_GETID	0x02e8


#define ATKBD_RET_ACK		0xfa
#define ATKBD_RET_NAK		0xfe
#define ATKBD_RET_BAT		0xaa
#define ATKBD_RET_EMUL0		0xe0
#define ATKBD_RET_EMUL1		0xe1
#define ATKBD_RET_RELEASE	0xf0
#define ATKBD_RET_HANGUEL	0xf1
#define ATKBD_RET_HANJA		0xf2
#define ATKBD_RET_ERR		0xff

#define ATKBD_KEY_UNKNOWN	  0
#define ATKBD_KEY_NULL		255

#define ATKBD_SCR_1		254
#define ATKBD_SCR_2		253
#define ATKBD_SCR_4		252
#define ATKBD_SCR_8		251
#define ATKBD_SCR_CLICK		250

#define ATKBD_SPECIAL		250

static unsigned char atkbd_scroll_keys[5][2] = {
	{ ATKBD_SCR_1,     0x45 },
	{ ATKBD_SCR_2,     0x29 },
	{ ATKBD_SCR_4,     0x36 },
	{ ATKBD_SCR_8,     0x27 },
	{ ATKBD_SCR_CLICK, 0x60 },
};

#endif
/*
 * The atkbd control structure
 */

struct atkbd {
	unsigned char keycode[512];
	char name[64];
	char phys[32];
	unsigned char cmdbuf[4];
	unsigned char cmdcnt;
	unsigned char set;
	unsigned char extra;
	unsigned char release;
	int lastkey;
	volatile signed char ack;
	unsigned char emul;
	unsigned short id;
	unsigned char write;
	unsigned char translated;
	unsigned char resend;
	unsigned char bat_xl;
	unsigned int last;
};

static struct atkbd atkbd_data;
static struct atkbd * const atkbd = &atkbd_data;

static const char* phys_filename;

/********** functions for interacting with 'uinput' **********/

static const char *uinput_dev_name = NULL;
static int uinput_fd;

static void uinput_open() {
	uinput_fd = open(uinput_dev_name, O_WRONLY);
}

static void uinput_set_evbit(int bit) {
	int r;

	r = ioctl(uinput_fd, UI_SET_EVBIT, bit);
	if (r==-1) { pferrx(); }
}

static void uinput_set_ledbit(int bit) {
	int r;

	r = ioctl(uinput_fd, UI_SET_LEDBIT, bit);
	if (r==-1) { pferrx();}
}

static void uinput_set_keybit(int bit) {
	int r;

	r = ioctl(uinput_fd, UI_SET_KEYBIT, bit);
	if (r==-1) { pferrx(); }
}

static void uinput_set_relbit(int bit) {
	int r;

	r = ioctl(uinput_fd, UI_SET_RELBIT, bit);
	if (r==-1) { pferrx(); }
}

static void uinput_create() {
	struct uinput_user_dev uinput = {
		.name = "atkbd ",
	};
	int r;

	snprintf(uinput.name, UINPUT_MAX_NAME_SIZE,
		 "atkbd %s", phys_filename);

	r = write(uinput_fd, &uinput, sizeof(uinput));
	if (r==-1) { pferrx(); }

	r = ioctl(uinput_fd, UI_DEV_CREATE);
	if (r==-1) { pferrx(); }
}

static void uinput_destroy() {
	int r;

	r = ioctl(uinput_fd, UI_DEV_DESTROY);
	if (r==-1) { pferrx(); }
}

static void uinput_close() {
	int r;

	r = close(uinput_fd);
	if (r==-1) { pferrx(); }
}

static void uinput_event(__u16 type, __u16 code, __s32 value) {
	struct input_event ev = {
		.type = type,
		.code = code,
		.value = value
	};
	int r;

	r = write(uinput_fd, &ev, sizeof(ev));
	if (r!=sizeof(ev)) { pferrx(); }
}


#define uinput_report_key(code,value) uinput_event(EV_KEY, (code), (value))
#define uinput_report_rel(code,value) uinput_event(EV_REL, (code), (value))
#define uinput_sync() uinput_event(EV_SYN, 0, 0)


/********** functions for accessing the raw keyboard device **********/

static int phys_fd = -1;
static const char* phys_filename;

static int phys_open() {
	phys_fd = open(phys_filename, O_RDWR);
	if (phys_fd == -1) {
		const int e = errno;
		perr(phys_filename);
		switch (e) {
		case EACCES:
			err("read-write access required.  Are you 'root'?\n");
			break;
		}
		exit(1);
	}
	return 0;
}

static int phys_write(unsigned char byte) {
	int r;
	r = write(phys_fd, &byte, 1);
	if (r==-1) { pferrx(); }
	if (r!=1) { err("cannot write"); exit(1); }
	return 0;
}

static void atkbd_interrupt(unsigned char data,
			    unsigned int flags);

static int phys_wait_for_input(int *ptimeout) {
	unsigned char byte;
	int r;

	if (ptimeout != NULL) {
		fd_set fds;
		struct timeval tv;

		FD_ZERO(&fds);
		FD_SET(phys_fd, &fds);
		tv.tv_sec=0; tv.tv_usec=*ptimeout;
		r = select(phys_fd+1, &fds, NULL, &fds, &tv);
		*ptimeout = tv.tv_sec*1000000 + tv.tv_usec;
		if (r==-1) { pferrx(); }
		if (r==0) { return -1; } /* timeout */
		if (r!=1) { err("cannot select"); exit(1); }
	}

	r = read(phys_fd, &byte, 1);
	if (r==-1) { pferrx(); }
	if (r!=1) { err("cannot read"); exit(1); }

	atkbd_interrupt(byte, 0);
	return 0;
}

static void phys_close() {
	int r;
	r = close(phys_fd);
	if (r==-1) { pferrx(); }
}

static int atkbd_connect();
static void atkbd_disconnect();

static void phys_rescan() {
	atkbd_disconnect();
	atkbd_connect();
}



static void atkbd_report_key(int code, int value)
{
	if (value == 3) {
		uinput_report_key(code, 1);
		uinput_report_key(code, 0);
	} else
		uinput_event(EV_KEY, code, value);
	uinput_sync();
}



/*
 * atkbd_interrupt(). Here takes place processing of data received from
 * the keyboard into events.
 */

static void atkbd_interrupt(unsigned char data,
			    unsigned int flags)
{
	unsigned int code = data;
	int scroll = 0, click = -1;
	int value;

#ifdef ATKBD_DEBUG
	printk(KERN_DEBUG "atkbd.c: Received %02x flags %02x\n", data, flags);
#endif

#if !defined(__i386__) && !defined (__x86_64__)
	if ((flags & (SERIO_FRAME | SERIO_PARITY)) && (~flags & SERIO_TIMEOUT) && !atkbd->resend && atkbd->write) {
		printk("atkbd.c: frame/parity error: %02x\n", flags);
		serio_write(serio, ATKBD_CMD_RESEND);
		atkbd->resend = 1;
		goto out;
	}

	if (!flags && data == ATKBD_RET_ACK)
		atkbd->resend = 0;
#endif

	if (!atkbd->ack)
		switch (code) {
			case ATKBD_RET_ACK:
				atkbd->ack = 1;
				goto out;
			case ATKBD_RET_NAK:
				atkbd->ack = -1;
				goto out;
		}

	if (atkbd->cmdcnt) {
		atkbd->cmdbuf[--atkbd->cmdcnt] = code;
		goto out;
	}

	if (atkbd->translated) {

		if (atkbd->emul ||
		    !(code == ATKBD_RET_EMUL0 || code == ATKBD_RET_EMUL1 ||
		      code == ATKBD_RET_HANGUEL || code == ATKBD_RET_HANJA ||
		      code == ATKBD_RET_ERR ||
	             (code == ATKBD_RET_BAT && !atkbd->bat_xl))) {
			atkbd->release = code >> 7;
			code &= 0x7f;
		}

		if (!atkbd->emul &&
		     (code & 0x7f) == (ATKBD_RET_BAT & 0x7f))
			atkbd->bat_xl = !atkbd->release;
	}

	switch (code) {
		case ATKBD_RET_BAT:
			phys_rescan();
			goto out;
		case ATKBD_RET_EMUL0:
			atkbd->emul = 1;
			goto out;
		case ATKBD_RET_EMUL1:
			atkbd->emul = 2;
			goto out;
		case ATKBD_RET_RELEASE:
			atkbd->release = 1;
			goto out;
		case ATKBD_RET_HANGUEL:
			atkbd_report_key(KEY_HANGUEL, 3);
			goto out;
		case ATKBD_RET_HANJA:
			atkbd_report_key(KEY_HANJA, 3);
			goto out;
		case ATKBD_RET_ERR:
			warn("Keyboard reports too many keys pressed.\n");
			goto out;
	}

	if (atkbd->set != 3)
		code = (code & 0x7f) | ((code & 0x80) << 1);
	if (atkbd->emul) {
		if (--atkbd->emul)
			goto out;
		code |= (atkbd->set != 3) ? 0x80 : 0x100;
	}

	switch (atkbd->keycode[code]) {
		case ATKBD_KEY_NULL:
			break;
		case ATKBD_KEY_UNKNOWN:
			warn("Unknown key %s (%s set %d, code %#x).\n",
				atkbd->release ? "released" : "pressed",
				atkbd->translated ? "translated" : "raw",
				atkbd->set, code);
			if (atkbd->translated && atkbd->set == 2 && code == 0x7a)
				warn("This is an XFree86 bug. It shouldn't access"
				     " hardware directly.\n");
			else
				warn("Use 'setkeycodes %s%02x <keycode>' to make it known.\n",						code & 0x80 ? "e0" : "", code & 0x7f);
			break;
		case ATKBD_SCR_1:
			scroll = 1 - atkbd->release * 2;
			break;
		case ATKBD_SCR_2:
			scroll = 2 - atkbd->release * 4;
			break;
		case ATKBD_SCR_4:
			scroll = 4 - atkbd->release * 8;
			break;
		case ATKBD_SCR_8:
			scroll = 8 - atkbd->release * 16;
			break;
		case ATKBD_SCR_CLICK:
			click = !atkbd->release;
			break;
		default:
			value = atkbd->release ? 0 :
				(1 + (!atkbd_softrepeat));

			switch (value) { 	/* Workaround Toshiba laptop multiple keypress */
				case 0:
					atkbd->last = 0;
					break;
				case 1:
					atkbd->last = code;
					break;
				case 2:
					value = 1;
					break;
			}

			atkbd_report_key(atkbd->keycode[code], value);
	}

	if (scroll || click != -1) {
		uinput_report_key(BTN_MIDDLE, click);
		uinput_report_rel(REL_WHEEL, scroll);
		uinput_sync();
	}

	atkbd->release = 0;
out:
	return;
}

/*
 * atkbd_sendbyte() sends a byte to the keyboard, and waits for
 * acknowledge. It doesn't handle resends according to the keyboard
 * protocol specs, because if these are needed, the keyboard needs
 * replacement anyway, and they only make a mess in the protocol.
 */

static int atkbd_sendbyte(unsigned char byte)
{
	int timeout = 20000; /* 200 msec */
	atkbd->ack = 0;

#ifdef ATKBD_DEBUG
	printk(KERN_DEBUG "atkbd.c: Sent: %02x\n", byte);
#endif
	if (phys_write(byte))
		return -1;

	while (!atkbd->ack && timeout>0)
		phys_wait_for_input(&timeout);

	return -(atkbd->ack <= 0);
}

/*
 * atkbd_command() sends a command, and its parameters to the keyboard,
 * then waits for the response and puts it in the param array.
 */

static int atkbd_command(unsigned char *param, int command)
{
	int timeout = 500000; /* 500 msec */
	int send = (command >> 12) & 0xf;
	int receive = (command >> 8) & 0xf;
	int i;

	atkbd->cmdcnt = receive;

	if (command == ATKBD_CMD_RESET_BAT)
		timeout = 2000000; /* 2 sec */

	if (receive && param)
		for (i = 0; i < receive; i++)
			atkbd->cmdbuf[(receive - 1) - i] = param[i];

	if (command & 0xff)
		if (atkbd_sendbyte(command & 0xff))
			return (atkbd->cmdcnt = 0) - 1;

	for (i = 0; i < send; i++)
		if (atkbd_sendbyte(param[i]))
			return (atkbd->cmdcnt = 0) - 1;

	while (atkbd->cmdcnt && timeout>0) {

		if (atkbd->cmdcnt == 1 &&
		    command == ATKBD_CMD_RESET_BAT && timeout > 100000)
			timeout = 100000;

		if (atkbd->cmdcnt == 1 && command == ATKBD_CMD_GETID &&
		    atkbd->cmdbuf[1] != 0xab && atkbd->cmdbuf[1] != 0xac) {
			atkbd->cmdcnt = 0;
			break;
		}

		phys_wait_for_input(&timeout);
	}

	if (param)
		for (i = 0; i < receive; i++)
			param[i] = atkbd->cmdbuf[(receive - 1) - i];

	if (command == ATKBD_CMD_RESET_BAT && atkbd->cmdcnt == 1)
		atkbd->cmdcnt = 0;

	if (atkbd->cmdcnt) {
		atkbd->cmdcnt = 0;
		return -1;
	}

	return 0;
}
#if 0

/*
 * Event callback from the input module. Events that change the state of
 * the hardware are processed here.
 */

static int atkbd_event(struct input_dev *dev, unsigned int type, unsigned int code, int value)
{
	struct atkbd *atkbd = dev->private;
	const short period[32] =
		{ 33,  37,  42,  46,  50,  54,  58,  63,  67,  75,  83,  92, 100, 109, 116, 125,
		 133, 149, 167, 182, 200, 217, 232, 250, 270, 303, 333, 370, 400, 435, 470, 500 };
	const short delay[4] =
		{ 250, 500, 750, 1000 };
	unsigned char param[2];
	int i, j;

	if (!atkbd->write)
		return -1;

	switch (type) {

		case EV_LED:

			param[0] = (test_bit(LED_SCROLLL, dev->led) ? 1 : 0)
			         | (test_bit(LED_NUML,    dev->led) ? 2 : 0)
			         | (test_bit(LED_CAPSL,   dev->led) ? 4 : 0);
		        atkbd_command(atkbd, param, ATKBD_CMD_SETLEDS);

			if (atkbd->extra) {
				param[0] = 0;
				param[1] = (test_bit(LED_COMPOSE, dev->led) ? 0x01 : 0)
					 | (test_bit(LED_SLEEP,   dev->led) ? 0x02 : 0)
					 | (test_bit(LED_SUSPEND, dev->led) ? 0x04 : 0)
				         | (test_bit(LED_MISC,    dev->led) ? 0x10 : 0)
				         | (test_bit(LED_MUTE,    dev->led) ? 0x20 : 0);
				atkbd_command(atkbd, param, ATKBD_CMD_EX_SETLEDS);
			}

			return 0;


		case EV_REP:

			if (atkbd_softrepeat) return 0;

			i = j = 0;
			while (i < 32 && period[i] < dev->rep[REP_PERIOD]) i++;
			while (j < 4 && delay[j] < dev->rep[REP_DELAY]) j++;
			dev->rep[REP_PERIOD] = period[i];
			dev->rep[REP_DELAY] = delay[j];
			param[0] = i | (j << 5);
			atkbd_command(atkbd, param, ATKBD_CMD_SETREP);

			return 0;
	}

	return -1;
}
#endif

/*
 * atkbd_probe() probes for an AT keyboard on a serio port.
 */

static int atkbd_probe()
{
	unsigned char param[2];

/*
 * Some systems, where the bit-twiddling when testing the io-lines of the
 * controller may confuse the keyboard need a full reset of the keyboard. On
 * these systems the BIOS also usually doesn't do it for us.
 */

	if (atkbd_reset)
		if (atkbd_command(NULL, ATKBD_CMD_RESET_BAT))
			warn("keyboard reset failed on\n");

/*
 * Then we check the keyboard ID. We should get 0xab83 under normal conditions.
 * Some keyboards report different values, but the first byte is always 0xab or
 * 0xac. Some old AT keyboards don't report anything. If a mouse is connected, this
 * should make sure we don't try to set the LEDs on it.
 */

	param[0] = param[1] = 0xa5;	/* initialize with invalid values */
	if (atkbd_command(param, ATKBD_CMD_GETID)) {

/*
 * If the get ID command failed, we check if we can at least set the LEDs on
 * the keyboard. This should work on every keyboard out there. It also turns
 * the LEDs off, which we want anyway.
 */
		param[0] = 0;
		if (atkbd_command(param, ATKBD_CMD_SETLEDS))
			return -1;
		atkbd->id = 0xabba;
		return 0;
	}

	if (param[0] != 0xab && param[0] != 0xac)
		return -1;
	atkbd->id = (param[0] << 8) | param[1];

	if (atkbd->id == 0xaca1 && atkbd->translated) {
		err("NCD terminal keyboards are only supported on non-translating\n");
		err("controllers. Use i8042.direct=1 to disable translation.\n");
		return -1;
	}

	return 0;
}

/*
 * atkbd_set_3 checks if a keyboard has a working Set 3 support, and
 * sets it into that. Unfortunately there are keyboards that can be switched
 * to Set 3, but don't work well in that (BTC Multimedia ...)
 */

static int atkbd_set_3()
{
	unsigned char param[2];

/*
 * For known special keyboards we can go ahead and set the correct set.
 * We check for NCD PS/2 Sun, NorthGate OmniKey 101 and
 * IBM RapidAccess / IBM EzButton / Chicony KBP-8993 keyboards.
 */

	if (atkbd->translated)
		return 2;

	if (atkbd->id == 0xaca1) {
		param[0] = 3;
		atkbd_command(param, ATKBD_CMD_SSCANSET);
		return 3;
	}

	if (atkbd_extra) {
		param[0] = 0x71;
		if (!atkbd_command(param, ATKBD_CMD_EX_ENABLE)) {
			atkbd->extra = 1;
			return 2;
		}
	}

	if (atkbd_set != 3)
		return 2;

	if (!atkbd_command(param, ATKBD_CMD_OK_GETID)) {
		atkbd->id = param[0] << 8 | param[1];
		return 2;
	}

	param[0] = 3;
	if (atkbd_command(param, ATKBD_CMD_SSCANSET))
		return 2;

	param[0] = 0;
	if (atkbd_command(param, ATKBD_CMD_GSCANSET))
		return 2;

	if (param[0] != 3) {
		param[0] = 2;
		if (atkbd_command(param, ATKBD_CMD_SSCANSET))
		return 2;
	}

	atkbd_command(param, ATKBD_CMD_SETALL_MBR);

	return 3;
}

static int atkbd_enable()
{
	unsigned char param[1];

/*
 * Set the LEDs to a defined state.
 */

	param[0] = 0;
	if (atkbd_command(param, ATKBD_CMD_SETLEDS))
		return -1;

/*
 * Set autorepeat to fastest possible.
 */

	param[0] = 0;
	if (atkbd_command(param, ATKBD_CMD_SETREP))
		return -1;

/*
 * Enable the keyboard to receive keystrokes.
 */

	if (atkbd_command(NULL, ATKBD_CMD_ENABLE)) {
		err("Failed to enable keyboard\n");
		return -1;
	}

	return 0;
}

/*
 * atkbd_disconnect() closes and frees.
 */

static void atkbd_disconnect()
{
	phys_close();
}

/*
 * atkbd_connect() is called when the serio module finds and interface
 * that isn't handled yet by an appropriate device driver. We check if
 * there is an AT keyboard out there and if yes, we register ourselves
 * to the input module.
 */

static int atkbd_connect()
{
	int i;

	memset(atkbd, 0, sizeof(struct atkbd));

#if 0
	switch (serio->type & SERIO_TYPE) {

		case SERIO_8042_XL:
			atkbd->translated = 1;
		case SERIO_8042:
			if (serio->write)
				atkbd->write = 1;
			break;
		case SERIO_RS232:
			if ((serio->type & SERIO_PROTO) == SERIO_PS2SER)
				break;
		default:
			kfree(atkbd);
			return;
	}
#else
	atkbd->translated = 1;
	atkbd->write = 1;
#endif

	if (phys_open()) {
		return -1;
	}

	if (atkbd->write) {
		uinput_set_evbit(EV_KEY);
		uinput_set_evbit(EV_LED);
		uinput_set_evbit(EV_REP);

		uinput_set_ledbit(LED_NUML);
		uinput_set_ledbit(LED_CAPSL);
		uinput_set_ledbit(LED_SCROLLL);
	} else  {
		uinput_set_evbit(EV_KEY);
		uinput_set_evbit(EV_REP);
	}

	if (atkbd_softrepeat) {
		assert("not implemented yet" == 0); 
	}

	atkbd->ack = 1;


	if (atkbd->write) {

		if (atkbd_probe()) {
			return -1;
		}

		atkbd->set = atkbd_set_3();
		atkbd_enable();

	} else {
		atkbd->set = 2;
		atkbd->id = 0xab00;
	}

	if (atkbd->extra) {
		uinput_set_ledbit(LED_COMPOSE);
		uinput_set_ledbit(LED_SUSPEND);
		uinput_set_ledbit(LED_SLEEP);
		uinput_set_ledbit(LED_MUTE);
		uinput_set_ledbit(LED_MISC);

		sprintf(atkbd->name, "AT Set 2 Extra keyboard");
	} else
		sprintf(atkbd->name, "AT %s Set %d keyboard",
			atkbd->translated ? "Translated" : "Raw", atkbd->set);

	if (atkbd_scroll) {
		for (i = 0; i < 5; i++)
			atkbd_set2_keycode[atkbd_scroll_keys[i][1]] = atkbd_scroll_keys[i][0];
		uinput_set_evbit(EV_REL);
		uinput_set_relbit(REL_WHEEL);
		uinput_set_keybit(BTN_MIDDLE);
	}

	if (atkbd->translated) {
		for (i = 0; i < 128; i++) {
			atkbd->keycode[i] = atkbd_set2_keycode[atkbd_unxlate_table[i]];
			atkbd->keycode[i | 0x80] = atkbd_set2_keycode[atkbd_unxlate_table[i] | 0x80];
		}
	} else if (atkbd->set == 3) {
		memcpy(atkbd->keycode, atkbd_set3_keycode, sizeof(atkbd->keycode));
	} else {
		memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
	}

	for (i = 0; i < 512; i++)
		if (atkbd->keycode[i] && atkbd->keycode[i] < ATKBD_SPECIAL)
			uinput_set_keybit(atkbd->keycode[i]);

	info("keyboard %s\n", atkbd->name);
	return 0;
}


int main(int argc, char**argv) {
	if (argc != 2) {
		fprintf(stderr, "Usage: %s raw_kbd_device\n", argv[0]);
		return 1;
	}

	phys_filename = argv[1];

	/* try devfs name first */
	uinput_dev_name = "/dev/misc/uinput";
	uinput_open();
	if (uinput_fd == -1 && errno==ENOENT) {
		/* was not found: try non-devfs name */
		uinput_dev_name = "/dev/uinput";
		uinput_open();
	}
	if (uinput_fd == -1) {
		const int e = errno;
		perr(uinput_dev_name);

		switch (e) {
		case ENOENT:
			err("Have you loaded the 'uinput' module?\n");
			break;
		case EACCES:
			err("Write access needed.  Are you 'root'?\n");
			break;
		}
		exit (1);
	}



	if (atkbd_connect() != 0) {
		fprintf(stderr, "cannot connect to device\n");
		return 1;
	}

	uinput_create();

	for (;;) {
		phys_wait_for_input(NULL);
	}

	uinput_destroy();

	atkbd_disconnect();
	uinput_close();
	return 0;
}

[-- Attachment #3: psmouse.tgz --]
[-- Type: text/plain, Size: 51247 bytes --]

psmouse/#define _UINPUT_H_

extern void uinput_open(void);
extern void uinput_create(void);
extern void uinput_event(int type, int code, int value);
extern void uinput_report_key(int code, int value);
extern void uinput_report_rel(int code, int value);
extern void uinput_report_abs(int code, int value);
extern void uinput_sync();

extern void uinput_set_evbit(unsigned int bit);
extern void uinput_set_ledbit(unsigned int bit);
extern void uinput_set_relbit(unsigned int bit);
extern void uinput_set_keybit(unsigned int bit);
extern void uinput_clear_keybit(unsigned int bit);


#endif /* _UINPUT_H_ */
#include <fcntl.h>
#include <linux/input.h>
#include <linux/uinput.h>
#include "psmouse.h"
#include "uinput.h"

#define UI_DEV "/dev/misc/uinput"

static int uinput_fd = -1;

void uinput_open(void) {
	uinput_fd = open(UI_DEV, O_WRONLY);
	if (uinput_fd == -1) {
		perror("Can't open");
		err("Have you loaded the 'uinput' module?\n");
		exit(1);
	}
}

void uinput_create(void) {
	struct uinput_user_dev uinput_user_dev;
	int r;

	strncpy(uinput_user_dev.name, psmouse->name,
		UINPUT_MAX_NAME_SIZE);

	r = write(uinput_fd, &uinput_user_dev, sizeof(uinput_user_dev));
	if (r != sizeof(uinput_user_dev)) {
		if (r==-1) perror("Can't write");
		else err("Can't write");
		exit(1);
	}

	r = ioctl(uinput_fd, UI_DEV_CREATE);
	if (r==-1) {
		perror("Can't create uinput device");
		exit(1);
	}
}

void uinput_event(int type, int code, int value) {
	struct input_event ev = {
		.type = type,
		.code = code,
		.value = value,
	};
	int r;

	r = write(uinput_fd, &ev, sizeof(ev));
	if (r != sizeof(ev)) {
		if (r==-1) perror("Can't write");
		else err("Can't write");
		exit(1);
	}
}

void uinput_report_key(int code, int value) {
	uinput_event(EV_KEY, code, value);
}

void uinput_report_rel(int code, int value) {
	uinput_event(EV_REL, code, value);
}

void uinput_report_abs(int code, int value) {
	uinput_event(EV_ABS, code, value);
}

void uinput_sync() {
	uinput_event(EV_SYN, SYN_REPORT, 0);
}

static void uinput_set_bit(int command, unsigned int bit) {
	if (ioctl(uinput_fd, command, bit) == -1) {
		perror("Can't ioctl");
		exit(1);
	}
}

void uinput_set_evbit(unsigned int bit) {
  uinput_set_bit(UI_SET_EVBIT, bit);
}
void uinput_set_ledbit(unsigned int bit)  {
  uinput_set_bit(UI_SET_LEDBIT, bit);
}
void uinput_set_relbit(unsigned int bit) {
  uinput_set_bit(UI_SET_RELBIT, bit);
}
void uinput_set_keybit(unsigned int bit) {
  uinput_set_bit(UI_SET_KEYBIT, bit);
}

void uinput_clear_keybit(unsigned int bit) {
  //FIXME!
}


 * Synaptics TouchPad PS/2 mouse driver
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 as published by
 * the Free Software Foundation.
 */

#ifndef _SYNAPTICS_H
#define _SYNAPTICS_H

extern void synaptics_process_byte();
extern int synaptics_detect();
extern int synaptics_init();
extern void synaptics_reset();

/* synaptics queries */
#define SYN_QUE_IDENTIFY		0x00
#define SYN_QUE_MODES			0x01
#define SYN_QUE_CAPABILITIES		0x02
#define SYN_QUE_MODEL			0x03
#define SYN_QUE_SERIAL_NUMBER_PREFIX	0x06
#define SYN_QUE_SERIAL_NUMBER_SUFFIX	0x07
#define SYN_QUE_RESOLUTION		0x08
#define SYN_QUE_EXT_CAPAB		0x09

/* synatics modes */
#define SYN_BIT_ABSOLUTE_MODE		(1 << 7)
#define SYN_BIT_HIGH_RATE		(1 << 6)
#define SYN_BIT_SLEEP_MODE		(1 << 3)
#define SYN_BIT_DISABLE_GESTURE		(1 << 2)
#define SYN_BIT_FOUR_BYTE_CLIENT	(1 << 1)
#define SYN_BIT_W_MODE			(1 << 0)

/* synaptics model ID bits */
#define SYN_MODEL_ROT180(m)		((m) & (1 << 23))
#define SYN_MODEL_PORTRAIT(m)		((m) & (1 << 22))
#define SYN_MODEL_SENSOR(m)		(((m) >> 16) & 0x3f)
#define SYN_MODEL_HARDWARE(m)		(((m) >> 9) & 0x7f)
#define SYN_MODEL_NEWABS(m)		((m) & (1 << 7))
#define SYN_MODEL_PEN(m)		((m) & (1 << 6))
#define SYN_MODEL_SIMPLIC(m)		((m) & (1 << 5))
#define SYN_MODEL_GEOMETRY(m)		((m) & 0x0f)

/* synaptics capability bits */
#define SYN_CAP_EXTENDED(c)		((c) & (1 << 23))
#define SYN_CAP_PASS_THROUGH(c)		((c) & (1 << 7))
#define SYN_CAP_SLEEP(c)		((c) & (1 << 4))
#define SYN_CAP_FOUR_BUTTON(c)		((c) & (1 << 3))
#define SYN_CAP_MULTIFINGER(c)		((c) & (1 << 1))
#define SYN_CAP_PALMDETECT(c)		((c) & (1 << 0))
#define SYN_CAP_VALID(c)		((((c) & 0x00ff00) >> 8) == 0x47)
#define SYN_EXT_CAP_REQUESTS(c)		((((c) & 0x700000) >> 20) == 1)
#define SYN_CAP_MULTI_BUTTON_NO(ec)	(((ec) & 0x00f000) >> 12)

/* synaptics modes query bits */
#define SYN_MODE_ABSOLUTE(m)		((m) & (1 << 7))
#define SYN_MODE_RATE(m)		((m) & (1 << 6))
#define SYN_MODE_BAUD_SLEEP(m)		((m) & (1 << 3))
#define SYN_MODE_DISABLE_GESTURE(m)	((m) & (1 << 2))
#define SYN_MODE_PACKSIZE(m)		((m) & (1 << 1))
#define SYN_MODE_WMODE(m)		((m) & (1 << 0))

/* synaptics identify query bits */
#define SYN_ID_MODEL(i) 		(((i) >> 4) & 0x0f)
#define SYN_ID_MAJOR(i) 		((i) & 0x0f)
#define SYN_ID_MINOR(i) 		(((i) >> 16) & 0xff)
#define SYN_ID_IS_SYNAPTICS(i)		((((i) >> 8) & 0xff) == 0x47)

/* synaptics special commands */
#define SYN_PS_SET_MODE2		0x14
#define SYN_PS_CLIENT_CMD		0x28

/* synaptics packet types */
#define SYN_NEWABS			0
#define SYN_NEWABS_STRICT		1
#define SYN_NEWABS_RELAXED		2
#define SYN_OLDABS			3

/*
 * A structure to describe the state of the touchpad hardware (buttons and pad)
 */

struct synaptics_hw_state {
	int x;
	int y;
	int z;
	int w;
	int left;
	int right;
	int up;
	int down;
	int b0;
	int b1;
	int b2;
	int b3;
	int b4;
	int b5;
	int b6;
	int b7;
};

struct synaptics_data {
	/* Data read from the touchpad */
	unsigned long int model_id;		/* Model-ID */
	unsigned long int capabilities; 	/* Capabilities */
	unsigned long int ext_cap; 		/* Extended Capabilities */
	unsigned long int identity;		/* Identification */

	/* Data for normal processing */
	unsigned int out_of_sync;		/* # of packets out of sync */
	int old_w;				/* Previous w value */
	unsigned char pkt_type;			/* packet type - old, new, etc */
};

#endif /* _SYNAPTICS_H */
 * Synaptics TouchPad PS/2 mouse driver
 *
 *   2004 Sau Dan LEE
 *
 *   2003 Dmitry Torokhov <dtor@mail.ru>
 *     Added support for pass-through port. Special thanks to Peter Berg Larsen
 *     for explaining various Synaptics quirks.
 *
 *   2003 Peter Osterlund <petero2@telia.com>
 *     Ported to 2.5 input device infrastructure.
 *
 *   Copyright (C) 2001 Stefan Gmeiner <riddlebox@freesurf.ch>
 *     start merging tpconfig and gpm code to a xfree-input module
 *     adding some changes and extensions (ex. 3rd and 4th button)
 *
 *   Copyright (c) 1997 C. Scott Ananian <cananian@alumni.priceton.edu>
 *   Copyright (c) 1998-2000 Bruce Kalk <kall@compass.com>
 *     code for the special synaptics commands (from the tpconfig-source)
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 as published by
 * the Free Software Foundation.
 *
 * Trademarks are the property of their respective owners.
 */

#include <stdio.h>
#include <stdlib.h>
#include <linux/input.h>
#include "psmouse.h"
#include "synaptics.h"

/*
 * The x/y limits are taken from the Synaptics TouchPad interfacing Guide,
 * section 2.3.2, which says that they should be valid regardless of the
 * actual size of the sensor.
 */
#define XMIN_NOMINAL 1472
#define XMAX_NOMINAL 5472
#define YMIN_NOMINAL 1408
#define YMAX_NOMINAL 4448

/*****************************************************************************
 *	Synaptics communications functions
 ****************************************************************************/

/*
 * Use the Synaptics extended ps/2 syntax to write a special command byte.
 * special command: 0xE8 rr 0xE8 ss 0xE8 tt 0xE8 uu where (rr*64)+(ss*16)+(tt*4)+uu
 *                  is the command. A 0xF3 or 0xE9 must follow (see synaptics_send_cmd
 *                  and synaptics_mode_cmd)
 */
static int synaptics_special_cmd(unsigned char command)
{
	int i;

	if (psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11))
		return -1;

	for (i = 6; i >= 0; i -= 2) {
		unsigned char d = (command >> i) & 3;
		if (psmouse_command(&d, PSMOUSE_CMD_SETRES))
			return -1;
	}

	return 0;
}

/*
 * Send a command to the synpatics touchpad by special commands
 */
static int synaptics_send_cmd(unsigned char c, unsigned char *param)
{
	if (synaptics_special_cmd(c))
		return -1;
	if (psmouse_command(param, PSMOUSE_CMD_GETINFO))
		return -1;
	return 0;
}

/*
 * Set the synaptics touchpad mode byte by special commands
 */
static int synaptics_mode_cmd(struct psmouse *psmouse, unsigned char mode)
{
	unsigned char param[1];

	if (synaptics_special_cmd(mode))
		return -1;
	param[0] = SYN_PS_SET_MODE2;
	if (psmouse_command(param, PSMOUSE_CMD_SETRATE))
		return -1;
	return 0;
}

/*
 * Read the model-id bytes from the touchpad
 * see also SYN_MODEL_* macros
 */
static int synaptics_model_id()
{
	struct synaptics_data *priv = psmouse->private;
	unsigned char mi[3];

	if (synaptics_send_cmd(SYN_QUE_MODEL, mi))
		return -1;
	priv->model_id = (mi[0]<<16) | (mi[1]<<8) | mi[2];
	return 0;
}

/*
 * Read the capability-bits from the touchpad
 * see also the SYN_CAP_* macros
 */
static int synaptics_capability()
{
	struct synaptics_data *priv = psmouse->private;
	unsigned char cap[3];

	if (synaptics_send_cmd(SYN_QUE_CAPABILITIES, cap))
		return -1;
	priv->capabilities = (cap[0]<<16) | (cap[1]<<8) | cap[2];
	priv->ext_cap = 0;
	if (!SYN_CAP_VALID(priv->capabilities))
		return -1;

	if (SYN_EXT_CAP_REQUESTS(priv->capabilities)) {
		if (synaptics_send_cmd(SYN_QUE_EXT_CAPAB, cap)) {
			err("Synaptics claims to have extended capabilities,"
			       " but I'm not able to read them.");
		} else
			priv->ext_cap = (cap[0]<<16) | (cap[1]<<8) | cap[2];
	}
	return 0;
}

/*
 * Identify Touchpad
 * See also the SYN_ID_* macros
 */
static int synaptics_identify()
{
	struct synaptics_data *priv = psmouse->private;
	unsigned char id[3];

	if (synaptics_send_cmd(SYN_QUE_IDENTIFY, id))
		return -1;
	priv->identity = (id[0]<<16) | (id[1]<<8) | id[2];
	if (SYN_ID_IS_SYNAPTICS(priv->identity))
		return 0;
	return -1;
}

static void print_ident(struct synaptics_data *priv)
{
	info("Synaptics Touchpad, model: %ld\n", SYN_ID_MODEL(priv->identity));
	info(" Firmware: %ld.%ld\n", SYN_ID_MAJOR(priv->identity),
	       SYN_ID_MINOR(priv->identity));
	if (SYN_MODEL_ROT180(priv->model_id))
		info(" 180 degree mounted touchpad\n");
	if (SYN_MODEL_PORTRAIT(priv->model_id))
		info(" portrait touchpad\n");
	info(" Sensor: %ld\n", SYN_MODEL_SENSOR(priv->model_id));
	if (SYN_MODEL_NEWABS(priv->model_id))
		info(" new absolute packet format\n");
	if (SYN_MODEL_PEN(priv->model_id))
		info(" pen detection\n");

	if (SYN_CAP_EXTENDED(priv->capabilities)) {
		info(" Touchpad has extended capability bits\n");
		if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) &&
		    SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) <= 8)
			info(" -> %d multi-buttons, i.e. besides standard buttons\n",
			       (int)(SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap)));
		else if (SYN_CAP_FOUR_BUTTON(priv->capabilities))
			info(" -> four buttons\n");
		if (SYN_CAP_MULTIFINGER(priv->capabilities))
			info(" -> multifinger detection\n");
		if (SYN_CAP_PALMDETECT(priv->capabilities))
			info(" -> palm detection\n");
		if (SYN_CAP_PASS_THROUGH(priv->capabilities))
			info(" -> pass-through port\n");
	}
}

static int synaptics_query_hardware()
{
	int retries = 0;

	while ((retries++ < 3) && psmouse_reset())
		err("synaptics reset failed\n");

	if (synaptics_identify())
		return -1;
	if (synaptics_model_id())
		return -1;
	if (synaptics_capability())
		return -1;

	return 0;
}

static int synaptics_set_mode(struct psmouse *psmouse, int mode)
{
	struct synaptics_data *priv = psmouse->private;

	mode |= SYN_BIT_ABSOLUTE_MODE;
	if (psmouse_rate >= 80)
		mode |= SYN_BIT_HIGH_RATE;
	if (SYN_ID_MAJOR(priv->identity) >= 4)
		mode |= SYN_BIT_DISABLE_GESTURE;
	if (SYN_CAP_EXTENDED(priv->capabilities))
		mode |= SYN_BIT_W_MODE;
	if (synaptics_mode_cmd(psmouse, mode))
		return -1;

	return 0;
}


/*****************************************************************************
 *	Driver initialization/cleanup functions
 ****************************************************************************/

#if 0
static inline void set_abs_params(struct input_dev *dev, int axis, int min, int max, int fuzz, int flat)
{
	dev->absmin[axis] = min;
	dev->absmax[axis] = max;
	dev->absfuzz[axis] = fuzz;
	dev->absflat[axis] = flat;

	set_bit(axis, dev->absbit);
}

static void set_input_params(struct input_dev *dev, struct synaptics_data *priv)
{
	set_bit(EV_ABS, dev->evbit);
	set_abs_params(dev, ABS_X, XMIN_NOMINAL, XMAX_NOMINAL, 0, 0);
	set_abs_params(dev, ABS_Y, YMIN_NOMINAL, YMAX_NOMINAL, 0, 0);
	set_abs_params(dev, ABS_PRESSURE, 0, 255, 0, 0);
	set_bit(ABS_TOOL_WIDTH, dev->absbit);

	set_bit(EV_KEY, dev->evbit);
	set_bit(BTN_TOUCH, dev->keybit);
	set_bit(BTN_TOOL_FINGER, dev->keybit);
	set_bit(BTN_TOOL_DOUBLETAP, dev->keybit);
	set_bit(BTN_TOOL_TRIPLETAP, dev->keybit);

	set_bit(BTN_LEFT, dev->keybit);
	set_bit(BTN_RIGHT, dev->keybit);
	set_bit(BTN_FORWARD, dev->keybit);
	set_bit(BTN_BACK, dev->keybit);
	if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap)) {
		switch (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
		default:
			/*
			 * if nExtBtn is greater than 8 it should be considered
			 * invalid and treated as 0
			 */
			break;
		case 8:
			set_bit(BTN_7, dev->keybit);
			set_bit(BTN_6, dev->keybit);
		case 6:
			set_bit(BTN_5, dev->keybit);
			set_bit(BTN_4, dev->keybit);
		case 4:
			set_bit(BTN_3, dev->keybit);
			set_bit(BTN_2, dev->keybit);
		case 2:
			set_bit(BTN_1, dev->keybit);
			set_bit(BTN_0, dev->keybit);
			break;
		}
	}

	clear_bit(EV_REL, dev->evbit);
	clear_bit(REL_X, dev->relbit);
	clear_bit(REL_Y, dev->relbit);
}
#endif

void synaptics_reset()
{
	/* reset touchpad back to relative mode, gestures enabled */
	synaptics_mode_cmd(psmouse, 0);
}

static void synaptics_disconnect()
{
	synaptics_reset(psmouse);
}

static int synaptics_reconnect()
{
	struct synaptics_data *priv = psmouse->private;
	struct synaptics_data old_priv = *priv;

	if (!synaptics_detect())
		return -1;

	if (synaptics_query_hardware()) {
		err("Unable to query Synaptics hardware.\n");
		return -1;
	}

	if (old_priv.identity != priv->identity ||
	    old_priv.model_id != priv->model_id ||
	    old_priv.capabilities != priv->capabilities ||
    	    old_priv.ext_cap != priv->ext_cap)
    		return -1;

	if (synaptics_set_mode(psmouse, 0)) {
		err("Unable to initialize Synaptics hardware.\n");
		return -1;
	}

	return 0;
}

int synaptics_detect()
{
	unsigned char param[4];

	param[0] = 0;

	psmouse_command(param, PSMOUSE_CMD_SETRES);
	psmouse_command(param, PSMOUSE_CMD_SETRES);
	psmouse_command(param, PSMOUSE_CMD_SETRES);
	psmouse_command(param, PSMOUSE_CMD_SETRES);
	psmouse_command(param, PSMOUSE_CMD_GETINFO);

	return param[1] == 0x47;
}

int synaptics_init()
{
	struct synaptics_data *priv;

	psmouse->private = priv = calloc(1, sizeof(struct synaptics_data));
	if (!priv)
		return -1;

	if (synaptics_query_hardware(psmouse)) {
		err("Unable to query Synaptics hardware.\n");
		goto init_fail;
	}

	if (synaptics_set_mode(psmouse, 0)) {
		err("Unable to initialize Synaptics hardware.\n");
		goto init_fail;
	}

	priv->pkt_type = SYN_MODEL_NEWABS(priv->model_id) ? SYN_NEWABS : SYN_OLDABS;

	print_ident(priv);

	psmouse->disconnect = synaptics_disconnect;
	psmouse->reconnect = synaptics_reconnect;

	return 0;

 init_fail:
	return -1;
}

/*****************************************************************************
 *	Functions to interpret the absolute mode packets
 ****************************************************************************/

static void synaptics_parse_hw_state(unsigned char buf[], struct synaptics_data *priv, struct synaptics_hw_state *hw)
{
	memset(hw, 0, sizeof(struct synaptics_hw_state));

	if (SYN_MODEL_NEWABS(priv->model_id)) {
		hw->x = (((buf[3] & 0x10) << 8) |
			 ((buf[1] & 0x0f) << 8) |
			 buf[4]);
		hw->y = (((buf[3] & 0x20) << 7) |
			 ((buf[1] & 0xf0) << 4) |
			 buf[5]);

		hw->z = buf[2];
		hw->w = (((buf[0] & 0x30) >> 2) |
			 ((buf[0] & 0x04) >> 1) |
			 ((buf[3] & 0x04) >> 2));

		hw->left  = (buf[0] & 0x01) ? 1 : 0;
		hw->right = (buf[0] & 0x02) ? 1 : 0;
		if (SYN_CAP_EXTENDED(priv->capabilities) &&
		    (SYN_CAP_FOUR_BUTTON(priv->capabilities))) {
			hw->up = ((buf[3] & 0x01)) ? 1 : 0;
			if (hw->left)
				hw->up = !hw->up;
			hw->down = ((buf[3] & 0x02)) ? 1 : 0;
			if (hw->right)
				hw->down = !hw->down;
		}
		if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) &&
		    ((buf[3] & 2) ? !hw->right : hw->right)) {
			switch (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
			default:
				/*
				 * if nExtBtn is greater than 8 it should be
				 * considered invalid and treated as 0
				 */
				break;
			case 8:
				hw->b7 = ((buf[5] & 0x08)) ? 1 : 0;
				hw->b6 = ((buf[4] & 0x08)) ? 1 : 0;
			case 6:
				hw->b5 = ((buf[5] & 0x04)) ? 1 : 0;
				hw->b4 = ((buf[4] & 0x04)) ? 1 : 0;
			case 4:
				hw->b3 = ((buf[5] & 0x02)) ? 1 : 0;
				hw->b2 = ((buf[4] & 0x02)) ? 1 : 0;
			case 2:
				hw->b1 = ((buf[5] & 0x01)) ? 1 : 0;
				hw->b0 = ((buf[4] & 0x01)) ? 1 : 0;
			}
		}
	} else {
		hw->x = (((buf[1] & 0x1f) << 8) | buf[2]);
		hw->y = (((buf[4] & 0x1f) << 8) | buf[5]);

		hw->z = (((buf[0] & 0x30) << 2) | (buf[3] & 0x3F));
		hw->w = (((buf[1] & 0x80) >> 4) | ((buf[0] & 0x04) >> 1));

		hw->left  = (buf[0] & 0x01) ? 1 : 0;
		hw->right = (buf[0] & 0x02) ? 1 : 0;
	}
}

/*
 *  called for each full received packet from the touchpad
 */
static void synaptics_process_packet()
{
	struct synaptics_data *priv = psmouse->private;
	struct synaptics_hw_state hw;
	int num_fingers;
	int finger_width;

	synaptics_parse_hw_state(psmouse->packet, priv, &hw);

	if (hw.z > 0) {
		num_fingers = 1;
		finger_width = 5;
		if (SYN_CAP_EXTENDED(priv->capabilities)) {
			switch (hw.w) {
			case 0 ... 1:
				if (SYN_CAP_MULTIFINGER(priv->capabilities))
					num_fingers = hw.w + 2;
				break;
			case 2:
				if (SYN_MODEL_PEN(priv->model_id))
					;   /* Nothing, treat a pen as a single finger */
				break;
			case 4 ... 15:
				if (SYN_CAP_PALMDETECT(priv->capabilities))
					finger_width = hw.w;
				break;
			}
		}
	} else {
		num_fingers = 0;
		finger_width = 0;
	}

	/* Post events
	 * BTN_TOUCH has to be first as mousedev relies on it when doing
	 * absolute -> relative conversion
	 */
	if (hw.z > 30) uinput_report_key(BTN_TOUCH, 1);
	if (hw.z < 25) uinput_report_key(BTN_TOUCH, 0);

	if (hw.z > 0) {
		uinput_report_abs(ABS_X, hw.x);
		uinput_report_abs(ABS_Y, YMAX_NOMINAL + YMIN_NOMINAL - hw.y);
	}
	uinput_report_abs(ABS_PRESSURE, hw.z);

	uinput_report_abs(ABS_TOOL_WIDTH, finger_width);
	uinput_report_key(BTN_TOOL_FINGER, num_fingers == 1);
	uinput_report_key(BTN_TOOL_DOUBLETAP, num_fingers == 2);
	uinput_report_key(BTN_TOOL_TRIPLETAP, num_fingers == 3);

	uinput_report_key(BTN_LEFT,    hw.left);
	uinput_report_key(BTN_RIGHT,   hw.right);
	uinput_report_key(BTN_FORWARD, hw.up);
	uinput_report_key(BTN_BACK,    hw.down);
	if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap))
		switch(SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
		default:
			/*
			 * if nExtBtn is greater than 8 it should be considered
			 * invalid and treated as 0
			 */
			break;
		case 8:
			uinput_report_key(BTN_7,       hw.b7);
			uinput_report_key(BTN_6,       hw.b6);
		case 6:
			uinput_report_key(BTN_5,       hw.b5);
			uinput_report_key(BTN_4,       hw.b4);
		case 4:
			uinput_report_key(BTN_3,       hw.b3);
			uinput_report_key(BTN_2,       hw.b2);
		case 2:
			uinput_report_key(BTN_1,       hw.b1);
			uinput_report_key(BTN_0,       hw.b0);
			break;
		}
	uinput_sync();
}

static int synaptics_validate_byte(unsigned char packet[], int idx, unsigned char pkt_type)
{
	static unsigned char newabs_mask[]	= { 0xC8, 0x00, 0x00, 0xC8, 0x00 };
	static unsigned char newabs_rel_mask[]	= { 0xC0, 0x00, 0x00, 0xC0, 0x00 };
	static unsigned char newabs_rslt[]	= { 0x80, 0x00, 0x00, 0xC0, 0x00 };
	static unsigned char oldabs_mask[]	= { 0xC0, 0x60, 0x00, 0xC0, 0x60 };
	static unsigned char oldabs_rslt[]	= { 0xC0, 0x00, 0x00, 0x80, 0x00 };

	switch (pkt_type) {
		case SYN_NEWABS:
		case SYN_NEWABS_RELAXED:
			return (packet[idx] & newabs_rel_mask[idx]) == newabs_rslt[idx];

		case SYN_NEWABS_STRICT:
			return (packet[idx] & newabs_mask[idx]) == newabs_rslt[idx];

		case SYN_OLDABS:
			return (packet[idx] & oldabs_mask[idx]) == oldabs_rslt[idx];

		default:
			err("synaptics: unknown packet type %d\n", pkt_type);
			return 0;
	}
}

static unsigned char synaptics_detect_pkt_type(struct psmouse *psmouse)
{
	int i;

	for (i = 0; i < 5; i++)
		if (!synaptics_validate_byte(psmouse->packet, i, SYN_NEWABS_STRICT)) {
			info("synaptics: using relaxed packet validation\n");
			return SYN_NEWABS_RELAXED;
		}

	return SYN_NEWABS_STRICT;
}

void synaptics_process_byte()
{
	struct synaptics_data *priv = psmouse->private;

	if (psmouse->pktcnt >= 6) { /* Full packet received */
		if (priv->out_of_sync) {
			priv->out_of_sync = 0;
			notice("Synaptics driver resynced.\n");
		}

		if (unlikely(priv->pkt_type == SYN_NEWABS))
			priv->pkt_type = synaptics_detect_pkt_type(psmouse);

		synaptics_process_packet();
		psmouse->pktcnt = 0;

	} else if (psmouse->pktcnt &&
		   !synaptics_validate_byte(psmouse->packet, psmouse->pktcnt - 1, priv->pkt_type)) {
		warn("Synaptics driver lost sync at byte %d\n", psmouse->pktcnt);
		psmouse->pktcnt = 0;
		if (++priv->out_of_sync == psmouse_resetafter) {
			psmouse->state = PSMOUSE_IGNORE;
			notice("synaptics: issuing reconnect request\n");
			phys_reconnect();
		}
	}
}
#define _PSMOUSE_H

#define PSMOUSE_CMD_SETSCALE11	0x00e6
#define PSMOUSE_CMD_SETRES	0x10e8
#define PSMOUSE_CMD_GETINFO	0x03e9
#define PSMOUSE_CMD_SETSTREAM	0x00ea
#define PSMOUSE_CMD_POLL	0x03eb
#define PSMOUSE_CMD_GETID	0x02f2
#define PSMOUSE_CMD_SETRATE	0x10f3
#define PSMOUSE_CMD_ENABLE	0x00f4
#define PSMOUSE_CMD_RESET_DIS	0x00f6
#define PSMOUSE_CMD_RESET_BAT	0x02ff

#define PSMOUSE_RET_BAT		0xaa
#define PSMOUSE_RET_ID		0x00
#define PSMOUSE_RET_ACK		0xfa
#define PSMOUSE_RET_NAK		0xfe

/* psmouse states */
#define PSMOUSE_CMD_MODE	0
#define PSMOUSE_ACTIVATED	1
#define PSMOUSE_IGNORE		2

struct psmouse;

struct psmouse {
	void *private;
	char *vendor;
	char *name;
	unsigned char cmdbuf[8];
	unsigned char packet[8];
	unsigned char cmdcnt;
	unsigned char pktcnt;
	unsigned char type;
	unsigned char model;
	unsigned char state;
	char acking;
	volatile char ack;
	char error;
	char devname[64];
	long long last;

	int (*reconnect)();
	void (*disconnect)();
};

#define PSMOUSE_PS2		1
#define PSMOUSE_PS2PP		2
#define PSMOUSE_PS2TPP		3
#define PSMOUSE_GENPS		4
#define PSMOUSE_IMPS		5
#define PSMOUSE_IMEX		6
#define PSMOUSE_SYNAPTICS 	7

extern int psmouse_command(unsigned char *param, int command);
extern int psmouse_reset(void);

extern void phys_reconnect();

extern int psmouse_smartscroll;
extern unsigned int psmouse_rate;
extern unsigned int psmouse_resetafter;

extern struct psmouse * const psmouse;


extern void uinput_set_evbit(int bit);
extern void uinput_set_ledbit(int bit);
extern void uinput_set_keybit(int bit);
extern void uinput_set_relbit(int bit);

extern void uinput_event(__u16 type, __u16 code, __s32 value);
#define uinput_report_key(code,value) uinput_event(EV_KEY, (code), (value))
#define uinput_report_rel(code,value) uinput_event(EV_REL, (code), (value))
#define uinput_report_abs(code,value) uinput_event(EV_ABS, (code), (value))
#define uinput_sync() uinput_event(EV_SYN, 0, 0)



#define warn(...) fprintf(stderr, "psmouse: (warning) " __VA_ARGS__)
#define err(...)  fprintf(stderr, "psmouse: ERROR " __VA_ARGS__)
#define info(...) printf("psmouse: " __VA_ARGS__)
#define notice(...) printf("psmouse: NOTE " __VA_ARGS__)
#define perr(msg)  do{fprintf(stderr, "psmouse: ERROR: "); perror(msg);}while(0)
#define perrx(msg) do{perr(msg); exit(1);}while(0)
#define pferrx() perrx(__FUNCTION__)
#define unlikely /* */

#endif /* _PSMOUSE_H */
 * PS/2 mouse driver
 *
 * Copyright (c) 1999-2002 Vojtech Pavlik
 * Copyright (c) 2004 Sau Dan LEE
 */

/*
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 as published by
 * the Free Software Foundation.
 */

/*
  This program is based on linux-2.6.6/drivers/input/mouse/*
  The difference is that this program 'psmouse' now runs in user-space
  (swappable),  while the kernel driver runs in kernel-space.

  Usage: psmouse /dev/misc/isa0060/serio0

  Prerequisites:
     1) 'uinput' module loaded or compiled in
         If not using 'devfs', you have to create the /dev/uinput char
         device with major 10.  The minor number can be found in
	 "cat /proc/misc" after loading the 'uinput' module.
     2) 'serio' module with SERIO_USERDEV patch loaded or compiled in
     3) 'i8042' module loaded or compiled in
     4) 'psmouse' module UNloaded and NOT compiled in
     5) 'mousedev' loaded to do anything really useful

  TODO:
     - options parsing should be added to allow user to
       specify the module parameters.
     - daemonize this program, so as to make it easy to run from /etc/inittab
     - pass-through port of synaptics devices is not supported yet.
*/


#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/time.h>
#include <linux/input.h>
#include <linux/uinput.h>
#include "psmouse.h"

#define module_param_named(name,var,type,defl) struct dummy
#define MODULE_PARM_DESC(name,desc) struct dummy




static char *psmouse_proto;
static unsigned int psmouse_max_proto = -1U;
module_param_named(proto, psmouse_proto, charp, 0);
MODULE_PARM_DESC(proto, "Highest protocol extension to probe (bare, imps, exps). Useful for KVM switches.");

int psmouse_resolution = 200;
module_param_named(resolution, psmouse_resolution, uint, 0);
MODULE_PARM_DESC(resolution, "Resolution, in dpi.");

unsigned int psmouse_rate = 100;
module_param_named(rate, psmouse_rate, uint, 0);
MODULE_PARM_DESC(rate, "Report rate, in reports per second.");

int psmouse_smartscroll = 1;
module_param_named(smartscroll, psmouse_smartscroll, bool, 0);
MODULE_PARM_DESC(smartscroll, "Logitech Smartscroll autorepeat, 1 = enabled (default), 0 = disabled.");

unsigned int psmouse_resetafter;
module_param_named(resetafter, psmouse_resetafter, uint, 0);
MODULE_PARM_DESC(resetafter, "Reset Synaptics Touchpad after so many bad packets (0 = never).");


static char *psmouse_protocols[] = { "None", "PS/2", "PS2++", "PS2T++", "GenPS/2", "ImPS/2", "ImExPS/2", "SynPS/2"};


static struct psmouse psmouse_data;
struct psmouse * const psmouse = &psmouse_data;


/********** functions for interacting with 'uinput' **********/

static const char *uinput_dev_name = NULL;
static int uinput_fd;

static void uinput_open() {
	uinput_fd = open(uinput_dev_name, O_WRONLY);
}

void uinput_set_evbit(int bit) {
	int r;

	r = ioctl(uinput_fd, UI_SET_EVBIT, bit);
	if (r==-1) { pferrx(); }
}

void uinput_set_ledbit(int bit) {
	int r;

	r = ioctl(uinput_fd, UI_SET_LEDBIT, bit);
	if (r==-1) { pferrx();}
}

void uinput_set_keybit(int bit) {
	int r;

	r = ioctl(uinput_fd, UI_SET_KEYBIT, bit);
	if (r==-1) { pferrx(); }
}

void uinput_set_relbit(int bit) {
	int r;

	r = ioctl(uinput_fd, UI_SET_RELBIT, bit);
	if (r==-1) { pferrx(); }
}


static const char* phys_filename;
static void uinput_create() {
	struct uinput_user_dev uinput = {
		.name = "psmouse ",
	};
	int r;

	snprintf(uinput.name, UINPUT_MAX_NAME_SIZE,
		 "psmouse %s", phys_filename);

	r = write(uinput_fd, &uinput, sizeof(uinput));
	if (r==-1) { pferrx(); }

	r = ioctl(uinput_fd, UI_DEV_CREATE);
	if (r==-1) { pferrx(); }
}

static void uinput_destroy() {
	int r;

	r = ioctl(uinput_fd, UI_DEV_DESTROY);
	if (r==-1) { pferrx(); }
}

static void uinput_close() {
	int r;

	r = close(uinput_fd);
	if (r==-1) { pferrx(); }
}

void uinput_event(__u16 type, __u16 code, __s32 value) {
	struct input_event ev = {
		.type = type,
		.code = code,
		.value = value
	};
	int r;

	r = write(uinput_fd, &ev, sizeof(ev));
	if (r!=sizeof(ev)) { pferrx(); }
}



/********** functions for accessing the raw keyboard device **********/

static int phys_fd = -1;
static const char* phys_filename;

static int phys_open() {
	phys_fd = open(phys_filename, O_RDWR);
	if (phys_fd == -1) {
		const int e = errno;
		perr(phys_filename);
		switch (e) {
		case EACCES:
			err("read-write access required.  Are you 'root'?\n");
			break;
		}
		exit(1);
	}
	return 0;
}

static int phys_write(unsigned char byte) {
	int r;
	r = write(phys_fd, &byte, 1);
	if (r==-1) { pferrx(); }
	if (r!=1) { err("cannot write"); exit(1); }
	return 0;
}

static void psmouse_interrupt(unsigned char data,
			      unsigned int flags);

static int phys_wait_for_input(int *ptimeout) {
	unsigned char byte;
	int r;

	if (ptimeout != NULL) {
		fd_set fds;
		struct timeval tv;

		FD_ZERO(&fds);
		FD_SET(phys_fd, &fds);
		tv.tv_sec=0; tv.tv_usec=*ptimeout;
		r = select(phys_fd+1, &fds, NULL, &fds, &tv);
		*ptimeout = tv.tv_sec*1000000 + tv.tv_usec;
		if (r==-1) { pferrx(); }
		if (r==0) { return -1; } /* timeout */
		if (r!=1) { err("cannot select"); exit(1); }
	}

	r = read(phys_fd, &byte, 1);
	if (r==-1) { pferrx(); }
	if (r!=1) { err("cannot read"); exit(1); }

	psmouse_interrupt(byte, 0);
	return 0;
}

static void phys_close() {
	int r;
	r = close(phys_fd);
	if (r==-1) { pferrx(); }
}

static int psmouse_connect();
static void psmouse_disconnect();
static int psmouse_reconnect();

static void phys_rescan() {
	psmouse_disconnect();
	psmouse_connect();
}

void phys_reconnect() {
	psmouse_reconnect();
}



/*
 * psmouse_process_packet() analyzes the PS/2 mouse packet contents and
 * reports relevant events to the input module.
 */

static void psmouse_process_packet()
{
	unsigned char *packet = psmouse->packet;


/*
 * The PS2++ protocol is a little bit complex
 */

	if (psmouse->type == PSMOUSE_PS2PP || psmouse->type == PSMOUSE_PS2TPP)
		ps2pp_process_packet();

/*
 * Scroll wheel on IntelliMice, scroll buttons on NetMice
 */

	if (psmouse->type == PSMOUSE_IMPS || psmouse->type == PSMOUSE_GENPS)
		uinput_report_rel(REL_WHEEL, -(signed char) packet[3]);

/*
 * Scroll wheel and buttons on IntelliMouse Explorer
 */

	if (psmouse->type == PSMOUSE_IMEX) {
		uinput_report_rel(REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[3] & 7));
		uinput_report_key(BTN_SIDE, (packet[3] >> 4) & 1);
		uinput_report_key(BTN_EXTRA, (packet[3] >> 5) & 1);
	}

/*
 * Extra buttons on Genius NewNet 3D
 */

	if (psmouse->type == PSMOUSE_GENPS) {
		uinput_report_key(BTN_SIDE, (packet[0] >> 6) & 1);
		uinput_report_key(BTN_EXTRA, (packet[0] >> 7) & 1);
	}

/*
 * Generic PS/2 Mouse
 */

	uinput_report_key(BTN_LEFT,    packet[0]       & 1);
	uinput_report_key(BTN_MIDDLE, (packet[0] >> 2) & 1);
	uinput_report_key(BTN_RIGHT,  (packet[0] >> 1) & 1);

	uinput_report_rel(REL_X, packet[1] ? (int) packet[1] - (int) ((packet[0] << 4) & 0x100) : 0);
	uinput_report_rel(REL_Y, packet[2] ? (int) ((packet[0] << 3) & 0x100) - (int) packet[2] : 0);

	uinput_sync();
}

/*
 * psmouse_interrupt() handles incoming characters, either gathering them into
 * packets or passing them to the command routine as command output.
 */

static void psmouse_interrupt(unsigned char data, unsigned int flags)
{
	if (psmouse->state == PSMOUSE_IGNORE)
		goto out;

	if (psmouse->acking) {
		switch (data) {
			case PSMOUSE_RET_ACK:
				psmouse->ack = 1;
				break;
			case PSMOUSE_RET_NAK:
				psmouse->ack = -1;
				break;
			default:
				psmouse->ack = 1;	/* Workaround for mice which don't ACK the Get ID command */
				if (psmouse->cmdcnt)
					psmouse->cmdbuf[--psmouse->cmdcnt] = data;
				break;
		}
		psmouse->acking = 0;
		goto out;
	}

	if (psmouse->cmdcnt) {
		psmouse->cmdbuf[--psmouse->cmdcnt] = data;
		goto out;
	}

	{
	struct timeval tv;
	long long jiffies;
	int r;

	r = gettimeofday(&tv, NULL);
	if (r==-1) { pferrx(); }
	jiffies = tv.tv_sec * 1000000 + tv.tv_usec;

	if (psmouse->state == PSMOUSE_ACTIVATED &&
	    psmouse->pktcnt 
	    &&  jiffies > psmouse->last + 500000) {
		warn("%s lost synchronization, throwing %d bytes away.\n",
		       psmouse->name, psmouse->pktcnt);
		psmouse->pktcnt = 0;
	}

	psmouse->last = jiffies;
	}

	psmouse->packet[psmouse->pktcnt++] = data;

	if (psmouse->packet[0] == PSMOUSE_RET_BAT) {
		if (psmouse->pktcnt == 1)
			goto out;

		if (psmouse->pktcnt == 2) {
			if (psmouse->packet[1] == PSMOUSE_RET_ID) {
				psmouse->state = PSMOUSE_IGNORE;
				phys_rescan();
				goto out;
			}
			if (psmouse->type == PSMOUSE_SYNAPTICS) {
				/* neither 0xAA nor 0x00 are valid first bytes
				 * for a packet in absolute mode
				 */
				psmouse->pktcnt = 0;
				goto out;
			}
		}
	}

	if (psmouse->type == PSMOUSE_SYNAPTICS) {
		/*
		 * The synaptics driver has its own resync logic,
		 * so it needs to receive all bytes one at a time.
		 */
		synaptics_process_byte(psmouse);
		goto out;
	}

	if (psmouse->pktcnt == 3 + (psmouse->type >= PSMOUSE_GENPS)) {
		psmouse_process_packet();
		psmouse->pktcnt = 0;
		goto out;
	}
out:
	return;
}

/*
 * psmouse_sendbyte() sends a byte to the mouse, and waits for acknowledge.
 * It doesn't handle retransmission, though it could - because when there would
 * be need for retransmissions, the mouse has to be replaced anyway.
 */

static int psmouse_sendbyte(unsigned char byte)
{
	int timeout = 10000; /* 100 msec */
	psmouse->ack = 0;
	psmouse->acking = 1;

	if (phys_write(byte)) {
		psmouse->acking = 0;
		return -1;
	}

	while (!psmouse->ack && timeout>0)
		phys_wait_for_input(&timeout);

	return -(psmouse->ack <= 0);
}

/*
 * psmouse_command() sends a command and its parameters to the mouse,
 * then waits for the response and puts it in the param array.
 */

int psmouse_command(unsigned char *param, int command)
{
	int timeout = 500000; /* 500 msec */
	int send = (command >> 12) & 0xf;
	int receive = (command >> 8) & 0xf;
	int i;

	psmouse->cmdcnt = receive;

	if (command == PSMOUSE_CMD_RESET_BAT)
                timeout = 4000000; /* 4 sec */

	/* initialize cmdbuf with preset values from param */
	if (receive)
	   for (i = 0; i < receive; i++)
		psmouse->cmdbuf[(receive - 1) - i] = param[i];

	if (command & 0xff)
		if (psmouse_sendbyte(command & 0xff))
			return (psmouse->cmdcnt = 0) - 1;

	for (i = 0; i < send; i++)
		if (psmouse_sendbyte(param[i]))
			return (psmouse->cmdcnt = 0) - 1;

	while (psmouse->cmdcnt && timeout>0) {

		if (psmouse->cmdcnt == 1 && command == PSMOUSE_CMD_RESET_BAT &&
				timeout > 100000) /* do not run in a endless loop */
			timeout = 100000; /* 1 sec */

		if (psmouse->cmdcnt == 1 && command == PSMOUSE_CMD_GETID &&
		    psmouse->cmdbuf[1] != 0xab && psmouse->cmdbuf[1] != 0xac) {
			psmouse->cmdcnt = 0;
			break;
		}

		phys_wait_for_input(&timeout);
	}

	for (i = 0; i < receive; i++)
		param[i] = psmouse->cmdbuf[(receive - 1) - i];

	if (psmouse->cmdcnt)
		return (psmouse->cmdcnt = 0) - 1;

	return 0;
}


/*
 * psmouse_reset() resets the mouse into power-on state.
 */
int psmouse_reset()
{
	unsigned char param[2];

	if (psmouse_command(param, PSMOUSE_CMD_RESET_BAT))
		return -1;

	if (param[0] != PSMOUSE_RET_BAT && param[1] != PSMOUSE_RET_ID)
		return -1;

	return 0;
}


/*
 * Genius NetMouse magic init.
 */
static int genius_detect()
{
	unsigned char param[4];

	param[0] = 3;
	psmouse_command(param, PSMOUSE_CMD_SETRES);
	psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
	psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
	psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
	psmouse_command(param, PSMOUSE_CMD_GETINFO);

	return param[0] == 0x00 && param[1] == 0x33 && param[2] == 0x55;
}

/*
 * IntelliMouse magic init.
 */
static int intellimouse_detect()
{
	unsigned char param[2];

	param[0] = 200;
	psmouse_command(param, PSMOUSE_CMD_SETRATE);
	param[0] = 100;
	psmouse_command(param, PSMOUSE_CMD_SETRATE);
	param[0] =  80;
	psmouse_command(param, PSMOUSE_CMD_SETRATE);
	psmouse_command(param, PSMOUSE_CMD_GETID);

	return param[0] == 3;
}

/*
 * Try IntelliMouse/Explorer magic init.
 */
static int im_explorer_detect()
{
	unsigned char param[2];

	param[0] = 200;
	psmouse_command(param, PSMOUSE_CMD_SETRATE);
	param[0] = 200;
	psmouse_command(param, PSMOUSE_CMD_SETRATE);
	param[0] =  80;
	psmouse_command(param, PSMOUSE_CMD_SETRATE);
	psmouse_command(param, PSMOUSE_CMD_GETID);

	return param[0] == 4;
}

/*
 * psmouse_extensions() probes for any extensions to the basic PS/2 protocol
 * the mouse may have.
 */

static int psmouse_extensions()
{
	int synaptics_hardware = 0;

	psmouse->vendor = "Generic";
	psmouse->name = "Mouse";
	psmouse->model = 0;

/*
 * Try Synaptics TouchPad
 */
	if (psmouse_max_proto > PSMOUSE_PS2 && synaptics_detect()) {
		synaptics_hardware = 1;
		psmouse->vendor = "Synaptics";
		psmouse->name = "TouchPad";

		if (psmouse_max_proto > PSMOUSE_IMEX) {
			if (synaptics_init() == 0)
				return PSMOUSE_SYNAPTICS;
/*
 * Some Synaptics touchpads can emulate extended protocols (like IMPS/2).
 * Unfortunately Logitech/Genius probes confuse some firmware versions so
 * we'll have to skip them.
 */
			psmouse_max_proto = PSMOUSE_IMEX;
		}
/*
 * Make sure that touchpad is in relative mode, gestures (taps) are enabled
 */
		synaptics_reset();
	}

	if (psmouse_max_proto > PSMOUSE_IMEX && genius_detect()) {
		uinput_set_keybit(BTN_EXTRA);
		uinput_set_keybit(BTN_SIDE);
		uinput_set_relbit(REL_WHEEL);

		psmouse->vendor = "Genius";
		psmouse->name = "Wheel Mouse";
		return PSMOUSE_GENPS;
	}

	if (psmouse_max_proto > PSMOUSE_IMEX) {
		int type = ps2pp_detect();
		if (type)
			return type;
	}

	if (psmouse_max_proto >= PSMOUSE_IMPS && intellimouse_detect()) {
		uinput_set_relbit(REL_WHEEL);

		if (psmouse_max_proto >= PSMOUSE_IMEX &&
					im_explorer_detect()) {
			uinput_set_keybit(BTN_SIDE);
			uinput_set_keybit(BTN_EXTRA);

			psmouse->name = "Explorer Mouse";
			return PSMOUSE_IMEX;
		}

		psmouse->name = "Wheel Mouse";
		return PSMOUSE_IMPS;
	}

/*
 * Okay, all failed, we have a standard mouse here. The number of the buttons
 * is still a question, though. We assume 3.
 */
	if (synaptics_hardware) {
/*
 * We detected Synaptics hardware but it did not respond to IMPS/2 probes.
 * We need to reset the touchpad because if there is a track point on the
 * pass through port it could get disabled while probing for protocol
 * extensions.
 */
		psmouse_reset();
		psmouse_command(NULL, PSMOUSE_CMD_RESET_DIS);
	}

	return PSMOUSE_PS2;
}

/*
 * psmouse_probe() probes for a PS/2 mouse.
 */

static int psmouse_probe()
{
	unsigned char param[2];

/*
 * First, we check if it's a mouse. It should send 0x00 or 0x03
 * in case of an IntelliMouse in 4-byte mode or 0x04 for IM Explorer.
 */

	param[0] = 0xa5;

	if (psmouse_command(param, PSMOUSE_CMD_GETID))
		return -1;

	if (param[0] != 0x00 && param[0] != 0x03 && param[0] != 0x04)
		return -1;

/*
 * Then we reset and disable the mouse so that it doesn't generate events.
 */

	if (psmouse_command(NULL, PSMOUSE_CMD_RESET_DIS))
		warn("Failed to reset mouse\n");

/*
 * And here we try to determine if it has any extensions over the
 * basic PS/2 3-button mouse.
 */

	return psmouse->type = psmouse_extensions();
}

/*
 * Here we set the mouse resolution.
 */

static void psmouse_set_resolution()
{
	unsigned char param[1];

	if (psmouse->type == PSMOUSE_PS2PP && psmouse_resolution > 400) {
		ps2pp_set_800dpi(psmouse);
		return;
	}

	if (!psmouse_resolution || psmouse_resolution >= 200)
		param[0] = 3;
	else if (psmouse_resolution >= 100)
		param[0] = 2;
	else if (psmouse_resolution >= 50)
		param[0] = 1;
	else if (psmouse_resolution)
		param[0] = 0;

        psmouse_command(param, PSMOUSE_CMD_SETRES);
}

/*
 * Here we set the mouse report rate.
 */

static void psmouse_set_rate()
{
	unsigned char rates[] = { 200, 100, 80, 60, 40, 20, 10, 0 };
	int i = 0;

	while (rates[i] > psmouse_rate) i++;
	psmouse_command(rates + i, PSMOUSE_CMD_SETRATE);
}

/*
 * psmouse_initialize() initializes the mouse to a sane state.
 */

static void psmouse_initialize()
{
	unsigned char param[2];

/*
 * We set the mouse report rate, resolution and scaling.
 */

	if (psmouse_max_proto != PSMOUSE_PS2) {
		psmouse_set_rate();
		psmouse_set_resolution();
		psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11);
	}

/*
 * We set the mouse into streaming mode.
 */

	psmouse_command(param, PSMOUSE_CMD_SETSTREAM);
}

/*
 * psmouse_activate() enables the mouse so that we get motion reports from it.
 */

static void psmouse_activate()
{
	if (psmouse_command(NULL, PSMOUSE_CMD_ENABLE))
		warn("Failed to enable mouse\n");

	psmouse->state = PSMOUSE_ACTIVATED;
}

#if 0
/*
 * psmouse_cleanup() resets the mouse into power-on state.
 */

static void psmouse_cleanup(struct serio *serio)
{
	struct psmouse *psmouse = serio->private;

	psmouse_reset(psmouse);
}
#endif

/*
 * psmouse_disconnect() closes and frees.
 */

static void psmouse_disconnect()
{
	psmouse->state = PSMOUSE_CMD_MODE;

	if (psmouse->disconnect)
		psmouse->disconnect(psmouse);

	psmouse->state = PSMOUSE_IGNORE;

	phys_close();
}

/*
 * psmouse_connect() is a callback from the serio module when
 * an unhandled serio port is found.
 */
static int psmouse_connect()
{
	memset(psmouse, 0, sizeof(struct psmouse));

	uinput_set_evbit(EV_KEY);
	uinput_set_evbit(EV_REL);

	uinput_set_keybit(BTN_LEFT);
	uinput_set_keybit(BTN_MIDDLE);
	uinput_set_keybit(BTN_RIGHT);

	uinput_set_relbit(REL_X);
	uinput_set_relbit(REL_Y);

	psmouse->state = PSMOUSE_CMD_MODE;

	if (phys_open()) {
		return -1;
	}

	if (psmouse_probe() <= 0) {
		return -1;
	}

	sprintf(psmouse->devname, "%s %s %s",
		psmouse_protocols[psmouse->type], psmouse->vendor, psmouse->name);
	info("%s\n", psmouse->devname);

	psmouse_initialize();

	psmouse_activate();

	return 0;
}

static int psmouse_reconnect()
{
	int old_type;

	old_type = psmouse->type;

	psmouse->state = PSMOUSE_CMD_MODE;
	psmouse->type = psmouse->acking = psmouse->cmdcnt = psmouse->pktcnt = 0;
	if (psmouse->reconnect) {
	       if (psmouse->reconnect())
			return -1;
	} else if (psmouse_probe() != old_type)
		return -1;

	/* ok, the device type (and capabilities) match the old one,
	 * we can continue using it, complete intialization
	 */
	psmouse->type = old_type;
	psmouse_initialize();

	psmouse_activate();
	return 0;
}
#if 0


static struct serio_dev psmouse_dev = {
	.interrupt =	psmouse_interrupt,
	.connect =	psmouse_connect,
	.reconnect =	psmouse_reconnect,
	.disconnect =	psmouse_disconnect,
	.cleanup =	psmouse_cleanup,
};

static inline void psmouse_parse_proto(void)
{
	if (psmouse_proto) {
		if (!strcmp(psmouse_proto, "bare"))
			psmouse_max_proto = PSMOUSE_PS2;
		else if (!strcmp(psmouse_proto, "imps"))
			psmouse_max_proto = PSMOUSE_IMPS;
		else if (!strcmp(psmouse_proto, "exps"))
			psmouse_max_proto = PSMOUSE_IMEX;
		else
			printk(KERN_ERR "psmouse: unknown protocol type '%s'\n", psmouse_proto);
	}
}

#endif

int main(int argc, char**argv) {
	if (argc != 2) {
		fprintf(stderr, "Usage: %s raw_ps2_mouse_device\n", argv[0]);
		return 1;
	}

	phys_filename = argv[1];

	/* try devfs name first */
	uinput_dev_name = "/dev/misc/uinput";
	uinput_open();
	if (uinput_fd == -1 && errno==ENOENT) {
		/* was not found: try non-devfs name */
		uinput_dev_name = "/dev/uinput";
		uinput_open();
	}
	if (uinput_fd == -1) {
		const int e = errno;
		perr(uinput_dev_name);

		switch (e) {
		case ENOENT:
			err("Have you loaded the 'uinput' module?\n");
			break;
		case EACCES:
			err("Write access needed.  Are you 'root'?\n");
			break;
		}
		exit (1);
	}


	if (psmouse_connect() != 0) {
		fprintf(stderr, "cannot connect to device\n");
		return 1;
	}

	uinput_create();

	for (;;) {
		phys_wait_for_input(NULL);
	}

	uinput_destroy();

	psmouse_disconnect();
	uinput_close();
	return 0;
}
 * Logitech PS/2++ mouse driver header
 *
 * Copyright (c) 2003 Vojtech Pavlik <vojtech@suse.cz>
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 as published by
 * the Free Software Foundation.
 */

#ifndef _LOGIPS2PP_H
#define _LOGIPS2PP_H

#define PS2PP_4BTN	0x01
#define PS2PP_WHEEL	0x02
#define PS2PP_MX	0x04
#define PS2PP_MX310	0x08

struct psmouse;
void ps2pp_process_packet();
void ps2pp_set_800dpi();
int ps2pp_detect();
#endif
 * Logitech PS/2++ mouse driver
 *
 * Copyright (c) 1999-2003 Vojtech Pavlik <vojtech@suse.cz>
 * Copyright (c) 2003 Eric Wong <eric@yhbt.net>
 * Copyright (c) 2004 Sau Dan LEE
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 as published by
 * the Free Software Foundation.
 */

#include <stdlib.h>
#include <linux/input.h>
#include "psmouse.h"
#include "logips2pp.h"

/*
 * Process a PS2++ or PS2T++ packet.
 */

void ps2pp_process_packet()
{
        unsigned char *packet = psmouse->packet;

	if ((packet[0] & 0x48) == 0x48 && (packet[1] & 0x02) == 0x02) {

		switch ((packet[1] >> 4) | (packet[0] & 0x30)) {

			case 0x0d: /* Mouse extra info */

				uinput_report_rel(packet[2] & 0x80 ? REL_HWHEEL : REL_WHEEL,
					(int) (packet[2] & 8) - (int) (packet[2] & 7));
				uinput_report_key(BTN_SIDE, (packet[2] >> 4) & 1);
				uinput_report_key(BTN_EXTRA, (packet[2] >> 5) & 1);

				break;

			case 0x0e: /* buttons 4, 5, 6, 7, 8, 9, 10 info */

				uinput_report_key(BTN_SIDE, (packet[2]) & 1);
				uinput_report_key(BTN_EXTRA, (packet[2] >> 1) & 1);
				uinput_report_key(BTN_BACK, (packet[2] >> 3) & 1);
				uinput_report_key(BTN_FORWARD, (packet[2] >> 4) & 1);
				uinput_report_key(BTN_TASK, (packet[2] >> 2) & 1);

				break;

			case 0x0f: /* TouchPad extra info */

				uinput_report_rel(packet[2] & 0x08 ? REL_HWHEEL : REL_WHEEL,
					(int) ((packet[2] >> 4) & 8) - (int) ((packet[2] >> 4) & 7));
				packet[0] = packet[2] | 0x08;
				break;

#ifdef DEBUG
			default:
				printk(KERN_WARNING "psmouse.c: Received PS2++ packet #%x, but don't know how to handle.\n",
					(packet[1] >> 4) | (packet[0] & 0x30));
#endif
		}

		packet[0] &= 0x0f;
		packet[1] = 0;
		packet[2] = 0;

	}
}

/*
 * ps2pp_cmd() sends a PS2++ command, sliced into two bit
 * pieces through the SETRES command. This is needed to send extended
 * commands to mice on notebooks that try to understand the PS/2 protocol
 * Ugly.
 */

static int ps2pp_cmd(unsigned char *param, unsigned char command)
{
	unsigned char d;
	int i;

	if (psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11))
		return -1;

	for (i = 6; i >= 0; i -= 2) {
		d = (command >> i) & 3;
		if(psmouse_command(&d, PSMOUSE_CMD_SETRES))
			return -1;
	}

	if (psmouse_command(param, PSMOUSE_CMD_POLL))
		return -1;

	return 0;
}

/*
 * SmartScroll / CruiseControl for some newer Logitech mice Defaults to
 * enabled if we do nothing to it. Of course I put this in because I want it
 * disabled :P
 * 1 - enabled (if previously disabled, also default)
 * 0/2 - disabled 
 */

static void ps2pp_set_smartscroll()
{
	unsigned char param[4];

	ps2pp_cmd(param, 0x32);

	param[0] = 0;
	psmouse_command(param, PSMOUSE_CMD_SETRES);
	psmouse_command(param, PSMOUSE_CMD_SETRES);
	psmouse_command(param, PSMOUSE_CMD_SETRES);

	if (psmouse_smartscroll == 1) 
		param[0] = 1;
	else
	if (psmouse_smartscroll > 2)
		return;

	/* else leave param[0] == 0 to disable */
	psmouse_command(param, PSMOUSE_CMD_SETRES);
}

/*
 * Support 800 dpi resolution _only_ if the user wants it (there are good
 * reasons to not use it even if the mouse supports it, and of course there are
 * also good reasons to use it, let the user decide).
 */

void ps2pp_set_800dpi()
{
	unsigned char param = 3;
	psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11);
	psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11);
	psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11);
	psmouse_command(&param, PSMOUSE_CMD_SETRES);
}

/*
 * Detect the exact model and features of a PS2++ or PS2T++ Logitech mouse or
 * touchpad.
 */

static int ps2pp_detect_model(unsigned char *param)
{
	int i;
	static struct _logips2_list {
		const int model;
		unsigned const int features;
	} logips2pp_list [] = {
		{ 12,	PS2PP_4BTN},
		{ 13,	0 },
		{ 40,	PS2PP_4BTN },
		{ 41,	PS2PP_4BTN },
		{ 42,	PS2PP_4BTN },
		{ 43,	PS2PP_4BTN },
		{ 50,	0 },
		{ 51,	0 },
		{ 52,	PS2PP_4BTN | PS2PP_WHEEL },
		{ 53,	PS2PP_WHEEL },
		{ 61,	PS2PP_WHEEL | PS2PP_MX },	/* MX700 */
		{ 73,	PS2PP_4BTN },
		{ 75,	PS2PP_WHEEL },
		{ 76,	PS2PP_WHEEL },
		{ 80,	PS2PP_4BTN | PS2PP_WHEEL },
		{ 81,	PS2PP_WHEEL },
		{ 83,	PS2PP_WHEEL },
		{ 88,	PS2PP_WHEEL },
		{ 96,	0 },
		{ 97,	0 },
		{ 100 ,	PS2PP_WHEEL | PS2PP_MX },	/* MX510 */
		{ 112 ,	PS2PP_WHEEL | PS2PP_MX },	/* MX500 */
		{ 114 ,	PS2PP_WHEEL | PS2PP_MX | PS2PP_MX310 },	/* MX310 */
		{ }
	};

	psmouse->vendor = "Logitech";
	psmouse->model = ((param[0] >> 4) & 0x07) | ((param[0] << 3) & 0x78);

#if 0
	if (param[1] < 3)
		clear_bit(BTN_MIDDLE, psmouse->dev.keybit);
	if (param[1] < 2)
		clear_bit(BTN_RIGHT, psmouse->dev.keybit);
#endif

	psmouse->type = PSMOUSE_PS2;

	for (i = 0; logips2pp_list[i].model; i++){
		if (logips2pp_list[i].model == psmouse->model){
			psmouse->type = PSMOUSE_PS2PP;
			if (logips2pp_list[i].features & PS2PP_4BTN)
				uinput_set_keybit(BTN_SIDE);

			if (logips2pp_list[i].features & PS2PP_WHEEL){
				uinput_set_relbit(REL_WHEEL);
				psmouse->name = "Wheel Mouse";
			}
			if (logips2pp_list[i].features & PS2PP_MX) {
				uinput_set_keybit(BTN_SIDE);
				uinput_set_keybit(BTN_EXTRA);
				uinput_set_keybit(BTN_TASK);
				if (!(logips2pp_list[i].features & PS2PP_MX310)){
					uinput_set_keybit(BTN_BACK);
					uinput_set_keybit(BTN_FORWARD);
				}
				psmouse->name = "MX Mouse";
			}
			break;
		}
	}
/*
 * Do Logitech PS2++ / PS2T++ magic init.
 */
	if (psmouse->type == PSMOUSE_PS2PP) {

		if (psmouse->model == 97) { /* TouchPad 3 */

			uinput_set_relbit(REL_WHEEL);
			uinput_set_relbit(REL_HWHEEL);

			param[0] = 0x11; param[1] = 0x04; param[2] = 0x68; /* Unprotect RAM */
			psmouse_command(param, 0x30d1);
			param[0] = 0x11; param[1] = 0x05; param[2] = 0x0b; /* Enable features */
			psmouse_command(param, 0x30d1);
			param[0] = 0x11; param[1] = 0x09; param[2] = 0xc3; /* Enable PS2++ */
			psmouse_command(param, 0x30d1);

			param[0] = 0;
			if (!psmouse_command(param, 0x13d1) &&
				param[0] == 0x06 && param[1] == 0x00 && param[2] == 0x14) {
				psmouse->name = "TouchPad 3";
				return PSMOUSE_PS2TPP;
			}

		} else {

			param[0] = param[1] = param[2] = 0;
			ps2pp_cmd(param, 0x39); /* Magic knock */
			ps2pp_cmd(param, 0xDB);

			if ((param[0] & 0x78) == 0x48 && (param[1] & 0xf3) == 0xc2 &&
				(param[2] & 3) == ((param[1] >> 2) & 3)) {
					ps2pp_set_smartscroll();
					return PSMOUSE_PS2PP;
			}
		}
	}

	return 0;
}

/*
 * Logitech magic init.
 */
int ps2pp_detect()
{
	unsigned char param[4];

	param[0] = 0;
	psmouse_command(param, PSMOUSE_CMD_SETRES);
	psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
	psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
	psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
	param[1] = 0;
	psmouse_command(param, PSMOUSE_CMD_GETINFO);

	return param[1] != 0 ? ps2pp_detect_model(param) : 0;
}

	$(LINK.c) -o $@ $^

logips2pp.o: logips2pp.c psmouse.h logips2pp.h
psmouse-base.o: psmouse-base.c psmouse.h uinput.h synaptics.h logips2pp.h
synaptics.o: synaptics.c psmouse.h synaptics.h

[-- Attachment #4: Type: text/plain, Size: 195 bytes --]




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

[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

BUG: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]

[Sau Dan Lee]

    Andries> 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?

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

Here they are:

        On Linux 2.4.*:
        PrintScreen: 0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa
        SysRq:       0x54 0xd4

        On Linux 2.6.*:
        PrintScreen: 0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa
        SysRq:       0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa

No  wonder: "showkey  -s"  in 2.6.*  is  deceiving: it  shows what  an
emulated keyboard  generates, not the  *real* scancodes.  Fortunately,
the SERIO_USERDEV patch is very very helpful here.

Using the SERIO_USERDEV patch from Tuukka Toivonen and me, the correct
scancodes are displayed:

        On Linux 2.6.*: od -t x1 /dev/misc/isa0060/serio0
        PrintScreen: 0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa
        SysRq:       0x54 0xd4


So, obviously, it is the fault of the Linux 2.6.* keyboard driver.


The story continues:

I've studied  the 2.6 keyboard driver  atkbd.c and found  the bug: The
keyboard  driver is  UNABLE  to distinguish  SysRq and  PrintScreen!!!
I've checked  this with  the help of  the 'evbug' module.   The driver
reports both keys to be KEY_SYSRQ, which is obviously wrong.

I've got a patch for this bug already.  See Bugzilla #2808.


Relatedly,  drivers/char/keyboard.c  assumes   that  SysRq  cannot  be
activated unless the Alt key(s) is/are pressed (and not yet released).
I'm going to fix this.  But since  this not a module, I need to reboot
to test it.  So, please be patient.


See http://bugzilla.kernel.org/show_bug.cgi?id=2808 for more info.



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

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

BUG FIX: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]

[Sau Dan Lee]

    Dan> Relatedly, drivers/char/keyboard.c assumes that SysRq cannot
    Dan> be activated unless the Alt key(s) is/are pressed (and not
    Dan> yet released).  I'm going to fix this.  But since this not a
    Dan> module, I need to reboot to test it.  So, please be patient.

Fixed.  The patch is already added to Bugzilla.

Using these  patches, the  keyboard behaviour is  correct again  on my
notebook:

        SysRq ==> Input Event with code KEY_SYSRQ
        PrintScreen ==> Input Event with code KEY_KPASTERISK
                        (because PrintScreen is Alt-KP_ASTERISK)

        SysRq SPACE gives sysrq help screen
        Alt-PrintScreen SPACE gives sysrq help screen
        PrintScreen SPACE gives "*" and no sysrq help screen        

    Dan> See http://bugzilla.kernel.org/show_bug.cgi?id=2808 for more
    Dan> info.

Both patches are there at the Bugzilla site.


(BTW, why did  Vojtech REJECT this bug report at  Bugzilla?  Give me a
reason!  I do observe the bug and I have even found a fix.)


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

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

BUG FIX: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]

[Sau Dan Lee]

>>>>> "bugme-daemon" == bugme-daemon  <bugme-daemon@osdl.org> writes:

    bugme-daemon> http://bugme.osdl.org/show_bug.cgi?id=2808
    bugme-daemon> vojtech@suse.cz changed:

    bugme-daemon>    What    |Removed             |Added
    bugme-daemon> ----------------------------------------------------
    bugme-daemon>      Status|NEW                 |REJECTED
    bugme-daemon>  Resolution|                    |INVALID

    Vojtech> I'm sorry you can't use the fn+printscreen function on
    Vojtech> your LifeBook, but such is life. 

Disappointed.


    Vojtech> Is using Alt+printscreen such a big difference?

That means I need to press FOUR keys to use sysrq, because PrintScreen
is  only  available via  [Fn].   That becomes  [Fn]+Alt+PrintScreen+X,
where "X" is the sysrq function.  :(


    Vojtech> On USB keyboards (and many others, too), there is no
    Vojtech> specific SysRq keycode, and thus the kernel magic-sysrq
    Vojtech> handler uses the alt-printscreen combination, to make it
    Vojtech> work on ALL keyboards. This is intentional.

Isn't  the keyboard  driver  supposed to  iron  out such  differences?
Isn't  it your  philosophy that  the drivers  should know  the devices
well, and present  a consistent interface to the  upper layers?  Then,
the correct way to do it is:

        USB keyboard driver: generate a "sysrq" event in reaction to
                             Alt-PrintScreen 
        AT/PS2 keyboard driver: generate a "sysrq" when receiving a
                                0x54 keycode

The  kernel  keyboard  handler  shouldn't  see  or  bother  about  the
difference.   It is  insane that  the handler  has to  care  about the
status of the Alt keys.


    Vojtech> Further, keycode 99 is KEY_SYSRQ, as defined in input.h,

Then, why use it for PrintScreen?   With the 'evbug' facility, I see a
keyboard  event with code  KEY_SYSRQ when  I press  PrintScreen.  Just
PrintScreen, not  Alt-PrintScreen.  So,  this is a  feature and  not a
bug?


    Vojtech> and is used for the PrtScr/SysRq key. 

So, why not have seperate keycodes for the two?



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

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

Re: BUG FIX: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]

[Vojtech Pavlik]

On Tue, Jun 01, 2004 at 11:44:44AM +0200, Sau Dan Lee wrote:
> >>>>> "bugme-daemon" == bugme-daemon  <bugme-daemon@osdl.org> writes:
> 
>     bugme-daemon> http://bugme.osdl.org/show_bug.cgi?id=2808
>     bugme-daemon> vojtech@suse.cz changed:
> 
>     bugme-daemon>    What    |Removed             |Added
>     bugme-daemon> ----------------------------------------------------
>     bugme-daemon>      Status|NEW                 |REJECTED
>     bugme-daemon>  Resolution|                    |INVALID
> 
>     Vojtech> I'm sorry you can't use the fn+printscreen function on
>     Vojtech> your LifeBook, but such is life. 
> 
> Disappointed.
> 
>     Vojtech> Is using Alt+printscreen such a big difference?
> 
> That means I need to press FOUR keys to use sysrq, because PrintScreen
> is  only  available via  [Fn].   That becomes  [Fn]+Alt+PrintScreen+X,
> where "X" is the sysrq function.  :(
> 
> 
>     Vojtech> On USB keyboards (and many others, too), there is no
>     Vojtech> specific SysRq keycode, and thus the kernel magic-sysrq
>     Vojtech> handler uses the alt-printscreen combination, to make it
>     Vojtech> work on ALL keyboards. This is intentional.
> 
> Isn't  the keyboard  driver  supposed to  iron  out such  differences?

The atkbd.c driver does exactly that. It hides the fact that there is a
special scancode for the PrintScreen key, if you press it together with
some other keys.

There is no special scancode on any other keyboard type for it,
including PS/2 keyboards in their native Set3 mode.

It's a hack by IBM engineers, the PC/XT keyboard had a SysRq key, the
PC/AT keyboard did not, yet some old DOS programs needed it, so they
made the AT keyboard generate the keycode for alt-sysrq when running in
XT compatibility mode.

Unfortunately, the XT compatibility mode stuck, and that's what we're
using now.

> Isn't  it your  philosophy that  the drivers  should know  the devices
> well, and present  a consistent interface to the  upper layers?  Then,
> the correct way to do it is:
> 
>         USB keyboard driver: generate a "sysrq" event in reaction to
>                              Alt-PrintScreen 
>         AT/PS2 keyboard driver: generate a "sysrq" when receiving a
>                                 0x54 keycode
> 
> The  kernel  keyboard  handler  shouldn't  see  or  bother  about  the
> difference.   It is  insane that  the handler  has to  care  about the
> status of the Alt keys.

The kernel works with real keys. There is no real sysrq key. My
definition of sanity is to base your thinking on reality where possible.

>     Vojtech> Further, keycode 99 is KEY_SYSRQ, as defined in input.h,
> 
> Then, why use it for PrintScreen?   With the 'evbug' facility, I see a
> keyboard  event with code  KEY_SYSRQ when  I press  PrintScreen.  Just
> PrintScreen, not  Alt-PrintScreen.  So,  this is a  feature and  not a
> bug?

Ok, it's probably a bad name for it, it should have been named
KEY_PRTSCR, but it wasn't, and it'd only cause breakage now to change
it.

>     Vojtech> and is used for the PrtScr/SysRq key. 
> 
> So, why not have seperate keycodes for the two?
 
Because there is only one key.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: BUG FIX: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]

[Sau Dan Lee]

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

    >>  Isn't the keyboard driver supposed to iron out such
    >> differences?

    Vojtech> The atkbd.c driver does exactly that. It hides the fact
    Vojtech> that there is a special scancode for the PrintScreen key,
    Vojtech> if you press it together with some other keys.

No,  it doesn't do  that.  I  press PrintScreen  (without Alt)  and it
tells the input system that it is a KEY_SYSRQ.



    Vojtech> It's a hack by IBM engineers, the PC/XT keyboard had a
    Vojtech> SysRq key, the PC/AT keyboard did not, yet some old DOS
    Vojtech> programs needed it, so they made the AT keyboard generate
    Vojtech> the keycode for alt-sysrq when running in XT
    Vojtech> compatibility mode.

It's a simple SysRq (0x54), not Alt-SysRq (0x38 0x54) in my notebook.


    Vojtech> Unfortunately, the XT compatibility mode stuck, and
    Vojtech> that's what we're using now.

I know this part of the history, and hence why PrintScreen is emulated
by Alt-KPAsterisk.


    Vojtech> The kernel works with real keys. There is no real sysrq
    Vojtech> key.

On my notebook, there IS a  real SysRq.  (The [Fn] part is not visible
to the kernel.  So, that's irrelevant.)



    Vojtech> Ok, it's probably a bad name for it, it should have been
    Vojtech> named KEY_PRTSCR, but it wasn't, and it'd only cause
    Vojtech> breakage now to change it.

Deprecate the old one.


    Vojtech> and is used for the PrtScr/SysRq key.
    >>  So, why not have seperate keycodes for the two?
 
    Vojtech> Because there is only one key.

On  some keyboards  (e.g.  my notebook),  they're  separate.  Is  that
enough a reason to have 2 different keycodes, then?



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

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

Re: BUG FIX: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> The kernel works with real keys. There is no real sysrq key. My
> definition of sanity is to base your thinking on reality where possible.

My keyboard has a separate key for SysRq (as much as 
'separate' makes sense for laptop keyboards; it's a Fn-
activated key).

If you want to go the route you're going, all laptop keyboards 
should have the numeric keypad produce the same emulated 
scancodes as some alphanumeric keys. This does sound a little, 
uhm, ridiculous to me.

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

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

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

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

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

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

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

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




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

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

Re: keyboard problem with 2.6.6

[Valdis.Kletnieks]

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

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

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

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

CONFIG_SERIO=y
CONFIG_KEYBOARD_ATKBD=y

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

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

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

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

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

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

    Valdis> CONFIG_SERIO=y 
    Valdis> CONFIG_KEYBOARD_ATKBD=y

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

"make help" shows:

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


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

        CONFIG_SERIO=m
        CONFIG_KEYBOARD_ATKBD=m



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

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

Re: keyboard problem with 2.6.6

[Valdis.Kletnieks]

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

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

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

*plonk* <add to killfile>

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

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


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

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

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

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

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

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

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

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



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

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


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

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


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


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

Does embedded systems always have a keyboard?




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

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

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

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

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

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

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

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


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

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


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

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



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

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

Re: keyboard problem with 2.6.6

[Martin Schlemmer]

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

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

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

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

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


Thanks,

-- 
Martin Schlemmer

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

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

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

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

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

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

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


-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Dmitry Torokhov]

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

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

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

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

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

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

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

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

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

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



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


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

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

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

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

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

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


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



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

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

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

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

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

    >>  How about mouse?

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

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

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



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

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

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

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

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

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

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

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

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

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

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



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

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

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

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

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

My question is: why do everything inside the kernel?


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

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




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

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

Re: keyboard problem with 2.6.6

[Pavel Machek]

Hi!

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

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

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

Re: keyboard problem with 2.6.6

[John Bradford]

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

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

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

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

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

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

John.

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

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

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

    Vojtech> What for?

For more imaginative innovations.

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

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

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

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

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



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

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

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

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

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

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[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