Windows are becoming inactive randomly

So randomly kde gets confused and starts marking all windows as inactive.

Steps to reproduce:

  1. open any window
  2. windows will automatically become inactive randomly (sometimes the issue happens and it will presits for a few minutes and then just randomly go away and everything works as normal)

What I expected:
Windows don't become inactive until I click away from them or hover (I have focus follows mouse set)

What is actually happening:
Windows become inactive even if I have my mouse over them

Journal :

So if I open the app drawer it immediately closes. Open krunner immediately closes. I have the desktop effect to make inactive windows transparent and that's how I was able to tell that is what's going on, as if I open any windows it immediately becomes inactive and transparent.

inxi -Fza
System:    Kernel: 5.13.8-zen1-1-zen x86_64 bits: 64 compiler: gcc v: 11.1.0 
           parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen 
           root=UUID=ef15347e-a4da-4628-afc3-2bff20cbb710 rw [email protected] quiet splash 
           rd.udev.log_priority=3 vt.global_cursor_default=0 systemd.unified_cgroup_hierarchy=1 
           resume=UUID=e7745511-30a0-4b3d-93c1-4bc3daa8b2b8 loglevel=3 sysrq_always_enabled=1 
           Desktop: KDE Plasma 5.22.4 tk: Qt 5.15.2 info: latte-dock wm: kwin_x11 vt: 1 dm: SDDM 
           Distro: Garuda Linux base: Arch Linux 
Machine:   Type: Desktop Mobo: ASRock model: X470 Taichi serial: <filter> UEFI: American Megatrends 
           v: P3.50 date: 07/18/2019 
Battery:   Device-1: hidpp_battery_1 model: Logitech Wireless Mouse MX Master 3 serial: <filter> 
           charge: 100% (should be ignored) rechargeable: yes status: Discharging 
CPU:       Info: 6-Core model: AMD Ryzen 5 2600X bits: 64 type: MT MCP arch: Zen+ family: 17 (23) 
           model-id: 8 stepping: 2 microcode: 800820D cache: L2: 3 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 86395 
           Speed: 4055 MHz min/max: 2200/3600 MHz boost: enabled Core speeds (MHz): 1: 4055 2: 3867 
           3: 4065 4: 4042 5: 4066 6: 4066 7: 4055 8: 4065 9: 4065 10: 3952 11: 4050 12: 4059 
           Vulnerabilities: Type: itlb_multihit status: Not affected 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass 
           mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 
           mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling 
           Type: srbds status: Not affected 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: NVIDIA GP104 [GeForce GTX 1080] vendor: Gigabyte driver: nvidia v: 470.57.02 
           alternate: nouveau,nvidia_drm bus-ID: 0e:00.0 chip-ID: 10de:1b80 class-ID: 0300 
           Display: x11 server: X.Org 1.20.13 compositor: kwin_x11 driver: loaded: nvidia 
           display-ID: :0 screens: 1 
           Screen-1: 0 s-res: 3840x3240 s-dpi: 80 s-size: 1219x1029mm (48.0x40.5") 
           s-diag: 1595mm (62.8") 
           Monitor-1: HDMI-0 res: 3840x2160 hz: 60 dpi: 52 size: 1872x1053mm (73.7x41.5") 
           diag: 2148mm (84.6") 
           Monitor-2: DP-0 res: 2560x1080 dpi: 81 size: 798x334mm (31.4x13.1") diag: 865mm (34.1") 
           OpenGL: renderer: NVIDIA GeForce GTX 1080/PCIe/SSE2 v: 4.6.0 NVIDIA 470.57.02 
           direct render: Yes 
Audio:     Device-1: NVIDIA GP104 High Definition Audio vendor: Gigabyte driver: snd_hda_intel 
           v: kernel bus-ID: 0e:00.1 chip-ID: 10de:10f0 class-ID: 0403 
           Sound Server-1: ALSA v: k5.13.8-zen1-1-zen running: yes 
           Sound Server-2: JACK v: 1.9.19 running: no 
           Sound Server-3: PulseAudio v: 15.0 running: yes 
           Sound Server-4: PipeWire v: 0.3.33 running: yes 
Network:   Device-1: Intel Dual Band Wireless-AC 3168NGW [Stone Peak] driver: iwlwifi v: kernel 
           port: e000 bus-ID: 08:00.0 chip-ID: 8086:24fb class-ID: 0280 
           IF: wlp8s0 state: down mac: <filter> 
           Device-2: Intel I211 Gigabit Network vendor: ASRock driver: igb v: kernel port: d000 
           bus-ID: 0a:00.0 chip-ID: 8086:1539 class-ID: 0200 
           IF: enp10s0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           IF-ID-1: anbox0 state: down mac: <filter> 
Bluetooth: Device-1: Intel Wireless-AC 3168 Bluetooth type: USB driver: btusb v: 0.8 bus-ID: 1-9:4 
           chip-ID: 8087:0aa7 class-ID: e001 
           Report: bt-adapter ID: hci0 rfk-id: 0 state: up address: <filter> 
Drives:    Local Storage: total: 2.27 TiB used: 504.46 GiB (21.7%) 
           SMART Message: Unable to run smartctl. Root privileges required. 
           ID-1: /dev/nvme0n1 maj-min: 259:1 vendor: Samsung model: SSD 970 EVO 250GB 
           size: 232.89 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 
           type: SSD serial: <filter> rev: 2B2QEXE7 temp: 38.9 C scheme: GPT 
           ID-2: /dev/nvme1n1 maj-min: 259:0 vendor: Samsung model: SSD 960 EVO 250GB 
           size: 232.89 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 
           type: SSD serial: <filter> rev: 3B7QCXE7 temp: 27.9 C scheme: GPT 
           ID-3: /dev/sda maj-min: 8:0 vendor: Seagate model: ST2000DX002-2DV164 size: 1.82 TiB 
           block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 7200 
           serial: <filter> rev: CC41 scheme: GPT 
Partition: ID-1: / raw-size: 215.45 GiB size: 215.45 GiB (100.00%) used: 42.82 GiB (19.9%) 
           fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:7 
           ID-2: /boot/efi raw-size: 260 MiB size: 256 MiB (98.46%) used: 562 KiB (0.2%) fs: vfat 
           dev: /dev/nvme0n1p1 maj-min: 259:6 
           ID-3: /home raw-size: 215.45 GiB size: 215.45 GiB (100.00%) used: 42.82 GiB (19.9%) 
           fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:7 
           ID-4: /var/log raw-size: 215.45 GiB size: 215.45 GiB (100.00%) used: 42.82 GiB (19.9%) 
           fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:7 
           ID-5: /var/tmp raw-size: 215.45 GiB size: 215.45 GiB (100.00%) used: 42.82 GiB (19.9%) 
           fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:7 
Swap:      Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) 
           ID-1: swap-1 type: partition size: 17.18 GiB used: 0 KiB (0.0%) priority: -2 
           dev: /dev/nvme0n1p3 maj-min: 259:8 
           ID-2: swap-2 type: zram size: 15.55 GiB used: 43.2 MiB (0.3%) priority: 100 
           dev: /dev/zram0 
Sensors:   System Temperatures: cpu: 42.9 C mobo: 34.0 C gpu: nvidia temp: 49 C 
           Fan Speeds (RPM): fan-1: 0 fan-2: 1298 fan-3: 1301 fan-4: 1522 fan-5: 1212 gpu: nvidia 
           fan: 21% 
           Power: 12v: N/A 5v: N/A 3.3v: 3.31 vbat: 3.28 
Info:      Processes: 466 Uptime: 29m wakeups: 4 Memory: 15.55 GiB used: 8.51 GiB (54.7%) 
           Init: systemd v: 249 tool: systemctl Compilers: gcc: 11.1.0 clang: 12.0.1 Packages: 
           pacman: 1973 lib: 513 flatpak: 0 Shell: Zsh v: 5.8 running-in: kitty inxi: 3.3.06 

You might want to investigate all those dbus errors. I am not sure if that is related to your issue or not but I don't think those are normal.

As a side note, I can't replicate this issue on my side.

  1. ok
  2. No, works.

I'm thinking this is something specific to your system or there would be many reports of this behavior from KDE users. My first thought would be that perhaps some software (perhaps from the AUR) that you installed may be causing this problem.

Does this happen on a live disk?

Did this happen from when you first installed Garuda, or did it start some time after installation?

Have you searched for similar bug reports online?

If this is a known KDE bug there's not much that we can do about it. In this case your best option is to report it on the KDE bug tracker in the hope that more reports will spur more effort to correct the bug.


This happened after some time of using garuda. I was using vanilla arch before this with the same exact packages ( I just created a list of the packages I was using in my previous install) and did not have this issue. That makes me think that it's not a KDE bug as I would of also have the issue in vanilla arch and it also makes me doubt its a packaged that I added as it would of also been an vanilla arch. Honestly, I can't really explain how this can happen here but not on arch except maybe its some conflict with some garuda-specific config or package? Couldn't find much online.

hence why I said random. Something happens that I still haven't figured out what that causes KDE to automaticly make any windows inactive even if you click (or hover in my case) on them. (and this something is only reproducable for me on garuda and not vanilla arch)

If it happened afterwards there's always the process of elimination, but it would be a lot of work to systematically find which change caused this.

1 Like

But it is also only reproducible on your specific install so that makes it hard for the rest of us to troubleshoot since it doesn't seem to be a general issue with Garuda.

1 Like

right yeah, it could be a lot of things I was hoping that someone may of run it to something similar and could maybe give some ideas. I was reading a bit on the arch wiki and something I can try is clearing the plasma cache ill do that and see if it helps otherwise I may just have to switch back to vanilla arch. the only two leads I really have is those dbus errors that I'm getting and I'm also getting another possible related issue where apps stay on the screen even after closed (there not even running anymore checked with htop it's just the graphics and window of the app just stay on screen ) but intrestingly I get a bunch of kwin errors like this Aug 07 10:50:42 Kiseki kwin_x11[3583]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 414, resource id: 12690147, major code: 3 (GetWindowAttributes), minor code: 0 Aug 07 10:50:42 Kiseki kwin_x11[3583]: qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 415, resource id: 12690147, major code: 14 (GetGeometry), minor code: 0 Aug 07 10:50:42 Kiseki dbus-daemon[683]: [system] Would reject message, 3 matched rules; type="method_call", sender=":1.23" (uid=0 pid=3732 comm="/usr/lib/udisks2/udisksd ") interface="org.freedesktop.PolicyKit1.Authority" member="CheckAuthorization" error name="(unset)" requested_reply="0" destination=":1.6" (uid=102 pid=692 comm="/usr/lib/polkit-1/polkitd --no-debug ") Aug 07 10:50:43 Kiseki kwin_x11[3583]: kwin_core: XCB error: 152 (BadDamage), sequence: 2115, resource id: 12690194, major code: 143 (DAMAGE), minor code: 2 (Destroy) this I have seen on arch but not to the amount I see here so that might be another clue. @dalto most likely yes this some conflict with my exact install which happens in gardua and not arch so it would be difficult to troubleshoot. So that's why I posting everything I can find out about the issue in hopes that might lead to someone having an idea. Or at the very least if someone else runs into the issue they can see what I tried

Try rolling back gtk3 and latte-dock. that fixed it for me

found the issue. The parachute kwin script was not playing nice with my multi-monitor setup. I had it set to toggle on the top left corner and it was getting activated accidently. It would only activate on one screen and it would confuse kwin making it think I was in a task switcher and thus the all windows should be inactive or something .Don't know why I didn't have this issue on vanilla arch. Maybe there was an update that broke something


That sounds like an issue with your compositor.

1 Like

and with the same hardware?

Is it possible you added some hardware that some time?

I get you found the main factor for this as a kWin script, but similar (not thae same exactly) happen when there are HW like cordless mice/keyboard etc.
Frequently reported as intermittent signal makes mice run crazy and such, often battery power related.

Your log is full of input devices and events, later re-discovered and others.

Consider testing cordless mouse/keyboard to see any changed behavior.
Or just keep it in mind for the future :wink:


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.