Xorg can use hot-plug, but configuration is troublesome.

If the configuration is incorrect, it cannot be used. If the configuration is not correct, use this:

Code:

>=Sys-apps/hal-0.5.10 > = X11-drivers/xf86-input-evdev-1.2.0 > = App-MISC/hal-info-20071011

Original post: 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 shocould 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 then ONS thenYour 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 shoshould.

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 deployments from Xorg. conf, then do as desertfox told you and add

Code:

Option "autoadddevices" "false"

In your "serverflags" section inside your Xorg. conf.
For all else:
Look inside/usr/share/hal/fdi/policy/10 osvendor/For example configurations.
Copy the ones you like to/etc/hal/fdi/policy/and change them to suit your needs.

And it is unmasked becouseTesting is needed. It is in ~ Arch becouse it shoshould work for most of youIf configured right.
And things like my crash-click (described below) is that kind of issues the developers are looking for and they shoshould be reported and fixed so this things cocould 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, cocould 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 fineOn 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.

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