You are not logged in.
I am excited and proud to report that with xorg-server-udev from the AUR and the following /etc/udev/rules.d/75-x11-input-rules I have a perfectly working xorg in my laptop WITHOUT running hal and WITHOUT xorg.conf:
SUBSYSTEM!="input", GOTO="x11_input_end"
ACTION!="change|add", GOTO="x11_input_end"
KERNEL!="event*", GOTO="x11_input_end"
# use the evdev driver by default
ENV{x11_driver}="evdev"
# set xkb layout if we have keys
ENV{ID_INPUT_KEY}=="?*", ENV{xkblayout}="us"
# use synaptics for touchpads
ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{x11_driver}="synaptics"
ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{x11_options.TapButton1}="1"
ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{x11_options.TapButton2}="2"
ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{x11_options.TapButton3}="3"
LABEL="x11_input_end"
Actually I have removed hal from my system (I just needed to recompile pcmanfm without hal support, to remove the unuseful hal dependency from pmount, to upgrade to the latest, hal-free rc release of pm-utils for hibernation and suspension and to configure properly the autofs daemon; nothing else was dependent on hal in my system).
No more fdi files for me. The udev rules are not properly documented but much more readable to me.
The removal of hal brought away also the dummy devicekit stuff. Very happy.
Last edited by patroclo7 (2010-01-04 23:34:23)
Mortuus in anima, curam gero cutis
Offline
First, we had to configure xorg.conf for everything.
Next, we had to configure xorg.conf and configure hal fdi policies.
Next, we didn't have to configure xorg.conf at all since xserver 1.6 but had to configure fdi
Next, we don't have to configure anything at all since the switch to devicekit
Now there is this new changes with removing hal and depending on udevEverytime something changes - something breaks. And some time have to go by for everything to be patched and work correctly. And worst of all - they manage to patch things up just great and then - they change it again.
Well I'm personaly sick and tired of all of this...
Devicekit was a replacement for certain parts of HAL, it doesn't have anything to do with X.
Devicekit is supposed to replace the most commonly used parts of HAL, for things like input, X is one of the only apps that need it, so rather than implementing it in devicekit, it's being implemented in X itself.
Offline
Neat. However, I'm wondering shall we need to edit these files totally by hand in the future? If so, I think it's a regression. At least I still hope want an auto-detection plus a way like this to modify manually.
Archlinux x86_64 on Thinkpad T400
Intel X4500MHD / ATI HD3470 Graphics, 2G RAM, 160G HD
Offline
Devicekit was a replacement for certain parts of HAL, it doesn't have anything to do with X.
Devicekit is supposed to replace the most commonly used parts of HAL, for things like input, X is one of the only apps that need it, so rather than implementing it in devicekit, it's being implemented in X itself.
Seems that these is not a separate part called devicekit now. devicekit-disks and devicekit-power are used for removable devices and power management as previously provided by HAL. Other parts of HAL will be replaced by other subsystems such as NetworkManager, bluez, pluseaudio etc. These subsystems will use libudev directly to access kernel events, so as to provide hot-plugging support. This is my understanding.
This presentation might be interesting: http://blog.fubar.dk/?p=103
Archlinux x86_64 on Thinkpad T400
Intel X4500MHD / ATI HD3470 Graphics, 2G RAM, 160G HD
Offline
Neat. However, I'm wondering shall we need to edit these files totally by hand in the future? If so, I think it's a regression. At least I still hope want an auto-detection plus a way like this to modify manually.
My guess is that most things are autodetected. I had to define only my keyboard layout and the tap buttons for my touchpad, so the only difference with the hal system is the non-autodetection of the tap buttons (other things, such as vertical-horizontal scrolling are properly autoconfigured also using udev). I think that this small regression will be fixed by the synaptics xorg driver. The keyboard layout can also be defined per-user in .xinirc with setxkbmap, so at that point I could avoid completely to cope with udev rules.
Nonetheless, since my main problem with hal fdi files (and with devicekit too) was the lack of documentation, I hope that the exact options usable in the udev rules are going to be documented more properly for people who want/need to configure stuff.
Mortuus in anima, curam gero cutis
Offline
In the following post from the phoronix forum there is a more artuiculate touchpad configuration:
http://www.phoronix.com/forums/showpost … ostcount=8
Last edited by patroclo7 (2010-01-05 10:15:35)
Mortuus in anima, curam gero cutis
Offline
so the only difference with the hal system is the non-autodetection of the tap buttons
Actually that's a deliberate choice, no tapping by default if your touchpad has physical buttons.
And yeah, most things will be autodetected, like they are now. But for personal configuration, you won't need to mess with the overly verbose hal fdi anymore, we're back at setting things in xorg.conf. This blog post has the details: http://who-t.blogspot.com/2010/01/new-c … order.html
Offline
It seems that the following is actually enough for me(I define the keyboard layout in .xinitrc):
ACTION!="change|add", GOTO="touchpad_end"
KERNEL!="event*", GOTO="touchpad_end"
ENV{ID_INPUT_TOUCHPAD}!="1", GOTO="touchpad_end"
ENV{x11_options.TapButton1}="1"
ENV{x11_options.TapButton2}="2"
ENV{x11_options.TapButton3}="3"
LABEL="touchpad_end"
Last edited by patroclo7 (2010-01-05 10:34:33)
Mortuus in anima, curam gero cutis
Offline
And yeah, most things will be autodetected, like they are now. But for personal configuration, you won't need to mess with the overly verbose hal fdi anymore, we're back at setting things in xorg.conf. This blog post has the details: http://who-t.blogspot.com/2010/01/new-c … order.html
Nice read and nice news. However I have tried the following as /etc/xorg.conf.d/11-synaptics.conf, as /etc/X11/xorg.conf.d/x11-synaptics.conf and as /etc/X11/corg.conf, but no tapping, so I am back to the udev rule:
Section "InputDevice"
Identifier "touchpad"
Driver "synaptics"
Option "AutoServerLayout" "on"
Option "TapButton1" "1"
Option "TapButton2" "2"
Option "TapButton3" "3"
EndSection
Perhaps the conf.d directory is read only in latest development releases, or needs to be enabled in some way in ./configure?
EDIT: Yes. I have checked the xorg-server git log and the support or udev configuration and for the conf.d/*.conf splitted configuration files has been added in the last two weeks. I have tried to compile the git version of the server and drivers, but they do not work for me. So I am back to xorg-server-udev from the AUR.
Last edited by patroclo7 (2010-01-05 14:17:50)
Mortuus in anima, curam gero cutis
Offline
Developer blog on the new Xorg:
Setting Up a Scripting Environment | Proud donor to wikipedia - link
Offline
Developer blog on the new Xorg:
Nice read. Never had to edit an fdi file fortunately. Glad I will not have to in future thanks to the new InputClasses. The split xorg.conf.d setup sounds interesting too.
Offline
I am excited and proud to report that with xorg-server-udev from the AUR and the following /etc/udev/rules.d/75-x11-input-rules I have a perfectly working xorg in my laptop WITHOUT running hal and WITHOUT xorg.conf:
SUBSYSTEM!="input", GOTO="x11_input_end" ACTION!="change|add", GOTO="x11_input_end" KERNEL!="event*", GOTO="x11_input_end" # use the evdev driver by default ENV{x11_driver}="evdev" # set xkb layout if we have keys ENV{ID_INPUT_KEY}=="?*", ENV{xkblayout}="us" # use synaptics for touchpads ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{x11_driver}="synaptics" ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{x11_options.TapButton1}="1" ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{x11_options.TapButton2}="2" ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{x11_options.TapButton3}="3" LABEL="x11_input_end"
Great stuff dude, thanks a lot! Right now I use your config, everything works, but I have to do a little bit more for my touchpad to work the way I want. But that'll work by taking the lines of the fdi file and write them in udev's syntax.
I don't need hal anymore *happy* :-)
edit: Now after a reboot everything is like before with hal, except pmount-hal doesn't exist anymore after recompilation ... but that's fine, I can write the labels by myself :-P
Last edited by Army (2010-01-05 15:55:47)
Offline
This will not make much difference to me as I do not run the HAL daemon and have turned input hotplugging off. I liked that HAL detected mice and I was even ok when it forced me to use the evdev driver for those mice. However I had to keep using kbd for the keyboard because of the Printscreen / arrow key bug. None of the workarounds I tried worked so I just have to keep my mice plugged in. Maybe if Xorg has to rewrite the hotplugging code they will get it right next time and let me do it with just mice and not necessarily the keyboard.
Actually I hope everything that depended on HAL drops it. The HAL9 dialogue was funny at first until I realized that it fails to tell you what HAL is actually doing to your system and makes me not trust it.
6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.
Offline
In the forthcoming ubuntu 10.4 hal was completely removed.
Offline
In the forthcoming ubuntu 10.4 hal was completely removed.
With that, the "deprecation of hal" will be soon to come.
Offline