Announcement

Collapse
No announcement yet.

The X.Org Plans For Moving Away From HAL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    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 )

    Comment


    • #12
      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.

      Comment


      • #13
        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:

        which in turn brings you to:


        I think the second link is quite informative.

        Comment


        • #14
          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...

          Comment


          • #15
            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.

            Comment


            • #16
              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

              Comment


              • #17
                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...

                Comment


                • #18
                  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.

                  Comment


                  • #19
                    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.

                    Comment


                    • #20
                      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...

                      Comment

                      Working...
                      X