Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 30

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

  1. #11
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,788

    Default

    That's excellent news! More stuff that no one needs is getting removed at last. I hope the maxcpu support will be raised to 256 millions CPUs soon to nicely complement the loss of HAL/DeviceKit.

    (I won't bother linking to the comic, bridgman, everyone knows it by now )

  2. #12
    Join Date
    May 2008
    Location
    Germany/NRW
    Posts
    510

    Default

    Quote Originally Posted by garytr24 View Post
    did the X guys consider using devicekit? what's the issue there?
    I guess the most obvious issue is (to me at least) the configuration of (input-)devices. For example my keyboard usually defaults to an us-layout when I'm using the evdev-driver, so to change this I had to edit some ugly xml-ish Hal-configfile because it would ignore the settings in my Xorg.conf. If everything is done by X itself all config-files will finally be in one place again.

  3. #13
    Join Date
    Jun 2008
    Posts
    165

    Default

    Quote Originally Posted by colo View Post
    All this is plain crazy imho - I don't see why HAL was such a bad piece of software to begin with. It's an established quasi-standard that managed to settle, and it was even available on non-Linux (at least on FreeBSD, to my knowledge) systems. Now everyone's going back to reinvent the wheel to make bootup a tenth of a second faster. Am I the only one thinking that's kinda stupid?
    I think you should at least use Google before wondering why HAL is being replaced.
    If you search "DeviceKit" you get:
    http://fedoraproject.org/wiki/Features/DeviceKit
    which in turn brings you to:
    http://lists.freedesktop.org/archive...ay/011560.html

    I think the second link is quite informative.

  4. #14
    Join Date
    Oct 2008
    Posts
    60

    Default

    Well, I always hated HAL for causing me nightmares (as a Linux veterant who lived fine before it). But I somehow understand why it was good for "Linux On The Desktop". I was making things "plug n' play".

    Udev is great, but lack some kind of dinamic policy and understandable syntax for less advanced users. I want to state it, FDI are ugly and override many settings like network, xorg.conf and modprobe.d (less frequent). So it caused me a lot of trouble, mainly with: synaptic, touchscreen, multiple keyboard, trackwheel, mouse acceleration, custom screen resolution, dbus lockup, various deadlock, making devices unusable until reboot after unplugging them, kernel panic (when my DVC-150b is plugged) and probably some other minor problem. It is why I removed it before it was dropped. It was a pain and I uderstand why a bunch of real code linux devs would want to drop it. It was annoying and buggy.

    But now, how is everything going to work? We are going to go back to duplicated, highly OS specific code in every applications? I think it is worst, because now we have no choice. We can't just drop things and go manually as there will be no unified framwork anymore. It is going to be software by software with minimal automated D-Bus communication...

  5. #15
    Join Date
    Jul 2009
    Posts
    264

    Default

    Quote Originally Posted by elanthis View Post
    At the very, very least, put the input handling code into a library, put the device files into something non-X-specific, and make it reasonable for other projects to reuse the data instead of making yet another X-only abstraction that has nothing X-specific about it. :/
    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.

  6. #16
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    956

    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?
    I hear you on this one. Seems when projects start changing things wholesale, its gonna cause a lot of angst in the community

  7. #17
    Join Date
    Mar 2009
    Location
    Hellas
    Posts
    1,033

    Default

    Quote Originally Posted by DeepDayze View Post
    I hear you on this one. Seems when projects start changing things wholesale, its gonna cause a lot of angst in the community
    Yeah the same with when projects stay static for too long. Humans my friend... humans... And a community has a lot of them...

  8. #18
    Join Date
    Sep 2006
    Location
    PL
    Posts
    910

    Default

    For example my keyboard usually defaults to an us-layout when I'm using the evdev-driver, so to change this I had to edit some ugly xml-ish Hal-configfile because it would ignore the settings in my Xorg.conf. If everything is done by X itself all config-files will finally be in one place again.
    i liked that. it was easy to grasp and it worked.

    i had one pc that was in a pretty special situation:

    usb keyboard - czech layout
    usb barcode scanner - us layout (because if you press digits in czech layout, you get various czech letters)

    with hal it was faily-easy to do such dynamic per-device config. even if one of the two devices was connected via ps/2 . i hope that the new solution would not result in loss of such possibilities.

  9. #19

    Default

    Quote Originally Posted by RealNC View Post
    That's excellent news! More stuff that no one needs is getting removed at last. I hope the maxcpu support will be raised to 256 millions CPUs soon to nicely complement the loss of HAL/DeviceKit.

    (I won't bother linking to the comic, bridgman, everyone knows it by now )
    Who said we'll loose DeviceKit?

    Btw. this comic is about something else... Someone should make a comic about fglrx which can't display a video without tearing.

  10. #20
    Join Date
    Jun 2009
    Location
    Elsewhere
    Posts
    89

    Default

    Quote Originally Posted by phoronix View Post
    [...] the migration away from HAL will likely be completed in time for X Server 1.8...
    As long as they don't screw us with XML anymore...

Posting Permissions

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