Announcement

Collapse
No announcement yet.

Installing latest Open Source ATI drivers under Ubuntu 8.04

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

  • Originally posted by dungeon View Post
    Tormod, current packages for Hardy miss 'XInput.h'. That header is in Hardy original 'x11proto-input-dev' package, later that header was moved to 'libxi-dev' as i see, but that package was not also updated for Hardy.
    Thanks for the info. Yeah, those files moving around between packages make things complicated. I guess compiling an input driver on top of the current stack would fail then. The ones in the PPA were built before I pushed this x11proto-input-dev. But the server and video drivers build fine, so I don't worry too much. I don't plan on maintaining the Hardy packages much more, it's out of scope for xorg-edgers. It's just that I have an R500 card at work, where I still run Hardy...

    I could spin a new libxi-dev, but I don't want to risk breaking something and spending time on fixing it. However, if you make a new libxi-dev and test it properly, I could push it in

    Comment


    • No i'm not X debian packager, i just pass through dependency hell of installing xorg-edgers packages and when i got finally break default X and see server EXA improvements and other goods, i can't compile anything, heh... OK i can just move 'XInput.h' manually. Do you know which commit for 'XInput.h' is right for your x11proto-input-dev_1.9.99.3? I think up to this http://cgit.freedesktop.org/xorg/lib...676f6af4baa44b but not sure.

      Comment


      • Originally posted by dungeon View Post
        No i'm not X debian packager, i just pass through dependency hell of installing xorg-edgers packages and when i got finally break default X and see server EXA improvements and other goods, i can't compile anything, heh...
        You know, power users like yourself should be using Jaunty
        OK i can just move 'XInput.h' manually. Do you know which commit for 'XInput.h' is right for your x11proto-input-dev_1.9.99.3? I think up to this http://cgit.freedesktop.org/xorg/lib...676f6af4baa44b but not sure.
        Somewhere around "Bump to 1.1.99.1" should be fine, I am not sure about the two next ones. I guess anything later than "Add XInput.h file from inputproto package." would fix your issue. I just realize now how old the libxi in Hardy is (git Sept 07)...

        Comment


        • Yes it is pretty old, maybe should be better to just put 'XInput.h' to your x11proto-input-dev_1.9.99.3. I tried to do that and package seems to build... Don't know how proper this way is, but that deb works for me.

          https://launchpad.net/~smoki00790/+archive

          Comment


          • Originally posted by dungeon View Post
            Yes it is pretty old, maybe should be better to just put 'XInput.h' to your x11proto-input-dev_1.9.99.3. I tried to do that and package seems to build... Don't know how proper this way is, but that deb works for me.
            I have uploaded a new libxi which includes XInput.h. I hope everything will be consistent now - I will build a new xserver and some drivers later and we'll see.

            Comment


            • I see you have many build failures because of Xinput.h (couple days and also right now), so it is better for me to not test packages right now. Hope you should found out what goes wrong.

              Comment


              • Originally posted by dungeon View Post
                I see you have many build failures because of Xinput.h (couple days and also right now), so it is better for me to not test packages right now. Hope you should found out what goes wrong.
                XI dependency hell... I am not sure I get this sorted out this year. Anyway, the built packages should work fine (well I hope) but building new packages can fail.

                Maybe I'll give up finding a matching libxi and do it like you suggested, adding XInput.h to x11proto-input-dev instead. BTW, exactly which version of XInput.h did you use?

                Comment


                • http://cgit.freedesktop.org/xorg/lib...676f6af4baa44b

                  md5sum bce8d0f7ccda4b2854fceb2ab5548f7a

                  I was not tried to recompile xserver with that, but 'xf86-input-joystick-1.3.2' can compile and he works, i mean gamepad.

                  Comment


                  • Thanks. This was the greatest PITA ever. Seems like there was no proper way of solving this, I was going in circles with the version combinations (yes also the upstream "recommended" ones) and selections of Debian and Ubuntu patches.

                    Finally it seems to be alright, a new libxi which lives happily with x11-proto-input and even the xserver builds on it. I haven't however built a new input driver (evdev or your gamepad stuff) so I don't know if it's 100% fine. But the PPA is all green now, and I am typing this from a Hardy fully updated from the PPA.

                    Comment


                    • But XInput.h is missed again, so compiling is impossibile afterward.

                      Comment


                      • desperate lol ! That would be back to square one However, this one was easier to fix. We now have a libxi that really includes XInput.h, rebuilt xserver, -evdev and -synaptics drivers. Seems to work fine.

                        The first -evdev I tried complained about CARD8, which is now defined in Xmd.h, so I patched -evdev to #include it. I could also upgrade x11proto-xext-dev to fix this the proper way, but since xext is on the bottom of the stack, I will not touch it right now. Just for information if someone compiles something and stumbles into this...

                        Comment


                        • Not A Good Experience

                          I just tried to install the new radeon driver etc on Hardy too. I used the xorg-edgers repo, and yes, I did read the usual disclaimer.

                          There are broken dependencies, with XInput.h causing problems, as it now exists in 2 packages at once. This left my system in an unusable state, as half of the packages were not installed. I had to manually restore all the packages to the state they were before. Woohoo, I love spending time fixing things that should never have been broken in the first place.

                          It is simply not good enough to say : We Don't Offer Any Guarantees Here. Nor is it good enough to say : Well Why Don't You At Least Use Intrepid. The fact of the matter is this - on this and other forums, people are being encouraged to help the testing and evaluation process, by trying things out and reporting any observations, or even, heaven forfend, bugs.

                          This is not going to be possible if the repos are in an inconsistent state. So what I suggest is this - either completely REMOVE the hardy packages/repo, or fix the inconsistencies.

                          There is also the grave matter of moving files between packages. This is simply unacceptable. While I don't expect perfection and flawless operation of new code, I surely don't expect the packages to break an entire system, by that cavalier and disgraceful practice. If there are any file conflicts between competing packages, then you are supposed to either make diversions, or make sure that no such conflicts exist in the first place.

                          I was lucky. I know how to admin my system, and can repair things if absolutely necessary. Which places me in a very small minority of Linux users. Other people will simply give up on Linux entirely, when faced with such difficulties.

                          On the plus side (!), it is good to see that the open source side of ATI things is really picking up speed. Let's not spoil things by making the whole development process look shoddy and feckless.

                          Comment


                          • Originally posted by gordboy View Post
                            I was lucky. I know how to admin my system, and can repair things if absolutely necessary. Which places me in a very small minority of Linux users. Other people will simply give up on Linux entirely, when faced with such difficulties.
                            IMHO only this small minority (and I would argue it's not that small) should be using bleeding edge things. If you don't know how to repair your system then you shouldn't use anything beside the stable branch, that is unless you are willing to learn how to repair it.

                            Comment


                            • I've got an odd one with the latest drm-modules and xorg-edgers updates on an ATI X1550 card. Everything works fine with the default settings (XAA), system is stable and runs as normal.

                              Enabling EXA in xorg.conf causes X to crash, however... but only AFTER booting up fully, displaying the desktop, loading menu bars, etc... it appears that everything is going to be fine and then boom, X crashes and Ubuntu does its typical over-and-over attempts to start X and fails.

                              Has anyone else run into this? I'm thinking it may be a specific userspace package of some kind that is crashing the party. I didn't see anything in the Sessions startup list that looked suspicious, though. I'm not running compiz.
                              Last edited by Porter; 12-22-2008, 09:49 AM.

                              Comment


                              • Does anyone else have the problem that (K)Ubuntu 8.10 doesn't stop requesting EDID information? My Xorg.0.log is getting longer and longer and longer, but the driver (self compiled RadeonHD 1.2.4 with EXA and DRI enabled) is running fine. I've got the same problem with Radeon 6.9.0 which is the default one I think...

                                Comment

                                Working...
                                X