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
