FYI PS/2 Mouse problems -- userland issue

FYI PS/2 Mouse problems -- userland issue

[Stephen Satchell]

Last week I had asked about mouse problems.  I have discovered the root 
cause.  This affects you if (1) you are using a KVM switch and (2) you have 
a "wheel" mouse.

The problem is that sometime during system initialization the mouse is 
being configured as a generic PS/2 mouse (no wheel).  This works 
fine...until you switch the mouse away from the system.  Depending on the 
KVM switch you are using, the mouse MAY reset itself into its native 
mode.  In the case of the Logitech wheel mice, this means that each mouse 
event sends four codes instead of three.  The X mouse support doesn't like 
that very much.  :)

This MAY be a kernel issue depending on where I locate the mouse 
initialization code.  If it is in the kernel, then there will need to be a 
patch to allow the mouse to be re-initialized into the mode everyone expects.

Satch

Re: FYI PS/2 Mouse problems -- userland issue

[Ben LaHaise]

On Tue, 21 Aug 2001, Stephen Satchell wrote:

> This MAY be a kernel issue depending on where I locate the mouse
> initialization code.  If it is in the kernel, then there will need to be a
> patch to allow the mouse to be re-initialized into the mode everyone expects.

The kernel has nothing to do with reinitializing the mouse: X has to do
that.  I was looking into this a few months ago when the installer's mouse
probe code stopped working on 2.4, and it became apparent that there is
lots of userland code that doesn't do the right thing to handle mouse hot
plug reinitialization.  gpm and X both need bugfixing in this area.  As
for the kernel, it needs a few improvements during 2.5: I plan to submit a
patch that replaces much of the existing pc keyboard/mouse code with state
machine driven code that doesn't block interrupts out for long periods of
time, as well as fixing a few of the lockup issues the current driver has.

		-ben

Re: FYI PS/2 Mouse problems -- userland issue

[James Simmons]

> As for the kernel, it needs a few improvements during 2.5: I plan to submit a
> patch that replaces much of the existing pc keyboard/mouse code with state
> machine driven code that doesn't block interrupts out for long periods of
> time, as well as fixing a few of the lockup issues the current driver has.

Their already is a replacement driver using the input api avaliable that I
was planning to intergrate into 2.5. It fixed alot of the issues people
are having now.  

Re: FYI PS/2 Mouse problems -- userland issue

[Ben LaHaise]

On Tue, 21 Aug 2001, James Simmons wrote:

> Their already is a replacement driver using the input api avaliable that I
> was planning to intergrate into 2.5. It fixed alot of the issues people
> are having now.

Whether it uses the input api or the existing scheme doesn't matter to me.
What's important is that the interrupt disables and udelay()'s are
removed, so I'll gladly merge my work with whatever else people have
prepared.  I would've done it sooner, but changing the keyboard driver is
an area of compatibility with sufficiently many hazzards that it's not
reasonable for 2.4.

		-ben

Re: FYI PS/2 Mouse problems -- userland issue

[Kurt Garloff]

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

On Tue, Aug 21, 2001 at 11:07:54AM -0700, Stephen Satchell wrote:
> This MAY be a kernel issue depending on where I locate the mouse 
> initialization code.  If it is in the kernel, then there will need to be a 
> patch to allow the mouse to be re-initialized into the mode everyone 
> expects.

The kernel (2.2.15--2.2.17, 2.4.x--2.4.8) had code to reinitialize a plain
PS2 mouse upon a reconnect event. 
It caused too many problems on mouses that are not plain PS/2, but eg.
synps2 (Synaptics touchpad). Those are not happy being reinitialized ...

The code has been disabled in 2.2.18/2.4.9 therefore. Use psaux-reconnect
boot param to get the code back.

But normally your mouse driver (gpm or X11) has to do the reinitialization
anyways, because it knows about the specific reinitialization sequence a
mouse needs. 
The kernel can't handle it, unless you put the whole collection of drivers
there. 

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, DE                                SCSI, Security

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

Re: FYI PS/2 Mouse problems -- userland issue

[James Simmons]

> Whether it uses the input api or the existing scheme doesn't matter to me.

Tonight I will post the input PS/2 stuff for people to try out.

Re: FYI PS/2 Mouse problems -- userland issue

[Gunther Mayer]

Andries.Brouwer@cwi.nl wrote:
> 
> > Armed with docs I was able to see just why our code
> > is completely wrong for handling things like the ps/2
> > mouse being removed at runtime.
> 
> Yes, or being added, to be more precise. But it will not be
> easy to do it right. So many different ps2-like types of mouse.
> There are heuristics, like the AA 00 that I gave last week or so.
> (But not every ps2-mouse emits this sequence.)

Not every mouse controller lets this sequence thru ?
(e.g. laptops with simultaneous stick +ps2 mouse)

A mouse not emitting this sequence would be broken.
However you could easily recover by polling the mouse
status every second. A newly-plugged mouse will have
characteristic bit pattern.

> And one can keep track of the timing. But the fact that the length
> of a packet is unknown (3, 4, 5, 8 bytes), and that in some modes
> and relative positions arbitrary data is legal, makes it more or less
> impossible to write code that is provably correct.

See above for a perfect solution.

> Also state machines have difficulties. Many types of mouse react
> to special sequences of ordinary commands, and enter a non-ps2 mode.

See http://home.t-online.de/home/gunther.mayer/gm_psauxprint-0.01.c
for a _dirty_ hack collecting info from various sources. This is the first
linux tool to implement the PS2-PNP protocol (for identifying MS mice).

Re: FYI PS/2 Mouse problems -- userland issue

[Ben LaHaise]

On Tue, 21 Aug 2001 Andries.Brouwer@cwi.nl wrote:

> > Armed with docs I was able to see just why our code
> > is completely wrong for handling things like the ps/2
> > mouse being removed at runtime.
>
> Yes, or being added, to be more precise. But it will not be
> easy to do it right. So many different ps2-like types of mouse.
> There are heuristics, like the AA 00 that I gave last week or so.
> (But not every ps2-mouse emits this sequence.)

That's what reset probes are for... =)  At least in the case of the mouse,
this really isn't the kernel's business.  But for the keyboard, it is.

> Also state machines have difficulties. Many types of mouse react

The state machine I'm talking about is for the general keyboard controller
poking code which currently is well sprinkled with udelay()s.  I really
don't want my dual 1.2GHz CPUs waiting on a keyboard controller.

		-ben

Re: FYI PS/2 Mouse problems -- userland issue

[Andries.Brouwer]

> Armed with docs I was able to see just why our code
> is completely wrong for handling things like the ps/2
> mouse being removed at runtime.

Yes, or being added, to be more precise. But it will not be
easy to do it right. So many different ps2-like types of mouse.
There are heuristics, like the AA 00 that I gave last week or so.
(But not every ps2-mouse emits this sequence.)
And one can keep track of the timing. But the fact that the length
of a packet is unknown (3, 4, 5, 8 bytes), and that in some modes
and relative positions arbitrary data is legal, makes it more or less
impossible to write code that is provably correct.
Also state machines have difficulties. Many types of mouse react
to special sequences of ordinary commands, and enter a non-ps2 mode.

As we already remarked in the previous round,
this is no kernel business.

Andries

[departing now - probably away from email for a while]

Re: FYI PS/2 Mouse problems -- userland issue

[Ben LaHaise]

On Tue, 21 Aug 2001 Andries.Brouwer@cwi.nl wrote:

>     machine driven code that doesn't block interrupts out for long periods of
>     time, as well as fixing a few of the lockup issues the current driver has.
>
> Have you written the patch already?
> There are interesting difficulties here.

Nothing in a usable state.  It needs a few days of work, but the general
design is done.  Having high resolution timers would help, but it's not
essential.  Most of the work was in tracking down all the docs for the
keyboard and ps/2 mouse ports to get an overview of what the code was
trying to coax the hardware into doing.  Armed with docs I was able to see
just why our code is completely wrong for handling things like the ps/2
mouse being removed at runtime.

		-ben

Re: FYI PS/2 Mouse problems -- userland issue

[Andries.Brouwer]

    From: Ben LaHaise <bcrl@redhat.com>

    On Tue, 21 Aug 2001, Stephen Satchell wrote:

    > This MAY be a kernel issue depending on where I locate the mouse
    > initialization code.  If it is in the kernel, then there will need
    > to be a patch to allow the mouse to be re-initialized into the mode
    > everyone expects.

[Funny - we just discussed this last week.]

    The kernel has nothing to do with reinitializing the mouse: X has to do
    that.

[Indeed. Or gpm.]

     I plan to submit a
    patch that replaces much of the existing pc keyboard/mouse code with state
    machine driven code that doesn't block interrupts out for long periods of
    time, as well as fixing a few of the lockup issues the current driver has.

Have you written the patch already?
There are interesting difficulties here.

Andries

Re: FYI PS/2 Mouse problems -- userland issue

[Pete Zaitcev]

> [...] it needs a few improvements during 2.5: I plan to submit a
> patch that replaces much of the existing pc keyboard/mouse code with state
> machine driven code that doesn't block interrupts out for long periods of
> time, as well as fixing a few of the lockup issues the current driver has.
> 
> 		-ben

Interesting. BTW, there is a request to introduce the mouse
into the Input/HID framework in the way PS/2 keyboard is now.
It does not overlap too much with a fix to hardware access,
but it may help to remove the multitude of broken code from
userland and direct it at your super-duper-state-machine code.

 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=50921

-- Pete