Description of problem: hal does not work with Xorg Version-Release number of selected component (if applicable): 0.5.12.29 How reproducible: Upgrade using yum to xorg-x11-server-Xorg.x86_64 1.6.4-0.1.fc11 updates xorg-x11-server-common.x86_64 1.6.4-0.1.fc11 updates and restart X. See that Xorg crashes, see bug https://bugzilla.redhat.com/show_bug.cgi?id=522936 Find out while researching this bug that AllowEmptyInput is the cause, so remove that line. Find then out that keyboard and mouse don't work. `lshal` knows about keyboard/mouse. Steps to Reproduce: 1. See above. 2. 3. Actual results: A non-working keyboard/mouse. Expected results: Working keyboard/mouse. Additional info:
This hal issue blocks me from a successful upgrade to xorg-x11-server-Xorg.x86_64 1.6.4-0.1.fc11. This blocks me, ultimately, from the greater part of the upgrades to the gui-oriented environment that Fedora offers. Therefore the urgency.
Surely this is an XOrg bug, right?
I cannot decide. I found out because of the Xorg issue mentioned. Xorg logs something about hal needing configuration etc when I leave out the AllowEmptyInput line. What can I do to help you find the rootcause?
Exact Xorg message without AllowEmptyInput: (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput.
Please always attach the full log from Xorg when reporting X bugs. Have you tried moving xorg.conf away temporarily to see if it makes any difference?
I did not yet know this was a Xorg bug as it is filed for hal. I do not use an empty config as I want to use radeonhd as driver. I can try that situation, though. What will it tell?
xorg.conf: Section "Monitor" Identifier "Philips" EndSection Section "ServerFlags" Option "AllowEmptyInput" "False" Option "DontZap" "False" EndSection Section "Device" Identifier "RadeonHD2600" Driver "radeonhd" Option "DRI" Option "AccelMethod" "exa" EndSection Section "Screen" Identifier "MyScreen" Device "RadeonHD2600" DefaultDepth 24 SubSection "Display" Depth 24 Virtual 1680 1050 EndSubSection EndSection Section "DRI" Mode 0666 EndSection
Created attachment 363321 [details] Xorg.log with `working` Xorg, no conf
Created attachment 363322 [details] Xorg.log with `crashing` Xorg, no conf
I attached two Xorg logfiles from my other radeonhd dualhead amchine. I started xorg *without* config in both cases. Once with the Xorg that works OK (if the config is enabled). Once with the Xorg that crashes (if the config is enabled). In both cases neither mouse nor keyboard work, Xorg starts fine. Normal dualhead conf there, not used now: Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" Option "Xinerama" "off" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us+inet" EndSection Section "Monitor" Identifier "Philips1" Option "DPMS" Option "LeftOf" "Philips2" EndSection Section "Monitor" Identifier "Philips2" Option "DPMS" EndSection Section "Device" Identifier "Videocard0" Driver "radeonhd" Option "Monitor-DVI-I_1/analog" "Philips1" Option "Monitor-DVI-I_2/analog" "Philips2" Option "RROutputOrder" "DVI-I_1/analog" Option "DRI" Option "AccelMethod" "exa" EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" DefaultDepth 24 SubSection "Display" Depth 24 Virtual 2560 1024 Viewport 0 0 EndSubSection EndSection Section "ServerFlags" Option "Xinerama" "False" Option "AllowEmptyInput" "False" Option "DontZap" "False" EndSection Section "DRI" Mode 0666 EndSection
I noticed you're running a custom kernel (realtime patched). Is the bug reproducible with a standard Fedora kernel too? If it is, please attach the output of the "hal-device" command.
I do not use `standard` kernels. I used the realtime kernel because that is standard on the dualhead box that is used for audio. I used that box so I did not have to test with *this* singlehead radeonhd box which has the very same behaviour but has no realtime but still 'custom' kernel. I also have to use the "AllowEmptyInput" "False" on my VIA Epia EN12000 which runs MythTV with different than radeonhd video hardware. That box logs stuff like: (....) (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins (==) ModulePath set to "/usr/lib/xorg/modules" (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. (II) Loader magic: 0xa40 (II) Module ABI versions: (....) What else could I test? Maybe check some hal logging? Does it work OK? Does it work well with 'my' kernels? (I do not know hal)
(In reply to comment #12) > I do not use `standard` kernels. Well, would you make an exception this time to test it? > What else could I test? > Maybe check some hal logging? Does it work OK? > Does it work well with 'my' kernels? > (I do not know hal) Let's look at the output of "hal-device" as I already suggested in comment #11.
Created attachment 363370 [details] hal-device log
There's no occurence of the words "input", "evdev" in the listing. That means hal does not see your input devices. What's the output of this?: ls -l /sys/class/input/ Does your kernel even have CONFIG_INPUT_EVDEV enabled?
# ls -l /sys/class/input/ total 0 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 event0 -> ../../devices/LNXSYSTM:00/LNXPWRBN:00/input/input0/event0 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 event1 -> ../../devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input1/event1 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 event2 -> ../../devices/virtual/input/input2/event2 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 event3 -> ../../devices/platform/i8042/serio0/input/input3/event3 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 event4 -> ../../devices/pci0000:00/0000:00:02.0/usb2/2-4/2-4:1.0/input/input4/event4 lrwxrwxrwx 1 root root 0 2009-10-01 18:24 event5 -> ../../devices/platform/pcspkr/input/input5/event5 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 input0 -> ../../devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 input1 -> ../../devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input1 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 input2 -> ../../devices/virtual/input/input2 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 input3 -> ../../devices/platform/i8042/serio0/input/input3 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 input4 -> ../../devices/pci0000:00/0000:00:02.0/usb2/2-4/2-4:1.0/input/input4 lrwxrwxrwx 1 root root 0 2009-10-01 18:24 input5 -> ../../devices/platform/pcspkr/input/input5 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 mice -> ../../devices/virtual/input/mice lrwxrwxrwx 1 root root 0 2009-10-01 18:23 mouse0 -> ../../devices/virtual/input/input2/mouse0 lrwxrwxrwx 1 root root 0 2009-10-01 18:23 mouse1 -> ../../devices/pci0000:00/0000:00:02.0/usb2/2-4/2-4:1.0/input/input4/mouse1 # grep -i evdev .config # CONFIG_INPUT_EVDEV is not set
Automatic discovery of keyboards and mice in Xorg+hal depends on working evdev driver. CONFIG_INPUT_EVDEV is necessary. Fedora kernels have it enabled.
Hal did not log or display this message. Could this be changed? I will test with CONFIG_INPUT_EVDEV in 'my' kernels.
(In reply to comment #18) > Hal did not log or display this message. > Could this be changed? Hal does not care. It reports what it finds. Having no input event devices in the system is a perfectly acceptable situation, so nothing should be changed here.
Then how would the user know? Xorg sees hal is not OK and logs a bit. This message does not give enough info. hal needs no configuration (so far at least) and just works with what it has. So we need someone with know-how to tell about a kernel device driver that doesn't mention it's importance to hal. I am looking for a way to make this issue self-solving...
(In reply to comment #20) > Then how would the user know? The user is not supposed to run a misconfigured kernel in the first place. > Xorg sees hal is not OK and logs a bit. No. Hal is OK. It told Xorg correctly that there were no available input evdev devices. I am closing this as NOTABUG.