[kmail2] [Bug 422173] Handling missing 'date' in email headers
https://bugs.kde.org/show_bug.cgi?id=422173 Tim Colgate changed: What|Removed |Added CC||k...@mettalogic.co.uk --- Comment #10 from Tim Colgate --- Was there agreement on the correct approach for this? The simplest would probably be to use the "Delivery-date:" field in the header if the "Date:" field is missing. Otherwise there are dates in the "Received:" fields. It looks like bug 425216 is basically the same issue, and 227942 may also be related. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 409097] kscreenlocker_greet using 100% cpu when in another user's session
https://bugs.kde.org/show_bug.cgi?id=409097 --- Comment #3 from Tim Colgate --- It doesn't appear to be a problem any more with Plasma 5.25.4 and Nvidia drivers 470.141.03 (in Debian). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455781] Title-bar stretches/compresses on resize / doesn't update content
https://bugs.kde.org/show_bug.cgi?id=455781 Tim Colgate changed: What|Removed |Added CC||k...@mettalogic.co.uk --- Comment #2 from Tim Colgate --- I also have the same problem and can reproduce it reliably by switching to a different user and back (e.g. and then back to ). I'm using nvidia proprietary drivers; I don't think their version (470.129.06-6 on Debian) is very important as I've had this problem for quite a while with various driver versions. I get the message: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 11823, resource id: 197132293, major code: 18 (ChangeProperty), minor code: 0 in the xterm where I started/restarted kwin_x11 each time I switch back to the original user. It's as though the title bar has been replaced with a static image which stretches/shrinks as the window is resized, but as the other comment says, the max/min etc. buttons themselves still work, provided you click where they should be, not just where they're displayed. Windows opened after I switch back to the orginal user behave correctly. This is all with the compositor disabled. If I enable the compositor I get more error messages on switching: ZoomConfig::instance called after the first use - ignoring PresentWindowsConfig::instance called after the first use - ignoring KscreenConfig::instance called after the first use - ignoring DesktopGridConfig::instance called after the first use - ignoring kwin_core: XCB error: 10 (BadAccess), sequence: 44738, resource id: 486, major code: 142 (Composite), minor code: 2 (RedirectSubwindows) qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 48284, resource id: 182452229, major code: 18 (ChangeProperty), minor code: 0 -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 409097] kscreenlocker_greet using 100% cpu when in another user's session
https://bugs.kde.org/show_bug.cgi?id=409097 Tim Colgate changed: What|Removed |Added CC||k...@mettalogic.co.uk -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 409097] New: kscreenlocker_greet using 100% cpu when in another user's session
https://bugs.kde.org/show_bug.cgi?id=409097 Bug ID: 409097 Summary: kscreenlocker_greet using 100% cpu when in another user's session Product: kscreenlocker Version: unspecified Platform: Debian testing OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: greeter Assignee: plasma-b...@kde.org Reporter: k...@mettalogic.co.uk CC: bhus...@gmail.com Target Milestone: --- SUMMARY kscreenlocker_greet process consumes 100% CPU if it starts up when that user isn't the active user, i.e. that user is not currently using the display. Note that that although this looks similar to bug #347772, it isn't the same bug. STEPS TO REPRODUCE 1. Have 2 users logged into X 2. In user1's session: sleep 5 ; kscreenlocker_greet 3. Immediately switch to user2 with e.g. OBSERVED RESULT After 5 seconds, user1's kscreenlocker_greet process starts and immediately consumes 100% CPU. 100% CPU is also used if that user's kscreenlocker_greet process is started automatically by plasma when the idle period expires, provided that I've already switched to another user. This is 100% reproducible for me. If I lock screen manually or run e.g. kscreenlocker_greet --graceTime 5000 then everything is fine. Although I'm running debian testing (libkscreenlocker5 5.14.5-1), I've also tried downloading the latest source of kscreenlocker/greeter from git. Adding ProfilerStart()/ProfilerStop() from Google's perf tools around app.exec() in main.cpp of greeter hasn't been very useful as it appears that CPU is being used somewhere in QSGBatchRenderer::Renderer::renderMergedBatch() which seems to be calling _nv023glcore() (somewhere in Nvidia's driver presumably). I'm assuming the problem is that something is trying to access the display, but can't, because it's being used by another user. However, as this could be quite common in a multi-user setup, perhaps there's something different about the way kscreenlocker_greet does it? EXPECTED RESULT kscreenlocker_greet should use <1% CPU. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian testing KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.3 Nvidia drivers: 418.74 ADDITIONAL INFORMATION kcachegrind output: http://www.mettalogic.co.uk/tim/tmp/screenlock_cachegrind.png -- You are receiving this mail because: You are watching all bug changes.
