The renderer string does not contain "Gallium 0.4 on" anymore,
instead it directly contains the gallium driver's name.
So assume that every unknown renderer is a gallium driver.
Details
- Reviewers
graesslin - Group Reviewers
Plasma - Commits
- R108:e302f87598de: Properly detect Gallium drivers with newer Mesa
Added a testcase, it succeeds only with this patch.
Diff Detail
- Repository
- R108 KWin
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
I understand why not 5.8, but why not 5.11?
Is it ok if I use the resulting kwinglplatform.cpp in kscreenlocker's 5.11 branch?
I consider detecting for newer driver a feature.
Is it ok if I use the resulting kwinglplatform.cpp in kscreenlocker's 5.11 branch?
Yes, as there it is required for a bugfix.
I consider detecting for newer driver a feature.
That might make things more difficult for downstreams, however.
Yes, of course. That's an issue which has created problems for me for years. KWin releases and mesa releases are not synced. This results in KWin not having a chance to be tested against latest Mesa. Distros combine these things. Like here openSUSE apparently combines a two year old KWin with a new Mesa. Backporting is even more an issue. Because other distros might not have the new driver versions. And some changes in the past have been mutual exclusive. If such issues happen KWin master must be changed to require the newer Mesa version and explicitly break compatibility with older Mesa.
In the end the problem here is not that KWin code needs to be adjusted, but that Mesa devs still don't get that their version and renderer information is considered by downstreams as part of an API.
Yes, it was decided that the latest Mesa for Leap is useful for newer hardware. Not uncommon, I suppose.
Note that I'm mostly asking for Plasma/5.11 here. When KWin 5.11 got released, Mesa already had this behaviour. So it has always been broken.
Backporting is even more an issue. Because other distros might not have the new driver versions. And some changes in the past have been mutual exclusive.
This commit isn't.
If such issues happen KWin master must be changed to require the newer Mesa version and explicitly break compatibility with older Mesa.
Well, you can get the mesa version at runtime, so this can't really happen. It's ugly, but solvable.
In the end the problem here is not that KWin code needs to be adjusted, but that Mesa devs still don't get that their version and renderer information is considered by downstreams as part of an API.
Yes, but until that is the case, ignoring the problem isn't a workaround.