Arch Linux

I will build a version of xorg-server according to your suggestions and will try to estimate whether this change is worth enough to switch to the hal backend enabled.

Be sure that it runs fine when hal and/or dbus aren't started. I don't want to have bugreports because of a hal daemon that wasn't started.

Exactly.

@ the requester: a xorg-server built as you requested has been in testing for quite a while. are you happy with it?
@ the developers: is xorg from now on gonna have hal enabled? im asking cause in such a case im gonna start building my own without it. please let me know.
thanks

testing/xorg-server 1.4.0.90-7 works just fine for me.

Grigorios, may I ask you why you want it disabled? does the hal-enabled version work without hal started?

i dont know, i havent tested it without HAL started. the reason i want a HALless X server is i have no use for HAL in general and i want to stay HAL free for as long as possible. HAL is only useful if you use a file manager that supports it IMO. And BTW i voted for this FR by accident :P

The point is that input configuration is not flexible when hal is enabled. And as most desktop users have hal enabled, their configuration is not flexible. XInput at this moment is in really bad shape, which will change by April 2009 or something like that. Please stick to something "proven" that "works", don't introduce new crap until XInput has been fixed.

"HAL is only useful if you use a file manager that supports it IMO"
you seem to have a very narrow view of what HAL is for... HAL is just a unified (across OSes) hardware query system. if it were solely for file managers, it wouldn't even exist.
anyway, X starts just fine for me without hal started.

"input configuration is not flexible when hal is enabled"
please elaborate. to me it's much more flexible that way, as I can have different options for each one of my input devices based on any hardware information available thanks to hal key matching. this is hopeless in xorg.conf (notably given evdev Name & likes options are broken, since they tried to reinvent what HAL already does, and failed at it), so one has e.g to write some udev rules to create some fixed device node which will anyway be enumerated and opened by X only on X startup, and lost on device unplug. this is not viable on my laptop situation.

that said I am not in the process of pushing things into people's computers, especially if they feel they don't need it. so I never expected to see this in core anytime soon. yet I need it and it seems that other people do, and it seems like testing is a good testbed for this, ironing issues out for the future.

attached file manually disables X11 keyboard information in hal. place it in /etc/hal/fdi/policy.

if xorg server is co;piled with hal, xorg.conf is a fallback for when hal information is not available for a given device.
this way, since the file removes X specific information from hal, X will use xorg.conf configuration for keyboard, even if hal is started.

you can do the same for mice and other devices. with key matching you can even do it selectively, so that some device use hal and some use xorg.conf.

alternative is to remove /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi and maybe /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi

so current status for me is:
- hal not started : xorg.conf is fully used (just as before)
- hal started+x11 info: defaults to hal info for config, fallbacks to xorg.conf
- hal started+removed info: ignores hal, uses xorg.conf

I guess we can make everyone happy...

sounds interesting, I cannot test this though, because hal-enabled xorg respects my xorg.conf anyway