The day has come!
Yesterday I dropped the superfluous hal dependency from gparted, today I uploaded gdm to stop using hal for getting the keyboard layout and use libxklavier instead.
I also applied Julian Cristau’s udevified X.org branch to our xorg-edgers packages into my halsectomy PPA, created some udev rules for udev-based X.org input detection ([1], [2]), and off we go: that was the last hal reverse dependency. My system now fully boots and works without hal.
Related posts:
- hal-sectomy continues The migration away from hal continues. Yesterday I uploaded new...
- DeviceKit update, future handling of Fn key maps I recently started working on packaging pieces of the new...
- gvfs: Buh-bye, hal! In the merciless vendetta for purging hal we now reached...
- Interrogation with Apport hooks / Qt developer needed So far, Apport package hooks were limited to collecting data...
Ähnliche Artikel bereitgestellt von Yet Another Related Posts Plugin.
#1 by David Nielsen on 2009/11/27 - 14:23
Zitieren
Congratulations on reaching this important milestone I know this took a lot of hard work and testing, I look forward to seeing it on a Ubuntu near me. Thank you for taking the time to do this.
However for the next time there is a big plan to radically change underlying technology upon which we rely and the claim is made that nothing will break, that they can live side by side during the transition.. please actually made sure that is the case and that previously working advanced but entirely correct uses of the old system aren’t entirely ignored:
Case in point, DeviceKitification of distros break iPod mounting for users of Banshee:
https://bugzilla.gnome.org/show_bug.cgi?id=586508
#2 by martin on 2009/11/27 - 14:26
Zitieren
This is great news. Thanks for doing this!
How about the “xvfb” utility from the xserver source package? I know that used to spit out some HAL error, does it work to launch “Xvfb :1″ on lucid now? ( see http://en.wikipedia.org/wiki/Xvfb )
#3 by bernot on 2009/11/27 - 15:31
Zitieren
hi,
searching your ppas with:
https://launchpad.net/ubuntu/+ppas?name_filter=pitti
does not show “halsectomy”
#4 by pitti on 2009/11/27 - 16:55
Zitieren
PPA link is in the original post.
#5 by pitti on 2009/11/27 - 16:57
Zitieren
I’m aware of the banshee situation, but so are the banshee developers. But that’s rather independent from the devkit-disks migration actually — as long as they still use hal, the package should depend on hal. However, hal is unmaintained now, so I hope they’ll switch over soon.
(It’s one of the reasons why we didn’t switch to banshee by default, too.)
#6 by pitti on 2009/11/27 - 16:59
Zitieren
I can start the server, and run “xeyes” on it. It doesn’t complain, but of course I can’t really see whether xeyes are working.
It still spits out a “(EE) config/hal: couldn’t initialise context: unknown error (null)” warning, but *shrug*.
#7 by martin on 2009/11/27 - 20:43
Zitieren
The error I get on karmic using Xvfb is this one:
(EE) config/hal: NewInputDeviceRequest failed (2)
(EE) config/hal: NewInputDeviceRequest failed (2)
(EE) config/hal: NewInputDeviceRequest failed (2)
(EE) config/hal: NewInputDeviceRequest failed (2)
(EE) config/hal: NewInputDeviceRequest failed (2)
(EE) config/hal: NewInputDeviceRequest failed (2)
If you can start up xeyes, that’s a step in the right direction I guess. I wonder why it’s printing these HAL warnings/errors though…
#8 by Zun on 2009/11/27 - 22:19
Zitieren
So now that I’ve finally figured out how to set up my keyboard preferences through an .fdi file I could just drop on any distro I’ll have to write udev rules to switch capslock to another ctrl and menu to compose?
Fuck this shit is getting annoying.
#9 by pitti on 2009/11/27 - 23:06
Zitieren
Why did you use fdi files in the first place? The installer/hal/etc. use /etc/default/console-setup for this, which is the definitive place for configuring this. That doesn’t change in the udev-based system.
#10 by pitti on 2009/11/27 - 23:07
Zitieren
(Of course gdm and GNOME allow a much more comfortable keyboard configuration, too…)
#11 by Zun on 2009/11/27 - 23:58
Zitieren
I used to just write my keyboard layout and settings into xorg.conf. When that no longer worked, I migrated it to .fdi. It’s something that used to work whether I used xdm/gdm/kdm or startx by itself. My keyboard layout is hungarian regardless of login manager and desktop environment. (qwertz during install and qwerty during login is a pain the ass.) Ubuntu isn’t the only distro I use, so while console-setup may be a solution here, dropping my preferred .fdi on a new install was rather convenient. Since hal is going away after such a short while, I’m rather disappointed.
#12 by Zun on 2009/11/28 - 00:20
Zitieren
Okay, so the above can be summed up as:
1. always having keyboard layout “hu” no matter what
2. always having the options “ctrl:nocaps,compose:menu” no matter what
3. there used to be a (somewhat complicated) distro-agnostic way of setting this up, that is likely to get removed from most distros shortly.
#13 by Tobias on 2009/11/29 - 12:16
Zitieren
Not that it matters much, but the name »hal-sectomy« is a misnomer.
Ectomy comes from the greek »εκτομή«, not from the latin root of »sectio«. If that’s what you thought it comes from.
You might try to get away with it by arguing that it’s an odd germanic Fugen-s.
#14 by Tormod on 2009/11/29 - 12:40
Zitieren
Nice! I tested it, and it works pretty good. Getting rid of hal also cuts down my boot time from 38 to 35 seconds. But my touchpad is now hypersensitive and I can’t figure out how to tame it. And the power-button immediately shuts the system down, and the sleep button puts it to sleep without the fade-out and screen-lock. Well, I guess these things will be sorted out soon.
#15 by pitti on 2009/11/29 - 15:17
Zitieren
I actually intended it to come from the medical term “sectomy” which means something like “amputate”.
I had a quick look, and e. g. http://medical-dictionary.thefreedictionary.com/-sectomy seems to confirm that.
#16 by Tormod on 2009/11/29 - 15:34
Zitieren
I got the touchpad right by adding this to /lib/udev/rules.d/66-xorg-synaptics.rules:
ATTRS{protocol}==”AlpsPS/2″, GOTO=”touchpad”
ATTRS{protocol}==”SynPS/2″, GOTO=”touchpad”
GOTO=”xorg_synaptics_end”
LABEL=”touchpad”
#17 by Tormod on 2009/11/29 - 15:41
Zitieren
Yes, “halectomy” would probably be more correct. http://medical-dictionary.thefreedictionary.com/-ectomy
#18 by pitti on 2009/11/29 - 16:19
Zitieren
Tormod, the additional protocols were discussed with Julien a few days ago. I asked him to add those to his git tree. If there are too many, I’ll write a small udev prober to check the input capabilities to figure out which device is a touchpad.
The misworking sleep/power buttons are due to gnome-power-manager dieing:
– DBUS error: Could not get owner of name ‘org.freedesktop.Hal’: no such name
** (gnome-power-manager:7872): WARNING **: Either HAL or DBUS are not working!
I’ll look into that soon.
#19 by Tobias on 2009/11/29 - 22:39
Zitieren
Pardon my ignorance, but what is the new, sanctioned way to set input device properties now that fdi files went out of style?
I mean, I can set them via the xinput program, but how do I set them on every boot properly?
I need my little nipple mouse to emulate mouse wheeling, which gives the best scrolling experience ever.
#20 by pitti on 2009/11/30 - 10:24
Zitieren
It has always worked to put them into xorg.conf, of course. If you used fdi files, and want to continue to use something system-wide (as opposed to your ~/.profile) and non-xorg.conf, you can rewrite the hal fdi files into udev rules, which should be pretty straightforward with the already existing rules as examples.
#21 by Tobias on 2009/12/01 - 15:15
Zitieren
Thanks.
I don’t know why I don’t have an xorg.conf. I guess because I thought it also went out of style.
When I put the xinput commands in my .profile then the settings are lost when I resume the machine from suspend. And .profile is not sourced again.
I’m gonna try with udev rules.
#22 by Tobias on 2009/12/01 - 17:27
Zitieren
Martin, can you explain me which of the rules.d files I should use as an example? Would I use the IMPORT{program}= construct with a call to xinput?
Also, this thread seems relevant:
http://www.pubbs.net/xorg/200911/52990/
#23 by Tobias on 2009/12/01 - 19:23
Zitieren
Okay, I found the example in xorg_synaptics_quirks.
#24 by Tormod on 2009/12/03 - 12:10
Zitieren
Just want to share the rule modification needed with the latest udev:
ACTION!=”add”, GOTO=”xorg_synaptics_end”
KERNEL!=”event*”, GOTO=”xorg_synaptics_end”
ENV{ID_INPUT_TOUCHPAD}!=”1″, GOTO=”xorg_synaptics_end”
# trackpoints satisfy above conditions, too, so we need to check if the device
#25 by Tormod on 2009/12/03 - 12:11
Zitieren
D*mn, you already had updated the one in your link, Martin! Dismiss my previous post.
#26 by Tobias on 2009/12/16 - 21:20
Zitieren
I can’t get it to work. Udev rules have no effect:
http://www.alice-dsl.net/towolf/udev
#27 by pitti on 2009/12/20 - 16:30
Zitieren
Tobias,
the problem is that your rule assigns the properties to a parent device, not the eventX interface (which X.org looks for). Please try
ENV{ID_INPUT_MOUSE}==1, ATTRS{name}==”DualPoint Stick”, ENV{x11_options.EmulateWheel}=”true”, [...]
Please see https://wiki.ubuntu.com/X/InputConfiguration for some details.