[gentoo-desktop] Re: How to set per-device mouse sensitivity : Revisited !

[Duncan]

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