| Summary: | multiple successive plasmashell and krunner crashes even though OpenGL drivers are installed on rv200 if "Enable compositor on startup" is enabled | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Felix Miata <mrmazda> |
| Component: | general | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED DOWNSTREAM | ||
| Severity: | crash | CC: | bhush94, kevin.kofler, mgraesslin, plasma-bugs, rdieter, simonandric5 |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 5.3.2 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | glxgears output | ||
|
Description
Felix Miata
2015-08-01 08:28:23 UTC
*** This bug has been marked as a duplicate of bug 350852 *** Both are same bug. *** This bug has been marked as a duplicate of bug 350852 *** If you want to reopen this, can you run glxinfo and paste results. Created attachment 93829 [details] glxgears output Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1249280 OK. We use OpenGL 2, which I can't see there. What hardware are you running? Edit, just seen in the downstream bug report. rv200 I got a plasma5 session to start without crashing after opening systemsettings5 in an IceWM session and deselecting "Enable compositor on startup". and then the shell with the panels and such worked? In plasma session: Configurable panel works. Application menu works. Systemsettings5 works. Konsole works. Ksnapshot works. KCalc works. Kcmshell5 xserver works. Konq works. Firefox 39 and esr17 both work. I don't understand. Plasmashell (the panels) shouldn't be working. The errors you got were in that application when it used OpenGL. Changing the window manager compositing shouldn't make any difference to that application. CC'ing one of the Window manager people for comments. Plasmashell normally works in Fedora (by using llvmpipe), thanks to this hack: http://pkgs.fedoraproject.org/cgit/qt5-qtbase.git/tree/10-qt5-check-opengl2.sh The thing is that the other stuff should also be working. We can discuss this in the downstream bug tracker, because the script was unfortunately not added to upstream Qt, only the flag it uses was. PS: See also https://codereview.qt-project.org/#/c/76992/ for the other half of the hack. KWin 5 should be using XRender compositing on this hardware, by the way. Is it possible that bug 317929 plays a role in this? I have 'Option "Composite" "Disable"' set in X config, yet it's been necessary also to set autoload=false for Module-kscreen to have it or xrandr startup commands obeyed. Disabling Composite in xorg.conf is a bad idea. It's no wonder that KWin compositing does not work if you have the Composite extension disabled. I also still don't know: * whether the plasmashell crash is gone for good now nor * why you had it on Fedora to begin with (Did you install mesa-dri-drivers within a running session? The xinit script only runs on X11 startup, so QT_XCB_FORCE_SOFTWARE_OPENGL gets set at that time. I did it this way because spawning glxinfo is a relatively expensive operation.) nor * why you had to install mesa-dri-drivers to begin with (it's installed by default on all our spins, isn't it?) nor * what other strange things (other than not having mesa-dri-drivers installed and disabling the Composite extension) you did to your Fedora installation. Can you reproduce any of the crashes on the unmodified Fedora KDE Live image? (In reply to Kevin Kofler from comment #16) > Disabling Composite in xorg.conf is a bad idea. It's no wonder that KWin > compositing does not work if you have the Composite extension disabled. I've had no luck finding any doc that reports Xorg enabled compositing is prerequisite to basic functionality using any version of Plasma. > I also still don't know: > * whether the plasmashell crash is gone for good now nor I think installing mesa-dri-drivers has made that crashing historical. > * why you had it on Fedora to begin with If you mean disabling compositing, years ago, some dev(s) invented new ways to annoy. As these new annoyances depended on compositing, once I discovered disabling compositing made the annoyances go away, I made a routine of disabling compositing, and as a bonus, found X to be faster so configured. I have well over two dozen Fedora installations 21 or newer. Their collective purpose is, as with other distros, testing what devs don't test, older, real hardware, rather than VMs running on fast recent hardware. Disabling compositing is routine post-installation activity here regardless of distro or hardware. If I don't do it, how will anyone find out before it's too late to fix when some evolutionary development has an unintended and unknown side effect of making compositing a requirement? > (Did you install mesa-dri-drivers > within a running session? The xinit script only runs on X11 startup, so IIRC, it's been years since I installed any Fedora package while X was running. :-) > * nor why you had to install mesa-dri-drivers to begin with (it's installed by > default on all our spins, isn't it?) nor Apparently it does not get installed automatically, at least if original install is minimal X and only as few packages as necessary (according to the package management system) are installed to get a working Xorg and KDE session. > * what other strange things (other than not having mesa-dri-drivers > installed and disabling the Composite extension) you did to your Fedora > installation. Those I can think of (that could conceivably have any impact on Xorg or KDE): Option "XkbOptions" "terminate:ctrl_alt_bksp" Option "DPMS" "off" DisplaySize ... PreferredMode... Virtual... (not used on comment 0 host) Xft.dpi is null # kdedrc [Module-kscreen] autoload=false Booting more often to multi-user.target than graphical.target, usually to run startx No Plymouth Droid tops all three preferred fonts lists in fontconfig. Kernel cmdline usually includes video=1024x768@60 (Grub2 is not installed) > Can you reproduce any of the crashes on the unmodified Fedora KDE Live image? Except for Knoppix, which I boot maybe 2-3 sessions per year, I don't download or boot from burned .iso images. I most often install to HD via HTTP started from Grub loading installation kernel and initrd, rarely from booting installation media, never via pxe, always manually, like a non-developer user might, not making use of installation scripting like Kickstart. The Plasmashell crashes were due to mesa-dri-drivers not being installed: In Fedora, even the llvmpipe is in mesa-dri-drivers. If you don't have mesa-dri-drivers, you have NO OpenGL support at all. No wonder QML2 doesn't work then. Please open a separate bug for the KWin / Composite issues, as they have nothing to do with the plasmashell backtrace this bug is about. I'm resolving this bug as DOWNSTREAM (missing package-level dependency). As I wrote above, the KWin issues are unrelated and need a separate bug report.
By the way:
> Except for Knoppix, which I boot maybe 2-3 sessions per year, I don't download or
> boot from burned .iso images. I most often install to HD via HTTP started from Grub
> loading installation kernel and initrd, rarely from booting installation media, never
> via pxe, always manually, like a non-developer user might, not making use of
> installation scripting like Kickstart.
1. Especially BECAUSE you have hardware that many developers don't have, you should be more responsive to requests for testing. (But in this case, I happen to also have a Radeon 9200 SE and can and will test it myself. That doesn't mean testing the live image on your machines wouldn't also be useful, because your hardware is almost certainly not identical to mine. And by the way, the Radeon 9200 SE is my primary machine, so it's not true all the devs use brand new hardware. :-) But this is also why I haven't done the testing yet, I need to reboot my primary machine for that, after burning a live DVD because I don't have any current 32-bit ones lying around.)
2. The live image is the most effective way to test a known-good Fedora setup, without affecting any of the installations present on the machine. Burn (or put on a USB stick, if your machine supports booting from USB), boot and see what happens. I didn't ask you to install from it, just to test ON the live image.
3. Because of your unusual setup, it is important to know for debugging whether this also happens on a known-good default setup. This is why I asked you to test the live image.
4. A non-developer user should not, and hopefully will usually not, install from netinstall with "minimal X". We recommend all our users to always install from the live image. So you are in fact NOT testing what normal users will get.
5. If you report bugs from heavily-customized Fedora installations, please indicate so from day 1. Not knowing this wasted a lot of our time debugging the issue. (Now I'll try to remember your name, so next time you report a bug, I'll hopefully know "Ah, this is the freak with the minimal netinstall who disables Composite and uses startx.", but you should not expect everyone to know you that way.) Old hardware does not necessarily imply the other changes you did. I installed from the live image (several releases ago though, upgraded using yum), I had mesa-dri-drivers installed out of the box, and I don't have Composite disabled (but admittedly, I disable compositing at KWin level because I don't like the effects).
(In reply to Kevin Kofler from comment #18) > Please open a separate bug for the KWin / Composite issues, as they have > nothing to do with the plasmashell backtrace this bug is about. Is not that bug 346059, maybe in need of change from plasmashell to kwin? Probably, yes. So let's use bug #346059, unless we find out that both plasmashell and KWin need fixing for that case (Composite disabled), then we need 2 bugs. |