| 代码: |
| >=sys-apps/hal-0.5.10 >=x11-drivers/xf86-input-evdev-1.2.0 >=app-misc/hal-info-20071011 |
原贴:http://forums.gentoo.org/viewtopic-p-4754927.html?sid=04fc0b4d9bc5a14d73e98d8e4a19c07a
First some info fo the ones not grasping this:
In xorg-server-1.4 there is hotplug possibilities.
To utilize them you need hal-0.5.10 and evdev-1.2.
It works like this:
X starts and asks HAL for input devices.
HAL tells X what inputdevices it knows of and how they should be configured (what driver to use, what layout to use).
X uses this information, starts the driver and configure it according to how HAL tells it to
What this means for the user:
If you have all the required components and right verions then your devices are hotplugged and the configuration for them resides with HAL (Input sections in xorg.conf is in this case depricated).
If any dependency is not met Xorg uses the old way of managing your devices (input sections in your xorg.conf is used).
So:
No special version of these packages are broken or "are the problem" in any way. If you experience problems this is most likely becouse you have not (re)configured things like you should.
If you do not intend to use hotplugging and do not use evdev, then 'emerge -C xf86-input-evdev' (and remove 'evdev' from your INPUT_DEVICES="" in make.conf).
If you do use evdev but still want to use the configurations from xorg.conf, then do as DesertFox told you and add
| 代码: |
| Option "AutoAddDevices" "false" |
For all else:
Look inside /usr/share/hal/fdi/policy/10osvendor/ for example configurations.
Copy the ones you like to /etc/hal/fdi/policy/ and change them to suit your needs.
And it is unmasked becouse testing is needed. it is in ~arch becouse it should work for most of you IF CONFIGURED RIGHT.
And things like my crash-click (described below) is that kind of issues the developers are looking for and they should be reported and fixed so this things could become usable for all and later stable sometime in the future.
For all you who have problems with up giving screenshots and alike:
This is a problem with your X-settings conflicting with your settings in the DE (GNOME, KDE). You may not have set them in the DE yourself, but still.
The fix is (at least in GNOME) very easy. Just reset your keyboard settings in the userprofile for your DE (in GNOME do 'gconftools-2 --recursive-unset /desktop/gnome/periphials (from memory, could be spelling-issues) and relogin).
That said I still have problems with my middle/right mousebutton crashing X for my Logitech keyboard+mouse. If I look inside my Xorg.0.log it seems like it can be becouse of a missconfigureation. It detects a keyboard on my mouse, try setting that one up with a 'us' layout (my keyboard is according to Xorg.log configuread as a 'se' which it also is in HAL). This leaves me with a us-keyboard and crash-clicking. this seems to be a upstream-problem.
And for all you whining about "oooooh, it is SOOO unstable": it works perfectly FINE on my other computer, which does have a USB-keyboard and a wireless USB-mouse. So it is only for some keyboard/mouse setups it breaks, and those will not be found if not the ones having them never tries this feature and bugreport. That is what ~arch is for.
If you can not handle this you do not belong in ~arch.
EDIT:
Sorry for being a bit grumpy. I took a look in this thread and find that many misundrstandings and declarations that borders to FUD so I wanted to try to set things straight.
This edit is about the right-cklick issue: for us having it please see bug 204951.