| Summary: | Joystick subsystem causes "not responding" when app is in the background | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Anthony @ POW Games <ant> |
| Component: | joystick | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED WORKSFORME | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | sezeroz |
| Version: | HG 2.0 | ||
| Hardware: | x86 | ||
| OS: | Windows 10 | ||
Anthony, can you enter a separate bug for the joystick hot-swap issue? I'd like to fix that ASAP for 2.0.9. Ryan is going to take a look at this bug. Thanks! Okay, so adding some logging to your program to figure out what's up without attaching the debugger... 1) It definitely moves to "not responding" state for me 2) It definitely _doesn't_ move to "not responding" if I don't use SDL_INIT_JOYSTICK 3) It's not locked up! It consistently calls SDL_PollEvent() and returns to the main loop to call my logging code. 4) Adding a renderer to clear the window and present doesn't change things; I was hoping it was Windows complaining that we didn't do any drawing, but it doesn't alter the behavior. Still digging... --ryan. I bisected this and figured out where this broke: https://hg.libsdl.org/SDL/rev/00411ca61edb I haven't dug deeper because I'm about to go to sleep for a few hours, but since this changeset adds a win32 event loop, it's pretty clear what's upsetting Windows in there. Sam, if you're bored, feel free to take this bug while I'm asleep! --ryan. Okay, so here's what's happening, I think: Our normal PumpEvents processing checks all windows in the process for new events (using PeekMessage() with a NULL window handle), so I think having a separate event loop for the device change message window upsets the system in some way that I don't fully understand. We have other message-only windows for other things, and they all just fire from our usual event loop, so I'm assuming it's safe to do the same thing with the device notifications, so long as it all runs on the correct thread. Just removing the second event loop stops the Not Responding issue, and hotplugging a joystick still correctly alerts the message-only window's windowproc, so I put this patch in: https://hg.libsdl.org/SDL/rev/67496c3f9626 If we absolutely _need_ that second event loop, feel free to back out this changeset, but from here it appears to be a correct fix. --ryan. Sam, eta on releasing 2.0.9? How long do I have to report on the hot-swapping thing on Android? I need to investigate further. Ryan, make sure you get enough sleep :) Thanks Ryan! If there are no show stoppers over the weekend, we're releasing on Monday. This bug has come back in 2.0.13 (Sorry Ryan!) I'm building the DLL with the VS2019 project. When using SDL_INIT_GAMECONTROLLER or SDL_INIT_JOYSTICK subsystem any app will cause a "Not responding" task if the window doesn't receive any input for 5+ seconds. The app doesn't lock and usually resumes normally once mouse / keyboard input is given to the window. I have no joysticks plugged in. Disabling / Enabling background events or HIDAPI doesn't seem to affect it. Was 2.0.12 good? (out of curiosity..) (In reply to Ozkan Sezer from comment #8) > Was 2.0.12 good? (out of curiosity..) Yes, the current 2.0.12 DLL from the SDL website works no problem, so it's either something that's changed since then, or it's specific to Visual Studio 2019. Optimisation doesn't make a difference. Can you check to see if this fixes it? https://hg.libsdl.org/SDL/rev/9b2477ccb1f0 Whoops, you'll need this too: https://hg.libsdl.org/SDL/rev/395ed93b549f No, and I think it seems worse now, it's struggling to recover from a "not responding". Alt-tabbing away from focus almost certainly locks it. It takes a long time before it frees up. Just to see if we're on the right track, can you verify that SDL_StartJoystickThread() is not getting called, and comment out the call to SDL_CreateDeviceNotification() and see if that helps? Of course I can't reproduce this here. :) Let me dig deeper and get back to you. It doesn't happen with the DLL compiled with debug info, which is strange. Sometimes it doesn't happen at all. Will update in a few hours. Sam, the conclusion is this: I'm confused :-) I started from scratch with the test build and the "not responding" is fixed now in the latest HG source. But, SDL_HINT_JOYSTICK_THREAD makes no difference - it's still fixed, which makes no sense yes. If I do SDL_SetHint(SDL_HINT_JOYSTICK_THREAD, "1"), the "not responding" should return, surely? Also, when I build the DLL with VisualC/SDL.sln project, SDL_JOYSTICK_DINPUT || SDL_JOYSTICK_XINPUT is not defined, so SDL_CreateDeviceNotification() is not compiled anyway? My head hurts now, so if nobody else is having any problem with this, close the bug - it was 100% an issue in 2.0.13 somewhere along the line though, and if SDL_HINT_JOYSTICK_THREAD is having no affect, maybe it's not needed after all. Scratch the part about SDL_JOYSTICK_DINPUT || SDL_JOYSTICK_XINPUT not being defined, they are defined, let me dig a little deeper If I back out of your fix https://hg.libsdl.org/SDL/rev/9b2477ccb1f0 from the latest HG, it still works. Is it possible that some other change in the past 2 weeks already fixed it? That's the only explanation. That, or I'm going mad. Either way, carry on and sorry if I've wasted time :-( I have seen this before, but only when not running under the debugger - and attaching the debugger makes it go away. Does debug vs release build matter? Also, crazy question... have you gotten any Windows updates since you were last able to reproduce it? I just compiled a DLL from a source snap-shot from 3 months ago and the bug exists there, which confirms that it is somehow fixed recently. Since it now works with or without SDL_HINT_JOYSTICK_THREAD, do we need still this hint? I think the hint doesn't hurt and one less thread is a good thing in general. Is there any chance you can bisect to find where this was fixed? I wish I could bisect easily. I'm manually downloading to source and opening up the VC project to compile the DLL, then copying it over to my test project. I'm too dumb / lazy to work out a better way :-) It was very easy to reproduce the bug in Windows 10 with the source code in the first post here - I don't believe there were any other conditions that influenced it other than a moment in time of SDLs source. Okay, well I was able to reproduce this over the summer, and I bisected all the way back to 2.0.4 and wasn't able to find a good build. I'm not sure code is the only factor here. In any case, I'm glad it's resolved for you! To clarify, I found a good build back in 2.0.4 and then after I did the bisect it showed the problem on exactly the same build. |
I hope I'm doing the right thing here. This worked in 2.0.8: #include "SDL.h" int main(int argc, char* argv[]) { SDL_Init(SDL_INIT_JOYSTICK); SDL_Window *window = SDL_CreateWindow("Test", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 500, 500, 0); bool running = true; do { SDL_Event event; while (SDL_PollEvent(&event)) { if (event.type == SDL_QUIT) running = false; } } while (running); SDL_DestroyWindow(window); SDL_Quit(); return 0; } This causes a lock-up after about 5+ seconds of the app losing focus. Observing the app in task-manager, you can see it disappear briefly before coming back as "not responding". Strangely, if you try to observe while running from Visual Studio, the task resumes ok when gaining focus back (something to do with the debugger attachment), but if you run the .exe from file manager, the app will need to be force-closed. 2.0.9 also causes app to restart in Android when certain joysticks are hot-swapped, then permanently breaking the joystick subsystem when the app returns, which didn't happen in 2.0.8. Haven't looked in more detail, but something looks to be broken in the new joystick stuff.