Hi,
2010/4/21 Duncan <[email protected]>:
> 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.
The <<<<<< mark was intended to highlight this line, telling that the
class is being merged on the device. It is the full (relevant) log.
Sorry for the noise, I found a solution.
The installed x11-drivers/xf86-input-evdev was 2.3.2 (currently
stable). After installing xorg 1.8.0, I just rebuilt it as
recommended.
I just tried the 2.4.0, currently ~amd64, and the settings apply.
Here is the final config file :
Section "InputClass"
Identifier "nomouse"
MatchDevicePath "/dev/input/mouse*"
Option "Ignore" "true"
EndSection
Section "InputClass"
Identifier "My mouse"
MatchProduct "Bluetooth Laser Travel Mouse"
MatchDevicePath "/dev/input/event12"
Option "AccelerationProfile" "-1"
Option "ConstantDeceleration" "10"
EndSection
(yes, in a separated file this time (for a quick hack, I used first
the file I known parsed by Xorg ;-) )
And the relevant part of the log ( Xorg :1 -retro -verbose 5 2>log ):
(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)
(**) Bluetooth Laser Travel Mouse: (accel) keeping acceleration scheme 1
(**) Option "ConstantDeceleration" "10"
(**) Bluetooth Laser Travel Mouse: (accel) constant deceleration by 10.0
(**) Option "AccelerationProfile" "-1"
(**) Bluetooth Laser Travel Mouse: (accel) acceleration profile -1
(**) Bluetooth Laser Travel Mouse: (accel) acceleration factor: 2.000
(**) Bluetooth Laser Travel Mouse: (accel) acceleration threshold: 4
(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: Ignoring device from InputClass "nomouse"
We can see the settings are applied.
Another question is : I have to be root to edit this file. Is it
possible to put some settings under $HOME?
I have to be root to change the mouse sensitivity setting, and as I
can't bear fast mice, some people like them.
Regards,
Mickael
