[kwin] [Bug 395646] New: all mouse events breaking in VirtualBox
https://bugs.kde.org/show_bug.cgi?id=395646 Bug ID: 395646 Summary: all mouse events breaking in VirtualBox Product: kwin Version: 5.13.1 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: majew...@gmx.net Target Milestone: --- Created attachment 113457 --> https://bugs.kde.org/attachment.cgi?id=113457=edit qdbus org.kde.KWin /KWin org.kde.KWin.supportInformation Since upgrading to Plasma 5.13.0 from 5.12.5, I've observed a regression on my VirtualBox-based VM that runs on my work notebook (host is Windows 10). To reproduce: 1. Start out with a Konsole window only. (That's usually all that I have open.) At this point, everything works as far as I can see. 2. Open some other application. I tried Firefox and Filelight, both by running them either from the Konsole or from KRunner. 3. The other application window opens. At this point, weird behavior ensues. Clicking into the other app causes Konsole to come back to the front. Clicking on the panel does nothing. Using the mouse wheel (on either app) cycles between the open windows, bringing them to the front in turns. Left clicks into the Konsole window get ignored, but right clicks work and bring up its context menu. 4. Run "kwin_x11 --replace &" from the terminal. This is the only thing so far that restores normal behavior for me, except that the app switcher in the panel continues to not work (it reacts to hover events by highlighting the hovered entry, but clicking on an entry does not do anything). 5. Change the active window with Alt-Tab. The weird behavior from step 3 re-emerges. Note that this bug only affects mouse events. Keyboard events work fine in all windows. Global shortcuts are not affected, either. I checked the pacman.log to see if any other updates installed at the same time may be causing the troubles, but found nothing that would be related to the behavior observed. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 385536] global shortcuts do not work with keys that have been mapped with keyboard options
https://bugs.kde.org/show_bug.cgi?id=385536 --- Comment #2 from Stefan Majewsky <majew...@gmx.net> --- After restarting kglobalaccel5 with `killall kglobalaccel5 && sleep 3 && kglobalaccel5 &`, the affected shortcuts start working. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 385536] New: global shortcuts do not work with keys that have been mapped with keyboard options
https://bugs.kde.org/show_bug.cgi?id=385536 Bug ID: 385536 Summary: global shortcuts do not work with keys that have been mapped with keyboard options Product: frameworks-kglobalaccel Version: 5.38.0 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mgraess...@kde.org Reporter: majew...@gmx.net CC: kdelibs-b...@kde.org Target Milestone: --- To reproduce: 1. Open the "Advanced" tab of `kcmshell5 kcm_keyboard`. 2. Enable "Configure keyboard options", and select (for example) "Caps Lock behavior > Make Caps Lock an additional Esc". Press "Apply". 3. Use a shortcut that involves the Esc key (e.g. Ctrl-Alt-Esc for xkill). The shortcut works when the actual Esc key is used, but not when the Caps Lock key is pressed, even though it should work like Esc. This is the instance where I first observed this. I've found another instance of the same problem where, after remapping Esc to F13, a global shortcut that is set to F13 is not triggered when I press the correct key. In `kcmshell5 keys`, the mapping is applied correctly. For example, if I click on one of the recording button and press the Esc key, it fills in "F13" as desired. Same for the Caps Lock key, which produces "Esc" in the input field. One noteworthy detail: This problem only happens when I use the keyboard options that kcm_keyboard presents, i.e. the symbols options from /usr/share/X11/xkb/rules/evdev et al. When I do not use keyboard options and instead employ an Xmodmap like below, everything works correctly. $ cat .Xmodmap clear Lock keycode 0x42 = Escape keycode 0x09 = F13 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 384597] Shift+alt+[arrow keys] and Shift+Meta+[arrow keys] shortcuts broken in 5.38.0
https://bugs.kde.org/show_bug.cgi?id=384597 Stefan Majewsky <majew...@gmx.net> changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 384597] Shift+alt+[arrow keys] and Shift+Meta+[arrow keys] shortcuts broken in 5.38.0
https://bugs.kde.org/show_bug.cgi?id=384597 --- Comment #20 from Stefan Majewsky <majew...@gmx.net> --- @grmat(In reply to grmat from comment #19) > Can confirm it is fixed, but why? > > Arch has not made a change to the package: > https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/ > kglobalaccel=82c50bed02e8de51c11588a2d4e2cc84e59bf7f0 They updated the version. kglobalaccel 5.38.1 has the change mentioned in #12 reverted if I understand #14 correctly. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 384634] some global shortcuts not working anymore with KF 5.38
https://bugs.kde.org/show_bug.cgi?id=384634 Stefan Majewsky <majew...@gmx.net> changed: What|Removed |Added Summary|some global shortcutsnot|some global shortcuts not |working anymore with KF |working anymore with KF |5.38|5.38 -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 384634] New: some global shortcutsnot working anymore with KF 5.38
https://bugs.kde.org/show_bug.cgi?id=384634 Bug ID: 384634 Summary: some global shortcutsnot working anymore with KF 5.38 Product: ksmserver Version: 5.10.5 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: l.lu...@kde.org Reporter: majew...@gmx.net Target Milestone: --- Yesterday, I got the KDE Frameworks upgrade from 5.37 to 5.38 through my distribution. Since then, some global shortcuts of ksmserver are not working anymore. Specifically: - Log Out Without Confirmation (Ctrl-Alt-Shift-Del) - Halt Without Confirmation (Ctrl-Alt-Shift-PgDn) However, not all of them are broken. The following ones still work: - Lock Session (Ctrl-Alt-L) - Log Out (Ctrl-Alt-Del) This may very well be a kglobalaccel bug since only Frameworks was updated, while Plasma wasn't. However, I'm filing this bug against ksmserver for now since other applications with global shortcuts (kded, KRunner, KWin, Plasma, Powerdevil, Yakuake) are not affected as far as my testing goes. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 381696] kmail hangs waiting for S/MIME signature verification while trying to compose a reply
https://bugs.kde.org/show_bug.cgi?id=381696 --- Comment #1 from Stefan Majewsky <majew...@gmx.net> --- Yesterday, I could reproduce this bug every single time. Today, not at all. So if there was an issue with gpgsm, it seems to have been fixed by a reboot. (I already tried to restart the graphical session, but I didn't try rebooting before filing the bug.) -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 381696] New: kmail hangs waiting for S/MIME signature verification while trying to compose a reply
https://bugs.kde.org/show_bug.cgi?id=381696 Bug ID: 381696 Summary: kmail hangs waiting for S/MIME signature verification while trying to compose a reply Product: kmail2 Version: 5.5.2 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: majew...@gmx.net Target Milestone: --- Steps to reproduce: 1. Don't use S/MIME yourself. (Don't know if this is significant, but I only have GPG set up.) 2. Receive a mail that bears an S/MIME signature. 3. Select it in the message list. 4. Click "Reply". 5. Compose reply and click "Send". What should happen: 3. The message should be displayed in the preview pane, probably with a "Not enough information to check validity" frame. 4. The message composer should open immediately. 5. The message should be sent immediately (notwithstanding the GPG confirmation dialogs). What actually happens: 3. It shows a "Please wait while signature is being verified" frame for a suspiciously long time. (I didn't time it exactly, but it's on the order of a full minute.) 4. When I click "Reply" immediately, it will hang for a minute before bringing up the composer. The UI thread will be stuck in the meantime. It doesn't consume CPU, though, so I figured it's stuck in IO wait. Attaching gdb shows a backtrace leading into libgpgme waiting on a select(), see below. 5. Upon sending, I get the same one-minute delay before the GPG-related modal dialogs come up. The bug seems to be limited to S/MIME-signed messages. Replying to PGP-signed messages incurs no such delay. What's noteworthy is that this bug has appeared out of the blue. I checked my pacman.log for recent updates to KMail and GPG, but the last update of GPG was two weeks ago. If it was related to that, I should've noticed it sooner. GPG is version 2.1.21 (libgcrypt 1.7.7). Another thing that I've noticed is that every of the actions 3., 4. and 5. spawns a new `gpgsm --server` process. It seems to be cleaned up when it's finished with not being able to verify the signature, but at various points, I saw 3 or 4 `gpgsm --server` instances in the process listing. - Backtrace (sorry for this mess, but this is Arch and I don't want to recompile stuff unless it is really really really needed): (gdb) bt #0 0x7f70ace11363 in select () at /usr/lib/libc.so.6 #1 0x7f70955a9769 in () at /usr/lib/libgpgme.so.11 #2 0x7f70955a4897 in () at /usr/lib/libgpgme.so.11 #3 0x7f7095584b9e in () at /usr/lib/libgpgme.so.11 #4 0x7f70955895c8 in gpgme_op_verify () at /usr/lib/libgpgme.so.11 #5 0x7f70a81f21c1 in GpgME::Context::verifyDetachedSignature(GpgME::Data const&, GpgME::Data const&) () at /usr/lib/libgpgmepp.so.6 #6 0x7f70a84dbeeb in () at /usr/lib/libqgpgme.so.7 #7 0x7f70a84dc2fd in QGpgME::QGpgMEVerifyDetachedJob::exec(QByteArray const&, QByteArray const&) () at /usr/lib/libqgpgme.so.7 #8 0x7f70a7fb451e in () at /usr/lib/libKF5MimeTreeParser.so.5 #9 0x7f70a7faadae in MimeTreeParser::SignedMessagePart::okVerify(QByteArray const&, QByteArray const&, KMime::Content*) () at /usr/lib/libKF5MimeTreeParser.so.5 #10 0x7f70a7fab2fd in MimeTreeParser::SignedMessagePart::startVerificationDetached(QByteArray const&, KMime::Content*, QByteArray const&) () at /usr/lib/libKF5MimeTreeParser.so.5 #11 0x7f70a7f8a39f in () at /usr/lib/libKF5MimeTreeParser.so.5 #12 0x7f70a7fa25ee in MimeTreeParser::ObjectTreeParser::processType(KMime::Content*, MimeTreeParser::ProcessResult&, QByteArray const&, QByteArray const&, QSharedPointer&, bool) () at /usr/lib/libKF5MimeTreeParser.so.5 #13 0x7f70a7fa3b15 in MimeTreeParser::ObjectTreeParser::parseObjectTreeInternal(KMime::Content*, bool) () at /usr/lib/libKF5MimeTreeParser.so.5 #14 0x7f70a7fa42f3 in MimeTreeParser::ObjectTreeParser::parseObjectTree(KMime::Content*) () at /usr/lib/libKF5MimeTreeParser.so.5 #15 0x7f70a9e0c4e4 in TemplateParser::TemplateParserJob::processWithTemplate(QString const&) () at /usr/lib/libKF5TemplateParser.so.5 #16 0x7f70a9e0fe38 in TemplateParser::TemplateParserJob::process(QSharedPointer const&, Akonadi::Collection const&) () at /usr/lib/libKF5TemplateParser.so.5 #17 0x7f70aa7b1357 in () at /usr/lib/libKF5MessageComposer.so.5 #18 0x7f70aa7ac20d in MessageComposer::MessageFactoryNG::createReplyAsync() () at /usr/lib/libKF5MessageComposer.so.5 #19 0x7f70af5e6c0c in () at /usr/lib/libkmailprivate.so.5 #20 0x7f70af57d9a6 in () at /usr/lib/libkmailprivate.so.5 #21 0x7f70af57b471 in () at /usr/lib/libkmailprivate.so.5 #22 0x7f70ad70d57f in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/libQt5Core.so.5 #23 0x7f70af6a73de in () at /usr/lib/libkmailprivate.so.5 ---Type
[palapeli] [Bug 366796] Ctrl-click should never, ever deselect all pieces
https://bugs.kde.org/show_bug.cgi?id=366796 --- Comment #7 from Stefan Majewsky <majew...@gmx.net> --- (In reply to Ian Wadham from comment #6) > @Matthew: I had a brief look at how Palapeli is handling selects. It is > mostly home-grown and could be changed, but I won't be fixing it. See my > reply to Christoph. Yeah, that was a result of my naive over-engineering back in the day. It was on my laundry list to rip out that monstrosity and move to simple hard-coded mouse actions, see e.g. [1]. I don't have had the time for quite a while to hack on KDE (and if I had, i would push the KF5 port through first), but if anyone wants to cleanup this mess, then by all means go ahead. And CC me on the review request if you like some extra pair of eyes that's familiar with the codebase (or at least was 4 years ago). [1] https://majewsky.wordpress.com/2012/02/13/is-anyone-using-custom-mouse-actions-in-palapeli/ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 365333] no redraws with OpenGL compositing backends on amdgpu driver
https://bugs.kde.org/show_bug.cgi?id=365333 --- Comment #5 from Stefan Majewsky <majew...@gmx.net> --- Addendum for point 1 in comment 4: Seeing that message again is especially critical in my situation since I moved from Catalyst to amdgpu, so the message did not apply to me when I saw it for the first time (when I set it to "Reuse screen content" while using the Catalyst driver). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 365333] no redraws with OpenGL compositing backends on amdgpu driver
https://bugs.kde.org/show_bug.cgi?id=365333 --- Comment #4 from Stefan Majewsky <majew...@gmx.net> --- Interesting. Then there may be two UI issues in there: 1. I did not see that message since it only appears when moving to that setting, not when the KCM starts out in it. 2. The message says "'Re-use screen content' causes severe performance problems on MESA drivers." It should be reworded to e.g. "severe performance and rendering problems", so people know what they're getting into when choosing that. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 365333] no redraws with OpenGL compositing backends on amdgpu driver
https://bugs.kde.org/show_bug.cgi?id=365333 --- Comment #2 from Stefan Majewsky <majew...@gmx.net> --- Created attachment 5 --> https://bugs.kde.org/attachment.cgi?id=5=edit glxinfo -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 365333] no redraws with OpenGL compositing backends on amdgpu driver
https://bugs.kde.org/show_bug.cgi?id=365333 --- Comment #1 from Stefan Majewsky <majew...@gmx.net> --- Created attachment 4 --> https://bugs.kde.org/attachment.cgi?id=4=edit qdbus org.kde.KWin /KWin supportInformation -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 365333] New: no redraws with OpenGL compositing backends on amdgpu driver
https://bugs.kde.org/show_bug.cgi?id=365333
Bug ID: 365333
Summary: no redraws with OpenGL compositing backends on amdgpu
driver
Product: kwin
Version: 5.7.0
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: NOR
Component: compositing
Assignee: kwin-bugs-n...@kde.org
Reporter: majew...@gmx.net
Last week, on my desktop PC, I switched from Catalyst to the new
xf86-video-amdgpu driver since the Catalyst driver suddenly started having
problems rendering some Steam games. After rebooting to switch to the new
kernel and X driver, I was greeted by a black screen.
Alt-Shift-F12 resolved the problem, and a few more attempts of Alt-Shift-F12
showed that the screen stopped redrawing whenever compositing was enabled. The
only exception is the mouse cursor which still moves appropriately, and changes
shape according to the surface beneath it.
I checked different settings in the kwincompositing KCM and found that the bug
only appears under the following settings:
* Rendering backend: OpenGL 2.0 or 3.1 (XRender works fine)
* OpenGL interface: GLX (EGL works fine)
* Tearing prevention: Reuse screen content ("Full screen repaints" and "Only
when cheap" appear to work fine in a short test)
The bug is really only hit when all three settings are set to the problematic
values. I first saw the problem in kwin 5.6 (after I installed the amdgpu
driver), and waited until this week to see if 5.7 would help, but the problem
is still reproducible.
Reproducible: Always
--
You are receiving this mail because:
You are watching all bug changes.
