Mailing List Archive

On Wed, Apr 21, 2010 at 08:36:32PM +0200, Mickael Chazaux wrote:
> 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 in HAL :
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <deviceinfo version="0.2">
> <device>
> <match key="info.product" contains="Bluetooth Laser Travel Mouse">
> <merge key="input.x11_options.ConstantDeceleration" type="string">2</merge>
> <merge key="input.x11_options.AccelerationProfile" type="string">-1</merge>
> </match>
> </device>
> </deviceinfo>
>
> in order to set the options ConstantDeceleration and
> AccelerationProfile to sane values.
>
> 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 ?

just guessing, maybe it is the last error (no driver...ignoring...)?
have you tried adding explicit Driver "evdev"?

yoyo

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

YoYo siska posted on Wed, 21 Apr 2010 22:34:38 +0200 as excerpted:

> just guessing, maybe it is the last error (no driver...ignoring...)?
> have you tried adding explicit Driver "evdev"?

Note that that error is on the /dev/input/mouseX devicefile. The
/dev/input/eventX devicefile gets the evdev driver, as logged. (Both
devicefiles match the mouse in question, as they're two separate virtual
drivers at the kernel level, exported as two separate devicefiles, but
driven by the same physical device, the one in question. I see the same
thing here with a system functioning as expected. But people running the
gpm text console mouse driver can't turn off the legacy mouseX driver, as
gpm has to have it as it's apparently not evdev compatible, yet. If it
was, things would be simpler as the mousedev driver could be configured
out of the kernel entirely, leaving only evdev.)

--
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

Hi,

2010/4/21 Duncan <1i5t5.duncan@cox.net>:
> 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

Mickael Chazaux posted on Thu, 22 Apr 2010 13:37:49 +0200 as excerpted:

> The <<<<<< mark was intended to highlight this line, telling that the
> class is being merged on the device. It is the full (relevant) log.

Ohh.. (He said) =:^)

> 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.

Very good! Simple enough solution, after all! =:^)

> Here is the final config file :
>
> Section "InputClass"
> Identifier "nomouse"
> MatchDevicePath "/dev/input/mouse*"
> Option "Ignore" "true"
> EndSection

BTW, prompted by my reply to you, I just set up a couple ignores here,
too, and yes they do rather lower the log hotplugging noise. =:^)

> (yes, in a separated file this time (for a quick hack, I used first the
> file I known parsed by Xorg ;-) )

Understood. I was just a bit worried that the problem might be in having
it in the same file, for some reason, since having different files for it
worked just fine here. But it was just the outdated driver.

> And the relevant part of the log ( Xorg :1 -retro -verbose 5 2>log ):
> [snipped] 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.

That's a reasonable question.

AFAIK, with xorg-server-1.8.0, the server looks in several paths but ONLY
until it finds one, then it stops looking for more. So there's no direct/
easy way to do what you suggest. There's a patch floating around,
however, that makes that multiple dirs, which makes it easier. The idea
wouldn't be for quite the reason you stated, but rather, to separate the
locations into, possibly, three dirs, two standard package-config-file
drop dirs (one for low priority defaults, one for medium priority
individual package overrides, for the syntouch touchpad driver to use,
say), plus a high priority sysadmin override dir.

You could probably find the patch and apply it yourself to 1.8.0.
Meanwhile, from the discussion, it seems reasonably likely that 1.8.1 will
include that patch.

What you'd probably do, then, would be to either set the permissions on
one to user writable in-place, or make it a symlink into your user's
homedir. There are some interesting security implications, however, as
there's little stopping a user who can write one setting in the file from
writing a rather less desirable one, and remember, xorg DOES still, until
KMS becomes the norm, etc, run as root, so allowing a user total freedom
to configure X effectively gives them full root permissions, if they know
how to get them.

Instead, what's likely to happen is that the normal runtime config tools
will be updated to include this sort of functionality. Just as KDE and
the like allow setting, for instance, mouse accel, and can save that
setting to reapply every time the desktop starts, eventually, they'll
allow per-hotplug-device settings just like xorg.conf does now.

Actually, I've not really looked around for it as it's not something I've
needed, but I believe it's possible to configure per input-device hotplug
runtime behavior now -- you just have to know the intricate details of how
to set the individual device properties from the command-line, and how to
script that if you want it automated. I know it's possible to do that
with xrandr for multiple monitors, as I've been handling resolution
transitions that way myself for sometime, given that until kde 4.4, kde's
multi-monitor display settings were seriously broken on a lot of hardware
(at least the Radeon series using xorg native drivers, as I run on my
workstation, and the Intel hardware and driver I use on the netbook, but
4.4 finally fixed it!). And I've read hints that there's ways to do it
with input-hotplugging as well, but that's still less mature than randr
is, so it's no surprise it's a bit more obscure and the desktops don't
really handle it yet, especially given that kde's RandR support just got
unbroken with 4.4 and RandR's a year or two ahead of input hotplugging!
So figure KDE might actually support it by 4.7 or 4.9 or so... but
meanwhile, if you are sufficiently determined and your google foo
sufficiently good, you can probably manage it from the command line now.
I just don't know the specifics.

--
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

On Thu, Apr 22, 2010 at 01:37:49PM +0200, Mickael Chazaux wrote:
> Hi,
>
>
> 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.

No, as far as I know. But you can use xinput to modify it on runtime (though
it's harder to make it just work this way when you plug in/connect your
mouse). If it is your "personal" preference, you should set it up in your X session,
not a global X configuration... xorg.conf and other are global configuration
for all users. X server starts up before you log in to your session, so it would not
know which user's config to load.

yoyo@tabletka ~ $ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Wacom Serial Tablet PC Pen Tablet/Digitizer id=8 [slave pointer (2)]
⎜ ↳ Wacom Serial Tablet PC Pen Tablet/Digitizer eraser id=7 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=9 [slave pointer (2)]
⎜ ↳ Bluetooth Wireless Laser Mouse id=14 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ ThinkPad Extra Buttons id=6 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]
↳ Sleep Button id=11 [slave keyboard (3)]
↳ Video Bus id=12 [slave keyboard (3)]
↳ Power Button id=13 [slave keyboard (3)]
yoyo@tabletka ~ $ xinput list-props 14
Device 'Bluetooth Wireless Laser Mouse':
Device Enabled (145): 1
Device Accel Profile (264): 0
Device Accel Constant Deceleration (265): 1.000000
Device Accel Adaptive Deceleration (267): 1.000000
Device Accel Velocity Scaling (268): 10.000000
...
yoyo@tabletka ~ $ xinput set-float-prop "Bluetooth Wireless Laser Mouse" "Device Accel Constant Deceleration" 3.0

yoyo

Hi,

2010/4/22 YoYo siska <yoyo@gl.ksp.sk>:
> On Thu, Apr 22, 2010 at 01:37:49PM +0200, Mickael Chazaux wrote:
>> Hi,
>>
>>
>> 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.
>
> No, as far as I know. But you can use xinput to modify it on runtime (though
> it's harder to make it just work this way when you plug in/connect your
> mouse). If it is your "personal" preference, you should set it up in your X session,
> not a global X configuration... xorg.conf and other are global configuration
> for all users. X server  starts up before you log in to your session, so it would not
> know which user's config to load.
>
> yoyo@tabletka ~ $ xinput list
> ⎡ Virtual core pointer                          id=2    [master pointer  (3)]
> ⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
> ⎜   ↳ Wacom Serial Tablet PC Pen Tablet/Digitizer       id=8    [slave  pointer  (2)]
> ⎜   ↳ Wacom Serial Tablet PC Pen Tablet/Digitizer eraser        id=7    [slave  pointer  (2)]
> ⎜   ↳ TPPS/2 IBM TrackPoint                     id=9    [slave  pointer  (2)]
> ⎜   ↳ Bluetooth Wireless Laser Mouse            id=14   [slave  pointer  (2)]
> ⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
>    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
>    ↳ ThinkPad Extra Buttons                    id=6    [slave  keyboard (3)]
>    ↳ AT Translated Set 2 keyboard              id=10   [slave  keyboard (3)]
>    ↳ Sleep Button                              id=11   [slave  keyboard (3)]
>    ↳ Video Bus                                 id=12   [slave  keyboard (3)]
>    ↳ Power Button                              id=13   [slave  keyboard (3)]
> yoyo@tabletka ~ $ xinput list-props 14
> Device 'Bluetooth Wireless Laser Mouse':
>        Device Enabled (145):   1
>        Device Accel Profile (264):     0
>        Device Accel Constant Deceleration (265):       1.000000
>        Device Accel Adaptive Deceleration (267):       1.000000
>        Device Accel Velocity Scaling (268):    10.000000
> ...
> yoyo@tabletka ~ $ xinput set-float-prop "Bluetooth Wireless Laser Mouse"  "Device Accel Constant Deceleration" 3.0
>

I did not knew about this xinput program. Quite useful!

Regards,

Mickael