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

[Duncan]

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