Announcement

Collapse
No announcement yet.

The X.Org Plans For Moving Away From HAL

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

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


            • #21
              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, 03:16 AM.

              Comment


              • #22
                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).

                Comment


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

                  Comment


                  • #24
                    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. :/

                    Comment


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

                      Comment


                      • #26
                        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/

                        Comment


                        • #27
                          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?

                          Comment


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

                            Comment


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

                              Comment


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

                                Comment

                                Working...
                                X