Announcement

Collapse
No announcement yet.

Intel Mesa Gives Problems With KDE's KWin, Again

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

  • mdias
    replied
    wtf.. checking on a renderer string to make assumptions? realy!?

    I believe the best way to handle this is to make the DE check the speed and availability of the needed operations on the active driver whenever it changes.

    Leave a comment:


  • Nille
    replied
    Kwin do it again

    BTW. AMD/ATI is not mentioned because no one from KDE test there Stuff on AMD/ATI and if only on an old Code Base.

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by marek View Post
    There are better ways of detecting those than some random string that happened to contain "GEM" by luck.
    Such as...?

    Leave a comment:


  • pingufunkybeat
    replied
    Marek, how would you test correctly if a driver provides appropriate functionality?

    It is known since the last KWin fiasco that you can't trust the advertised functionality, and checking for direct rendering is also a hack which doesn't even work anymore. Blacklists caused their own set of problems, and if there is no check, KWin will crash all the time, like 4.5 did.

    What is the correct way to check this?

    Leave a comment:


  • marek
    replied
    Originally posted by AnonymousCoward View Post
    Oh right, so now it's the kwin developers' fault that the free graphics driver developers fucked up once again?
    They didn't fuck up at all. The Intel devs only changed the renderer string. It's a valid change, a normal one, it may happen from time to time and apps shouldn't rely on it. On the other hand, detecting KMS/GEM/DRI2 via some string in OpenGL is clearly a hack. There are better ways of detecting those than some random string that happened to contain "GEM" by luck. (I am surprised too that someone parses that string.)

    Anyway, the fact the driver devs haven't tested it is, of course, their fault. But the real problem lies in the Kwin code, Martin has even admitted that with the code snippet in his blog post. It's pretty clear that hacks like that would cause breakage sooner or later.

    Leave a comment:


  • energyman
    replied
    intel driver devs fuck up all the time. Just look up Linus' rants whenever they drop a load of crap into the kernel.

    They could also learn a lot from the kernel: never change behaviour expected by the userspace.

    Such a change in a point release is more than stupid. Once again intel's devs fucked up.

    Leave a comment:


  • pingufunkybeat
    replied
    I don't know how well that works, but KWin needs OpenGL 2 functionality for some things, so even hardware-accelerated drivers using old codepaths don't work -- that's why they're checking for DRI2. Only Intel does not list DRI2 in the renderer string either, so they tested for GEM, which got removed.

    Grepping the renderer string is an old evil which broke many things in the past, even 10 years ago, but there is simply no good way to test what the driver actually supports today, and that's a problem.

    With KDE 4.5, KWin made changes which broke things on Mesa drivers and were (rightly) criticised for not testing with open drivers. They said that they trusted the drivers about the functionality they advertised, but didn't implement.

    This time, Mesa devs made changes which broke KWin, and KWin guys did not even know about it until it hit Ubuntu repositories.

    Leave a comment:


  • curaga
    replied
    Hm, right. In that case, how about the driver name (as output by xdriinfo)? Parsing that ought to be easier, with only three (AFAIK) software drivers.

    Leave a comment:


  • pingufunkybeat
    replied
    Software rasteriser uses direct rendering, so checking that is completely pointless.

    What KWin needs to do is whether GL is hardware-accelerated, and there is no way to check that. Even in forums when people debug driver issues, people look at the renderer string.

    Martin is a volunteer and has my thanks for all his hard work. He also rants a lot, which is sometimes unfortunate. But the sad fact is that Intel released a driver which broke KWin, one of the most important applications in Linux. They either

    - released a driver without even testing whether it works, or
    - released a driver although they knew it would break the desktop for many users, and didn't tell anyone.

    Either way, it's very very unfortunate.

    Leave a comment:


  • curaga
    replied
    For the record, there appears to be a nice function called glXIsDirect, which is what glxinfo uses.

    Leave a comment:

Working...
X