[kwin] [Bug 492285] Forward backend configuration from startplasma to kwin
https://bugs.kde.org/show_bug.cgi?id=492285 --- Comment #4 from Robin Bankhead --- Thank you for clarifying things for me. So it sounds like the virtual backend *can* provide what a 3rd-party VNC server would need on the output side. I will look elsewhere for what would need doing on the input side. Can I just enquire regarding virtual backend outputs, can they be resized dynamically? And could a virtual output be added (dynamically or at launch) to a "bare metal" session as a second screen? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 492285] Support headless VNC server like WayVNC
https://bugs.kde.org/show_bug.cgi?id=492285 --- Comment #2 from Robin Bankhead --- (In reply to Vlad Zahorodnii from comment #1) > It sounds like you rather need a way to tell the plasma start script to > start kwin_wayland with the virtual backend and also provide a way to pass > additional arguments to configure the mode size or the refresh rate. *If* the virtual backend is viable for such a purpose (this is one aspect on which I wasn't able to get up-to-date info), then what you detail would be a necessary part of the puzzle, yes. But there is also how inputs are handled. I don't understand very well how responsibilities divide up between what the compositor needs to do to enable it and what a VNC server, as a distinct entity, needs to implement for itself. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 466836] Add a sort option "As in Dolphin" in the available sorting options; Sorting is not followed Dolphin in some cases.
https://bugs.kde.org/show_bug.cgi?id=466836 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 492285] New: Support headless VNC server like WayVNC
https://bugs.kde.org/show_bug.cgi?id=492285 Bug ID: 492285 Summary: Support headless VNC server like WayVNC Classification: Plasma Product: kwin Version: unspecified Platform: unspecified OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: kde.b...@headbank.co.uk Target Milestone: --- Simply put, I would like to be able to run a headless, persistent, detachable/reconnectable plasma-wayland session with a VNC server, as wlroots-based compositors are able to do with the aid of WayVNC[1]. I am aware that kwin_wayland has a virtual backend, which was mooted when introduced as a means to provide such functionality[2] - that was a long time ago so I do not know whether that would still be considered the best starting point. I am also unsure how easily reproducible is what wlroots provides that WayVNC needs, or whether it would be necessary to implement everything including the server in a "KDE Way"; so I don't know if this will be a big ask or a VERY big ask. I would just like to know if there's an avenue and any interest towards it. I think it could be very beneficial in cloud systems, VMs and even plain old LAN usage once X11 finally shuffles off. [1] https://github.com/any1/wayvnc [2] http://blog.martin-graesslin.com/blog/2015/10/september-update-for-plasmas-wayland-porting/ -- You are receiving this mail because: You are watching all bug changes.
[KRdp] [Bug 481912] Feature request: Wayland remote login sessions with Plasma, like xrdp
https://bugs.kde.org/show_bug.cgi?id=481912 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 15329] Save and remember positions of all windows
https://bugs.kde.org/show_bug.cgi?id=15329 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 --- Comment #28 from Robin Bankhead --- Created attachment 172758 --> https://bugs.kde.org/attachment.cgi?id=172758&action=edit Screenshot of Gammaray attached to kglobalacceld in Xvnc session Found it. Another KDAB app, do you work for them? ;-) So it looks like your theory was correct. So does this confirm TigerVNC's Record extension impl is where the issue must lie? [Please advise if you want any further things out of GammaRay.] -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 --- Comment #26 from Robin Bankhead --- If that's the case then we may have run out of road here, because tigervnc only support systemd nowadays. What I could do is solicit for Gentoo systemd+KDE users in the forums to see if the issue exists for them, but I am doubtful that it will as I've not seen this bug when the server runs under systemd on other distros. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840
--- Comment #24 from Robin Bankhead ---
Could it have anything to do with dbus?
I can't resist the suspicion that openrc vs systemd lies at the root of the
issue, and the logging shows a number of dbus-related complaints including this
one that's repeated several times during session launch:
Couldn't start kglobalaccel from org.kde.kglobalaccel.service:
QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name
org.kde.kglobalaccel was not provided by any .service files")
A number of dbus-related things including polkit, pipewire and plasma-pa have
issues in this session as well (although oddly, most do not occur if I launch
vncserver directly as my user instead of by initscript).
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 --- Comment #21 from Robin Bankhead --- Created attachment 172739 --> https://bugs.kde.org/attachment.cgi?id=172739&action=edit perf.data.perfparser exported from hotspot, xz-compressed -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 Robin Bankhead changed: What|Removed |Added Attachment #172729|0 |1 is obsolete|| --- Comment #19 from Robin Bankhead --- Created attachment 172737 --> https://bugs.kde.org/attachment.cgi?id=172737&action=edit perf.data capture, xz-compressed (raw size 387MB) The rebuilding isn't much of an issue, I just didn't want to do so on-spec without explicit direction to do so. Likewise I haven't done so for glibc but am happy to do so if needed. I installed hotspot but with the additional symbols installed the "??" break down into several separate units so it seemed easier to re-run the capture so you can scrutinise it on your end, I hope that's OK. I can save the .perfparser file from hotspot and upload that instead if that's preferable and sufficient? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 --- Comment #17 from Robin Bankhead --- Created attachment 172729 --> https://bugs.kde.org/attachment.cgi?id=172729&action=edit perf.data capture, xz-compressed (raw size 414MB) perf data as requested, ~10s worth captured just after triggering the bug. This is now under kglobalacceld-6.1.4 (without the above patch applied). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 Robin Bankhead changed: What|Removed |Added Attachment #172536|0 |1 is obsolete|| --- Comment #16 from Robin Bankhead --- Created attachment 172567 --> https://bugs.kde.org/attachment.cgi?id=172567&action=edit TigerVNC Xvnc session log with timestamps Output log with 1s-resolution timestamps; I connect viewer, trigger the bug by pressing left CTRL key at 22:29:01, do nothing for 1min, then kill kglobalacceld and log out. Regarding "perf" that looks a sizeable package to build (141MB source tarball) so I may not have an opportunity to do so before the weekend. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 --- Comment #15 from Robin Bankhead --- (In reply to fanzhuyifan from comment #12) > Any chance you could get timestamps in front of the log lines, so that we > know how long everything is taking? E.g., take a look at > https://serverfault.com/questions/310098/how-to-add-a-timestamp-to-bash- > script-log Unfortunately how tigervnc's vncsession binary handles console output seems to be hardcoded. It goes in ~/.vnc/myhostname:1.log and it rotates-out the previous file on launch so I would have to manually tail it after launch. Guess that's adequate to capture when the bug is triggered. Do you want millisecond resolution? Will doing tail -f on the file provide that with sufficient accuracy? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 --- Comment #14 from Robin Bankhead --- (In reply to fanzhuyifan from comment #6) > When kglobalacceld uses 100% of CPU, could you attach a gdb instance to it, > press Ctrl-C, and upload the results of `thread apply all backtrace full`? > This is to see where kglobalacceld is stuck at. You would need to install > debug symbols. > > Could you reattach the logs if you add the following environment variable > before running kglobalacceld? > QT_LOGGING_RULES="kf.globalaccel.kglobalacceld.debug=true" > > Thanks! Output below: -- robin@lentoo ~ $ gdb -p `pidof kglobalacceld` GNU gdb (Gentoo 15.1 vanilla) 15.1 Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". Attaching to process 3000 [New LWP 3028] [New LWP 3021] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x7f9fc6668180 in ?? () from /usr/lib64/libglib-2.0.so.0 (gdb) Quit (gdb) thread apply all backtrace full Thread 3 (Thread 0x7f9fc20006c0 (LWP 3021) "QDBusConnection"): #0 0x7f9fc6d2266f in poll () at /lib64/libc.so.6 #1 0x7f9fc666b8d7 in ??? () at /usr/lib64/libglib-2.0.so.0 #2 0x7f9fc666bfa0 in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #3 0x7f9fc72c1670 in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib64/libQt6Core.so.6 #4 0x7f9fc750f2aa in QEventLoop::exec(QFlags) () at /usr/lib64/libQt6Core.so.6 #5 0x7f9fc744c8c0 in QThread::exec() () at /usr/lib64/libQt6Core.so.6 #6 0x7f9fc6a65b8e in ??? () at /usr/lib64/libQt6DBus.so.6 #7 0x7f9fc73ee76a in ??? () at /usr/lib64/libQt6Core.so.6 #8 0x7f9fc6cc3379 in ??? () at /lib64/libc.so.6 #9 0x7f9fc6d2f2cc in ??? () at /lib64/libc.so.6 Thread 2 (Thread 0x7f9fc16006c0 (LWP 3028) "QXcbEventQueue"): #0 0x7f9fc6d2266f in poll () at /lib64/libc.so.6 #1 0x7f9fc5b1c4a2 in ??? () at /usr/lib64/libxcb.so.1 #2 0x7f9fc5b1e86a in xcb_wait_for_event () at /usr/lib64/libxcb.so.1 #3 0x7f9fc2d7b418 in ??? () at /usr/lib64/qt6/plugins/platforms/../../../libQt6XcbQpa.so.6 #4 0x7f9fc73ee76a in ??? () at /usr/lib64/libQt6Core.so.6 #5 0x7f9fc6cc3379 in ??? () at /lib64/libc.so.6 #6 0x7f9fc6d2f2cc in ??? () at /lib64/libc.so.6 Thread 1 (Thread 0x7f9fc2ddce40 (LWP 3000) "kglobalacceld"): #0 0x7f9fc6668180 in ??? () at /usr/lib64/libglib-2.0.so.0 #1 0x7f9fc6669fed in ??? () at /usr/lib64/libglib-2.0.so.0 #2 0x7f9fc666b4dc in ??? () at /usr/lib64/libglib-2.0.so.0 #3 0x7f9fc666b816 in ??? () at /usr/lib64/libglib-2.0.so.0 #4 0x7f9fc666bfa0 in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #5 0x7f9fc72c1670 in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib64/libQt6Core.so.6 #6 0x7f9fc750f2aa in QEventLoop::exec(QFlags) () at /usr/lib64/libQt6Core.so.6 #7 0x7f9fc750f45a in QCoreApplication::exec() () at /usr/lib64/libQt6Core.so.6 #8 0x558d983bfa9c in main () - Guessing you will need me to obtain symbols for other libs shown above? (As mentioned I need to recompile packages to get them, yay Gentoo). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 Robin Bankhead changed: What|Removed |Added Attachment #171431|0 |1 is obsolete|| --- Comment #11 from Robin Bankhead --- Created attachment 172536 --> https://bugs.kde.org/attachment.cgi?id=172536&action=edit TigerVNC Xvnc session log with kglobalacceld debug output Attaching Xvnc log with the debug-level output enabled for kglobalacceld. In the logged session I simply launched the session, connected a viewer (which triggered the bug), waited ~1min, then killed it and logged out. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 --- Comment #9 from Robin Bankhead --- Have rebuilt kglobalacceld with the full MR patch -- no change, as you expected -- and without stripping. If I have to do the same for other packages as well, it will be a while before I can do this as it will precipitate a full upgrade. If not, I will get gdb built tomorrow night and test then. On this run I issued $ export QT_LOGGING_RULES="kf.globalaccel.kglobalacceld.debug=true" before starting the tigervnc initscript, but this did not lead to any additional output showing up in the Xvnc log. Perhaps this was not the appropriate method of supplying the env var to the session? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 --- Comment #7 from Robin Bankhead --- Will do - once I re-teach myself how. Been over a decade. Ctrl+C might not work under the bugged condition within the VNC session - is there any problem with doing that in a VT, or in a parallel SSH session? Also: In the other bug I note that the commit I just tried is just part of a merge request that includes other stuff, is this what I should be using to patch? https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/52.diff -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 Robin Bankhead changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #5 from Robin Bankhead --- Rebuilt kglobalacceld-6.1.2 with the patch from comment #2 applied. No change in bug behaviour :( -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 --- Comment #3 from Robin Bankhead --- Thanks. We will see in October. I spotted this commit and did wonder if it might be pertinent. However I note that your description of the issue describes the CPU surge as being "1 minute plus"; my finding is that it continues indefinitely (I have let it run up to about 15 minutes). Does this still fit within your diagnosis? PS: a small (and probably predictable) further observation: Connecting to the session in "view only" mode, the bug does not trigger. If the session is then switched to full-input (done within the TigerVNC vncviewer settings mid-session), it triggers immediately (no keyboard input required). -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 306352] 100% cpu usage when waking up from suspend or switching between x servers, might be caused by kglobalaccel
https://bugs.kde.org/show_bug.cgi?id=306352 --- Comment #30 from Robin Bankhead --- For those who have triggered the behaviour by using xmodmap, this recent commit may be of interest: https://github.com/KDE/kglobalacceld/commit/105a0eaf80effcc4c014ed8b0b14bc2d656bae33 It speaks of the remapping of lots of keys at once (giving xmodmap as example) causing a CPU surge for "over 1 minute". I do not know when (if?) this commit will see release (it's not in kglobalacceld-6.1.3) but it will be interesting to see if it solves the issue for you ... and if so, whether it does or does not for others of us with different contexts/triggers. PS: To follow-up the bit I left hanging above, it _was_ still the case that the surge was only triggered when I pressed a(ny) key; however, I deleted my ~/.cache dir and since then, it triggers as soon as the vncviewer connects to the session. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 --- Comment #1 from Robin Bankhead --- I obtained a change in behaviour by removing all KDE/Plasma related content from ~/.cache folder. Having done this and launched a new tigervnc Xvnc session, the CPU surge starts as soon as the VNC client connects - no manual keypress is required to trigger it. (The subsequent behaviour on killing/restarting kglobalacceld is the same.) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 489840] New: kglobalacceld 100% CPU in Xvnc session
https://bugs.kde.org/show_bug.cgi?id=489840 Bug ID: 489840 Summary: kglobalacceld 100% CPU in Xvnc session Classification: Frameworks and Libraries Product: frameworks-kglobalaccel Version: 6.1.0 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: kde.b...@headbank.co.uk Target Milestone: --- Created attachment 171431 --> https://bugs.kde.org/attachment.cgi?id=171431&action=edit TigerVNC Xvnc session log SUMMARY When a plasma-x11 session is launched in TigerVNC's Xvnc on current Gentoo (default OpenRC-based Plasma profile), kglobalacceld does not initialise correctly: the shortcuts it should manage do not work, and as soon as the session receives any keyboard input via the VNC client, it immediately goes to 100% CPU. If manually killed and relaunched, the CPU surge is not repeated but keyboard input is completely disabled - not just the shortcuts, it's not even possible to e.g. type text in KWrite. After this there are also other input dysfunctions seen, possibly indicating spurious modifier-key down states: e.g. Scrolling down with the wheel of a mouse on any window reduces its opacity; dragging on a scrollbar moves the whole window. A version of this bug existed on the same host under KDE5, with the difference that killing and relaunching the then-named kglobalaccel5 *did* allow it to function normally thereafter (and there was none of the brokenness described above). STEPS TO REPRODUCE 1. emerge net-misc/tigervnc kde-plasma/plasma-desktop:6 2. Configure and start tigervnc initscript for existing user of plasma-x11 desktop 3. Connect to Plasma VNC session from TigerVNC vncviewer on another machine 4. Press any key OBSERVED RESULT kglobalacceld process goes to 100% and global shortcuts are unavailable. EXPECTED RESULT Global shortcuts can be used as configured and CPU does not melt. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.9.1-gentoo (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i7-7600U CPU @ 2.80GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 620 Manufacturer: LENOVO Product Name: 20HMS17U03 System Version: ThinkPad X270 ADDITIONAL INFORMATION I described the KDE5 occurrence of this bug in the existing and very old Bug #306352 , however I think myself and others were wrong to glom onto that older issue with a grab-bag of very differing symptoms, contexts and apparent triggers. I'm hopeful that this single very specific scenario can be examined in isolation to get purchase on what the cause might be. Attached is a VNC session log in which I - Started the tigervnc initscript from a console VT with plasmax11 session configured for my user - connected via tigervnc-client from another machine - Pressed CTRL key to trigger the CPU surge - Issued "killall -USR1 kglobalacceld" via a desktop shortcut (only way I can do so when the bug triggers) - Opened yakuake via its tray icon - Opened Kwrite and dolphin from iconbar to test shortcut function - Issued "/usr/libexec/kglobalacceld" in yakuake - Attempted global shortcuts e.g. Alt-Tab with the opened apps (nope) - Attempted typing in another tab in yakuake (nope) - Killed kglobalacceld again by closing the tab in yakuake - Shutdown the machine -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 306352] 100% cpu usage when waking up from suspend or switching between x servers, might be caused by kglobalaccel
https://bugs.kde.org/show_bug.cgi?id=306352 --- Comment #29 from Robin Bankhead --- Plasma 6(.1) update: situation worse :( [Reminder, my context = in tigervnc-server session] The initial CPU spike still happens (I'm not sure if it actually still required any keyboard input to trigger it, will verify this when I'm able). Worse: even after killing and restarting the now-named /usr/libexec/kglobalacceld as before (which does still calm the CPU), I now lose keyboard responsiveness entirely after 1min or so. (There are also some mouse behaviour peculiarities that I'm not yet ready to lay out comprehensively.) There is more than likely an additional bug at play for me here, but I thought the further anecdata might help others here. FWIW, no such issues in a fluxbox session launched the same way. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 484384] No system info displayed on Raspberry Pi OS
https://bugs.kde.org/show_bug.cgi?id=484384 Robin Bankhead changed: What|Removed |Added Summary|No system info displayed on |No system info displayed on |wayland/raspberry pi OS |Raspberry Pi OS --- Comment #1 from Robin Bankhead --- To confirm, the issue is not Wayland-specific and occurs also in plasma-x11 session. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 484384] New: No system info displayed on wayland/raspberry pi OS
https://bugs.kde.org/show_bug.cgi?id=484384 Bug ID: 484384 Summary: No system info displayed on wayland/raspberry pi OS Classification: Applications Product: plasma-systemmonitor Version: 5.27.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: kde.b...@headbank.co.uk CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- SUMMARY The applets displaying Memory, Disk, CPU, Networks, Network Rates and System have no content on Raspberry Pi OS Bookworm Lite, on a Raspberry Pi 5. STEPS TO REPRODUCE 1. Install Raspberry Pi OS Bookworm Lite 2. apt install plasma-systemmonitor 3. Launch plasma-wayland session 4. Open System Monitor OBSERVED RESULT Applets in application window are blank. EXPECTED RESULT Applets in application window display system metrics. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.1.0-rpi7-rpi-2712 (64-bit) (available in About System) KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION Currently unable to determine if this works under x11 session as I'm unable to get one running. Will update if I can. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 422529] Put config files inside a kde subdirectory in ~/.config, ~/.local/share, and ~/.cache
https://bugs.kde.org/show_bug.cgi?id=422529 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434922] plasma system-monitor not working properly on RPI4 and possibly other ARM systems
https://bugs.kde.org/show_bug.cgi?id=434922 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 443168] Add a setting to not follow sorting as in Dolphin when Gwenview started by image click
https://bugs.kde.org/show_bug.cgi?id=443168 --- Comment #26 from Robin Bankhead --- @JoostR it's not at all inappropriate to discuss how to resolve a bug in that bug's comment thread. That's exactly what it is for. What behaviour is desired must be hashed out before it can be implemented in code. What concerned me above was scope-creep. Perhaps I was mistaken, but I did not think any of us were concerned with .directory file handling before Andrew joined the thread. Per-directory behaviour was not mentioned in the bug summary. I do not use .directory files; I thought that (a) Dolphin does not use them by default, and (b) thus most people do not use them. Perhaps I'm incorrect in one or both of these assumptions too; if so please set me straight and accept my apologies. Based on Andrew's initial post it seems clear that Gwenview knows nothing of .directory files, not even through Dolphin: It simply copies Dolphin's *global* sort setting. Any solution to this particular bug needs to address how Gwenview behaves when there are no .directory files involved. My suggestion remains: 1) Gwenview should implement commandline switches that allow to override its configured default sort-mode 2) Dolphin should invoke Gwenview with the switches to mirror its own sort-mode, or not, as a configuration option (which option is the default: TBD) Alternatively, if it's considered undesirable for the two apps to be codependent in this way for the sake of this one feature, let Gwenview ignore Dolphin entirely. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 443168] Add a setting to not follow sorting as in Dolphin when Gwenview started by image click
https://bugs.kde.org/show_bug.cgi?id=443168 --- Comment #22 from Robin Bankhead --- > @Robin Bankhead > > It doesn't make any sense for Gwenview to revert to obeying Dolphin's > > ordering instead of persisting the ordering chosen in its own UI, across > > multiple direct launches (i.e. not from within Dolphin). > > Gwenview should have its own ordering setting, but able to be overridden on > > invocation (which the onus then is on Dolphin to do). This might be of > > benefit for other external apps calling Gwenview also. > As said above, yes there should be an option to not follow dolphin sorting > when clicked image. Also, it will not be really "following Dolphin", but > "following .directory file". My comment that you quote was in relation to the original scope of this bug, which had nothing to do with obeying (or not) .directory files. The latter is a separate issue introduced by you. It's not up to me but I think you should leave this bug as it was, and file a new bug for your issue. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 443168] gwenview ignores settings in initial sort order
https://bugs.kde.org/show_bug.cgi?id=443168 --- Comment #16 from Robin Bankhead --- (In reply to Andrew Shark from comment #13) > > I fail to see why it should be in sync with Dolphin at all > > That is incorrect. My use case is that I do not use Gwenview as an image > browser, but as image viewer. I set the Esc key to quit Gwenview, not to go > to Browse mode. I click an image in Dolphin, then start switching images > with right and left arrows. In dolphin I have a folder sorted by date (I > sometimes rename my screenshots, but want them to be shown in order when > they were taken). Gwenview showed me the wrong order. I then realized that > it has its own order, not used the order from Dolphin. > > So Gwenview should sort images in sync with Dolphin view. At least when > image was opened by click from Dolphin. Or at least there should be an > option for such behavior. Interesting. From your comment I assume you have Dolphin set to remember view settings per-directory (IIRC this involves dropping a .directory file in the folder). So Gwenview is ignoring these files - perhaps not surprising, it has no setting that mirrors this. I think your issue is external to this bug, though similar in character (sort of). It would certainly make sense for Gwenview to obey the .directory files (perhaps ideally as an optional setting, in KDE philosophy). I would report it separately. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 443168] gwenview ignores settings in initial sort order
https://bugs.kde.org/show_bug.cgi?id=443168 --- Comment #12 from Robin Bankhead --- (In reply to Christoph Cullmann from comment #11) > The first thing I need to do is always to set the order twice. It shows sort > by name, but doesn't do that, I need to set an other one and set it back. > > I think the old behaviour was a lot saner, I fail to see why it should be in > sync with Dolphin at all, e.g. Kate or even our file open dialogs are not in > sync and that makes sense. Very small clarification: You don't need to flip to another selection and back; clicking on the (already-selected) radio causes it to take its correct effect. -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 306352] 100% cpu usage when waking up from suspend or switching between x servers, might be caused by kglobalaccel
https://bugs.kde.org/show_bug.cgi?id=306352 --- Comment #24 from Robin Bankhead --- I've found a way to trigger the cpu thrash on-demand (when in VNC session). I noticed one of my custom shortcuts was triggering it every time, but on investigation it is not the shortcut but this command in the invoked script that actually causes it: xdotool key --clearmodifiers "shift+Left" I wonder if anyone can now deduce what is the common factor between the two triggering scenarios: 1. The first keyboard input of any kind in a new VNC session 2. Running xdotool to simulate keyboard events -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 306352] 100% cpu usage when waking up from suspend or switching between x servers, might be caused by kglobalaccel
https://bugs.kde.org/show_bug.cgi?id=306352 --- Comment #23 from Robin Bankhead --- Sorry, amendment to the above on further investigation. The CPU spike is triggered by ANY keyboard input (e.g. typing a letter key, which opens the quick-launcher, or CTRL on its own which has no UI effect). -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 306352] 100% cpu usage when waking up from suspend or switching between x servers, might be caused by kglobalaccel
https://bugs.kde.org/show_bug.cgi?id=306352 --- Comment #22 from Robin Bankhead --- Further data point: I just added a systemmonitor plasmoid to my panel to show CPU usage, and interestingly after first opening my vnc session it actually did not show any heavy activity. It started maxing one core, however, as soon as I opened Yakuake (with a keyboard shortcut, natch). This sort of makes a lot more sense, even if it doesn't present a full diagnosis: I'm actually giving kglobalaccel itself some input that "upsets" it. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 425638] SMS disappears instead of being send
https://bugs.kde.org/show_bug.cgi?id=425638 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 464392] Since SDK 31 bump, it is not possible to send SMS using KDE Connect
https://bugs.kde.org/show_bug.cgi?id=464392 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 306352] 100% cpu usage when waking up from suspend or switching between x servers, might be caused by kglobalaccel
https://bugs.kde.org/show_bug.cgi?id=306352 --- Comment #18 from Robin Bankhead --- As mentioned above I'm on Gentoo, so no systemd involved here. And being in VNC I don't see it being graphics stack related either, but that's probably a bit above my pay-grade to say ;) I'm not sure either about taking some portion of the above off to a different bugreport. Right now we have a slightly disparate bag of seeming trigger-environments but a single unifying symptom. That the initial report is 10yrs old doesn't mean much. Unless more is done to show that the different cases are causing the same outcome for totally different reasons (and how many different ways can there actually be to drive a relatively simple process, like I imagine kglobalaccel5 is, into a CPU meltdown?) then I think the theory of a common cause holds water and it's therefore better if all the details remain in one place for the reference of whoever can input and maybe make a needed connection. -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 306352] 100% cpu usage when waking up from suspend or switching between x servers, might be caused by kglobalaccel
https://bugs.kde.org/show_bug.cgi?id=306352 --- Comment #16 from Robin Bankhead --- Just to update on my earlier, I haven't found a way of re-triggering the high CPU usage after killing and relaunching kglobalaccel5 at the start of my VNC session, and it has not recurred again during such a session. (It's possible it has happened without me noticing though.) This is now under kglobalaccel-5.99.0, plasma-desktop-5.26.2. -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 306352] 100% cpu usage when waking up from suspend or switching between x servers, might be caused by kglobalaccel
https://bugs.kde.org/show_bug.cgi?id=306352 --- Comment #15 from Robin Bankhead --- FWIW, the issue as I outlined my experience of it is still occurring under kde-frameworks/kglobalaccel-5.97.0, but for the first time I have also encountered it recurring later in my VNC session. (It is possible it's happened previously, but I'm not normally physically near the machine during a session so might not notice). The only possible triggering action I can think of from that session was me toggling fullscreen in TigerVNC, which is set to resize the remote desktop to client window size (using xrandr - this would presumably happen on initial connection too as I don't have initial screen res set to match the client display I use). I'll try to reproduce this later to check. -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 306352] 100% cpu usage when waking up from suspend or switching between x servers, might be caused by kglobalaccel
https://bugs.kde.org/show_bug.cgi?id=306352 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk --- Comment #10 from Robin Bankhead --- I see the same issue with kglobalaccel-5.95.0 in plasma-desktop-5.25.0 on Gentoo, when launching the plasma session within TigerVNC server. kglobalaccel5 goes straight to 100% and has to be killed (after relaunching it behaves normally). I do NOT have an ~/.Xmodmap file. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 443168] gwenview ignores settings in initial sort order
https://bugs.kde.org/show_bug.cgi?id=443168 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk --- Comment #5 from Robin Bankhead --- It doesn't make any sense for Gwenview to revert to obeying Dolphin's ordering instead of persisting the ordering chosen in its own UI, across multiple direct launches (i.e. not from within Dolphin). Gwenview should have its own ordering setting, but able to be overridden on invocation (which the onus then is on Dolphin to do). This might be of benefit for other external apps calling Gwenview also. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 450230] Improve cover and flip switch
https://bugs.kde.org/show_bug.cgi?id=450230 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk --- Comment #1 from Robin Bankhead --- Subscribing. IIRC, Cover Switch was "inspired" by the UI of iTunes and/or the iPod Touch (wow we are going back a bit aren't we? lol). I wonder if the devs have actually experienced that UI? While acknowledging that design trends move on, the new look I just find utterly lacking in the polish and slickness that appealed about the original. (Granted this is only v1.0, but I infer that the design changes have been conscious decisions.) I also agree that configurability is desirable. It is kind of a KDE hallmark after all ;) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443757] Please bring back cover switch effect
https://bugs.kde.org/show_bug.cgi?id=443757 --- Comment #16 from Robin Bankhead --- Have just updated to 5.24 and have to be honest, this is not a very good replacement. - Windows are smaller - Thick blue border around centred window - No reflections - Opaque grey background instead of wallpaper shaded - Transition animation is too slow but jerky at start and end The smoothness and visual appeal of the old cover switch is basically all gone. Aesthetically none of the ways this has changed are appealing to me. Sorry if a bit negative, hope others like it but I won't be using it. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443757] Please bring back cover switch effect
https://bugs.kde.org/show_bug.cgi?id=443757 --- Comment #11 from Robin Bankhead --- Maybe I'll understand when I see the new version, but I don't see how removing reflections is an improvement. Couldn't they be made an option? Good to see this has been done though. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443757] Please bring back cover switch effect
https://bugs.kde.org/show_bug.cgi?id=443757 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438883] Re-implement Desktop Cube effect with modern effects API
https://bugs.kde.org/show_bug.cgi?id=438883 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443410] Please restore the Desktop Cube switching effect
https://bugs.kde.org/show_bug.cgi?id=443410 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 433260] Tabbing to select power/session item and pressing Enter/Return opens the item under the cursor rather than invoking the highlighted power/session action
https://bugs.kde.org/show_bug.cgi?id=433260 Robin Bankhead changed: What|Removed |Added CC||kde.b...@headbank.co.uk --- Comment #4 from Robin Bankhead --- It's not hover. I launched kickoff using Win key with mouse pointer well away from the launcher area, hit the 6* TABs to focus Sleep option, hit ENTER, and it opened the highlighted item from the Favourites list (Firefox in my case). *Offtopic, but the added number of keystrokes to reach the power options is rather a retrograde step IMO. -- You are receiving this mail because: You are watching all bug changes.
