当前位置:Linux教程 - Linux - Linux: 2.6 Input Drivers FAQ(en)

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