I have more than 20 Fedora 22 and Rawhide (workspace-5.2.2-5) installations which for months I was unable to get KF5 to get past a startup crash. Eventually I got several working with 5.[8,9].0, both 32 bit with and without Hyperthreading, Athlon class and P4, and 64 bit, most single core, some with with a mix of Intel, ATI and Nouveau drivers working Xorg. In most I initialize via startx. With a few I use sddm or kdm. I can't recall if I have any that do not lose the panel anywhere between the first minute after logging in, and many minutes or an hour or more later. Yesterday I did my first Tumbleweed installation with KF5(.8.0; workspace 5.2.2-3.1), and it exhibits the same problem as in Fedora. When this happens there is no context menu from which to log out. The only way I've found to get a panel back without losing saved settings is via Konsole "qdbus org.kde.ksmserver /KSMServer logout 0 0 0". What all installations have in common that I can remember: 1-using traditional style application menu, not application launcher 2-fonts changed from 9 default to 10, and generic sans-serif 3-DPI forced at least to 120 via Xorg config or xrandr 4-kdedrc contains autoload=false for Module-kscreen 5-Konsole open in upper left with size 10 fonts and white background 6-compositing disabled both via Xorg config and by deselecting in systemsettings -> display 7-panel height has been upped to in excess of 50 8-clock is configured to show seconds 9-NUM=on, repeat=20, delay=250 set in systemsettings -> keyboard 10-screen locker disabled 11-detailed selected but otherwise untouched in regional -> formats 12-energy saving boxes all deselected except dim screen, set to triple digits (111 or higher) 13-task manager set to no sort, no group, deselected "only when full" and "only tasks from current activity" 14-screen edge preselects deselected in active screen corners and edges 15-virtual desktops set to 3 or 4 16-default Breeze theme 17-notification sounds enabled for login and logout 18-hardware clock on local time (EST/EDT) 19-all native windows are missing visible borders (e.g. Firefox has borders) 20-via fontconfig all three lists are topped by a Droid 21-I log out of sessions without first closing Konsole 22-disappearance of panel seems to be avoided by not having Konsole running (I virtually always have Konsole open, usually in upper left screen corner) 23-2nd most recent sequence of events leading to taskbar disappearance (Tumbleweed 64 bit; intel VGA): a:login from KDM b:open Konsole c:kcmshell5 --list d:kcmshell5 xserver e:drag titlebar of kcmshell5 window rightward f:click close button on kcmshell5 window 24-most recent sequence of events leading to taskbar disappearance (Rawhide 32 bit; radeon VGA) a:run a shell script in Konsole b:right click menu starter c:click cancel
Another sequence resulting in disappearance (Tumbleweed: Intel VGA): 1-'kcmshell5 xserver &' in Konsole 2-drag titlebar of kcmshell5 window rightward 3-adjust vertical scroll position of kcmshell5 window content 4-drag bottom edge of kcmshell5 window up to minimum window height
It looks like installing libxcb-cursor0-0.1.2-1.1.x86_64 libxcb-dpms0-1.11-3.2.x86_64 libxcb-record0-1.11-3.2.x86_64 on host gx745's TW made this go away.
Thanks for reporting back. So this is closable ?
(In reply to David Edmundson from comment #3) > Thanks for reporting back. > So this is closable ? If a sample size of one installation and 20 minutes uptime, of which only about 3 minutes is actual activity, is enough, yes. I have no idea when confirmation on Fedora could become possible.
This bug is a sample size of 1 too. I'll close for now. We can always reopen.
(In reply to David Edmundson from comment #5) > This bug is a sample size of 1 too. No it's not. I have over 20 Fedora 22 and Rawhide installations that still have this problem, and no way to know when a solution for them might become available.
Spoke too soon. The panel just disappeared. By clicking on the open Firefox on it.
Felix, To me this seems not to be a KDE bug, but either a distro issue or your systems are missing a number of required packages. You seem to have managed to install Plasma 5 without required libxcb libraries and the question would be what else are you missing ? For openSUSE you are the only one reporting this issue about a disappearing panel and the fact that those three libxcb packages were not installed, makes me wonder. Did you reported the bug to Fedora ? To see if you might be missing packages on those systems as well ??
(In reply to Raymond Wooninck from comment #8) > To me this seems not to be a KDE bug, but either a distro issue or your > systems are missing a number of required packages. You seem to have managed > to install Plasma 5 without required libxcb libraries and the question would > be what else are you missing ? I trust the package manager to figure out what is required, report what it will do, then install if given permission to proceed. If something required is missing, it isn't anything I did or didn't do beyond disabling suggests/recommends or picking the time and day to install or perform online updates. > For openSUSE you are the only one reporting this issue about a disappearing > panel and the fact that those three libxcb packages were not installed, > makes me wonder. It doesn't make me wonder much. I see a behavior on a bunch of similar installations, but keep quiet about it several weeks to see if anyone mentions it on a mailing list, IRC or a bug report. When I see it a happen in yet another distro, I see seriously reduced likelihood that the problem observed is distro-dependent. > Did you reported the bug to Fedora ? To see if you might be missing packages > on those systems as well ?? What I see here looks suspiciously like either or both of two things: 1-something is dependent on something that the package management system does not find to be required; and/or 2-dependence on an option that is usually and is by default, but is not enabled (e.g. Xorg compositing).
Created attachment 92241 [details] Kubuntu 15.04 .xsession-errors I've now replicated this problem on host gx62b in Kubuntu, less than 5 minutes after logging in. Panel disappeared on attempting to grab the bottom of the Konsole window to reduce its height and show some desktop between Konsole window and panel. Other windows open the time: upper right kcmshell5 xserver; under upper right kcmshell5 fonts; lower right corner kcalc. Resolution 1440x900. DPI 108. Theme elarun.
Still happening in freshly upgraded F22's 5.10 (host big41)., which produces no .xsession-errors.
Just happened in Rawhide's 5.10 (host big41) switching Firefox between fullscreen and windowed.
In host gx28b right after dnf upgrade including 5.10 in F22, taskbar disappears immeditately on clicking desktop, right after making panel tall enough to be useful (roughly twice its default height).
Forgot to mention in comment 13 this is repeatable, because the need remains, as panel height is not remembered across the forced restart.
about panel height not being remembered: panel height is synced on disk every 2 minutes or so, so is normal that if it gets killed soon after. however with kquitapp5 plasmashell should be fine
Problem remains in 5.12.0 on Tumbleweed host gx745, unless Xorg compositing is allowed. A reading of https://techbase.kde.org/Development/Tutorials/Plasma5/ThemeDetails suggests that compositing enabled is not a Plasmashell depends. Yet, removing Option "Composite" "Disable" from Xorg configuration avoids this problem. http://stackoverflow.com/questions/3127360/what-is-egl-and-how-can-i-use-it suggested enabling egl might avoid the problem. I tried explicitly enabling egl (Option "AccelMethod" "glamor") on gx745, which has Q965 gfx, but it didn't avoid the problem.
Problem remains in 5.12.0 on F22 host gx27b even without compositing disabled in Xorg configuration.
Comment 18 should not have been made. On host gx27b, 'Option "Composite" "Disable"' had been set in both xorg.conf and in xorg.conf.d/, and I had only removed it from xorg.conf.d/70-extensions.conf before testing.
Compositing remains a requirement to keep a working panel on host big41 with Rawhide's 5.13.0.
I'm not completely sure if I experience the same bug; if you don't think so I can of course open a new report. I'm using OpenSUSE Tumbleweed as well, the following versions at the moment: Plasma: 5.4.1 Qt version: 5.5.0 64bit Every once in a while, quite erratically, the background wallpaper together with the panel / task bar just disappear on three out of my four virtual desktops. If I remember correctly everything stays visible and usable on the desktop I've been using at the time the bug occurred. I couldn't see any relation with my actions - I basically never edit Xorg configs or so, and if I upgrade my system's software I reboot right afterwards, so it's not an effect of upgrading a running system. It just seems to "happen". I tried to execute the "sequences of events" mentioned above - none of them triggered the bug in my case. All libxcb packages (mentioned above) are installed.
Hello, there have been 16 new versions of Plasma after the most recent comment. Is this still reproducible?
Marking as needsinfo. Though I feel this report has switched topic a few times, so any new bugs would be best in a new report
I wish the previous two comments had come a week ago. In the past 7 days I upgraded at least 30 installations hosting Plasma to latest releases, Fedora 32 & 34, openSUSE Tumbleweed, and Mageia 8. It would have been perfect timing to test them all. Comprehensive tests to see if anything here in comments #0 or #1 remains reproducible will take some time. Going back longer than I can remember, a bigger problem is never getting a panel to open in the first place, in Fedora (31?, 32, 33), in openSUSE Tumbleweed, and IIRC, also in Mageia (8?). This very moment, on host big31 with Radeon HD6450, 5.73.0 on Fedora 33, just upgraded to from Fedora 32 last night, is giving me no panel on session open. If it can't be opened, testing for disappearance is made impossible. In this situation: # kquitapp5 plasmashell "Application plasmashell could not be found using service org.kde.plasmashell and path /MainApplication." Something must be missing, but I have no idea how to determine what. In some cases of this I have found that emptying ~/.cache/ solves the problem. WRT effect of disabling compositing, I'll have to have a panel to be able to test for anything that might cause its disappearance. At least it doesn't block starting a session, as it had been doing for some time. In Mageia 8 on same PC with 5.75, item 23 in comment #0 is not reproducible. Item 24 in comment #0 has no cancel button to click. Comment #1 is not reproducible. In Tumbleweed on same host, Plasma session only is installed, no KDE apps, no SDDM, no systemsettings5 or LightDM, . It does start with compositing disabled, and matches behavior of Mageia 8 regarding non-reproducibility for #0-23 and #1.
On host hp945, Fedora 33, 5.73 session starts with left open Konsole, but there is no panel, no response to right click on desktop, and clearing ~/.cache/ while Plasma isn't running doesn't have any effect. Also: # kquitapp5 plasmashell "Application plasmashell could not be found using service org.kde.plasmashell and path /MainApplication."
Created attachment 132851 [details] journal for a comment 24 plasma session attempt .xsession-errors for same session: kwin: unable to claim manager selection, another wm running? (try using --replace) /bin/sh: /usr/bin/kmix: No such file or directory KCrash: Attempting to start /usr/bin/plasmashell KCrash: Application 'plasmashell' crashing... klauncher: Exiting on signal 1 Application::crashHandler() called with signal 11; recent crashes: 1 malloc_consolidate(): unaligned fastbin chunk detected KCrash: Application 'kwin_x11' crashing... Invalid MIT-MAGIC-COOKIE-1 keykdeinit5: Communication error with launcher. Exiting!
On host big41, Fedora 33, 5.73 session starts with left open Konsole, but there is no panel, no response to right click on desktop, and clearing ~/.cache/ while Plasma isn't running doesn't have any effect. Also: # kquitapp5 plasmashell "Application plasmashell could not be found using service org.kde.plasmashell and path /MainApplication."
New information was added with recent comments; changing status for inspection.
Hello and thank you again for the bug report! Unfortunately we were not able to address it yet, nor even manage to reproduce the issue ourselves. Can we ask you to please check if this issue is still happening with Plasma 5.27? If it is, please change the status to REPORTED. Thanks a lot!
As noted 3 years ago, the original problem was subsumed by a bigger problem, that being a Plasma session will never complete opening when compositing is globally enabled, not getting as far as to write anything to .xsession-errors until after closing the session, or painting a background to replace every splash - one per display stays while the primary where Konsole reopens just stays black . If I move the Konsole window, it leaves a trail in its wake. I had to switch to disabling compositing within systemsettings5 to be able to use Plasma sessions at all. # cat /etc/X11/xorg.conf.d/70-extensions.conf Section "Extensions" Option "Composite" "Disable" EndSection # inxi -SGxxz --vs inxi 3.3.29-00 (2023-08-15) System: Kernel: 6.4.16-200.fc38.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 2.39-9.fc38 Desktop: KDE Plasma v: 5.27.8 tk: Qt v: 5.15.10 wm: kwin_x11 dm: 1: KDM 2: XDM Distro: Fedora release 39 (Thirty Nine) Graphics: Device-1: AMD Oland [Radeon HD 8570 / R5 430 OEM R7 240/340 Radeon 520 OEM] vendor: Dell driver: amdgpu v: kernel arch: GCN-1 pcie: speed: 2.5 GT/s lanes: 8 ports: active: DP-1,DVI-I-1 empty: none bus-ID: 01:00.0 chip-ID: 1002:6611 temp: 50.0 C Display: x11 server: X.Org v: 1.20.14 with: Xwayland v: 23.2.0 compositor: kwin_x11 driver: X: loaded: amdgpu unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1 Screen-1: 0 s-res: 4240x1440 s-dpi: 120 Monitor-1: DVI-I-1 mapped: DVI-I-0 pos: right model: Dell P2213 res: 1680x1050 dpi: 90 diag: 558mm (22") Monitor-2: DP-1 mapped: DisplayPort-0 pos: primary,left model: Acer K272HUL res: 2560x1440 dpi: 109 diag: 686mm (27") API: OpenGL v: 4.6 Mesa 23.2.0-rc3 renderer: AMD Radeon R7 200 Series (oland LLVM 16.0.6 DRM 3.52 6.4.16-200.fc38.x86_64) direct-render: Yes # ps -A | grep lasm 2000 ? 00:00:00 startplasma-x11 2146 ? 00:00:07 plasmashell # ls -gG .xsession-errors -rw------- 1 0 Sep 20 00:19 .xsession-errors # ls -Gg .xsession-errors -rw------- 1 197 Sep 20 00:43 .xsession-errors # cat .xsession-errors kdeinit5_wrapper: Warning: connect(/run/user/0/kdeinit5__0) failed: : No such file or directory Error: Can not contact kdeinit5! startkde: Starting up... startkde: Shutting down... startkde: Done. #
What do you mean exactly by "when compositing is globally enabled"? Isn't this the default on Plasma X11? Clearly it's not broken for every Plasma X11 user. It looks like you're a very technically knowledgeable user who's comfortable customizing the system at a low level. Is it possible that one of your customization has caused this problem? Can you reproduce it with a new clean user account created in System Settings > Users with no customizations applied? Please test that.
(In reply to Nate Graham from comment #30) > What do you mean exactly by "when compositing is globally enabled"? (In reply to Felix Miata from comment #29) > a Plasma session will never complete opening when compositing is > globally enabled This was a destructive typo. It should have read "globally disabled". :( > # cat /etc/X11/xorg.conf.d/70-extensions.conf > Section "Extensions" > Option "Composite" "Disable" > EndSection Above configuration causes global disabling - every user on the installation has compositing disabled then compositing in Xorg is disabled, whether in Plasma or XFCE or Gnome or Cinnamon etc. No user setting can override it. I can't think there is any possibility to reproduce this as long as global disabling of compositing also disables Plasma sessions. I left this open so you can decide whether keeping it open makes any sense. I have no idea whether disabling of Plasma by globally disabling compositing is intended. If it was up to me, that result constitutes a bug, but it might be intended. That disabling it is permissible via systemsettings5 but not at the system level seems more like a bug than an intention, but I'm not a programmer.
Aha, that makes more sense, thanks. This isn't a configuration that's supported by Plasma, so I'm afraid we won't be able to offer support for it or fix bugs that it's causing. Sorry, but thanks anyway for reporting this!
Is it documented somewhere that the Composite extension is required now even if compositing is disabled in Plasma? (I would expect Plasma to start up without requiring Composite and to automatically disable compositing in that case.)