The X.Org Plans For Moving Away From HAL

[Xheyther]

We tried to do that originally, but in the end nobody even pretended to care, so we're just doing our own thing again. Oh well.

It's curious.
x.org somehow lacks devs, testers and so on. As that means (to you) nobody care, you come back your own soup, so even if someone care and want to help he couldn't (remember it's your own thing).

This is madness, I believe.

[DanL]

Doesn't it make you wish there was a "Reach out and bitchslap someone" button in mailing lists?

You would probably be on the receiving end of this button a lot more than you think (as would I).

[bash]

I don't understand why lots of people are whining so much about this change.

If you look here, you can see what is currently planned to replace the different parts of HAL:

http://www.x.org/wiki/XorgHAL

When it comes to user-specific configuration they want to move from .fdi files (Which lots of people complained about) back to edititing the good 'ol xorg.conf.

When it comes to the input driver files they also want to move from the .fdi files, to a new directy called xorg.conf.d in which the driver files can be put. And from what I understand from reading through the mailing lits these files will also use the same syntax as the xorg.conf.

So IMO from a user "that-wants-to-edit-something" point of view this seems like an improvement. I prefer the syntax of xorg.conf over the fake XML-ish syntax of .fdi files.

And furter it currently seems like whatever will be in the xorg.conf will override the bits in xorg.conf.d, so you'll have only one file where you can put all your specific changes, instead of needing to find the specific .fdi file.

This is how I currently understand the changes and I don't see why should be so bad.

[Adarion]

As long as they don't screw us with XML anymore...

LOL. Ah the "good old" dfi files.
I so like(d) xorg.conf. I mean, yes, it could grow in size but HAL with all these single fdi files with their horrible batch of XML around the actual options just drove me crazy. And HAL sometimes kinda messed up, and nothing would work. And when the HAL project is not being in development anymore, well, then things just have to change somehow.
I just hope the change will come without larger bumps and holes on the road. :/

[Wyatt]

Happy day! New kernel and my nemesis, HAL, is going the way of the Dodo inside of six months. I've been waiting for this announcement with bated breath, I assure you.

[yoshi314]

Doesn't it make you wish there was a "Reach out and bitchslap someone" button in mailing lists?

just a little bit of faith will do the trick :

http://www.myconfinedspace.com/2006/01/03/punch-to-the-faceover-tcpip/

[skarllot]

We tried to do that originally, but in the end nobody even pretended to care, so we're just doing our own thing again. Oh well.

Why not do your own thing as DeviceKit-input?
Not are DeviceKit-disks and DeviceKit-power extensions from DeviceKit?

[daniels]

Why not do your own thing as DeviceKit-input?
Not are DeviceKit-disks and DeviceKit-power extensions from DeviceKit?

Two reasons: firstly, davidz made it extremely clear that DeviceKit would have nothing whatsoever to do with input and was just for device enumeration[0]; secondly, because the name to use this week is u* (e.g. udisks, upower), and uinput is already taken.

[0]: And formatting/labelling disks, setting up RAID, etc ... oh well, I guess it's just what he's interested in at the end of the day.

[aaahaaap]

Two reasons: firstly, davidz made it extremely clear that DeviceKit would have nothing whatsoever to do with input and was just for device enumeration[0]; secondly, because the name to use this week is u* (e.g. udisks, upower), and uinput is already taken.

[0]: And formatting/labelling disks, setting up RAID, etc ... oh well, I guess it's just what he's interested in at the end of the day.

What's posted here seems to imply a devicekit-input (or whatever it should be called) would be an option if someone would step up to do it.

http://lists.x.org/archives/xorg/2009-May/045582.html

Did the DeviceKit/u* devs state a reason they don't want to develop a devicekit-input?

Not having an OS-independent abstraction-layer would no doubt suck for the BSD's.

[AliBaba]

I'm using latest Xorg from Debian/experimental (or git, don't know) which starts to use udev only.

I had to recompile a few packages and get NetworkManager 0.8rc but ultimately I was able to remove HAL completely. No problems so far.