Re: [MOUSE] Alias for /dev/psaux
From: Vojtech Pavlik
Date: Wed Nov 05 2003 - 13:01:54 EST
On Wed, Nov 05, 2003 at 09:36:28AM -0800, Linus Torvalds wrote:
> The alternative approach is to _not_ try to autodetect and leave it in a
> sane default state - or at least leaving the detection to a minimum, but
> having sane ways of letting the user set the thing.
Would sysfs be a sane enough way?
> As an example, the old psaux driver allowed the user to _send_ to the
> mouse, not just receive. That made it possible for user mode to autodetect
> the mouse, and set the settings. The input-mode mouse driver totally drops
> that feature - which forces the kernel to get it right.
> That's a very fragile design: making feedback impossible means that you
> have to always get it right - which in turn tends to be fundamentally
> impossible (ie new mice etc). And right now we force the user to make the
> choice at _boot_ time, which means that the installer can't even ask the
I agree here.
In the original design I assumed the PS/2 hardware is sane enough to be
(auto)detectable. Most other hardware is, so why not PS/2 mice? It has
become obvious that there are many caveats and many broken devices (most
notably KVMs and notebook transparent mux chips) in the equation.
I still would prefer to have the autodetect be enabled, because it works
for 99% of the cases and allow to set the mouse protocol manually
(either boot time or via sysfs) for the troublesome cases.
If psmouse.o is a module, the installer of course can ask the user.
> Also, some of the autodetect code is less intrusive. For example, if the
> mouse driver decides it's a Logitech mouse, it will have set the
> resolution down to zero, but it will have left the reporting rate at the
Originally, the psmouse code set all the resolution/rate/scaling to sane
values after the detection was run. It does that only conditionally now,
which causes a lot of problems with the intrusiveness of the probing.
There are four approaches:
1) Kill some of the probes (but having the MS one is needed for 80% of mice)
2) Get the values from the mouse and restore them after probing
3) Set the mouse to sane values like before
4) detect -> reset -> initialize
IMO sane values are
* 80 samples/sec
+ interactive enough, about the same as the refresh rate
of the monitor - you never can actually see a smoother
movement than your monitor HZ
+ slow enough that old hardware doesn't choke
* 400 dpi
+ simply the default. 99% USB mice are 400 dpi by
default, and PS/2 mice at least 90%
* 1:1 scaling
+ has anyone ever changed this one?
Nevertheless, we probably cannot stop at least two of these three groups
of people from complaining:
* 2.5.* users will see erratic movement of their X cursor if
they set mouse acceleration to insane values, because 200
samples/sec rate used through 2.5 effectively disabled
* 2.4 users will see mouse 'slowdown', because 2.4 default
(or better the HW default) is 60 samples/sec (thus the
speed when acceleration kicks in goes up 1.33x)
* 2.4 users who have set up different speed/res/scale values
in XF86Config, because those are ignored in 2.6
> In contrast, an unrecognized mouse will have gone through the intellimouse
> test, which will have set the rate down to 80 (in addition to having the
> resolution set down to the lowest setting by the Logitech detect code). So
> now some mice get even _worse_ behaviour. Or at least different.
Agreed, this is simply WRONG. We need to have the mouse set to defined
speed/resolution/scaling after we probe. Options listed above.
> Right now we can't make big changes, but it would be good to think about
> the issues.
> And we could make the defaults a bit nicer and less likely to screw up.
SuSE Labs, SuSE CR
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/