The NEW Build Your Own Arcade Controls
Main => Software Forum => Linux => Topic started by: shock_ on May 16, 2016, 05:37:02 pm
-
At the moment I'm working on a cabinet build based off Ubuntu Xenial, and trying to make things boot straight into a front end via startx & .xinitrc.
That much works and I get graphics displaying normally on tty1, but I'm having this symptom:
When the machine reaches the front end (Attract Mode) in this case, keystrokes respond normally. Once I open a game (any game), MAME doesn't appear to respond to any keys, including the esc key. The keyboard itself still works, because I can 'CTRL-ALT-F2' to tty2, then sign in and 'kill -9 $(pgrep mame)' to regain control and return to the front end in tty1. For some games (older ones? 'lighter' ones? e.g. dkong) after killing it once like this I can then re-enter via the front end and MAME works normally with all keys behaving. For other games (e.g. donpachi, or its sequels) it still won't respond and needs to be killed from another console, every time.
I've noticed that even in games like donpachi that don't respond to keys, if I hold down PgDn (which is the 'fast forward' key in SDL-based MAME) while opening the game, the top-right corner will show the framerate and percentage of speedup, and then that doesn't drop away when the key is released; the game keeps running (and graphically looking fine) and the fast forward stats keep updating, even though MAME's no longer responding to keystrokes or even apparently aware the fast forwarding should have stopped -- almost like the keyboard is 'freezing', save for the CTRL-ALT console switching.
This happens whether or not there's a front end involved; changing ~/.xinitrc to run a MAME game directly has the same symptoms.
The system is installed on a 1TB USB HDD, and the same problem happens on three separate physical machines when booting from that disk (one AMD video card, one Nvidia, one Intel off the mobo).
The system was originally installed as a regular amd64 desktop, with mame64 successfully compiled on itself. When running mame64 (directly, or via a front end) off a terminal within a normal lightdm/Unity session, it works flawlessly for all games, so presumably there's some magic going on in the dm layer or nearby, that's 'fixing' whatever is wrong or missing when I'm starting x straight off a console.
I did get some advice that led me to suspect the problem was with the user account not being in the 'video' group, but after 'usermod -a -G video emulation' (and rebooting to be sure) nothing improved.
My experience in Linux is nearly all either cli-based server things, or working within a full DE... this middle ground of raw X is scary :\
-
Attaching some `ps auxf` output.
-
Hi,
The symptom you are describing looks like a focus/keyboard grabbing issue. It seems that you are not using a window manager.
Without WM; during mame SDL initialization the input (keyboard) is grabbed but shortly released to root windows (revertToRoot) by SDL2. You can force the focus back to mame window id in order to cure the issue (until next launch). Taking care of the focus events is normally the job of the window manager. You can install a lightweight WM like openbox, fluxbox, ...
Cheers,
-
I've never really learned about SDL (or lots of things) but this sounds pretty plausible to me. Maybe a lot of the advice I'd been following about reliably bypassing window managers altogether related to much earlier builds of MAME, and the world isn't so straightforward any more.
Getting Openbox into the mix has definitely been working so far, thanks for your ear!
-
Getting Openbox into the mix has definitely been working so far, thanks for your ear!
Happy to help ;-)
-
Yeah, MAME isn't really intended to work that way. Linux is enough of a headache when everyone's got a terminal and a WM and one of the 357 popular window managers. If you can work out a way to get it going that doesn't do too much violence to the code we might be interested in the patch though.
-
Yeah, MAME isn't really intended to work that way. Linux is enough of a headache when everyone's got a terminal and a WM and one of the 357 popular window managers. If you can work out a way to get it going that doesn't do too much violence to the code we might be interested in the patch though.
Hi, I have a workaround for GM 0.171 which can be used for stock MAME (tested on 0.174). The location to re-establish the focus is not perfect due to SDL2 internal timed events which prevent a nice fix. The texture/surface handling is the best location in the current windows management queue to ensure that focus is treated in any case.