I want to say that maybe it only happens with the first Alt-Tab attempt, but I think it's safe to say it happens every time. If I have a couple of windows open and I try to alt-tab switch between them, it's like the first attempt is never caught. I may get frustrated with the issue (along with the many others) and whack the alt-tab several times hard before it finally switches (or I may just use my mouse instead). But once it does switch, further switches work fine. I'm going to guess/surmise that the cause is due to the side switching module/widget coming to life with the first alt-tab call. I don't know if it will happen hours later as well (if maybe the widget/switching feature sleeps). I just felt I had to finally post this rather than just sit on it an accept it. Reproducible: Always Steps to Reproduce: 1) Open multiple windows 2) Press Alt-Tab to switch between windows Actual Results: The first time, the key combo won't get caught. Subsequent Alt-Tab presses work correctly. Expected Results: Alt-Tab should ALWAYS get caught and perform the intended function. Intel Core I3 8GB RAM.
bug #354658 ? run "kcmshell5 kwintabbox", select flipswitch or coverflow as tabbox, try again. Still a problem?
Still a problem. Curious that I saw no "visual" difference between flipswitch or coverflow. I changed it to "Breeze Dark" and saw the side "widget" was replaced with a center "menu" when I hold Alt-Tab. But even with single, quick Alt-Tab under Breeze Dark still did NOT register a window switch at all. It wasn't until I waited ~5 seconds before pressing it again at which time, the window switched immediately. I have 4 windows open Chrome: (to read your message) Terminal: (to type your command) Task Switcher: (resultant from said command) Terminal: (running atop so I waited until my system settled down after logging in after a reboot before attempting Alt-Tab)
> Curious that I saw no "visual" difference between flipswitch or coverflow. Can you please attach the output of "qdbus org.kde.KWin /KWin supportInformation"
Output: https://paste.kde.org/pg8uzxnyx
> Compositing Type: XRender Xrender compositing doesn't support coverflow or flipswitch - and its usage is perhaps a bad sign reg. QtQuick (which relies on OpenGL) => glxinfo? I assume simply disabling the tabbox altogether (just highlight the selected window) will cause more responsive switching?
XRender... I saw I had the option to change it to OpenGL and have done so (3.1, EGL). I'm seeing new effects including switching effects (kde is oh-so-pretty), and it is much more performant. I did a bunch of restarts/tests and while it seems to have been hit-or-miss, I think it may be working correctly now (based on the last 2 restarts/tests). ***** Compositing is active Compositing Type: OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Haswell OpenGL version string: 3.3 (Core Profile) Mesa 11.2.1 OpenGL platform interface: EGL OpenGL shading language version string: 3.30 Driver: Intel GPU class: Haswell OpenGL version: 3.3 GLSL version: 3.30 Mesa version: 11.2.1 X server version: 1.18.3 Linux kernel version: 4.5.1 Direct rendering: Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no OpenGL 2 Shaders are used Painting blocks for vertical retrace: no *****
> including switching effects [...] and it is much more performant Also w/ the "regular" tabboxes?
You know what, I retract my statement that it is working correctly. I didn't know what you were asking in comment-7 and I went back to the visualization settings and changed it back to Breeze. Alt-Tab didn't switch anything on the first attempt. I then started to walk through the different switching visualizations and trying each one out (without rebooting. only applying) and that was the same case with just about each one, where the first switch isn't acted upon. Once I had gone through each visualization, I could go back to any of the others, apply, and the switching action would occur but I'm guessing that is just because the action was cached from my previous attempt that originally failed to act on the first alt-tab for that particular visualization.
bug #333511 For confirmation: does or does this not apply to the coverflow/flipswitch effects (they largely differ from all others, so this is important)
gawd I wish I could find some consistency to this issue. I rebooted, logged in, ran atop, opened settings, opened chrome, tried to drag chrome and the GUI froze up (except for mouse movement). Prior to the reboot, I couldn't view videos in fullscreen (youtube, kodi). After the gui hangup, I switched to tty and re-enabled my /etc/X11/xorg.conf.d/intel.conf which contains 'Option "AccelMethod" "uxa"' which was a workaround for another bug I encountered/reported before. journalctl had been dumping "QPainter::...: Painter not active" So after re-enabling that conf file, I rebooted again, ran atop, opened settings, opened chrome, verified I was using flipswitch visualization, pressed Alt-Tab, and it worked. I tried coverswitch, and it also worked. I changed to Breeze and that too worked... ...AHHH, I just right now (while typing this comment) switched to Grid and that DID FAIL to catch the first alt-tab. Also just tried thumbnails and that failed to catch. I'm going to try another theory by changing to Grid, reboot, try it, switch to flip/cover and try that. If that fails, I will report/comment.
Ok, with Grid having been selected, I rebooted. I opened the usual windows and alt-tab was NOT caught with the first try. 2nd was fine. I switched to flip. Alt-tab was caught correctly. I switched to cover. Alt-tab was also caught correctly. I switched to breeze. Alt-tab was NOT caught with the first try. Now I'll switch back to flip, reboot and my expectation will be that it works fine. I won't report back unless something goes wrong with it (or you need something else from me).
*** This bug has been marked as a duplicate of bug 354658 ***