05787: All: SDLMAME with SDL 2.0 loses focus on start when pressing inputs

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
05787	Interface	Major	Always	Dec 7, 2014, 00:28	Jan 6, 2015, 16:33

Tester	samsho2	View Status	Public	Platform	SDLMAME
Assigned To		Resolution	Open	OS	Windows Vista/7/8 (64-bit)
Status [?]	Acknowledged			Driver
Version	0.156	Fixed in Version		Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	05787: All: SDLMAME with SDL 2.0 loses focus on start when pressing inputs
Description	If you press keys on your keyboard right after launching SDLMAME (with SDL 2 enabled) in OpenGL mode, the SDLMAME window will lose focus and you will be unable to control SDLMAME without clicking on the window with your mouse or tabbing back to it somehow.
Steps To Reproduce	1. Build SDLMAME with SDL 2.0 or 1.2 2. Configure SDLMAME's video setting to use "opengl" 3. Configure SDLMAME to run in full screen mode 4. Open the Windows command prompt, and enter the SDLMAME binary and rom name. 5. Right after pressing ENTER to launch SDLMAME, quickly press the "A" key on the keyboard rapidly. 6. When SDLMAME launches, it will actually be in borderless windowed mode (not true full screen), and the window will not have focus, so you won't be able to do anything in SDLMAME without clicking on the window again.
Additional Information	This happens with both SDL 1.2 or SDL 2.0. This issue makes SDLMAME with OpenGL almost impossible to use in arcade cabinets with frontends. If someone presses a button while a game is launching, it won't be controllable because of this. SDL_WINDOW_FULLSCREEN_DESKTOP works better than SDL_WINDOW_FULLSCREEN, by the way. SDL_WINDOW_FULLSCREEN_DESKTOP gets rid of the flicker when you launch the program. This is the INI file I use: http://pastebin.com/twXVEbpi
Github Commit

Flags
Regression Version
Affected Sets / Systems	All

Attached Files

No.11282 B2K24 Senior Tester Dec 9, 2014, 02:23	This behavior does seem to happen exactly as described. Keyboard inputs have no effect unless you specifically click on the window. I'm noticing while keyboard inputs don't work, I'm still able to use my game pad to send inputs without having to click on the window with my mouse. I'm able to map UI END to a button which I guess could be a partial work-around to this behavior. I don't have an Arcade cabinet, so I'm unable to test that kind of functionality.
No.11284 R. Belmont Developer Dec 9, 2014, 04:58	Why are you hammering on keys while MAME starts up? And does -video accel also show the problem? -video accel is the preferred way to run SDL 2 builds, as it properly shows laserdisc games.
No.11285 samsho2 Tester Dec 9, 2014, 05:14	Trying to make my cabinet kid proof. Kids tend to hammer on buttons right after selecting a game from a frontend. The thing is, it only does it in OpenGL mode, and it doesn't do it in win32 MAME, so it doesn't seem right. Does accel work in Windows? I get this: Invalid video value accel; reverting to software
No.11318 R. Belmont Developer Dec 23, 2014, 02:05 edited on: Dec 23, 2014, 02:06	"Invalid video value accel" indicates an SDL 1.2 compile. -video accel is an SDL 2-specific option, so if you get that error you are not running an SDL 2 compile and this report has some issues.
No.11319 samsho2 Tester Dec 23, 2014, 02:22	I did some more testing and confirmed that this happens in both SDL 1.2 and SDL 2.0. I'm updating.
No.11351 samsho2 Tester Jan 4, 2015, 07:18	For reference, this behavior doesn't seem to be limited to SDLMAME. I'm seeing the same behavior in Retroarch and other OpenGL programs. Is it possibly a general issue with Windows and OpenGL or possibly Windows and SDL?
No.11361 R. Belmont Developer Jan 6, 2015, 04:18	Ok, and this definitely doesn't happen with normal Windows MAME? Because I can understand an explanation for this behavior in terms of how Windows manages keyboard events, but there's no particular reason SDL or OpenGL should affect that.
No.11362 samsho2 Tester Jan 6, 2015, 16:33	It definitely doesn't happen with normal Windows MAME, and it doesn't happen with SDLMAME using software rendering instead of OpenGL, which is why I'm beginning to wonder if it has something to do with OpenGL specifically.