This happens on any window manager that doesn't wrap the client window in another frame -- such as all of the tiling window managers, evilwm, etc.
I'm on Arch (EndeavourOS), XFCE and LightDM and have this problem as well.
I don't see actual errors in steam logs, I've added all the steamlogs anyway, maybe you can see more.
logs.zip
I've just recorded it with OBS as well:
https://youtu.be/GocSVsKH88Y
This happens on any window manager that doesn't wrap the client window in another frame -- such as all of the tiling window managers, evilwm, etc.
Yeah, I've tried Plasma just to check this.
On Plasma, everythings fine.
On XFCE, Steam is doing this weird thing hanging in specific places, loitering around and not doing what i want it to do.
This is happening to me as well. I cannot drag any Steam windows by click-dragging the title bars. The window will move once about every 1000 tries if I use my "Super" Key and click-drag the Steam client window.
The setting I have set is in Window Manager Tweaks > Accessibility > "Key used to grab and move windows:" - Super
Are there any semi-reliable workarounds other than switching window managers?
Steam Beta Branch: Stable Client
Steam Version: 1709846872
Linux Version 6.7.8-arch1-1
Intel i9-10850k
NVIDIA RTX3080
I can report similar issues on Arch using Xmonad. Given that Xmonad is a tiling window manager with forced window placement, you can actually see the WM fight the Steam window: I have different colored borders for non-/focused windows and the Steam window borders get redrawn constantly. This essentially DOSes the WM (100% process utilization) and compromises other functionality as well (cf. ValveSoftware/steam-for-linux#10545).
Funnily enough, this issue does not occur on i3 (another tiling WM). Maybe https://github.com/ValveSoftware/steam-for-linux/issues/10544#issuecomment-1970723691 has some merit to it. The issue did not occur on previous versions.
I'm having the same problem on Gnome Xorg. I have Hyprland for messing arround, but Gnome is my DE and it was working yesterday.
What I really changed/modified is that I switched from discrete GPU mode to Hybrid mode on my laptop's BIOS. I usually let it on dGPU mode, but I was testing some Wayland this with Gnome 46 and Plasma 6 on another SSD.
I'm switching back to dGPU mode and check if only it makes any difference.
Teste with dGPU only mode and tested also on Gnome Wayland. I can only try to guess here, that using Steam with Hyprland changed its behavior somehow.
I'm using the flatpak version and just removing and reinstalling it did not solve the problem at first. It seems that flatpak is not really uninstalling it, at least not after at least 5 times with --delete-data, since installing it again was too fast for a flatpak (less than 6 seconds with me choosing between stable or beta)
After installing the rpm one via dnf and everything is OK and also after 5+ times uninstalling and reinstalling the flatpak version, it also work.
As I did not touch Steam's nor my NVIDIA's or iGPU's configurations, I don't know what switching between Discrete and Hybrid mode on the UEFI could've messed up.
Fedora Workstation 39
RTX 2060 mobile 6GB
Intel i7 10750h
NVIDIA drivers 550.54.14
Kernel 6.8.0-cb1.0
So one update on my side, i've used gdb to check if I can see any errors in the output of steam while moving its windows (and snapping back to its last location). It does not.
I'm not even a programmer and using tutorials on the web for GDB because this behaviour annoys me so much.
If anyone can nudge me towards a respectable manual how I can trace this error with gdb on lightdm/xfce I would appreciate it.
Tried Steam in a lot of different WMs. A few of the common ones work (Openbox), but most of the older ones (TWM, FVWM, Blackbox) have various issues. If it's a clue to what Steam is doing wrong, one of them kept printing errors about unknown XClientMessageEvent, type 0x269 whenever you try to move the Steam window by click-dragging near the top.
I wish Steam would just behave like a normal program and not try to re-implement what the WM is supposed to do; or at least to stop actively fighting the WM...
Confirming that this issue is also impacting GNOME it seems. I'm running Fedora Workstation 39 and it's simply impossible to move the window outside of using the keystroke to move from one monitor to the other, but even if I do that it still takes up the whole screen.
Valve please can we get this fixed because it's a real hecking issue.
This is on a desktop with a Dedicated GPU ONLY
Having what sounds like the same issue on Mint using Cinnamon.
Just a heads-up for all Xmonad users: The current (unreleased) development version of xmonad-contrib introduces some workarounds for apparently misbehaving client applications such as Steam. In particular, the fixSteamFlicker event handler manages to address the problems I previously encountered and make the Steam client usable again on Xmonad. You can simply copy the relevant lines of code to your local xmonad.hs until the next xmonad-contrib version is released.
Some of the discussion threads go into more detail as to what may be happening in the background. Maybe some of the observations may be useful to other (non-Xmonad) users as well or even Valve to find out what in the Steam client is causing this. If you dare looking at the haskell code, you may even be able to extract a solution for your own environment as well.
I got the latest Beta release today (Steam-Version: 1716866472)
And now it is working again
Thank you <3
Confirmed working with fixStreamFlicker and Steam-Version: 1716584667
Closing per the last couple comments.
Your system information
Please describe your issue in as much detail as possible:
Since last stable steam update, I can no longer move any of the steam windows, they automagically come back to their original position. See this video : https://github.com/ValveSoftware/steam-for-linux/assets/1150555/486692dd-a506-4e2d-9c0f-78efbb59b433
I'm under Gentoo - Xfce-4.18 - Xfwm 4.18.0.
Steps for reproducing this issue: