Ubuntu nouveau Xorg separate X screen - Groovyume segfault with some systems

[tiben]

Hi,

I experience a segmentation fault problem with groovyume 0.160 during boot with few system like `genesis` or `psu` when xorg is configured in Separate X screens.
All others systems i tried works perfectly  (sms, nes, snes, tg16, punisher, rtype, raiden, bublbobl among others)

I suspect the segfault occurs on systems which have dynamic resolutions but it's only a supposition.

Here is my setup:
Ubuntu 15.04 with patched 15khz  kernel 3.19.6
Nvidia card using nouveau driver 1.0.11 manually patched for low res
One LCD monitor on DVI output and one CRT Monitor on VGA output connected using an ArcadeForge UMSA adapter
xorg.conf configured using "Separate X screen"

I launch groovyume using this kind of command line:
DISPLAY=:0.1 groovyume genesis -cart ghouls

I tried others xorg layout like dual head with xrandr. The bug does not occurs but this config leads to others problems like scrolling issues, fullscreen displaying ubuntu taskbar.. so i dicarded it

Related to this, i can't find newer version of groovymame/groovyume for linux than 0.160. Does it exists?

Finally, I would like to thanks the developpers of groovymame/groovyarcade which did a very great job!

[Calamity]

I suspect the segfault occurs on systems which have dynamic resolutions but it's only a supposition.

That makes a lot of sense.

I've never been able to setup X properly for multi-monitor with MAME. I gave up long ago when we were still with sdl 1.2 and never tried again. Because of this I've never tested this.

Bear in mind that in order to perform dynamic resolution switching in sdl 2 I needed to force a reset of the sdl video subsystem altogether. This seems to work fine for me (only tested ATI) and has the advantage that makes unnecessary to patch sdl too (we used to do this for sdl 1.2 so it actually recognized the newly created resolutions once after sdl initialization). However it's not as smooth anymore as it was with sdl 1.2, where a simple window resize would trigger the mode switch without more mess. So yeah expect to see the desktop popping up for a couple of seconds, this thing is not actually intended to run with a desktop behind anyway but...

As a workaround, you should limit the need for resolution switching by using super resolutions:

groovymame genesis castlill -resolution 2560x0 -cleanstretch 2

This most probably will fix genesis but not psu (if progressive/interlaced mode switches are involved).

[tiben]

Thanks, the super resolution does the trick!

And I confirm this does not work with psu system.

I've never been able to setup X properly for multi-monitor with MAME

I love linux but i must admit configuring Xorg is a pain in the ass!

So yeah expect to see the desktop popping up for a couple of seconds, this thing is not actually intended to run with a desktop behind anyway but...

Yes, i noticed this behavior with extended desktop X configuration. That's why i configured xorg in "Separate X screens" (aka Zaphodheads using nouveau driver) which isolates my CRT monitor from the desktop. Basically i only have an X mouse arrow displayed on the screen when nothing is launched using DISPLAY=:0.1 . I also have really better performances (almost perfect scroll on most systems i tried) than in extended desktop or by using groovyarcade livecd with default settings.

So, if i understand what you said about SDL 2, it could be a problem which is triggered in the "sdl reseting" phase (when switching res) when the X screen is not in the first  DISPLAY (or something like this related to my xorg configuration) ?

[Calamity]

I also have really better performances (almost perfect scroll on most systems i tried) than in extended desktop or by using groovyarcade livecd with default settings.

With GM "almost perfect scroll" means it's not working. It's either *perfect* or not working at all (even if it almost looks good).

(Obviously I mean games where the correct refresh is achieved, not compromise cases like vertical games on horizontal monitors, etc.)

So, if i understand what you said about SDL 2, it could be a problem which is triggered in the "sdl reseting" phase (when switching res) when the X screen is not in the first  DISPLAY (or something like this related to my xorg configuration) ?

It could be, but it also could be related to the nouveau driver rather than the fact you're not using the first display. Or something about Ubuntu. The video stack is so complex, and using wrappers like sdl only makes things worse. All I can say is it works for the Arch + radeon driver + single screen combination.

What I do in those cases is to add debug logs to several points to find out where the segmentation fault happens, in case I can find a way to bypass it.

[tiben]

It's either *perfect* or not working at all (even if it almost looks good).

Sorry if i was not clear. I mean, a lot of systems have *perfect scroll*. I noticed small tears and not so smooth scrolls only on vertical games like dangerous seed or raiden.

What I do in those cases is to add debug logs to several points to find out where the segmentation fault happens, in case I can find a way to bypass it.

I'm not a C/C++ guru but having coding skills i think i could try this. Are Linux GM sources available somewhere ? Or should i simply apply this "hi_0162.diff" to official mame sources ? The only git repo i found in groovyarcade google project page seems to be outdated.

Thank you for your answers


EDIT:
I think i've found myself the answer: http://forum.arcadecontrols.com/index.php?topic=122840.0

[tiben]

After diving into the Mame code base i finally found the bug.

It occurs when resetting SDL in method `sdl_window_info::window_changeres` and come from the Mesa "dri" nouveau driver when X is in ZaphodHeads mode (package libgl1-mesa-dri).

The bug is known by the Mesa team and a patch has been adressed here:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=a98600b0ebdfc8481c168aae6c5670071e22fc29

I've tested ti and confirm this resolves the problem.

Now i have another problem: After a switchres, the display switches on the wrong screen. This occurs only sometimes and this is indeterministic. I suspect a problem specific to SDL so i'll direct my investigation in this way.

Hope this will help.

[Calamity]

Thanks for coming back with an answer, that's  great. No idea what the second problem could be. It's probably due to reinitializing the sdl video subsystem as a way to achieve fullscreen dynamic resolution switching, which is not officially supported.

[tiben]

Hi,

I finally got it!

Launching gm by setting some SDL environment vars fix the wrong screen problem:

Code: [Select]

$ SDL_VIDEO_X11_XRANDR=0 SDL_VIDEO_X11_XVIDMODE=0 DISPLAY=:0.1 ./mame64 -v genesis ghouls

My tests were pretty empirical, i must admit that i don't really understand  all the intricacies. Maybe this has some side effects but it works, even pse/psu systems!

Hope this will helps

Thanks for your support and the work you do on groovymame!

[Calamity]

Thanks for sharing this! From what I've read it looks like you're forcing the XVidMode and XRandR extensions disabled for SDL with those options. No idea why this is required anyway.

[Doozer]

I can also share some commands to disable screen(s) and allow laptop VGA without LVDS or dual screen setup. It has to be done when X is running.

Check the screen names with:

Code: [Select]

xrandr -d :0 -q

Then disable/enable screen as you need:

Laptop VGA port only

Code: [Select]

xrandr --output VGA on --output LVDS off

Duplicate screen

Code: [Select]

xrandr --output LVDS --auto --output VGA --auto --same-as LVDS

Extend screen

Code: [Select]

xrandr --output VGA --auto --right-of LVDS

Note: some ATI cards with report DVI-0 instead of VGA.

[tiben]

Doozer,
Does dynamic "resolution switching" systems (psu,  genesis etc..) act well on your setup?

During my tests i came up with problems using a dual heads setup like taskbar appearing and scrolling tears.

Using Zaphodhead mode, i came up with the idea to force shutting the main screen using Xorg just before but is resulted screens size problems after resolution switching "in game" (half of the windows went off the screen or the screen take only half of the size of the monitor...)

i'll take another look.


I've written some guidelines about my solution here: https://github.com/TiBeN/15khz-arcade-pkg. Hopes this can helps someone.

[Doozer]

During my tests i came up with problems using a dual heads setup like taskbar appearing and scrolling tears.

I am not seeing such issue. If you want I can cross-check your problem if you give me a reproducible process.

[tiben]

Hi Doozer,

I can't give you a precise test case because i tried many things in between and i can't remember exactly in which setup it was thrown.

I could try to reproduce it if someone asks but for now i am happy with my setup.