Bug 524352 - hal does not work with Xorg: no keyboard mouse in gnome
Summary: hal does not work with Xorg: no keyboard mouse in gnome
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: hal
Version: 11
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-19 09:57 UTC by udo
Modified: 2009-10-01 18:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-01 18:19:12 UTC


Attachments (Terms of Use)
Xorg.log with `working` Xorg, no conf (103.28 KB, text/plain)
2009-10-01 13:17 UTC, udo
no flags Details
Xorg.log with `crashing` Xorg, no conf (104.97 KB, text/plain)
2009-10-01 13:18 UTC, udo
no flags Details
hal-device log (152.44 KB, text/plain)
2009-10-01 16:20 UTC, udo
no flags Details

Description udo 2009-09-19 09:57:42 UTC
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:

Comment 1 udo 2009-09-22 13:13:46 UTC
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.

Comment 2 Richard Hughes 2009-09-22 14:00:36 UTC
Surely this is an XOrg bug, right?

Comment 3 udo 2009-09-22 14:19:22 UTC
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?

Comment 4 udo 2009-09-22 14:20:56 UTC
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.

Comment 5 Michal Schmidt 2009-10-01 07:16:33 UTC
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?

Comment 6 udo 2009-10-01 12:54:20 UTC
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?

Comment 7 udo 2009-10-01 12:55:13 UTC
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

Comment 8 udo 2009-10-01 13:17:39 UTC
Created attachment 363321 [details]
Xorg.log with `working` Xorg, no conf

Comment 9 udo 2009-10-01 13:18:13 UTC
Created attachment 363322 [details]
Xorg.log with `crashing` Xorg, no conf

Comment 10 udo 2009-10-01 13:21:51 UTC
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

Comment 11 Michal Schmidt 2009-10-01 14:56:01 UTC
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.

Comment 12 udo 2009-10-01 15:05:37 UTC
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)

Comment 13 Michal Schmidt 2009-10-01 15:50:51 UTC
(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.

Comment 14 udo 2009-10-01 16:20:40 UTC
Created attachment 363370 [details]
hal-device log

Comment 15 Michal Schmidt 2009-10-01 16:35:14 UTC
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?

Comment 16 udo 2009-10-01 16:45:49 UTC
# 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

Comment 17 Michal Schmidt 2009-10-01 17:15:12 UTC
Automatic discovery of keyboards and mice in Xorg+hal depends on working evdev driver. CONFIG_INPUT_EVDEV is necessary. Fedora kernels have it enabled.

Comment 18 udo 2009-10-01 17:24:47 UTC
Hal did not log or display this message. 
Could this be changed?
I will test with CONFIG_INPUT_EVDEV in 'my' kernels.

Comment 19 Michal Schmidt 2009-10-01 17:46:04 UTC
(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.

Comment 20 udo 2009-10-01 17:55:47 UTC
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...

Comment 21 Michal Schmidt 2009-10-01 18:19:12 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.