[gentoo-amd64] Re: ATI driver conflict with xorg-server

[Duncan]

Daiajo Tibdixious posted on Thu, 06 Oct 2016 15:57:10 +1100 as excerpted:

> Doing this on phone as chromium update still going (in console mode).
>
> Ati-drivers-15.12-r1 requires xorg-server-1.17.4 or less, yet world
> update insists on pulling in xorg-server-1.8 which then pulls in masked
> versions of xf86-input-evdev & xf86-video-ati & and the emerge dies
> because the 2 versions of xorg-server can't co-exist.
>
> I want ati-drivers as my led screen does not look good with basic radeon
> driver.
>
> I am wondering why masked versions are being pulled in as nothing in
> package.accept_keywords nor package.unmask
>
> In world I just have xorg-x11 meta package. I'm wondering if I should
> replace that with specific packages. The ebuild does not suggest its
> pulling in the 1.8 version, but I may be miss-reading it.
>
> I have manually installed the latest stable versions of the affected
> packages & expect it to work.

I know you're on the phone, but please disable HTML mail for the mailing 
lists, at least.  Also, on phone or not, shouldn't affect your ability to 
quote and then reply in context, /under/ the part you're referring to, 
instead of above it, entirely out of context.

Did you really mean the very old xorg-server-1.8, which you specified 
twice so I'd ordinarily think so, but it's _really_ old, older than the 
oldest 1.12.4-r5 in the main tree, so it's hardly a sane guess, or the 
newer 1.18.x?  1.8, whatever graveyard you might be pulling it from, is 
certainly < 1.17.4, tho, while 1.18.x is certainly not...

Assuming you mean 1.18.x...

You're running into two incompatible requirements, causing emerge to die 
in ordered to let you resolve things manually, as it can't figure out an 
automatic resolution.

1) The xorg drivers (xf86-*) must be built to match the xorg-server 
version they will be running with.  For minor upgrades, this is usually 
just an ABI incompatibility and the the same driver versions can be 
rebuilt to match the new server version, but the xorg-server jump to 1.18 
is an API jump as well, and requires newer versions of the drivers that 
can handle that new API.

So that's what's pulling in the newer drivers.  You can't upgrade the 
server to 1.18.* without upgrading the drivers as well.

2) One of the problems with proprietary drivers is that they often lag 
freedomware development in support of new APIs by some time, forcing 
distros (and on metadistros such as gentoo that offer multiple versions 
to choose from, users) to choose between holding back in ordered to 
accommodate those still using the lagging proprietary drivers, at the 
expense of allowing those using all freedomware use of the bugfixes and 
newer features available in current versions, or moving forward at full 
freedomware API change speed for those with all freedomware, while 
inconveniencing and occasionally entirely dropping support for those who 
choose to use proprietaryware that doesn't support the newer APIs.  And 
unlike freedomware, the community can't do anything to bring the lagging 
proprietaryware support for the new APIs because it's proprietary and 
won't let them at it -- the proprietaryware developers must do it 
themselves, and hold hostage anyone using that software to their own 
whims and schedules as to when that might be, including never, because 
the code isn't available to the community for people to either make those 
changes themselves or to pay someone else to do it (perhaps with a 
kickstarter project or the like) if they can't.

This is what's happening here.  Your ATI driver doesn't yet support those 
new APIs in xorg-server-1.18.x, and thus won't load if you try to force 
the driver to run with the new server.


Now normally, when faced with such a case portage will recognize that the 
two versions can't be installed together and that your ati drivers only 
work with the older version, and will resolve the problem by dropping the 
newer version of xorg-server.  However, in this case it's not doing so, 
possibly because something else (shouldn't be the xorg metapackage, but 
might be a newer version of... something else) actually requires the 
newer version, or possibly due to some other bug.

Regardless, your only choice to keep your ATI driver working, unless 
there's an upgrade to it you can unmask, is to continue with the older 
xorg-server-1.17.x.  You may still be able to upgrade the other xorg 
drivers (the xf86-* stuff), or may not, but even if you can keep them, if 
they were built against xorg-server-1.18.x, you'll have to rebuild them 
against the older 1.17.x once it's remerged, in ordered to get them to 
work with it.

Of course your other choice is to try the latest radeon or amdgpu driver 
and see if it fixes the LED issue with your monitor that you mentioned, 
allowing you to drop the proprietaryware ATI driver.  If you haven't 
tried it in awhile, it may indeed be fixed.


Meanwhile, the easiest way to ensure that portage doesn't consider xorg-
server-1.18, if you decide you need to stay with the ATI driver and 
there's no upgrade yet to it to work with 1.18, would be to package.mask 
=xorg-server-1.18* (or similar).  Just don't forget to unmask it once a 
newer ATI driver that supports it is available. =:^)

Of course as mentioned, since you've already manually tried 1.18 and the 
other driver upgrades, you'll have to either rebuild them as well, or 
downgrade them too, once you downgrade back to xorg-server-1.17.x.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman