Shooting inconsistencies

[tyqualters]

Your system information

• System information from steam (Steam -> Help -> System Information) in a gist:
  https://gist.github.com/tyqualters/9bd5c9fb34bdf148d1c65acb22791316
• Have you checked for system updates?: [Yes/No]

---

Clicks sometimes not registering in-game. Clicking to fire on enemy may or may not register; sometimes takes about 5 clicks before player actually shoots. Suspecting this has to do with input handling.

No issues with UI, no issues experienced from other games.

According to the replies, this issue is consistent among Arch and Ubuntu-based systems, as well as KDE + Gnome desktop environments, and has been consistent since the November 16 update.

Steps for reproducing this issue:

1. Play CS:2 on official servers

[dataprolet]

Coming from #3569 I just want to add that we both use Arch and X11 on a MSI/AMD plattform in case that's of relevance.

[hp-pepster]

My son (Sys info) is apparently plagued by the same issue, he did some digging and it also happens on local sessions (practice, ws maps). The mouse inputs continue to work again only after he presses a key on the keyboard. He has bound MOUSEWHEELDOWN to jump, which stops working as well.
My system (Sys info) does work as expected without any noticeable mouse problems.

[henrym11106]

same thing for me on arch+kde+x11+AMDGPU. it's like the mouse (cursor?) leaves the game "window" at random running both fullscreen windowed and regular fullscreen. pitch/yaw input always works but no buttons for several seconds at a time, functionality usually comes back after moving the mouse enough.

I'm pretty sure this only started after the 2023-11-16 update, but my system was also updated during this time.
there also used to be an issue when alt-tabbing in and out where aim will snap to a random direction upon tabbing back in. doesn't seem to happen now.

also it looks like everyone having this issue is using KDE/kwin...

[senecaso]

This started happening for me as well following the update on Nov 16, 2023. Prior to that, it was never an issue. I tried using a different mouse and the same issue occurs. Running on Kubuntu 22.04

System Information here

[liphiwolf]

Same issue for me on Arch Linux with KDE, X11 and Nvidia GTX970. I have also noticed that shooting only works sometimes when a key is pressed.
SystemInfo: https://gist.github.com/liphiwolf/9bde91b920ba48f67a94b696cbd45f78

[hp-pepster]

My son (Sys info) is apparently plagued by the same issue, he did some digging and it also happens on local sessions (practice, ws maps). The mouse inputs continue to work again only after he presses a key on the keyboard. He has bound MOUSEWHEELDOWN to jump, which stops working as well. My system (Sys info) does work as expected without any noticeable mouse problems.

Correction: Happens on my system as well. We did some more testing. Normally we play in 4:3 stretched (1080x1000 or 1080x960). With 1080x1000, the bug seems to occurs more often.

I wonder how many users (all unix-users?) are affected by this bug and do not notice it.

[pawelswiszcz]

Manjaro Gnome X11 also clicks sometimes not registering in-game. Clicking to fire on enemy may or may not be registered.

[liphiwolf]

I have done some in-game tests and for me the issue comes from the "home-screen cursor" hovering above the taskbar while trying to shoot.

Steps to reproduce:

• Tab out of cs2
• position your cursor over your taskbar
• tab back into cs2
• try to shoot
• profit??

[bastimeyer]

This has been happening on my system for the past week or so. Left clicks randomly don't get registered. Spamming or switching weapons doesn't help. Moving the mouse for a bit apparently does. Really frustrating...

Running Arch with KDE Plasma on X11 at 1920x1080, KWin compositing disabled while in-game. Using two screens, with the one on the right hand side being the primary one. Playing in fullscreen mode.

[tyqualters]

@bastimeyer In response to your reply, I also run Arch + KDE on X11 but at 2560x1440. I was experiencing this issue, but following the guidance from @liphiwolf, whenever I moved out of game and back into game, I just made sure my cursor was positioned in the center of my screen away from the task bar and then ALT+TAB'd to the game.

I haven't experienced any issues of the sorts since following this.

[semyon2105]

This problem happens in KDE Plasma when the panel is in any mode that's not "Always Visible".

[semyon2105]

This might have to do with some recent KDE Plasma update. I'm having similar problems with the panel capturing mouse clicks in Dota 2 as well. It wasn't like this a few weeks ago.

[senecaso]

It started happening to me without any KDE or OS updates, but it immediately started happening following the mentioned cs2 update.

…

On Sun, Nov 26, 2023, 3:26 p.m. Semyon Ivanov ***@***.***> wrote: This might have to do with some recent KDE Plasma update. I'm having similar problems with the panel capturing mouse clicks in Dota 2 as well. It wasn't like this a few weeks ago. — Reply to this email directly, view it on GitHub <#3566 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIOD2NG6CZ2QAJ3SSPPIMTYGPFZTAVCNFSM6AAAAAA7QUUKZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRWHEZTMNJQGE> . You are receiving this because you commented.Message ID: ***@***.***>

[pawelswiszcz]

Hello @kisak-valve
Maybe have any news about this? I've noticed that right button also sometimes is not registered. Problem is on Manajro Gnome 45 X11 GTX 1050 Ti.
Disabled all panels and problem still exists (the top and bottom)
The last update broke this behavior, because before that all was fine.

[dataprolet]

It's probably a problem with the exclusive fullscreen not working and the cursor not being bind to the game window.

Steps to reproduce:

1. Shoot
2. Aim down
3. At some point the cursor will leave the game's window
4. Clicks will not be registered

[pawelswiszcz]

You might be right.
The game starts without proper fullscreen. The top bar is visible. I've always changed this in settings for proper full screen and saved options. But yesterday I didn't do that and all click and shots was fine.

Replying to #3566 (comment)

[senecaso]

I was able to confirm the steps indicated by @dataprolet . I tried both in "windowed" and in "fullscreen", and the issue only appears to happen in "fullscreen" mode. If you just keep aiming down, until its at your feet, then lift the mouse and keep going down, eventually the cursor leaves the game window and all mouse clicks stop registering. So, the workaround until Valve is able to fix this is to scroll way up when this happens to get your cursor away from the bottom of the screen, but of course this doesn't help much when you're trying to clutch in comp and you cant fire or defuse.

I will try to reproduce this on Gnome as well, since most of the people here seem to be using KDE.

[senecaso]

I wasn't able to reproduce this using the exact same steps on an Ubuntu 22.04 (Gnome) system. However, that same system experienced the issue, but the conditions to trigger it seem to be different somehow. This Gnome system had its "task bar" mounted at the top of the screen, so the process was repeated by trying to scroll up, as well as left, but even then we were unable to reliably reproduce the issue.

[dataprolet]

It seems that if you change from fullscreen to windowed and back while being in game the game correctly switches to exclusive fullscreen and the cursor can't leave the game.

[marcT21]

same behavior on my linux Mint

[flying-pizza-69]

i was able to fix my issue on bspwm by making the fullscreen cs2 window float.

steps:

1. Run your game on fullscreen mode with your preferred resolution and refresh rate.
2. Press Esc to get your cursor, press your sxhkd key combination to toggle to floating mode in bspwm. Basically executing bspc node -t floating
3. If you are using Polybar then move your CS2 window away from Polybar so they don't overlap with each other. If they overlap then the issue would still be there.

Edit: my game works fine if i pkill polybar

[senecaso]

@dataprolet is right. If you change the video settings while in a game (ie: not in the lobby or main menu), it seems to address most of this issue. It doesn't fix it entirely, but it is significantly better, and nearly all clicks are registering for me now. Sadly, the workaround doesn't persist between restarts (it does between maps), so you have to do it again each time you restart the game.

1. start the game
2. leave the video settings as they are when the game starts (likely in windowed mode)
3. join a game, casual is fine
4. once the game starts, go to the video setting and change mode from "fullscreen" to "windowed"
5. click apply
6. change mode from "windowed" to "fullscreen"
7. click apply
8. play game as usual

[tyqualters]

Replying to #3566 (comment)

That approach is not a great fix because any ALT+TAB messes it right back up. Setting the window as "Always on Top" (right click on CS2 in task bar, more > keep above others) in Full Screen mode seems to be a good enough fix for me as it only needs to be applied once per session and doesn't get messed up with ALT+TABs or other common behaviors.

[senecaso]

Good to know, I'll give that a try as well. I don't typically alt-tab out, so I haven't noticed that side-effect yet. If your approach works, then that's easier until it can be properly fixed.

[luisalvarado]

This might be related to the package manager. When conducting an experiment between the DEB, Flatpak and Snap versions, I also noticed this same issue with the Flatpak one (At least more of it) compared to the snap which had none, but I will leave the video here to explain better https://www.youtube.com/watch?v=2FBnTa33jSQ

It is more about stuttering and inconsistencies, but this was also felt during the recording, so I just happen to see someone also created an issue about it.

[turrini]

The same thing is happening to me. I'm using Debian Bookworm (stable, steam.deb, and no packages from testing/sid/experimental), and since the introduction of Arms Race, most of the time, mouse1/2/3/4/5 doesn't work. The fastest way to trigger this on my machine is by pressing ctrl+alt+mouse1 or just ctrl+mouse1 (I use ctrl for crouch and alt for walk, and inverted y-axis, I know, really uncommon =D )

I suppose that the screen is not really going to fullscreen, and it doesn't matter if it's windowed or not.

[ipaqmaster]

For me the problem has been happening with xfce4-panel but the problem only begun in early Feb 2024. I have a shell one-liner kill and restore it after cs2 closes as a workaround for the time being. It is set to 'always' hide.

[henrym11106]

Still a problem on Plasma 6 + x11, and as with plasma 5, disabling auto-hide usually results in the taskbar staying on top of the game screen in addition to stealing mouse inputs. changing the game from fullscreen to windowed-fullscreen and back can help but alt-tab tends to break it again. no guarantee that the phantom taskbar won't steal inputs either way.

setting the game tab to "keep above others" breaks alt-tab and still allows for stolen inputs sometimes.

[benlc]

Same issue here. Fedora 39, latest Gnome, X11. I believe the issue isn't occurring on wayland

[ipaqmaster]

Extremely lazy toggle command I have in my shell history for xfce4:
! pgrep cs2 && xfce4-panel || pkill xfce4-panel & exit

I had a command with /proc/cs2PidHere watch for automatically starting it back up with inotifywait. But it became a perfection side-project of its own far too quickly.

[uncebb]

I'm also having this issue. Some mentioned the click going to the panel, but still happens even with the panel completely removed from the screen running CS2.

info: OpenSUSE Tumbleweed, x11, KDE Plasma 6

[AmbreKC]

I'm just here to say that I'm also encountering this issue, here are my settings before reading the workarounds suggested in this topic

https://gist.github.com/AmbreKC/0e8e25f9cd3624c8c331036565bd524b

I will try the workarounds listed here and report if I see any improvements.

I also alt-tab out and in a lot during games.

[AmbreKC]

It looks like these windows rules in KDE solved the issue for me

If it's important, I'm using latte-dock not the vanilla kde docks to be able to have per-activity docks and both are set to auto-hide

[tyqualters]

If it's important, I'm using latte-dock not the vanilla kde docks to be able to have per-activity docks and both are set to auto-hide

Just tried it myself and seems to be working for me also. Not using latte-dock.

[HanM23]

This fix works for me as well, using regular kde dock (i have two).
I only (see picture) checked 'yes' for 'Maximized vertically' and 'no' for the others, it does the trick like that. Thank you !

Manjaro/Plasma 6/Nvidia/Intel

EDIT : it does not work at 100%, it minimizes the miss click issue. I tried by adding several other properties like below :

EDIT 2 : I completely resolved this issue, i have deleted the above rule with whatever properties as it's not necessary anymore, for me at least.
This issue comes from the panel within KDE, although, i do not know really if the issue has to be fixed on kde or cs2 side.

Anyway, on my desktop i have two kde panels. One at the bottom with the application launcher and systray and one on the side to launch my favorites applications. The visibility of this panel has to be "Always visible", if i put it on "dodge windows" i have those miss-click issues, with whatever windows rules. Therefore both panels are on "Always visible" and this is fine like that, no more issue.

I cannot compare with Plasma 5, as i had XFCE before plasma 6. XFCE panels were also always visible, and no issue.

Cheers

[dataprolet]

I can confirm that changing the panel to "Always visible" does indeed work.

I also use gamemode to completely kill the whole plasmashell, which also works.
Here's the content of my ~/.config/gamemode.ini:

start=killall plasmashell
end=kstart5 plasmashell

System info and runtime diagnostics.

[tyqualters]

Just an update on my end, the previous fixes have stopped working. The Window Rule method doesn't work, setting to Always on Top doesn't work, and changing back and forth between Fullscreen and Windowed Fullscreen only works sometimes.

Right now, a weird fix is right clicking on CS2 and untoggling CS2 > More > Fullscreen before continuing changing between Fullscreen and Windowed Fullscreen.

Even worse, the fix may last half a game to a game and a half. After that, without switching virtual desktops or ALT+TABing the issue will appear out of nowhere again.

[bryandesrosiers]

Right now, a weird fix is right clicking on CS2 and untoggling CS2 > More > Fullscreen before continuing changing between Fullscreen and Windowed Fullscreen.

I've discovered (on Kubuntu 23.10 atleast) if follow your initial steps but change a couple of things:

1. Right click the CS2 icon (or window bar)
2. Click "More Actions"
3. Click "Configure Special Application Settings"
4. Then add a property for "Fullscreen" and set it to "Force"

Which solves your quirky workaround, allows for alt tabbing, and consistent shooting to be done.

[HammyHavoc]

Replying to #3566 (comment)

Works great!

[ipaqmaster]

Any built-in fix underway for this? I haven't encountered another game with this problem yet.

[henrym11106]

As per #3454 (comment) and #3679 (comment)
adding SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0 %command% to launch options seems to work around this. only tested for about 20 minutes but I don't think I had any problems. nothing else has been reliable for me.

this prevents the game from minimizing and I'm pretty sure this is how CSGO behaved in fullscreen on linux; i.e. the game remains visible in the background while alt-tabbed.

EDIT: can still lose clicks to the phantom taskbar sometimes.

[ipaqmaster]

This problem persists on a brand new Archlinux installation with xfce4-panel running.

In some short testing I didn't experience the issue at all with SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0. Thanks for sharing that. Nothing else has worked and it was really inconveniencing killing the panel before every match to make sure my clicks register.

[HanM23]

This problem persists on a brand new Archlinux installation with xfce4-panel running.

In some short testing I didn't experience the issue at all with SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0. Thanks for sharing that. Nothing else has worked and it was really inconveniencing killing the panel before every match to make sure my clicks register.

I do not think to have to do those things with xfce.

Try this :

1. Use only fixed panels
2. In the properties of the game : xfconf-query -c xfwm4 -p /general/use_compositing -s false; %command%; xfconf-query -c xfwm4 -p /general/use_compositing -s true

You can also use gamemode to run whatever commands you want before and after launch the game. in this case, just put : gamemoderun %command%, in the properties.

Nonethless, if you want to take advantage of freesync or gsync, it's necessary to disable the compositor.

[lightstream]

Also have this problem on XFCE & Arch. Sadly neither SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0 nor the suggestion by @HanM23 to disable compositing made any difference for me. I've also tried other suggestions such as toggling fullscreen modes, changing auto-hide of taskbars, etc with no luck.

The only way I can play CS2 at the moment is to exit XFCE to the command prompt (completely kill X), and restart X standalone i.e. with everything except exec xfce4-terminal commented out in my .xinitrc file. I then have to start Steam from the terminal, and finally I can play with perfect mouse response. Using X standalone is kinda weird, there's no niceties like panels, application menus, window decorations, wallpapers etc. More serious is that I don't think my mic works there.

Previously I was playing fine in Gnome with Wayland, but CS2 just crashes on start-up on that system right now.

edit: actually mic does work fine

[HanM23]

It seems those shooting inconsistencies are no more, what about you ?
I removed the tricks i set as a workaround, shooting is ok now.

[henrym11106]

The issue persists. if I launch the game and set it to fullscreen without touching anything else it's okay for a while but alt-tabbing breaks it for me. other actions might also break it.
AMDGPU, X11, KDE Plasma 6, up-to-date (stable) Arch-based system.

also I now have a weird issue after I guess the last update where my viewmodel jerks and twitches all over the place while moving. changing settings doesn't seem to help.

[ipaqmaster]

Lately I am now experiencing this after killing xfce4-panel. The game is dropping click inputs and I don't have a cause yet.

[ipaqmaster]

also I now have a weird issue after I guess the last update where my viewmodel jerks and twitches all over the place while moving. changing settings doesn't seem to help.

That will be this: #3746

[ipaqmaster]

I figured out this second tier of the same problem for me. I started encountering the issue again earlier this week despite fixing the xfce4-panel variant of this issue with SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0 but CS2 also has issues with a workspace switching mouse feature of this Window Manager.

It turns out the second cause for me is this "Wrap workspaces when reaching the screen edge" setting in the window manager where "With the mouse pointer" is checked as enabled shown in the below screenshot while two or more workspaces exist.

This default feature lets you move your mouse to either the left or right side of the screen and switches you to another workspace if you have more than one enabled. I hide all my distracting junk on a second workspace during the day and sometimes forget to reduce that back to '1' workspace into the evening. This workspace mouse switching feature was causing CS2 to stop processing my clicks as the mouse bumps into the left side of the screen, where the CS2 window meets the edge of my display session.

Like the desktop panel at the bottom causing my mouse clicks to be dropped when I pull down this is an identical problem for the edges of my graphical session. But only when this checkbox is enabled and more than one workspace exists.