Re: [MOUSE] Alias for /dev/psaux

[Vojtech Pavlik]

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

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

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
	  mouse acceleration.

	* 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.
> 
> 		Linus

-- 
Vojtech Pavlik
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/