[Linux] Unable to aim towards top-left corner with mouse

[sebth]

When aiming towards the top-left corner with the mouse in-game (both offline and online), the view stops moving. I'm able to aim in all directions except diagonally towards the top-left corner. This happens both in fullscreen and in windowed mode, no matter how fast or slow I move the mouse, altough the mouse is allowed to travel a small distance before the view stops moving. Disabling raw mouse input doesn't help.

The distance the mouse is allowed to travel before the view stops moving seems to depend on the resolution / window size: the problem is more apparent with a low resolution and a low mouse sensitivity.

System information output from Steam:

Processor Information:
    Vendor:  AuthenticAMD
    CPU Family:  0x10
    CPU Model:  0xa
    CPU Stepping:  0x0
    CPU Type:  0x0
    Speed:  2800 Mhz
    6 logical processors
    6 physical processors
    HyperThreading:  Unsupported
    FCMOV:  Supported
    SSE2:  Supported
    SSE3:  Supported
    SSSE3:  Unsupported
    SSE4a:  Supported
    SSE41:  Unsupported
    SSE42:  Unsupported

Network Information:
    Network Speed:  

Operating System Version:
    Debian GNU/Linux 7.6 (wheezy) (64 bit)
    Kernel Name:  Linux
    Kernel Version:  3.2.60
    X Server Vendor:  The X.Org Foundation
    X Server Release:  11204000
    X Window Manager:  awesome
    Steam Runtime Version:  steam-runtime-release_2014-08-20

Video Card:
    Driver:  NVIDIA Corporation GeForce GT 630/PCIe/SSE2

    Driver Version:  4.3.0 NVIDIA 319.82
    OpenGL Version: 4.3
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 75 Hz
    VendorID:  0x10de
    DeviceID:  0x1284
    Number of Monitors:  1
    Number of Logical Video Cards:  1
    Primary Display Resolution:  1680 x 1050
    Desktop Resolution: 1680 x 1050
    Primary Display Size: 18.50" x 11.81"  (21.93" diag)
                                            47.0cm x 30.0cm  (55.7cm diag)
    Primary Bus: PCI Express 8x
    Primary VRAM: 2048 MB
    Supported MSAA Modes:  2x 4x 8x 16x 

Sound card:
    Audio device: AV200

Memory:
    RAM:  7977 Mb

Miscellaneous:
    UI Language:  English
    LANG:  POSIX
    Microphone:  Not set
    Total Hard Disk Space Available:  906645 Mb
    Largest Free Hard Disk Block:  377110 Mb

Installed software:

Recent Failure Reports:

(My mouse is a standard USB mouse which uses the evdev driver; nothing special. It works fine in other games like Counter-Strike 1.6 and Quake 3.)

[sebth]

I tried playing without any window manager running, and the problem persists, so it has nothing to do with 'awesome'.

[sebth]

It seems like CS:GO ignores relative SDL_MOUSEMOTION events with mouse position (0, 0). I've managed to work around this bug by patching SDL2 to clamp the mouse to x > 0 when it is in relative mode.

[thatarchguy]

I am having a problem similar. When I look top left, my sensitivity drops almost in half. I noticed this on a few maps where I had to look up and to the left, like going into boiler on inferno map.

I run Arch with AwesomeWM

[fallore]

@sebth any chance youre still around to explain your workaround? i have no idea how to do what you mentioned

[sebth]

This problem disappeared for me when I upgraded from Debian 7 to Debian 8. I haven't tried to figure out what could've caused the behaviour to change, but this is the patch I used:

diff -ru SDL2-2.0.3/src/events/SDL_mouse.c SDL2-2.0.3.fix/src/events/SDL_mouse.c
--- SDL2-2.0.3/src/events/SDL_mouse.c   2014-03-16 03:31:44.000000000 +0100
+++ SDL2-2.0.3.fix/src/events/SDL_mouse.c   2014-09-24 16:10:19.000000000 +0200
@@ -238,31 +238,33 @@
     }

     /* Update internal mouse coordinates */
-    if (!mouse->relative_mode) {
-        mouse->x = x;
-        mouse->y = y;
-    } else {
-        mouse->x += xrel;
-        mouse->y += yrel;
-    }
+    if (!relative) {
+        if (!mouse->relative_mode) {
+            mouse->x = x;
+            mouse->y = y;
+        } else {
+            mouse->x += xrel;
+            mouse->y += yrel;
+        }

-    SDL_GetWindowSize(mouse->focus, &x_max, &y_max);
-    --x_max;
-    --y_max;
+        SDL_GetWindowSize(mouse->focus, &x_max, &y_max);
+        --x_max;
+        --y_max;

-    /* make sure that the pointers find themselves inside the windows */
-    if (mouse->x > x_max) {
-        mouse->x = x_max;
-    }
-    if (mouse->x < 0) {
-        mouse->x = 0;
-    }
+        /* make sure that the pointers find themselves inside the windows */
+        if (mouse->x > x_max) {
+            mouse->x = x_max;
+        }
+        if (mouse->x < 0) {
+            mouse->x = 0;
+        }

-    if (mouse->y > y_max) {
-        mouse->y = y_max;
-    }
-    if (mouse->y < 0) {
-        mouse->y = 0;
+        if (mouse->y > y_max) {
+            mouse->y = y_max;
+        }
+        if (mouse->y < 0) {
+            mouse->y = 0;
+        }
     }

     mouse->xdelta += xrel;

Basically it stops the updating of mouse coordinates when the mouse is set to relative mode. This prevents the mouse from getting to coordinates (0, 0) when in-game. I guess you could also modify the statements under /* make sure that the pointers find themselves inside the windows */ to stop the mouse at 1 instead of 0, but I can't test that as the problem disappeared.

So, to get CS:GO to use this, just get the SDL2 source code (https://www.libsdl.org/release/SDL2-2.0.3.tar.gz), patch it with the patch above, and build it. You don't need to install the library as we are going to preload it. Remember to build it as a 32-bit library even if you're on a 64-bit system, as CS:GO is 32-bit. (If you need help on how to patch and build an open source project, there are many good guides on the web if you search for it.)

After you've built the library, right click on CS:GO in your Steam games list, choose Properties, and then Set Launch Options. Use this as your Launch Options: LD_PRELOAD=/path/to/SDL2-2.0.3/build/.libs/libSDL2-2.0.so.0 %command%, and CS:GO will use your patched SDL2 instead of the bundled one.

[ggnolife]

Make sure you do "CFLAGS='-m32 -O2' LDFLAGS=-m32 ./configure --build=i686-pc-linux-gnu" before you build it so it builds as 32bit!

[davidw-valve]

I am trying to work out this issue but am not having much luck reproducing it so far.

For people it occurs for, does it occur for other Source FPS games, such as TF2 or Portal 2? (Dota2 uses very different mouse code so isn't a good comparison point).

[fallore]

So, I am having the version of the problem where my sensitivity is cut in half (approximately) when I move my view up and left, not that it stops altogether. I tried on TF2 and it seems to be completely fine. I don't have portal 2 installed nor time to test it at the moment, unfortunately. I've posted my specs and specific problem in #405

[sebth]

The Source FPSes I have are CS:GO and Half-Life 2. When I was running Debian 7, I only had this problem in CS:GO, not in Half-Life 2.

[atomicflag]

@davidw-valve sebth's patch seems to have solved the problem for me. Tested Portal 2 - works fine as it is.

[fallore]

@coffee-lord were you having sebth's version of the problem where you couldn't aim up and to the left at all, or mine where your sensitivity in that direction was halved? do you think you could upload your patched SDL? i am having no luck changing and building mine on my own.

[fallore]

so i finally figured out how to correctly build the directory with the patched mouse file and can confirm that this problem is different than mine in #405 or at least that it did not solve it for me, if that's any help to you @davidw-valve

[atomicflag]

@fallore in my case the problem was halved sensitivity when moving towards upper left corner. Initially i tried different polling rates for mouse (125,500,1000 Hz) and found that this issue had gotten worse when the polling rate was low (125 Hz). I might be wrong though. are you sure that the lib's preloaded correctly? it has to be 32 bit. i think the game will still launch if the lib's 64 bit but the fix won't work.

[fallore]

@coffee-lord is there a way to check if i built the directory correctly, or if csgo is loading it correctly? i used the flags to make it 32 bit, or at least received no error when i input them before the ./configure and make commands. these are the commands i used:

153 CFLAGS='-m32 -O2' 154 LDFLAGS=-m32 155 ./configure --build=i686-pc-linux-gnu 156 make

i made the correct changes to the mouse.c file before i built it, and i received no errors when i built it. my launch option is thus "LD_PRELOAD=/home/fallore/SDL2-2.0.3/build/.libs/libSDL2-2.0.so.0 %command% -freq 144 -novid -console "

i also tried it without the -freq 144 etc commands to see if that was the problem

any other info i can share that might enlighten why this did not work for me?

[atomicflag]

@fallore what does the file /home/fallore/SDL2-2.0.3/build/.libs/libSDL2-2.0.so.0 say? i think file's supposed to tell you whether it's 32 or 64 bits. Apart from that it looks like you did the same thing i did. Weird. i know this inconsistency in mouse sensitivity can be so annoying

[fallore]

@coffee-lord i'm unable to open it in text editor. it tells me it doesn't detect the character encoding? how do i check?

[atomicflag]

@fallore no it's a tool called file. much like ls and cd. e.g.

$ file /usr/lib/libgc.so.1.0.3 
/usr/lib/libgc.so.1.0.3: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=5ca785446841d41354db10857ad89ef83a870c80, stripped

[fallore]

so file does show it linked to the proper file (file libSDL2-2.0.so.0
libSDL2-2.0.so.0: symbolic link to `libSDL2-2.0.so.0.2.1' ), but when i put the launch option CSGO wont start. i'm pretty lost at this point :(

i was able to find this error log if anyone can tell me what it means/what i need to do

http://dpaste.com/3BGHPMB

[atomicflag]

@fallore Wait, so you're saying it did work before the patched lib right? So after adding LD_PRELOAD part CSGO doesn't start anymore? I found your system info in #405 so i assume it did work before. If that's the case then i don't know what might be causing it yet. Your log seems to be the same as mine up to the point where SDL tries to initialize the video thing and then segfaults. You haven't messed with the steam runtime or anything haven't you? Other things you could try is to put the path to the real lib instead of symlink (e.g. absolute path to libSDL2-2.0.so.0.2.1) and put the path in quotes like this LD_PRELOAD="path...". Then you could try to ./configure the lib all in one line, e.g.

CFLAGS='-m32 -O2' LDFLAGS=-m32 ./configure --build=i686-pc-linux-gnu

instead of

CFLAGS='-m32 -O2'
LDFLAGS=-m32
./configure --build=i686-pc-linux-gnu

I'm talking out of my ass here but it might be still worth to try it. It says in your system profile that you have 3 monitors; maybe try plugging 2 off and see if it works with just one?

[sebth]

@fallore @coffee-lord Yes,

CFLAGS='-m32 -O2'
LDFLAGS=-m32
./configure --build=i686-pc-linux-gnu

is wrong. If you don't type export in front of the variables, configure won't see them. Use

CFLAGS='-m32 -O2' LDFLAGS=-m32 ./configure --build=i686-pc-linux-gnu

or

export CFLAGS='-m32 -O2'
export LDFLAGS=-m32
./configure --build=i686-pc-linux-gnu

.

To see which libSDL CS:GO is using, you can run lsof -ppidof csgo_linux| grep libSDL while CS:GO is running.

[ahnook]

I've uploaded a video demonstrating steps to reproduce this bug. While testing, I discovered that mouse DPI makes a huge difference on whether or not you'll trigger this bug under normal gameplay. Higher DPI means a higher chance of the cursor going into the top left corner, which causes the issue. I myself played for a whole year with 400 DPI and I had never triggered this bug before, but as soon as I raised it while playing around with my DPI+sensitivity due to the 2016-01-07 update, I immediately ran into it.

I suspect this might be the reason why some people have always had trouble with this, while others have never experienced it, especially considering how popular 400 DPI is in CS:GO. I also wonder if this might be the reason why @davidw-valve has been unable to reproduce it so far.

I can confirm that @sebth's patch fixes the issue, however it also causes my cursor to stop working if I press escape in game to access the menu, as I do in the video above. Because of this, I used instead the following patch, which prevents the cursor from going into the (0,0) position by warping it to (1,0).

diff -drp -u10 SDL2-2.0.4.orig/src/events/SDL_mouse.c SDL2-2.0.4/src/events/SDL_mouse.c
--- SDL2-2.0.4.orig/src/events/SDL_mouse.c  2016-01-02 17:56:31.000000000 -0200
+++ SDL2-2.0.4/src/events/SDL_mouse.c   2016-01-08 16:43:48.590681755 -0200
@@ -261,20 +261,24 @@ SDL_PrivateSendMouseMotion(SDL_Window *
         if (mouse->x < 0) {
             mouse->x = 0;
         }

         if (mouse->y > y_max) {
             mouse->y = y_max;
         }
         if (mouse->y < 0) {
             mouse->y = 0;
         }
+
+        if (relative && mouse->x == 0 && mouse->y == 0) {
+          mouse->x = 1;
+        }
     }

     mouse->xdelta += xrel;
     mouse->ydelta += yrel;

     /* Move the mouse cursor, if needed */
     if (mouse->cursor_shown && !mouse->relative_mode &&
         mouse->MoveCursor && mouse->cur_cursor) {
         mouse->MoveCursor(mouse->cur_cursor);
     }

Some extra info:

• A new update came out while I was typing this. I just tested this issue and it persists.
• The issue occurs in fullscreen, windowed or fullscreen windowed modes. Native resolution and lower resolutions both seem to be affected (at least the ones I tested).
• As already mentioned by @sebth, toggling m_rawinput doesn't make any difference. X.org mouse acceleration also does not make a difference.
• My own system information (note that the recent failures at the bottom have nothing to do with this issue).

[JoshuaMurphynz]

Works fine in the buy menu. Just in game is broken On 9 Jan 2016 15:12, "ahnook" notifications@github.com wrote:

I've uploaded a video demonstrating steps to reproduce this bug https://youtu.be/m4P8uTWSgxs. While testing, I discovered that mouse DPI makes a huge difference on whether or not you'll trigger this bug under normal gameplay. Higher DPI means a higher chance of the cursor going into the top left corner, which causes the issue. I myself played for a whole year with 400 DPI and I had never triggered this bug before, but as soon as I raised it while playing around with my DPI+sensitivity due to the 2016-01-07 update, I immediately ran into it.

I suspect this might be the reason why some people have always had trouble with this, while others have never experienced it, especially considering how popular 400 DPI is in CS:GO. I also wonder if this might be the reason why @davidw-valve https://github.com/davidw-valve has been unable to reproduce it so far.

I can confirm that @sebth https://github.com/sebth's patch fixes the issue, however it also causes my cursor to stop working if I press escape in game to access the menu, as I do in the video above. Because of this, I used instead the following patch, which prevents the cursor from going into the (0,0) position by warping it to (1,0).

diff -drp -u10 SDL2-2.0.4.orig/src/events/SDL_mouse.c SDL2-2.0.4/src/events/SDL_mouse.c--- SDL2-2.0.4.orig/src/events/SDL_mouse.c 2016-01-02 17:56:31.000000000 -0200+++ SDL2-2.0.4/src/events/SDL_mouse.c 2016-01-08 16:43:48.590681755 -0200@@ -261,20 +261,24 @@ SDL_PrivateSendMouseMotion(SDL_Window * if (mouse->x < 0) { mouse->x = 0; }

     if (mouse->y > y_max) {
         mouse->y = y_max;
     }
     if (mouse->y < 0) {
         mouse->y = 0;
     }++        if (relative && mouse->x == 0 && mouse->y == 0) {+          mouse->x = 1;+        }
 }

 mouse->xdelta += xrel;
 mouse->ydelta += yrel;

 /* Move the mouse cursor, if needed */
 if (mouse->cursor_shown && !mouse->relative_mode &&
     mouse->MoveCursor && mouse->cur_cursor) {
     mouse->MoveCursor(mouse->cur_cursor);
 }

Some extra info:

• A new update came out while I was typing this. I just tested this issue and it persists.
• The issue occurs in fullscreen, windowed or fullscreen windowed modes. Native resolution and lower resolutions both seem to be affected (at least the ones I tested).
• As already mentioned by @sebth https://github.com/sebth, toggling m_rawinput doesn't make any difference. X.org mouse acceleration also does not make a difference.
• My own system information http://pastie.org/pastes/10678642/text?key=utvgqzlbmpvnh92whypdsq (note that the recent failures at the bottom have nothing to do with this issue).

— Reply to this email directly or view it on GitHub https://github.com/ValveSoftware/Counter-Strike-Global-Offensive/issues/44#issuecomment-170180858 .

[andras-kiss]

Just tested @ahnook 's patch with 2.0.4, it works. Corner bug gone. But I think I will use the valve version, I'm too worried about a VAC ban.

[AnAkkk]

You can simply use the SDL in built feature to load another SDL version: https://plus.google.com/+RyanGordon/posts/TB8UfnDYu4U

export SDL_DYNAMIC_API=/path to other sdl

[BeniaminK]

@ahnook How did you test this script? I already built the libSDL, placed it in the ~/.steam/steamapps/common/Counter-Strike Global Offensive/bin folder replacing the old libSDL2-2.0.so.0 library (I added some additional debugging to see, whether this file is used) and as I see, the game doesn't load this library. Could you provide more information what should I do to make it work?

export SDL_DYNAMIC_API= - this doesn't work neither

[ahnook]

@BeniaminK I used LD_PRELOAD in csgo's launch options, as described by @sebth in his comment above where he posted his own patch. Here's a step by step of the whole process, since I saw others also having trouble testing this.

1. Download libsdl's code and unpack it somewhere (I'll be using ~/libsdl in this example):

mkdir ~/libsdl
cd ~/libsdl
wget 'https://www.libsdl.org/release/SDL2-2.0.4.tar.gz'
tar xvzf SDL2-2.0.4.tar.gz

2. Still inside the same folder, download the patch and apply it:

wget 'http://pastie.org/pastes/10680849/download' -O sdl_0x0.patch
patch -p0 < sdl_0x0.patch

3. Enter the extracted folder and compile libsdl for 32-bit:

cd SDL2-2.0.4
CFLAGS='-m32 -O2' LDFLAGS=-m32 ./configure --build=i686-pc-linux-gnu
make

4. Open steam, open your library, right click CS:GO on the menu on the left and click 'Properties'

5. In the window that opens, go into the 'General' tab and click the 'Set launch options...' button.

6. In the window that opens, prepend whatever options you might already have in there with

LD_PRELOAD=$HOME/libsdl/SDL2-2.0.4/build/.libs/libSDL2-2.0.so.0 %command%

If you already have %command% in there, then don't duplicate it, just prepend the LD_PRELOAD part.

Remember to click OK to save your changes.

7. Run CS:GO and check that it is using your patched lib (also as described by @sebth above):

lsof -p `pidof csgo_linux` | grep libSDL

If all went well, you should see a line ending in the path to your patched lib. If not, you will see the path to some other copy of the lib in your system.

Note that it is critical that you compile the lib for 32-bit and also that LD_PRELOAD points correctly to it, without any typos.

Finally, if you want to go back to valve's copy of the lib at any time, just edit the launch options again and remove the LD_PRELOAD part.

I hope this helps.

[carbn]

I've successfully worked around this issue by lowering my mouse DPI from 1600 to 400 and setting my sensitivity to 4x. With 1600 DPI the game is almost unplayable, but with 400 the bug is not even noticeable. The only problem is that buying using the mouse is a bit awkward as the cursor speed is super slow. I'd still prefer to have 1600 DPI in-game as I use it also on the desktop.

[btegs]

@carbn - 1600 DPI is pretty high for this game. Most pros put their DPI at something like 400 or 450 DPI and then adjust the in-game sensitivity to achieve an ideal "real sensitivity" between 800 and 1000.

[rtuovine]

I am able to reproduce the bug the same way as in ahnook's video above.

SDL version is, using lsof -ppidof csgo_linux| grep libSDL

...Counter-Strike Global Offensive/bin/libSDL2-2.0.so.0

and my system information is here.

I was not able to compile and link another version, as was also suggested by ahnook. When writing make I get

/usr/bin/ld: "cannot find -lts"

which (I think) is because this libts is not compatible with 64 bit. I couldn't find a way around this (except tweaking the DPI and sensitivity so that the bug isn't so noticeable).

[ahnook]

@rtuovine maybe try configuring with CFLAGS='-m32 -O2' LDFLAGS=-m32 ./configure --build=i686-pc-linux-gnu --disable-input-tslib and see if that error goes away.

---

I've experimented with this bug some more and discovered that, while mouse DPI greatly affects whether the cursor will move into the top left corner and trigger the bug, in-game FPS will greatly affect how much the crosshair will be decelerated once the bug is triggered.

I've uploaded a video demonstrating this effect. At 60 FPS, the deceleration is so slight I can only tell it is happening by attempting to repeatedly move the mouse up-left and down-right between the same two points (at first there seems to be no deceleration, but after enough iterations, the crosshair visibly drifts towards the bottom right corner). On the other hand, at 700+ FPS, the deceleration is so great that I can barely move the crosshair at all, even while quickly dragging my mouse all the way across the mousepad.

In conclusion, people trying to reproduce this bug should reduce video quality settings and uncap their framerate before attempting the reproduction, while people trying to minimize the effects of the bug during normal gameplay should cap their framerate with fps_max to as low a value as possible (in addition to reducing their mouse DPI as already suggested above).

[zikk]

Hello, thnks everybody, it's reassuring to see that the bugs are submitted and people find solutions. Still, after following the steps show from @ahnook or @sebth and i change my launch options in steam, the game no longer launch, i don't know why :/ If anybody can be of help, you'd save me :)

[ramyD]

Just wanted to add that this is the configure line that actually worked for me:

CFLAGS='-m32 -O2' LDFLAGS=-m32 ./configure --build=i686-pc-linux-gnu -C --x-includes=/usr/lib/x86_64-linux-gnu/ --x-libraries=/usr/inclue/X11/

[zikk]

@ramyD I tried you configure method, it wouldn't compile afterward with it. I still can't run the game with the LD_PREALOAD, i'm getting this error : http://pastebin.com/Ufy4tw1d

[hasufell]

I can't believe that a bug that breaks mouse behavior has been unfixed since September 2014. Are you serious valve?

[zikk]

Makes me wonder, it seems that Stattrak music kits are a more important thing to be focusing on!

[andras-kiss]

@thedoctorz Well yeah. That's a big part of the income/profit that keeps cs:go going. I would say that's a great thing that people are buying these skins, and Valve is smart enough to focus on these. Would be great though if they fixed issues like this and the sound-loop bug which is even more annoying.

[zikk]

This fix seems so easy to make, that i just don't understand how are they still delaying it or something ? I know that the skins are part of their income, and if i were them i'd milk it to death. Doesn't mean you have to forget part of your players.

[hasufell]

and Valve is smart enough to focus on these

There's nothing smart about not fixing important bugs. It upsets customers.

[andras-kiss]

@hasufell Most people don't notice it and most people who notice it don't care. If you have finite resources, you need to prioritize. Look how many people are concerned with this bug, and how many are with skins... Don't get me wrong: I also consider fixing gamebreaking bugs more important than silly skins. But there is a bigger picture. You need stupid people to buy skins in order to continue develping the game. This bug WILL be fixed. And guess where the money will come from to employ the developer who will do the patch: skins...

[hasufell]

@andras-kiss I don't need a lecture on valves business model. And I don't care at all where their money comes from. I'm a customer and I care about bugs getting fixed in a resaonble timeframe. This timeframe is not reasonable. Period.

[andras-kiss]

@hasufell You can fix it yourself. ahnook's patch works.

[hasufell]

That is wrong. It's not an SDL bug. And I am not interested in getting VAC banned by hacking on libraries.

[andras-kiss]

@hasufell Yeah that's true. Let's hope Valve fixes it soon.

[ramyD]

Hey everyone, could we please keep the discussion on topic and not pollute the bug thread with opinions?

@thedoctorz Could you paste the result of the ./configure line (before typing "make"). Here is what mine looks like. If SDL is not compiling then it's definitively not going to work when running CSGO.

Also, what version of linux are you running?

SDL2 Configure Summary: Building Shared Libraries Building Static Libraries Enabled modules : atomic audio video render events joystick haptic power filesystem threads timers file loadso cpuinfo assembly Assembly Math : mmx 3dnow sse Audio drivers : disk dummy oss pulse(dynamic) Video drivers : dummy x11(dynamic) opengl opengl_es2 wayland(dynamic) X11 libraries : xcursor xdbe xinerama xinput2 xinput2_multitouch xrandr xscrnsaver xshape xvidmode Input drivers : linuxev linuxkd Using libudev : YES Using dbus : YES Using ibus : YES

[hasufell]

Hey everyone, could we please keep the discussion on topic and not pollute the bug thread with opinions?

Posting hacks that may get you VAC banned in a bug report thread isn't much more ontopic. This has to be fixed by valve. If you think this is an SDL bug (pretty unlikely), post it on the SDL bug tracker: https://bugzilla.libsdl.org/

[zikk]

@ramyD, I get this:

SDL2 Configure Summary:

Building Shared Libraries Building Static Libraries Enabled modules : atomic audio video render events joystick haptic power filesystem threads timers file loadso cpuinfo assembly Assembly Math : mmx 3dnow sse Audio drivers : disk dummy oss alsa(dynamic) Video drivers : dummy x11(dynamic) opengl X11 libraries : xshape xvidmode Input drivers : linuxev linuxkd Using libudev : YES Using dbus : NO

[ramyD]

what distro?, Ubuntu?

[zikk]

Ah sorry, Forgot openSUSE tumbleweed

[ramyD]

Ok then I'm not sure what kind of window system you're using since openSUSE has an experimental support for wayland. Please post your system information as described in the readme of this project.

The error you're getting when launching CSGO "SDL_Init(SDL_INIT_VIDEO) failed: No available video device" happens when the SDL lib you compiled doesn't find where to output the video - I had this exact error and noticed that it wasn't detecting my x11 libs, hence my post for the config. I'm unsure if you're on another window compositor or if you're simply missing xorg-dev libs. I'll get a better idea after you post your system information

[zikk]

@ramyD Here's the system information output by steam: http://pastebin.com/nWj37gj7