Linux: 2.6 Input Drivers FAQ(en)
Posted by jeremy on Thursday, November 6, 2003 - 04:49
In recent 2.6-test kernels [forum], the behaviour of the mouse has changed. Evidently in 2.6.0-test6 [story] boot-time logic was added that attempts to determine the proper settings, however if this fails you can be left with an illogical configuration resulting in an unresponsive mouse. Linux creator Linus Torvalds explains, "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." Recently upgrading from 2.6.0-test6-mm4 [story] to 2.6.0-test9-mm2 [story], I personally found that the default behaviour made my mouse unusably sluggish.
During a discussion of the matter on the lkml, Vojtech Pavlik explained what the current logic is attempting to do, and how this can result in annoyance for some users. He describes the problem I had as follows, "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)". The solution for me was to pass in "psmouse_noext=1" from my boot loader which Linus explains "gets you close to 2.4.x behaviour."
Going forward, an alternative configuration method was suggested which will result in a sane default. Linus summarized, "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'."
From: Matt [email blocked]
To: herbert
Subject: Re:[MOUSE] Alias for /dev/psaux
Date: Wed, 05 Nov 2003 15:17:39 +0000
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
From: Linus Torvalds [email blocked]
Subject: Re:[MOUSE] Alias for /dev/psaux
Date: Wed, 5 Nov 2003 08:27:30 -0800 (PST)
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
From: Vojtech Pavlik [email blocked]
Subject: Re: [MOUSE] Alias for /dev/psaux
Date: Wed, 5 Nov 2003 18:02:17 +0100
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
From: Linus Torvalds [email blocked]
Subject: Re: [MOUSE] Alias for /dev/psaux
Date: Wed, 5 Nov 2003 09:36:28 -0800 (PST)
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
From: Vojtech Pavlik [email blocked]
Subject: Re: [MOUSE] Alias for /dev/psaux
Date: Wed, 5 Nov 2003 19:00:35 +0100
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
From: Linus Torvalds [email blocked]
Subject: Re: [MOUSE] Alias for /dev/psaux
Date: Wed, 5 Nov 2003 10:39:23 -0800 (PST)
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
From: Vojtech Pavlik [email blocked]
Subject: Re: [MOUSE] Alias for /dev/psaux
Date: Wed, 5 Nov 2003 18:39:07 +0100
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
From: Linus Torvalds [email blocked]
Subject: Re: [MOUSE] Alias for /dev/psaux
Date: Wed, 5 Nov 2003 09:49:42 -0800 (PST)
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
From: Vojtech Pavlik [email blocked]
Subject: Re: [MOUSE] Alias for /dev/psaux
Date: Wed, 5 Nov 2003 19:03:21 +0100
On Wed, Nov 05, 2003 at 09:49:42AM -0800, Linus Torvalds wrote:
>
> Does that sound like a reasonable plan?
Yes, it does.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Related Links:
Archive of above thread
[add new comment]
Mouse insanity
Interesting comment posted by Anonymous on Thursday, November 6, 2003 - 13:02
The mouse driver on my PCs has been great (my Q3A average is as good as ever), but on my ThinkPad the nipple mouse _constantly_ freaks out, very sporadically. By freak out I mean the driver prints an error about losing sync with its input stream, and the mouse does everything from close and resize windows to move my task-bar to different parts of the screen. In the past the problem seemed to surface after my laptop had been on for an hour or more, but under 2.6.0-test9-mm1 it happens constantly. My laptop mouse is all but unusable in its present state. :( Anyone have any advice?
-Nick
[ reply to this comment ]
If you want 2.6 behaviour bac
Insightful comment posted by cef on Thursday, November 6, 2003 - 15:42
If you want 2.6 behaviour back, try adding "psmouse_rate=60 psmouse_resolution=200" into the kernel command line (eg: lilo's append line or via grub or whatever your bootloader might be). This may reduce the problems you've got with test9-mm1, but may not remove them.
For me, I found I only needed the psmouse_resolution one, as it was the one causing me the most grief. Fiddle with the values to suit your needs though. Could be you'll find some settings that work better and reduce your issue.
These options are not yet covered in ./Documentation/kernel-parameters.txt, but that may be because they're just trying to keep the current set of patches down ONLY to fixes.
On a side note: Perhaps this could be related to the laptop going into some sort of power-saving related mode? This would explain a lot of such weird behaviour, as the mouse could be resetting back to defaults or getting confused after it's been deactivated/reactivated.
[ reply to this comment ]
and what about usb mouse?
Interesting comment posted by Anonymous on Friday, November 7, 2003 - 04:35
I also have erratic behaviour of my usb mouse.
"psmouse_rate=60 psmouse_resolution=200" seems good for ps2 mice, but how about usb? Is there a similar command?
Cheers,
nico.
[ reply to this comment ]
Hmm
Interesting comment posted by Anonymous on Saturday, November 8, 2003 - 07:04
Will check out these settings. I doubt the problem is power related. In fact, the mouse stops working completely after waking up, forcing me to reload the module.
Thanks for the tips,
-Nick
[ reply to this comment ]
It may also be a hardware issue
Interesting comment posted by Mr_Z on Thursday, November 6, 2003 - 17:06
Do you have another OS installed on this laptop, or only Linux? If you have another OS to test with, I'd recommend it, as it may be a hardware issue.
I was helping a friend with their WinME laptop, and it had identical symptoms. In the end, we just disabled the nipple mouse and went with an external mouse. I'm pretty sure their system was having hardware problems, not software. (There was a nice rattle coming from the laptop as well. Plus, the nipple mouse would sometimes decide to start wandering around the screen, even when it wasn't going fully psycho.)
Their laptop was a Toshiba Satelite, with a Synaptics "eraserhead" mouse.
[ reply to this comment ]
...or XF86Config problem.
Interesting comment posted by Anonymous on Friday, November 7, 2003 - 02:29
My Logitec PS/2 wheelmouse was behaving very weird, both in gpm and X with test 9. It worked just fine with a live cd with a 2.4 kernel, so I thought it was caused by test 9. Turned out that gpm -t ps2 worked just fine, and also imps2, only the default setting didn't work. After looking a bit better to the X config file (an edited old one that was used with a serial mouse), changing IntelliMouse to IMPS/2 fixed all problems.
[ reply to this comment ]
Wandering
Interesting comment posted by Anonymous on Friday, November 7, 2003 - 09:53
The wandering behaviour is normal. It's the internal compensation for a not-perfectly-calibrated eraser. If you push in one direction for too long it thinks the mouse needs correction so it wanders in the opposite direction for a few seconds up to a minute even after you stop touching it. Very annoying. Especially when you are trying to do delicate work.
It's kind of like N64 game controllers that get confused if you are touching them when you turn the system on.
[ reply to this comment ]
This wasn't the normal wandering
Interesting comment posted by Anonymous on Saturday, November 8, 2003 - 07:16
(This is Mr Z... too lazy to find my password right now.)
I'm aware of the internal re-zeroing effect. This wasn't it. I'd pick up the laptop and the pointer would start drifting in a different direction instantly. I could leave it sitting there for 20 minutes and the pointer would make circuits around the screen. (I watched it do this during a defrag.)
[ reply to this comment ]
The Wandering Eraser/Nipple Mouse
Interesting comment posted by Anonymous on Monday, November 10, 2003 - 09:49
I've been trying to avoid waiting for the mouse to stop drifting. My technique -- arrived at by somewhat non-scientific means -- is to let go of it for a moment then push it in the direction opposite to the direction I was holding it. This seems to help it settle down more quickly.
[ reply to this comment ]
Hmmm
Interesting comment posted by Anonymous on Saturday, November 8, 2003 - 07:10
Yeah I'm really, really hoping its a problem with the driver and not the hardware. It started happening the second I switched to 2.6.0-test4 from 2.4.21. I'll find some time to switch back to 2.4 for a few hours one of these days...
-Nick
[ reply to this comment ]
IBM Thinkpad problems
Interesting comment posted by Anonymous on Saturday, November 8, 2003 - 12:44
Some problems with mouse jumping were reported with APM/ACPI support. They are caused by a bug in IBM thinkpad bios.
OTOH I think the new kernel mouse support does not really support the nipple mouse. tp4d (the user space tool) does not work either. I will not upgrade before that works.
[ reply to this comment ]
thinkpad 770ed
Interesting comment posted by Anonymous on Saturday, November 8, 2003 - 17:09
The eraserhead pointer on my thinkpad works flawlessly with 2.6; it's worked with every kernel in the series I've tried, back to around 2.5.59.
These are just ordinary PS/2 devices, no? Why wouldn't they work?
[ reply to this comment ]
Thank you thank you thank you!
Interesting comment posted by Anonymous on Monday, November 10, 2003 - 10:44
I believe removing APM support has solved the problem. Thanks a million! This problem has been driving me _crazy_ since test5!
-Nick
[ reply to this comment ]
getting the 2.4 /dev/psaux back
Insightful comment posted by Anonymous on Thursday, January 22, 2004 - 00:30
See if my psaux module helps.
[ reply to this comment ]
Interesting comment "Multiple Mice" by Anonymous
Okay comment "2.6 can" by molo
Off topic comment "Laptop" by Con Kolivas
2.6 Wheel Mouse w/ KVM Switch
Insightful comment posted by Anonymous on Saturday, January 3, 2004 - 07:56
After reading many mail posts, comments, and suggestions regarding using a mouse in 2.6 with a KVM switch, I thought the only solutions were psmouse_noext (which disabled my mouse wheel) or an obscure kernel patch to work around the problem. Not so!
Adding psmouse_resetafter=1 to my kernel command line allows me to switch back and forth to my linux machine once again, without having to unplug the mouse connection or switch between virtual terminals. Hooray! According to the source (drivers/input/mouse/psmouse-base.c), this is only for resetting the synaptics touchpad, but it resets my mouse after (in this case) 1 bad packet. Works like a charm.
[ reply to this comment ]
Redundant comment "Re: [MOUSE] Alias for /dev/psaux" by Anonymous
Similar Problem -- needed to enable usb mouse
Okay comment posted by Anonymous on Saturday, January 24, 2004 - 12:25
I had what appeared to be a similar problem. Touchpad worked great in 2.4. Switch to 2.6 and while the touchpad continued to work in the console (gpm - imps2, /dev/psauax, raw) the X configuration just died; the mouse was going crazy all over the place. My X configuration had these vitals, protocol mouse, imps/2, /dev/gpmdata.
Well, I tried the synaptics driver, and while it detected my touchpad, it wouldn't respond properly. However, i discovered after many restarts of X and gpm that I just need to add the usbmouse module. I believe the laptop somehow repeats the touchpad USB->psaux. Once that was done, both my touchpad and my connected USB mouse work perfectly.
Anyway, you may want to check with the setup of your usb interfaces before you try the synaptic driver -- I believe for some setups this more accurately mimics the setup of the old 2.4 configuration.
BTW -- Toshiba Satellite 3005. Oh, and the Power management now works great! Good work all around for the new stable kernel. Me-like-ee. 发布人:jjk 来自:kerneltrap