Slashdot Mirror
KDE Plasma 5 Problem Traced To Bug In Intel Graphics Driver
prisoninmate writes with news that certain complaints about the KDE Plasma 5 desktop environment may not be KDE's fault at all:
Apparently, KDE Plasma 5 runs just fine, and the issue is related to a serious Intel Graphics Driver Stack bug. The good news is that a workaround for the bug is already available, and it requires you to modify the /etc/X11/xorg.conf.d/20-intel.conf file from your Linux kernel-based operating system, by switching back to the older UXA acceleration method instead of the default SNA method used in many distros.
Some of have SystemD and don't have /etc/X11, you insensitive clod!
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
...and I still think that plasma 5 is not ready for prime time (to put it mildly)
I feel a bit bad now, because around week/two weeks ago I managed to find it out by myself that switching to UXA fixed the crashes on my machine. Looks like I should have made some fuss about it!
Once a upon a time, Intel used to be the answer to users questions about which graphics hardware would work best on a new linux installation. It was never the fastest hardware, but it had the reputation for being the most stable with adequate performance for ordinary desktop use. That doesn't seem to be the case anymore with high performance desktop shells exposing more and more flaws with Intel's graphic stack.
Oddly enough ... desktops are rendered in graphics, and bugs cause strange behavior because nobody planned for them.
There's probably tons of things which can go wrong when your graphics driver has bugs in it.
Lost at C:>. Found at C.
... cause a crash when desktops are switched? All that does is move windows from onscreen to off and vice verca. What the hell is KDE doing with the X server than means this happens anyway?
Bugs like that are discovered when you actually starts using new features to render things more hardware accelerated. If no major application used it before, it is common to uncover bugs in drivers. The alternative though is not use new features.
You have to do it yourself.
If I were a KDE dev, I would write a display server in house, bundle it with LibreOffice, then roll the whole thing into systemd. Then we could finally ditch those pesky operating systems all together.
Just think of how easy ps output would be to read.
Oddly enough windows are moved around all the time. There must be something specific they're doing here wrt switching desktops since apparently the crash doesn't happen at other times.
Where do you get the idea that the crash doesn't happen at other times? I looked around and see reports from a month ago of XBMC on GNOME crashing on startup, and mpv player crashing after watching a video for a bit, all originating from the same point in the same driver. There's a bug in Intel's new SNA driver and this causes various failures in otherwise-working code which happens to rely on the driver; switching to Intel's older UXA driver fixes the problem.
By shooting a black kid?
Or did you mean George Zimmer?
(For comparison: George Zimmerman)
You are the one saying this is just a move. Did you write the code? Do you know what it does?
Or are you just naively deciding the bug must be in moving windows because that's what you think it is?
There's a lot of pieces to a window manager and a graphic driver.
Obviously, some of these are interacting and causing the crash. Saying must be something specific ... well, that's the nature of bugs, you have to do the right things to trigger them.
If it was "just moving windows", the crash would happen all the time. Which means it's probably more complicated than your oversimplified explanation.
Lost at C:>. Found at C.
just installed Kububtu 15 with plasma. yikes, there's no task bar or "start"-like menu anymore. How do I get back those interface features I'm comfortable with?
Some drink at the fountain of knowledge. Others just gargle.
Considering we had a Samsung firmware bug in TRIM that turned out to not to be an issue with Samsung drives, but with the TRIM code itself.
How about using glamor instead of uxa? Does that work around it too, or is the bug just so rare I haven't noticed it?
I run KDE plasma 5, have been using glamor for a long while, and am running the xorg-edgers drivers... and I haven't seen anything like the bug described at kde.org.
I'm going to regret asking but.. is KDE talking directly to the graphics drivers? I knew the situation with X on a programming level was bad but.. that bad?
Is that why starting with version 4 KDE has worked terribly (if at all) in VNC? Is it because it wants to talk directly to the hardware's drivers and VNC is something other than hardware?
- Forgive me if the KDE/VNC situation has improved, I stopped using KDE in part because of this over a year ago.
I agree. I've had nothing but trouble with Intel's graphics drivers compared to nVidia. Generally the nVidia proprietary drivers just work and work well.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
FYI I've written a window manager. Switching desktops involves nothing more than moving the correct windows on and off screen. You can't unmap them because that generates a different event which the applications might respond to incorrectly in the circumstances.
I've used KDE for a while, from 3 through 5. 4 worked really well and when I got the upgrade to 5, I thought that I finally had the perfect desktop - if it worked like 4 and looked like 5, I'd be ecstatic.
Unfortunately, I found it to be overall a little sluggish to start and that deteriorated over time to the often reported states of coming out of screensaver to a black screen with cursor for a minute before anything would show; a programs menu which would take 30 seconds to open the first time, no matter how long ago the machine booted - and 1-5 seconds thereafter; to finally booting to a black desktop with just a mouse cursor. Deleting cache files makes the problem simmer down a little, for a while, but they never truly to away and they creep right back up to full size within a few days.
I also had the applet that controls wireless refuse to ever connect to my AP after once inadvertently touching the flight mode toggle. I could connect from the cli, but no amount of pushing and prodding on the applet would get me there.
Not to mention that this isn't the first time it's the "gpu driver's fault". The built in dark theme only works on machines with great graphics cards. Older machines get a white-on-white panel.
And let's not forget the xembed debacle. Way to force your philosophical outlook on the people who can't change anything - end users.
I don't know what happened, but the kde guys, imo, lost the plot. I've had to switch to xfce to be able to use my desktop. I've ditched Linux for win10 in my laptop and have a fast boot and os. That ditch was done as a rage-quit of KDE because of the aforementioned wireless issues - I just had enough of trying to work around the beautiful, but ultimately brain-damaged plasma5.