Announcement
Collapse
No announcement yet.
Martin Takes His Mesa Issues To The List
Collapse
X
-
Originally posted by locovaca View PostSince they had already provided KWin notice that they were doing it wrong, why do they have to stay up to date on all of the downstream code and follow up to make sure that KWin was really updated?
Comment
-
Originally posted by TheBlackCat View PostUpdated to do what? As I said, they didn't provide a feasible alternative.
- use the GL 1.5-ish code paths by default (which worked on all drivers) and make GL 2.x code paths a user option
- use a (DX9-ish) subset of GL 2.x which could be supported on all of the hardware where that level of support was exposed
- use a small set of functional tests rather than blacklisting, discussed with driver devs to use what "should work", driver devs would prioritize anything that crashed those tests
- work with the driver devs to identify a set of extensions/levels which could be used to identify drivers that would work well with KWin
- in the worst case, whitelist for GL 2.x code paths rather than blacklistTest signature
Comment
-
I don't know how you do function tests with partly unstable drivers? Like for example nouveau, when i try the dx10+ cards then these work fine. dx9 however have got no problem with basic kde effects, but as soon as i try a game (with kernel .39) then the driver will crash. So how does your function check look like in that case? Test something and see if there is kernel oops? Something similar you find with other drivers certainly too, on some days r600g git was extremely unstable too... The best way is to know first that the driver works, therefore whitelisting is not that bad. Of course using an environment var to disable the opengl checks is a bit complicated. At least when you don't know it - usually you can not see in any gui use this var to override those settings. With kde 4.4.5 there was at least a menu option that disabled those checks. In case of bad drivers (which did not fully crash the system) you could at least press alt+shift+f12 to get from a black screen to 2d desktop. Of course if your system crashes after login you have to find the configfile to disable the setting, also not that simple... In a perfect (driver) world everything would just work and be stable as advertised, but in reality this it not always the case.
Comment
-
Originally posted by Kano View PostSo how does your function check look like in that case? Test something and see if there is kernel oops?
Originally posted by Kano View PostSomething similar you find with other drivers certainly too, on some days r600g git was extremely unstable too...
Originally posted by Kano View PostIn a perfect (driver) world everything would just work and be stable as advertised, but in reality this it not always the case.Test signature
Comment
-
Originally posted by Kano View PostIt depends, when you look at debian i would not say that sid is the best branch. It is ok, when you are experienced and you can handle the things which usually happen. But is a pain to support lots of others which ran in into problems. I did that and it was no fun at the end. Also debian got maybe a bit outdated too due to the long freeze. I do not use arch (or gentoo) however, but i prefer the way of selected backports. I have got no problem when there would be a kde 4.x backport repo. It just has to install without problems. It is basically a good thing when you have got a stable system you can base your updates on. Of course not every package will be the latest one possible, but is that really needed? I had to patch a handfull of lines to compile nouveau with xserver 1.7. I get most likely the same speed as when you run 1.10, so what did you gain?
Comment
-
Originally posted by smitty3268 View PostNo he hasn't, and he's said he won't do so in a stable KDE release because of the possibility of regressions. So he's waiting for KDE 4.7.
Ubuntu has fixed the issue by patching Mesa to add GEM back into the intel driver string. Apparently the Fedora guys want an actual fix, so it's not yet clear if they will create the patch themselves or if KDE will make one for 4.7 and Fedora will just backport it.
Comment
-
Originally posted by kraftman View PostThe point is they test drivers if they work with gnome, but it seems they don't do the same when comes to KDE. KWin developer at least tests some drivers on different platforms (not that much, though) thus he's able to make some blacklists.
And this is not true. If he would care only about nvidia there won't be any white and blacklists.
I'm not able to change a thing and devs are free to do what they want. I simply said what I think. If os drivers will be crashing in KDE I'll simply switch.
Comment
-
Originally posted by locovaca View PostSince they had already provided KWin notice that they were doing it wrong, why do they have to stay up to date on all of the downstream code and follow up to make sure that KWin was really updated? You seem to think Mesa devs have nothing better to do so they might as well follow up on every project that might use their libraries. Mesa served notice that KWin was doing it wrong; at that point KWin should've fixed their code OR asked for clarification. Neither happened.
People have a hard enough time keeping up with their own code to have to consider how people downstream might be misusing their code.
The drivers are supposed to report what features they support, and Kwin tried to do the right thing by querying the drivers. However some drivers crashed when queried. Other drivers would claim to support features, then crash when those features were used. To work around these mesa flaws Kwin instead used the drived identification strings. The mesa devs complained about this, but didn't offer Kwin any workable alternatives.
Comment
Comment