Installing latest Open Source ATI drivers under Ubuntu 8.04

[Porter]

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.

[val-gaav]

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.

[gordboy]

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.

[tormod]

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...

[dungeon]

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

[tormod]

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.

[dungeon]

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.

[tormod]

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?

[dungeon]

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.

[tormod]

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.