Page 3 of 3 FirstFirst 123
Results 21 to 30 of 30

Thread: The X.Org Plans For Moving Away From HAL

  1. #21

    Default

    Quote Originally Posted by daniels View Post
    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.
    Last edited by Xheyther; 12-03-2009 at 03:16 AM.

  2. #22
    Join Date
    Oct 2007
    Posts
    1,259

    Default

    Quote Originally Posted by deanjo View Post
    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).

  3. #23
    Join Date
    Sep 2008
    Posts
    39

    Default

    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.

  4. #24
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    769

    Default

    Quote Originally Posted by VinzC View Post
    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. :/

  5. #25
    Join Date
    Jan 2009
    Location
    Columbus, OH, USA
    Posts
    323

    Thumbs up

    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.

  6. #26
    Join Date
    Sep 2006
    Location
    PL
    Posts
    909

    Default

    Quote Originally Posted by deanjo View Post
    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/...aceover-tcpip/

  7. #27
    Join Date
    Dec 2009
    Location
    Brazil
    Posts
    1

    Default

    Quote Originally Posted by daniels View Post
    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?

  8. #28
    Join Date
    Jul 2009
    Posts
    261

    Default

    Quote Originally Posted by skarllot View Post
    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.

  9. #29
    Join Date
    Dec 2009
    Posts
    1

    Default

    Quote Originally Posted by daniels View Post
    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.

  10. #30
    Join Date
    Dec 2008
    Location
    Austria
    Posts
    31

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •