Groovymame 0.169 LINUX SDL 2.0.4 keyboard input issue [closed]

[Doozer]

Hi Folks,

If someone is willing to provide help to test a fix to the latest groovy patch and SDL2 issue please fell free to grab the executable from the link and check if neogeo games are processing the inputs. Thanks.

First ensure that you have the latest SDL2 v2.0.4 release installed (example are made from ArchLinux based systems)

Code: [Select]

[root@cabvm64 ~]# pacman -Q sdl2
sdl2 2.0.4-2

Now you can replace the groovymame executable with the provided one.

GROOVYMAME_SDL2_TEST_VERSION

[Doozer]

It is now obvious that for some games the inputs are not processed at all when groovymame (all version) is combined with SDL 2.0.4.

The reason behind this is coming from SDL that stops to provide events in to the input poller thread. Because this behaviour is not affecting stock mame version, the solution is hiding somewhere inside groovy patch.

[Doozer]

Only the keyboard events are not received, the mouse events are properly transmitted and processed inside sdlinput_poll.

[Calamity]

It could be the app window loosing focus when we switch resolutions. Starting with SDL2 we had to bypass sdl and force mode setting through xrandr, this is done in set_custom_video_mode. I never liked this idea but it was the only way (can't remember the details). If you remove that call to xrandr, maybe it will work (making GM unusable).

[Doozer]

It could be the app window loosing focus when we switch resolutions. Starting with SDL2 we had to bypass sdl and force mode setting through xrandr, this is done in set_custom_video_mode. I never liked this idea but it was the only way (can't remember the details). If you remove that call to xrandr, maybe it will work (making GM unusable).

I have already tested this and xrandr call is not the issue. I had this focus issue idea and forced focus to GM and keys are not received at all.

Now I am a bit struggling with testing because disabling the switchres calls did not bring the keyboard back. That why I changed my approach. I am taking an incremental approach and building stock + hi patch to see if something is hidden here (but I do not expect to find something here). 

[Calamity]

I am taking an incremental approach and building stock + hi patch to see if something is hidden here (but I do not expect to find something here).

Very good idea.

[Doozer]

OK, the issue is qualified. The window focus for any reason is not reported back to SDL2. Forcing the focus with xdotool or using a window manager make GM working as expected. Houra, at least we know what to fix.

@Calamity:

1) Where should the sdlinput_process_events_buf be placed in the worker (stock) or inside the poll_input?
2) How to set the window focus without using _NET_ACTIVE_WINDOW call?

[Calamity]

Great job Doozer!

1) sdlinput_process_events_buf should be placed back in the poll_input call, if it's made sure this is not the cause of the problem
2) No idea of that call. I'd say we must actively use a sdl call to re-attach the focus to window after mode switching, provided that call exists.

[Doozer]

I will play a bit with SDL_WINDOW_INPUT_GRABBED and SDL_WINDOW_INPUT_FOCUS to see how to bring a fix.

[Doozer]

In SDL 2.0.4 the window creation is destroying an intermediate window that will not link to its parent when no window manager is installed. Instead it links to the default X root window.

SDL 2.0.3

Code: [Select]

Destroyed : 0xa00002
Destroyed : 0xa00007
Destroyed : 0xa0000c
Mapped    : 0xa00011
Mapped    : 0xa00012
Reparented: 0xa00011 to 0xa00012

SDL 2.0.4

Code: [Select]

Destroyed : 0xa00002
Mapped    : 0xa00007
Mapped    : 0xa00008
Reparented: 0xa00007 to 0xa00008
Reparented: 0xa00007 to 0x25d
Mapped    : 0xa00007
Destroyed : 0xa00008


[Calamity]

Do you think that's a bug in SDL 2.0.4, or just something we need to count with?

[Doozer]

Do you think that's a bug in SDL 2.0.4, or just something we need to count with?

At the moment I cannot confirm that it is a SDL bug. I prefer to say that we have to take it as it is for the meantime.

I have attached here a patch to be installed on top of hi+groovy that is giving the focus to the SDL created window. I have reverted the sdl early call in worker thread as well. All my tests confirm that the keyboard is now handled as expected with and without WM. Please check it and include it to main groovy patch as a temporary fix until situation gets better.

Cheers,

[Calamity]

Awesome job Doozer, I will update the patch in a while.

[Doozer]

Awesome job Doozer, I will update the patch in a while.

Thanks. I will be happy if it works for everyone.

[Calamity]

I've uploaded 0169_groovymame_015l_fix4.diff, including new Doozer's patch for SDL 2.0.4 input.

(Windows users don't need to update)

[Doozer]

I've uploaded 0169_groovymame_015l_fix4.diff, including new Doozer's patch for SDL 2.0.4 input.

(Windows users don't need to update)

Still an issue with timing. If we set the focus to early (before SDL destroy and remap) then we loose the focus. Even v5 is affected.

[Doozer]

I am working on another version to solve the timing issue as well.

[Doozer]

There is a call to the SDL library that kill the focus after the creation of the window (after call to complete_create_wt). Do you have an idea where it can hide?

[Doozer]

I know more precisely when the annoying remaps is performed. It happens between the two initial calls to the GL texture creation function. It is definitely a new behaviour introduced by the SDL 2.0.4 library. Assuming a WM is present, it is not making any trouble. In case no WM is active, the window is reparented to the X root window which cause the lost of focus.

The initial patch is not waiting the second call to the GL texture before changing the window focus. This is resulting in loosing the focus again after the remmap is performed. Adding a delay is solving the issue but looks a very ugly path to solve this. Something better can be done here.

SDL 2.0.4

Code: [Select]

OpenGL: VBO supported
OpenGL: PBO supported
OpenGL: FBO supported
OpenGL: using vid filter: 1
GL texture: copy 1, shader 0, dynamic 1, 960x672 960x672 [RGB32, Equal: 1, Palette: 0,
            scale 3x3, border 0, pitch 384,960/8192], bytes/pix 4
Reparented: 0xc00007 to 0x25d
Mapped    : 0xc00007
Destroyed : 0xc00008
GL texture: copy 1, shader 0, dynamic 1, 960x672 960x672 [RGB32, Equal: 1, Palette: 0,
            scale 3x3, border 0, pitch 384,960/8192], bytes/pix 4

SDL 2.0.3

Code: [Select]

OpenGL: VBO supported
OpenGL: PBO supported
OpenGL: FBO supported
OpenGL: using vid filter: 1
GL texture: copy 1, shader 0, dynamic 1, 960x672 960x672 [RGB32, Equal: 1, Palette: 0,
            scale 3x3, border 0, pitch 384,960/8192], bytes/pix 4
GL texture: copy 1, shader 0, dynamic 1, 960x672 960x672 [RGB32, Equal: 1, Palette: 0,
            scale 3x3, border 0, pitch 384,960/8192], bytes/pix 4


[Calamity]

So interesting. Why can't your get focus call be synchronized with the second GL texture call, are those parts running in separate threads? Please point me to the files where this is happening.

[Doozer]

So interesting. Why can't your get focus call be synchronized with the second GL texture call, are those parts running in separate threads? Please point me to the files where this is happening.

The final and only visible window is created in an internal secondary X11 call. The mame window name is set on this window and not on the first. The sdl_create function returns the id of the second window (which is correct) but X still have its focus linked to X root window during the first handle creation (which is not used and destroyed). During the destruction of the first handle (during the SDL housekeeping?) I assume that the focus is not given to the second one (the visible window) because of a 'RevertToNone' default behaviour effect (in absence of WM and _NET_ACTIVE_WINDOW handling).

Nevertheless, I have made a last version of the patch which will always linking the focus to the 2nd window handle. Now I have keyboard keystrokes processed 100% of the case, no timing issue any more.

Code: [Select]

OpenGL: VBO supported
OpenGL: PBO supported
OpenGL: FBO supported
OpenGL: using vid filter: 1
GL texture: copy 1, shader 0, dynamic 1, 960x672 960x672 [RGB32, Equal: 1, Palette: 0,
            scale 3x3, border 0, pitch 384,960/8192], bytes/pix 4
SwitchRes: initial window focus handle is 0x000000
Reparented: 0xc00007 to 0x25d
Mapped    : 0xc00007
Destroyed : 0xc00008
GL texture: copy 1, shader 0, dynamic 1, 960x672 960x672 [RGB32, Equal: 1, Palette: 0,
            scale 3x3, border 0, pitch 384,960/8192], bytes/pix 4
SwitchRes: initial window focus handle is 0x000000
SwitchRes: new window focus handle is 0xc00007


[Doozer]

So interesting. Why can't your get focus call be synchronized with the second GL texture call, are those parts running in separate threads? Please point me to the files where this is happening.

Indeed it is not linked to the mame or SDL directly but to X11 default behaviour. It is normally the job of the window manager to take care of this by intercepting the event and linking the focus back. Because we do not use a window manager on GroovyArcade we were affected by this issue. Normally, this behaviour was not reproducible on complete distro like Ubuntu, Fedora, Arch... because they use a window manager.