Hi:
This patch creates an alias for /dev/psaux so that mousedev is loaded
automatically.
Thanks,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> This patch creates an alias for /dev/psaux so that mousedev is loaded
> automatically.
[...]
> Index: kernel-source-2.5/drivers/input/mousedev.c
[...]
> +#ifdef CONFIG_INPUT_MOUSEDEV_PSAUX
> +MODULE_ALIAS_CHARDEV(MISC_MAJOR, PSMOUSE_MINOR);
> +#endif
Well if you intend to go this way you have to add aliases for all
low-level mouse drivers, e.g. HID etc. What makes psmouse so special?
And if new mouse driver is added (worst case - off tree) it won't be catched.
I like hotplug approach better ...
-andrey
Please Cc me on reply.
had excatly the same problem moving to test9-mm1, way i fixed it was to
pass the options "psmouse_rate=60 psmouse_resolution=200" to the kernel
at boot (these were the old defaults).
matt
On Wed, 5 Nov 2003, Matt wrote:
>
> had excatly the same problem moving to test9-mm1, way i fixed it was to
> pass the options "psmouse_rate=60 psmouse_resolution=200" to the kernel
> at boot (these were the old defaults).
Can you guys test passing in "psmouse_noext=1" instead?
The thing is, the psmouse initialization in 2.4.x does _nothing_. Nada.
Zilch. Zero. And it obviously works fine. So the 2.6.x code is apparently
just _crap_.
The extended psmouse detection code will try different things, and one
thing in particular is that the Logitech magic ID matching sets the
resolution to zero, while the IntelliMouse thing sets the rate to 80.
I don't know what the proper thing to do is, but I'm pretty certain that
the current mouse initialization has got to go. It clearly breaks setups
that worked fine in 2.4.x, and the 2.6.x doesn't actually have any
_advantages_ that I can tell. Maybe Vojtech can inform us.
Passing in "psmouse_noext=1" gets you close to 2.4.x behaviour.
Linus
On Wed, Nov 05, 2003 at 08:27:30AM -0800, Linus Torvalds wrote:
>
> On Wed, 5 Nov 2003, Matt wrote:
> >
> > had excatly the same problem moving to test9-mm1, way i fixed it was to
> > pass the options "psmouse_rate=60 psmouse_resolution=200" to the kernel
> > at boot (these were the old defaults).
>
> Can you guys test passing in "psmouse_noext=1" instead?
>
> The thing is, the psmouse initialization in 2.4.x does _nothing_. Nada.
> Zilch. Zero. And it obviously works fine. So the 2.6.x code is apparently
> just _crap_.
>
> The extended psmouse detection code will try different things, and one
> thing in particular is that the Logitech magic ID matching sets the
> resolution to zero, while the IntelliMouse thing sets the rate to 80.
>
> I don't know what the proper thing to do is, but I'm pretty certain that
> the current mouse initialization has got to go. It clearly breaks setups
> that worked fine in 2.4.x, and the 2.6.x doesn't actually have any
> _advantages_ that I can tell. Maybe Vojtech can inform us.
>
> Passing in "psmouse_noext=1" gets you close to 2.4.x behaviour.
The main problem here is actually how the X/GPM mouse acceleration
works. It has a certain threshold in mixels per update after which it
begins multiplying the values coming from a mouse by a user settable
multiplier.
The problem is in "mixels per update". It's not in "mixels per second",
which means that if you change the updates per second value, the
threshold kicks in at a different mouse speed.
This of course annoys people. Both ways. I've got a bunch of mails that
mouse worked just fine with psmouse_rate=200 (or 2.5.* code, which is
the equivalent) and that the default settings (same as 2.4) are utter
crap. And I've also got a bunch of mails stating the opposite.
Also, all the complaints started coming in only after I changed the
default value down from 200. This was unfortunately needed because of
old machines where the i8042 will ignore all keyboard input if mouse
input is available and the mouse is able to saturate the cable at 200
updates per second.
The reason to use a high rate of updates per second is that the more
updates per second you get, the more snappy the system feels. Suddenly
windows are dragged smoothly on the screen and in GIMP the
freehand-drawn curves are actually curves and not just polygons. Also,
fine pointing is much easier, because the hand-mouse-screen-eye feedback
loop is faster.
Imagine what life used to be with old serial mice. That's the same, only
exaggerated.
Regarding removing all extension support from the psmouse driver in the
kernel, well, then we can ditch the input core completely, because the
only way to make your mouse wheel work will be to let X access the PS/2
port directly again, with all the problems that causes.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Wed, 5 Nov 2003, Vojtech Pavlik wrote:
>
> Regarding removing all extension support from the psmouse driver in the
> kernel, well, then we can ditch the input core completely, because the
> only way to make your mouse wheel work will be to let X access the PS/2
> port directly again, with all the problems that causes.
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.
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.
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.
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.
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
On Wed, Nov 05, 2003 at 08:27:30AM -0800, Linus Torvalds wrote:
> On Wed, 5 Nov 2003, Matt wrote:
> >
> > had excatly the same problem moving to test9-mm1, way i fixed it was to
> > pass the options "psmouse_rate=60 psmouse_resolution=200" to the kernel
> > at boot (these were the old defaults).
>
> Can you guys test passing in "psmouse_noext=1" instead?
>
> The thing is, the psmouse initialization in 2.4.x does _nothing_. Nada.
> Zilch. Zero. And it obviously works fine. So the 2.6.x code is apparently
> just _crap_.
>
> The extended psmouse detection code will try different things, and one
> thing in particular is that the Logitech magic ID matching sets the
> resolution to zero, while the IntelliMouse thing sets the rate to 80.
We could save the bootup mouse settings (the mouse will tell us) and
restore them after we go trough all the probing if desired.
That is, if it's really really needed not to change the default mouse
settings.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Wed, 5 Nov 2003, Vojtech Pavlik wrote:
>
> We could save the bootup mouse settings (the mouse will tell us) and
> restore them after we go trough all the probing if desired.
That sounds like a good idea. At least for the mice that we didn't
recognize, that otherwise get basically "random" commands.
How about something like this:
- if "mouse_noext" is set (which implies that we won't be doing any
probing), we also don't set rate/precision unless the user asked us.
Thus "psmouse_noext" becomes the "ultra-safe" setting. We still want to
have some way to set things like wheel etc info by hand later on (ie as
a response to the user _telling_ us what mouse it is), but that's a
more long-range plan.
- if we do probing, we first ask the mouse for its current details, and
we restore the thing by default afterwards. That at least should give
us 2.4.x behaviour unless the mouse is broken (and for broken mice
you'd just have to have "mouse_noext").
Again, long-term we'd want to have the possibility of tweaking the
results later even with the autodetection.
Does that sound like a reasonable plan?
Linus
On Wed, Nov 05, 2003 at 09:49:42AM -0800, Linus Torvalds wrote:
> On Wed, 5 Nov 2003, Vojtech Pavlik wrote:
> >
> > We could save the bootup mouse settings (the mouse will tell us) and
> > restore them after we go trough all the probing if desired.
>
> That sounds like a good idea. At least for the mice that we didn't
> recognize, that otherwise get basically "random" commands.
>
> How about something like this:
>
> - if "mouse_noext" is set (which implies that we won't be doing any
> probing), we also don't set rate/precision unless the user asked us.
>
> Thus "psmouse_noext" becomes the "ultra-safe" setting. We still want to
> have some way to set things like wheel etc info by hand later on (ie as
> a response to the user _telling_ us what mouse it is), but that's a
> more long-range plan.
>
> - if we do probing, we first ask the mouse for its current details, and
> we restore the thing by default afterwards. That at least should give
> us 2.4.x behaviour unless the mouse is broken (and for broken mice
> you'd just have to have "mouse_noext").
>
> Again, long-term we'd want to have the possibility of tweaking the
> results later even with the autodetection.
>
> Does that sound like a reasonable plan?
Yes, it does.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
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
On Wed, 5 Nov 2003, Vojtech Pavlik wrote:
> 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?
I suspect sysfs would be a _good_ way to do it. I'm sure it could be
screwed up too, but I don't think it would necessarily be wrong to be able
to do
echo imps2 > /sys/class/input/mouse/1/protocol
echo 200 > /sys/class/input/mouse/1/rate
or something similar.
> 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.
I'm a big believer in having the "default behaviour" be as user-friendly
as possible. I do not believe in the mantra "we should do as little as
possible, and let the user set everything up".
> If psmouse.o is a module, the installer of course can ask the user.
I think that's a failure. For one thing, you need the module to even _let_
the user select the mouse type: you can't seriously expect installers for
normal users to not run graphically and with a mouse already?
In general, module parameters are _always_ a sign of failure. I don't know
of a single one that can be considered a "good thing". They are sometimes
required, but they should be required only for hardware that is just very
fundamentally broken.
Linus
Vojtech Pavlik writes:
> IMO sane values are
...
> * 1:1 scaling
> + has anyone ever changed this one?
I reset it to 2:1 while trying to get the PS/2 mouse attached to
my Dell laptop to work "reasonably". I never was fully successful
because I didn't know how the different parameters interacted --
the recent posts to LKML has clarified that.
Currently I only use psmouse_noext, which is absolutely required
to prevent total mayhem. (You wouldn't believe what crap it spews
out otherwise after a resume from suspend.)
/Mikael
On Wed, Nov 05, 2003 at 07:03:21PM +0100, Vojtech Pavlik wrote:
> > How about something like this:
> >
> > - if "mouse_noext" is set (which implies that we won't be doing any
> > probing), we also don't set rate/precision unless the user asked us.
> >
> > Thus "psmouse_noext" becomes the "ultra-safe" setting. We still want to
> > have some way to set things like wheel etc info by hand later on (ie as
> > a response to the user _telling_ us what mouse it is), but that's a
> > more long-range plan.
> >
> > - if we do probing, we first ask the mouse for its current details, and
> > we restore the thing by default afterwards. That at least should give
> > us 2.4.x behaviour unless the mouse is broken (and for broken mice
> > you'd just have to have "mouse_noext").
> >
> > Again, long-term we'd want to have the possibility of tweaking the
> > results later even with the autodetection.
> >
> > Does that sound like a reasonable plan?
>
> Yes, it does.
It didn't work out.
The problem is that the psmouse driver always issues the 0xf6 RESET
command as the second command in the command sequence. This is correct,
because we need to disable the mouse input, so that it doesn't collide
with further probing and setup.
The 0xf6 RESET command will initalize the mouse to the default (100
samples/second, 100 dpi, 1:1 mapping) settings.
So there is no point in saving those settings and restoring them later,
when we know what they are already.
Also, in 2.4, the 0xf6 RESET is one of the first commands XFree86 sends
to the mouse, so again, there is no state left from BIOS or powerup
defaults.
XFree86 also sets the mouse to 200dpi, because that's what some mice
need to operate properly (Windows does the same). Most mice ignore that
setting, anyway.
So the attached patch sets the mouse to 100 samples/second, 200 dpi, 1:1
mapping, which is a standard setting, as close to 2.4 XFree86 behavior as
possible, and a good performance setting, too.
It also in the case of 'psmouse_noext' doesn't probe and set anything
all, though it still issues the RESET command. This is as safe as one
can get.
The only real problem remaining is that the report rate and resolution
cannot be set from XFree86 config and only is available as a
kernel/module parameter. The fix is, howewer not 2.6.0 material.
The attached patch, although rather obvious, was tested on most of my
computers and laptops, and works fine.
Please apply it before 2.6.0 ...
Thanks.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Sun, Nov 09, 2003 at 10:33:41AM +0000, John Bradford wrote:
> > XFree86 also sets the mouse to 200dpi
>
> That's odd, I have a mouse which doesn't work correctly unless I
> specifically add an Option "Resolution" "200" line to XF86Config.
This has changed between the versions of XFree86. Older versions used a
value of 100 which is the PS/2 default. Because of mice which give
trouble when they don't get a 200, like yours, this was changed in the
recent version(s).
> Either the default isn't 200, or something else must be happening
> differently when I set the resolution manually.
>
> Without a resolution option at all, the mouse has to be moved at a
> certain speed to register movement at all. This has nothing to do
> with accelleration, (which I don't use). Moving the mouse slowly, for
> any length of time, never produces any movement on-screen. Moving it
> quickly does. With the resolution set to 200 or above, it works as
> expected. Lower than 200, and it exhibits the strange behavior.
>
> The same thing happens with gpm.
>
> (This behavior is observable with 2.4. I haven't tested this mouse
> with the in-kernel driver in 2.6 yet).
Please test, but after you apply the patch.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
> XFree86 also sets the mouse to 200dpi
That's odd, I have a mouse which doesn't work correctly unless I
specifically add an Option "Resolution" "200" line to XF86Config.
Either the default isn't 200, or something else must be happening
differently when I set the resolution manually.
Without a resolution option at all, the mouse has to be moved at a
certain speed to register movement at all. This has nothing to do
with accelleration, (which I don't use). Moving the mouse slowly, for
any length of time, never produces any movement on-screen. Moving it
quickly does. With the resolution set to 200 or above, it works as
expected. Lower than 200, and it exhibits the strange behavior.
The same thing happens with gpm.
(This behavior is observable with 2.4. I haven't tested this mouse
with the in-kernel driver in 2.6 yet).
John.