We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2447

Summary: X11 SDL_SetWindowBordered doesn't return if window is hidden
Product: SDL Reporter: James Legg <jlegg>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: jwyatt
Version: 2.0.5Keywords: target-2.0.6
Hardware: x86_64   
OS: Linux   
Attachments: Quick patch that covers most cases

Description James Legg 2014-03-12 09:45:03 UTC 
Under X11, changing the window bordered state of a hidden window with SDL_SetWindowBordered results in SDL_SetWindowBordered not returning. SDL_SetWindowBordered does not freeze if setting the bordered state of a hidden window to the state it already is.

For example:
> $ cat sdltest.cpp
> #include <SDL.h>
> 
> int main(int argn, char **argv)
> {
> 	SDL_Init(SDL_INIT_VIDEO);
> 	SDL_Window * const window = SDL_CreateWindow(
> 		"Window!",
> 		0, 0,
> 		640, 480,
> 		SDL_WINDOW_HIDDEN);
> 	SDL_SetWindowBordered(window, SDL_FALSE);
> 	SDL_Quit();
> }
> $ gcc sddlest.cpp $(sdl2-config --libs --cflags) -g -o sdltest
> $ gdb sdltest
> GNU gdb (GDB) Fedora 7.6.1-46.fc19
[snip]
> (gdb) run
> Starting program: /home/jlegg/test/sdltest 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
[wait several seconds]
> ^C
> Program received signal SIGINT, Interrupt.
> 0x00000035174eb7e0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
> 81	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
> (gdb) thread apply all bt
> 
> Thread 1 (Thread 0x7ffff7ca9740 (LWP 10579)):
> #0  0x00000035174eb7e0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
> #1  0x000000351ac09f42 in poll (__timeout=-1, __nfds=1, __fds=0x7fffffffdc00) at /usr/include/bits/poll2.h:46
> #2  _xcb_conn_wait (c=c@entry=0x60cf50, cond=cond@entry=0x60cf90, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:414
> #3  0x000000351ac0b5df in xcb_wait_for_event (c=0x60cf50) at xcb_in.c:526
> #4  0x000000351a841848 in _XReadEvents (dpy=dpy@entry=0x60ac80) at xcb_io.c:401
> #5  0x000000351a829e51 in XIfEvent (dpy=0x60ac80, event=0x7fffffffdda0, predicate=0x7ffff7db2fe0 <isConfigureNotify>, arg=0x776f48 "\b") at IfEvent.c:68
> #6  0x00007ffff7db511b in X11_SetWindowBordered (_this=<optimized out>, window=<optimized out>, bordered=<optimized out>) at /opt/src/sdl/src/video/x11/SDL_x11window.c:895
> #7  0x0000000000400803 in main (argn=1, argv=0x7fffffffdfa8) at sdltest.cpp:11

I'm using SDL hg c5d603f7094e on x86_64 Fedora 19.
Comment 1 Ryan C. Gordon 2015-02-19 05:22:20 UTC 
Marking a large number of bugs with the "triage-2.0.4" keyword at once. Sorry if you got a lot of email from this. This is to help me sort through some bugs in regards to a 2.0.4 release. We may or may not fix this bug for 2.0.4, though!
Comment 2 Jason Wyatt 2015-04-16 15:08:09 UTC 
This also seems to cause sporadic hangs when using Ubuntu Unity.

Is SDL waiting for the correct event in XIfEvent, in X11_SetWindowBordered (line 867-ish)?

SetWindowBordered either calls XChangeProperty, which generates a PropertyNotify event, or XSetTransientForHint, which doesn't seem to generate any events. Switching to checking for PropertyNotify events instead of ConfigureNotify events seems to cure these hangs.
Comment 3 Jason Wyatt 2015-04-16 15:26:09 UTC 
Created attachment 2127 [details]
Quick patch that covers most cases
Comment 4 Sam Lantinga 2017-08-14 20:17:48 UTC 
Hey Ryan, is this a good change for 2.0.6?
Comment 5 Ryan C. Gordon 2017-08-16 06:31:33 UTC 
(In reply to Sam Lantinga from comment #4)
> Hey Ryan, is this a good change for 2.0.6?

I think the goal with the ConfigureNotify check was to wait until the Window Manager had definitely made a change to the window (and it happens to often work because most WMs moves the client window a little to accommodate the border change...? But that isn't required).

I'm not sure the PropertyNotify event, acknowledging the change, actually means the border of the window has actually gotten around to changing on the WM's end of things, but maybe this just isn't something we can check directly. In which case, maybe just XFlush() and don't wait at all?

(tl;dr: it couldn't hurt to apply this patch, but we might move from waiting forever to not waiting long enough.)

--ryan.
Comment 6 Ryan C. Gordon 2017-08-17 21:53:47 UTC 
Sigh, it turns out we already had this problem and I removed the ConfigureNotify check outright in 2015. I miss my memory some days.

https://hg.libsdl.org/SDL/rev/bbb6d1f2a849

(That was Bug #3052.)

So this _should_ also be resolved for hidden windows. Resolving bug; if this is still causing problems, though, feel free to reopen!

--ryan.