Mickael Chazaux posted on Wed, 21 Apr 2010 20:36:32 +0200 as excerpted:
> Hi,
>
> Again, I hit in the whizzingly fast mouse problem with Xorg. With my
> previous release of Xorg (1.7.6) I solved this using a hal FDI file.
> Here is the link fore reference :
>
> http://www.gossamer-threads.com/lists/gentoo/desktop/207830
>
> The solution was to merge this XML fragment [snip]
> Today I tried Xorg 1.8.0, and I added this content to
> /etc/X11/xorg.conf.d/10-evdev.conf :
>
> Section "InputClass"
> Identifier "My mouse"
> MatchProduct "Bluetooth Laser Travel Mouse"
> Option "AccelerationProfile" "-1"
> Option "ConstantDeceleration" "10"
> EndSection
>
> In Xorg log (Xorg -retro -verbose 10 2>log) I see :
>
> (II) config/udev: Adding input device Bluetooth Laser Travel Mouse
> (/dev/input/event12)
> (**) Bluetooth Laser Travel Mouse: Applying InputClass "My mouse"
> <<<<<<<<<<<
> (**) Bluetooth Laser Travel Mouse: Applying InputClass "evdev pointer
> catchall"
> (**) Bluetooth Laser Travel Mouse: always reports core events
> (**) Bluetooth Laser Travel Mouse: Device: "/dev/input/event12"
> (II) Bluetooth Laser Travel Mouse: Found 12 mouse buttons
> (II) Bluetooth Laser Travel Mouse: Found scroll wheel(s)
> (II) Bluetooth Laser Travel Mouse: Found relative axes
> (II) Bluetooth Laser Travel Mouse: Found x and y relative axes
> (II) Bluetooth Laser Travel Mouse: Configuring as mouse
> (**) Bluetooth Laser Travel Mouse: YAxisMapping: buttons 4 and 5
> (**) Bluetooth Laser Travel Mouse: EmulateWheelButton: 4,
> EmulateWheelInertia: 10, EmulateWheelTimeout: 200
> (II) XINPUT: Adding extended input device "Bluetooth Laser Travel
> Mouse" (type: MOUSE)
> (II) Bluetooth Laser Travel Mouse: initialized for relative axes.
> (II) config/udev: Adding input device Bluetooth Laser Travel Mouse
> (/dev/input/mouse2)
> (**) Bluetooth Laser Travel Mouse: Applying InputClass "My mouse"
> (EE) No input driver/identifier specified (ignoring)
>
> So I assume my options are merged in the configuration. But it has no
> effect. What can be wrong ?
Your options DO seem to be merged as we see it applying the specific
inputclass by ID string.
However, we see it detected twice, using two different device files and
kernel drivers.
Do you use gpm for text-mode mouse? AFAIK, it doesn't yet support evdev,
or at least I couldn't figure out how to do it, so if you use it, you need
to keep the kernel input/mouse driver around for that. But if you don't
use a mouse at the text console anyway, you can probably disable the
kernel mouse driver and thus /dev/input/mouseX and mice, while keeping
evdev and /dev/input/eventX. That would simplify things for udev and X,
somewhat.
But if like me you use gpm and thus need to keep /dev/input/mice and the
individual mouseX devices around, you'll just have to live with the extra
devices, as I am. By default, xorg-server is set, using the catchall, to
only use evdev, and to ignore the mouse device as it won't be assigned a
driver, as that (EE) log entry seems to indicate is happening. So that
itself shouldn't be an issue.
What I'm wondering, however, is if either the order of application or the
application of your own settings to the /dev/input/mouseX device (despite
it not having an assigned driver) is screwing things up.
What happens if...?
OK, before we get to that, I just noticed something else. You're editing
the default /etc/X11/xorg.conf.d/10-evdev.conf .
There's a better way. Create your OWN file, something like
00-mc-bluetooth-mouse.conf . 00- puts it in order before the 10- file, so
it's processed first and thus receives precedence over the defaults. -mc-
is your initials. Here, I use jed, my initials, to indicate my own
settings. The idea is simply to make it easy to distinguish your own
settings from any default settings. Then follows a name that identifies
the function to you, with the .conf extension, or X will ignore it.
That way, the default files stay unmodified and are easier and less risky
to etc-update or whatever you use.
So you probably want to create your own separate file, as I mentioned, and
leave the default one untouched.
Now that we got that out of the way... what happens...
... if you add a couple more lines to your section inputclass, above, like
so (MatchDevicePath and Driver, also note that I've column tabulated the
entries for ease of reading, I had my whole xorg.conf aligned like this,
and of course now do it in my xorg.conf.d/*.conf files):
Section "InputClass"
Identifier "My mouse"
MatchProduct "Bluetooth Laser Travel Mouse"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "AccelerationProfile" "-1"
Option "ConstantDeceleration" "10"
EndSection
The idea for the event* devicepath match came from the blog entry
introducing xorg.conf.d to the world, here (see Dan Nicholson's Jan 4 2010
5:02 PM, comment):
http://who-t.blogspot.com/2010/01/new-configuration-world-order.html
Basically, what we're doing is confining our config so it ONLY matches
that product, ONLY on evdev devicefiles, NOT on /dev/input/mouseX files.
That way, it's now safe to tell it specifically to load the evdev driver,
without having to worry about it trying to use that driver on the mouseX
devfile as well.
With this in place, it shouldn't fall thru to the catchall entry at all,
and we should eliminate all possibility of it getting mixed up by either
that, or the mouseX device.
If desired, you can add a similar specific mouseX device ignore section
(or another file, there's a reason it's modular now!), as follows:
Section "InputClass"
Identifier "Ignore mousedev"
MatchDevicePath "/dev/input/mouse*"
Option "ignore" "1"
EndSection
BTW, that <<<<< mark, does that indicate snippage? Did you snip anything
related to the input detection if so? Because I expected to see it
applying the accel profile and constant decel settings there. But I'm not
sure if it does that before seeing a driver or not, or whether you snipped
out that bit if it was there, etc.
Either way, I think/hope the above changes will make the log easier to
follow, even if they don't solve the issue. So try it and reply with the
new log info if it still doesn't work, and perhaps there'll be some other
hint there. If nothing else, the documentation is pretty specific that
once the driver is set, it's set, and with the above, your settings should
set it and we should for sure see it set there and not with the catchall
settings. If with the above it's still not setting the driver until it
reaches catchall, then we know something else strange is going on, as it
would seem to be ignoring your whole custom section. The only way I can
think that that might happen would be if the match isn't matching for some
reason, but I guess we'll see.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
