hald 0.5.10 blocks (at least) all input devices, which results in (eg) X11 not starting. (Excerpt from Xorg.0.log will follow later, since the currently present logfile is from a correct run, so I need to reinstall hal 0.5.10 and reproduce this.) Reproducible: Always Steps to Reproduce:
Created attachment 136786 [details] Xorg Log file with HAL 5.10 installed prevents X from starting. This is my Xorg-x11 logfile with HAL-5.10 installed. X dies immediately with no inputs.
I'd try to unmask evdev-1.2.0: echo "=x11-drivers/xf86-input-evdev-1.2.0 **" >> /etc/portage/package.keywords Supposedly, that version was masked because it could only work with hal 0.5.10.
I can confirm the fact that with hal-0.5.10 and xf86-input-evdev-1.1.5-r2 X doesn't start. And crashes if device is hotplugged. Unmasking xf86-input-evdev-1.2.0 helps, I can start X server, my mouse is working.
After unmasking the package, Xorg-x11 now comes up, but I only have vertical movement of my mouse. Possibly a required xorg.conf change? (In reply to comment #2) > I'd try to unmask evdev-1.2.0: > echo "=x11-drivers/xf86-input-evdev-1.2.0 **" >> /etc/portage/package.keywords > Supposedly, that version was masked because it could only work with hal 0.5.10.
I can confirm that it is not that easy. x11-drivers/xf86-input-evdev-1.2.0 ignores XkbLayout=de and crashes when pressing middle-mouse...
(In reply to comment #0) > hald 0.5.10 blocks (at least) all input devices, which results in (eg) X11 not > starting. > (Excerpt from Xorg.0.log will follow later, since the currently present logfile > is from a correct run, so I need to reinstall hal 0.5.10 and reproduce this.) > > > Reproducible: Always > > Steps to Reproduce: > Exactly same error here, but I have a MS Wireless Optical Desktop 2.1 (not BT, but wireless and USB). If I unplug the receiver, X starts fine, but plugging it back makes X drop. Temporarily resolved with: emerge -1Ov "<sys-apps/hal-0.5.10" "<app-misc/hal-info-20071011" "<gnome-extra/gnome-power-manager-2.20.1"
(In reply to comment #5) > I can confirm that it is not that easy. > x11-drivers/xf86-input-evdev-1.2.0 ignores XkbLayout=de and crashes when > pressing middle-mouse... > IMHO it is not evdev problem, but hal. See bug #200061 Eric, strange that your mouse is not fully functional after updating evdev. In my case it works just fine with xf86-input-evdev-1.2.0. Are you sure that you haven't made any other changes to xorg.conf which could break your mouse horizontal movements?
No, I hadn't made any changes in xorg.conf. I tried using mouse driver evdev and mouse with same results. Apparently, someone else believes it is HAL problem as well as I just synced again, and now hal-0.5.10 has been masked by package.mask in portage "until input and mounting issues are worked out".
You need to write a custom FDI file for HAL to describe the proper configuration. The documentation for this still needs to be written. Please see the TODO list at http://blog.cardoe.com/archives/2007/11/23/hal-0510-and-things-todo-before-hitting-the-tree/
Here's a few details on getting evdev working. There's a post at http://lists.freedesktop.org/archives/xorg/2007-October/029219.html with the basics, and another that I can't seem to find in the archive, so I pasted it here: Date: Thu, 15 Nov 2007 00:48:12 -0800 From: David Sharp <whereami@gmail.com> To: Nicolas Mailhot <nicolas.mailhot@laposte.net> Subject: Re: Xorg Input Hotplugging Cc: xorg@lists.freedesktop.org, Daniel Stone <daniel.stone@nokia.com>, hal@lists.freedesktop.org On Nov 14, 2007 3:12 AM, Nicolas Mailhot <nicolas.mailhot@laposte.net> wrote: > Hi all, > > I'd appreciate help in converting this old working xorg evdev config to > the new hal hotplug fdi syntax (since it just hit fedora-devel, and the > old xorg.cong results in no input) > > I understand you're supposed to drop xml files in > /etc/hal/fdi/policy/, and I more or less grok the basic syntax rules, > but the mapping from the old directives to the new key names is evading > me. what you want is for the hal devices to have properties that xorg will understand, like input.x11_driver This seems like it should cover most devices (it's not installed by make install, last I checked): http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blob;hb=HEAD;f=config/x11-in +put.fdi for example: <match key="info.capabilities" contains="input.mouse"> <merge key="input.x11_driver" type="string">mouse</merge> <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux"> <merge key="input.x11_driver" type="string">evdev</merge> </match> </match> this says: if a device has key info.capabilities with a value that contains input.mouse set key 'input.x11_driver' to the value 'mouse' if linux set key 'input.x11_driver' to the value 'evdev' I guess you said you understand the basic syntax, so maybe you got this far. so, assuming this file isn't working as-is for you, you need to match properties for your devices, and merge the properties that xorg will understand. You can find these properties in various ways: - hal-device-manager is a gui interface - lshal lists all hal devices and properties. - hal-device does as well (it can also and and remove devices) - hal-find-by-capability does what it says. capabilities come from the property 'info.capabilities' - hal-find-by-property also does what it says, but is a bit limited (can only find properties with string values, not int, bool, or lists) at least one of the properties for your devices should contain their usb vendor/product IDs. other properties xorg understands for keyboards: - input.xkb.rules - input.xkb.model - input.xkb.layout - input.xkb.variant - input.xkb.options xorg will look for devices with these capabilities (info.capabilities): - input.keys - input.keyboard (deprecated) - input.mouse - input.touchpad xorg expects these properties to be set on these devices: - input.x11_driver - input.device (usually already set)
slightly modified x11-input.fdi for german users. works on my macbook pro. tested with external and build-in keyboard: (http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blob;hb=HEAD;f=config/x11-input.fdi): <?xml version="1.0" encoding="UTF-8"?> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.mouse"> <merge key="input.x11_driver" type="string">mouse</merge> <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux"> <merge key="input.x11_driver" type="string">evdev</merge> </match> </match> <match key="info.capabilities" contains="input.keys"> <merge key="input.xkb.rules" type="string">base</merge> <!-- If we're using Linux, we use evdev by default (falling back to keyboard otherwise). --> <merge key="input.x11_driver" type="string">keyboard</merge> <merge key="input.xkb.model" type="string">pc105</merge> <merge key="input.xkb.layout" type="string">de</merge> <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux"> <merge key="input.x11_driver" type="string">evdev</merge> <merge key="input.xkb.model" type="string">evdev</merge> </match> </match> </device> </deviceinfo> You need the x11-drivers/xf86-input-evdev-1.2.0 driver for this.
If xorg-server is going to rely on keyboard configuration to be stored in HAL and require that people write the files themselves, xorg-server should be like every other package out there (example, libgphoto2) and provide documentation on how to write configuration files since xorg.conf is not the place to configure your keyboard. Or provide some sample files.
after upgrading hal to 0.5.10 i have exactly the same situation as Comment #4 From Eric Bosch, only the mouse Y-axis works. after downgrading back to 0.5.9.1-r3 everything is working again (with xf86-input-evdev-1.2.0) Xorg.0.log says: (**) Logitech USB Receiver: always reports core events (II) Logitech USB Receiver: Found 1 absolute axes. (II) Logitech USB Receiver: Configuring as pointer. (II) Logitech USB Receiver: Found 5 relative axes. (II) Logitech USB Receiver: Configuring as pointer. (EE) Logitech USB Receiver: Unable to parse 'RelAxis 0' as a map specifier. (**) Logitech USB Receiver: Configuring 1 absolute axes. Section "InputDevice" Identifier "Keyboard0" Driver "evdev" Option "SendCoreEvents" "true" Option "Device" "/dev/input/by-id/usb-Logitech_USB_Receiver-event-kbd" Option "XkbLayout" "de" EndSection Section "InputDevice" Identifier "Mouse0" Driver "evdev" Option "SendCoreEvents" "true" Option "Device" "/dev/input/by-id/usb-Logitech_USB_Receiver-event-mouse" Option "evBits" "+1-2" Option "keyBits" "~272-287" Option "relBits" "~0-2 ~6 ~8" Option "Pass" "3" EndSection It's a Logitech Cordless Desktop Wave, keyboard and mouse are using the same usb receiver.
(In reply to comment #5) > I can confirm that it is not that easy. > x11-drivers/xf86-input-evdev-1.2.0 ignores XkbLayout=de and crashes when > pressing middle-mouse... > You can consider yourself lucky - for me any mouse button but the left one crashes X (which makes use of context menus rather tricky). I also don't seem to be able to track the issue down to its cause as all I get is a short message in /var/log/messages about a segfault in X. Building xorg-server/xf86-input-evdev with USE=debug doesn't really improve the debugging situation.
(In reply to comment #14) > (In reply to comment #5) > > I can confirm that it is not that easy. > > x11-drivers/xf86-input-evdev-1.2.0 ignores XkbLayout=de and crashes when > > pressing middle-mouse... > > > You can consider yourself lucky - for me any mouse button but the left one > crashes X (which makes use of context menus rather tricky). I also don't seem > to be able to track the issue down to its cause as all I get is a short message > in /var/log/messages about a segfault in X. Building > xorg-server/xf86-input-evdev with USE=debug doesn't really improve the > debugging situation. As I am not the only one anymore, I created bug #204951 on this issue.
hal 0.5.10 enables automatic input device hotplugging because of certain fdi files in /usr/share/hal/fdi/policy/10vendor. xorg-server will add an evdev keyboard and evdev mice AND will add devices in the xorg.conf, making things confusing. EITHER copy customized fdi files to /etc/hal/fdi/policy and put Option "AllowEmptyInput" "yes" in section ServerFlags in xorg.conf to prevent xorg-server from adding default devices (resulting in two keyboards). OR disable the hotplugging through hal by specifying Option "AutoAddDevices" "off" to section ServerFlags in xorg.conf. I recommend that, because current kernel oops sometimes when unplugging usb mice that are in use over evdev by xorg. The default is stupid and breaks things, so a warning is needed.
This may help: try to add Option "AutoAddDevices" "False" to your ServerLayout. It fixed my layout, but not my mouse. See http://bugs.gentoo.org/show_bug.cgi?id=200061#c22 Also have a look at bug 204128 and bug 210710
This appears a mish-mash of links to other bugs, most of which are closed. I'm sorry, but the existing bug report is no longer usable to me. Rather then leave it here to gather bitrot, I will apologise here for the lack of service that you have received. Should you still fill that a specific set of einfo/ewarn statements (please be concise and to a degree politically correct) would help users that wish to work around HAL and continue to use /etc/X11/xorg.conf, can I ask that you file a (new) bug on HAL 0.5.11-r7 and assign it to me please.
