Sign in to follow this  
Matias Goldberg

SDL2 and Linux [RANT]

Recommended Posts

Matias Goldberg    9582

Hi everyone!

 

I chose SDL2 after hearing wonders about it: multiplatform, handles windowing, multiple monitors (specially on Linux!), input, releasing of input grabbing when debugging, it's backed by Valve, etc, etc.

I'm an Ogre developer and we have our own windowing management code for all platforms; however it's not perfect and it doesn't handle input. From what I've heard SDL2 would be a great replacement in all aspects.

 

So I believed what I've been told and went ahead. Now I'm quite pissed. This piece of software is buggy as hell on Linux. This is what I've found:

 

1. Creating a GL context that is not supported (i.e. trying a 4.6 or a 5.0 context) will result in a deadlock when calling SDL_GL_CreateContext (or when making the next X11 function if I create the context myself). The callstack is (sorry for no symbols):

0 __lll_lock_wait 135 0x7ffff5316f2c 
1 _L_lock_909 /lib/x86_64-linux-gnu/libpthread.so.0 0x7ffff5312657 
2 __GI___pthread_mutex_lock 79 0x7ffff5312480 
3 ?? /usr/lib/x86_64-linux-gnu/libX11.so.6 0x7ffff5a27973 
4 ?? /usr/lib/libGL.so.1 0x7fffec262406 
5 ?? /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so 0x7fffe706b844 
6 ?? /usr/lib/libGL.so.1 0x7fffec236022 
7 glXDestroyContext /usr/lib/libGL.so.1 0x7fffec23622c 
8 ?? /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 0x7ffff6e1e931 
9 ?? /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 0x7ffff6e13710 
10 Demo::GraphicsSystem::initialize GraphicsSystem.cpp 140 0x42906e
It may look like it could be AMD's GL driver fault, or the dri driver, or X11. But this doesn't happen when the GL context attempt is used on a non-SDL window.
Either SDL2 is at fault, or it is setting some obscure property on the X11's window that triggers this 100% repeatable deadlock.
 
2. Unless the window starts maximized (the bug can still be triggered by restoring the maximized window and then maximizing it again), maximizing the window will leave a small portion of the screen to the left not being rendered.
This could get fixed by making the window borderless when going fullscreen... except that all the ways to query if the window is maximized are broken!!!
Similar bugs have already been noticed, and turns out the cause of all these issues have been reported over and over and over again. The bug reports even contain patches to fix the problem! And it's an easy one! But it appears they never made into the repo, despite some of the bug reports being 2 years old.
 
3. There's like a chance of 1 in 5 that if I set a breakpoint in QtCreator while my application is rendering, to lock the entire system. I can only move the mouse, music still plays (until the end of the track is reached) and that's it. Clicking doesn't do anything, the keyboard is completely locked up. I must do a hard reset.
 
4. Going fullscreen that involves changing the display resolution will report the wrong screen size (i.e. if I demand 1280x720 but I was at 1920x1080 when launching; SDL2 wrongly reports the resolution is now 1920x1080; leading to incorrect rendering)
 
 
So simply... WHAT THE F**K!?
I thought this was a solid stable piece of software recommended by Valve for Linux gaming. I know for personal experience that window and input management on Linux is a nightmare so I expected things to not go fully smooth, but what I found highly under-delivered and frankly, it is over hyped.
Turns out the windowing code we have in Ogre seems to be working better than SDL's so far. Too bad it doesn't handle input; which is an aspect I do like about SDL and have no complaints.
Am I wrong? Am I the only one with these problems??? Am I overreacting?

Share this post


Link to post
Share on other sites
TheChubu    9454


I think it's a little silly to be angry about a product which was provided to you to use for free.
Free software isn't above criticism. That you think that you have to pay for something for you to criticize it tells me more about you than about how silly the idea might be.

Share this post


Link to post
Share on other sites
Roots    1625

 


I think it's a little silly to be angry about a product which was provided to you to use for free.
Free software isn't above criticism. That you think that you have to pay for something for you to criticize it tells me more about you than about how silly the idea might be.

 

 

Of course it isn't. I never said it was. But when I read the original post, I sensed it more anger (it was tagged with [RANT] after all) than criticism. Maybe that was wrong to presume of me though. It's difficult to discern one's emotions over a forum such as this.

Share this post


Link to post
Share on other sites
Brain    18906

 


I think it's a little silly to be angry about a product which was provided to you to use for free.
Free software isn't above criticism. That you think that you have to pay for something for you to criticize it tells me more about you than about how silly the idea might be.

 

 

Personally, i believe that rather than criticise open source software the correct cultulral thing to do is contribute and fix the issues. It isn't above criticism but when you have the skill set, time and access to be able to fix it yourself, why not "quit-yer-bitchin' and get coding"? :)

 

Glad to hear though that the bugs were fixed pretty sharpish, nobody likes to be told their code is bad, and most developers will of course jump on these things but they have to be told about them first, sometimes repeatedly ;)

Share this post


Link to post
Share on other sites
Matias Goldberg    9582

Roots was correct, my anger was in over excess considering it is free software.

 

However good part of that anger was fueled by the fact that one major bug (maximizing, resizing and restoring) was not only reported in 2012, but also had multiple patches proposed that were never applied. This made me question the will of the developers to push the sw forward on the Linux platform.

Add that to the other bugs, and my anger went off charts. I mean, a program that hangs if the video drivers aren't really, really up to date (i.e. we first try to create a GL context, if that fails try to do it again with a lower spec) can't be deployed (the amount of bug reports would be too high); which means I would have to seriously reconsider using SDL.

 

However considering two of those major bugs got fixed (which strongly affect end-user deployment) were fixed within a day after this post, restores my faith on the software; living up to its good reputation.

Edited by Matias Goldberg

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this