The NEW Build Your Own Arcade Controls

Software Support => GroovyMAME => Topic started by: Substring on April 09, 2019, 07:21:58 am

Title: Collaborative effort for GroovyArcade
Post by: Substring on April 09, 2019, 07:21:58 am
Hi everyone,

Here is an attemps of going a little more open source for GA. I've set up a gitlab repo https://gitlab.com/substring45/test (https://gitlab.com/substring45/test) mirrored at https://github.com/substring/test (https://github.com/substring/test) (gitlab automatically pushed to github). I'll explain later why i'm using both.

So the aim of this repo is to:

DISCLAIMER
This is does not build a usable GA yet ! The ISO is bootable, you can launch X, even GM, but it's a real bare Arch linux ISO with GM and a few other emulators. The kernel is not even patched with 15kHz (despite the 15kHz is packaged). The repo is more a proof of concept that much can be automatically done to build the final iso.

What needs to be done
Well, still much in fact (this list is not complete, just showing major steps):

For curious people

Final word
I hope we can make it grow in a real GroovyArcade build system!

Credits go to Calamity, ves and doozer for their respective work on groovymame, groovyarcade, and linux 15kHz patches.
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on April 09, 2019, 03:24:39 pm
So long as there become a well documented readme and still an option at boot to select display, im all for no gasetup. Will check it out soon and hopefully can contribute in some way even if small.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 10, 2019, 07:22:26 am
So long as there become a well documented readme and still an option at boot to select display, im all for no gasetup. Will check it out soon and hopefully can contribute in some way even if small.
I've written a wiki at https://gitlab.com/substring45/test/wikis/local-build (https://gitlab.com/substring45/test/wikis/local-build), it should have all the info to locally build, but I may have missed some parts/pre-requisites
Title: Re: Collaborative effort for GroovyArcade
Post by: cools on April 11, 2019, 03:52:38 am
Is there a reason not to use the central AUR?

I had packages there for Groovy a couple of years ago, just don't have the time to maintain anymore.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 11, 2019, 05:00:11 am
Is there a reason not to use the central AUR?

I had packages there for Groovy a couple of years ago, just don't have the time to maintain anymore.

Good question! I considered for a moment submitting packages to AUR. But haven't done it yet for a few reasons:
- as for now, I feel it easier to handle packages on my side. It's just 2 of them : groovymame and the 15khz kernel
- I feel it's better for now if people want to contribute to the repo, and not lock AUR packages to me only
- keeping it up with the linux package that updates every 5 days is too demanding for now

But that's something I could definitely consider in a near future. Or if someone wants to take the task, that's a good thing.

Which packages had you added to AUR ? Feel like resurrrecting them ?
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 11, 2019, 06:45:40 am
Hi substring,

I'll look into your repo as soon as I have time. Thanks for your work.

Hopefully I can get the Switchres library updated. Currently it's a mess.

@keilmillerjr, if you remove GA, how would people do the required setup? Most users can't even manage command line.
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on April 11, 2019, 08:41:36 am
Hi substring,

I'll look into your repo as soon as I have time. Thanks for your work.

Hopefully I can get the Switchres library updated. Currently it's a mess.

@keilmillerjr, if you remove GA, how would people do the required setup? Most users can't even manage command line.

Gasetup was filled with things that didnt work, and most likely had to configure by editing the files directly anyways. I guess broken items and lacl of documentarion leads me against it. Honestly, id be happy if i can get it 15khz kernel patched, and groovymame working with switchres.
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 11, 2019, 10:32:53 am
Gasetup was filled with things that didnt work, and most likely had to configure by editing the files directly anyways. I guess broken items and lacl of documentarion leads me against it. Honestly, id be happy if i can get it 15khz kernel patched, and groovymame working with switchres.

Well if that's the case, I think it'd be better to do a thorough cleanup and remove deprecated parts or fix what doesn't work. I really like the old school text menu system rather than a GUI setup, but that's me. But I do believe you need a setup system, otherwise you're restricting GA to users already familiar with Linux, which probably don't really need GA after all.

With regards to 15 kHz kernel patches, I think we should move away from hardcoded patches and adopt EDID emulation if possible. I like to think about custom video in general rather than "15 kHz" because there are many types of monitors you can use for emulation, and Switchres/GroovyMAME supports any possible configuration, so by restricting it to 15/31 kHz you're loosing a lot of flexibility.

In my view, the problem we currently have, as I've been discussing with Ves, is that modern video cards have lots of heads, and GA boot menu can't target the required one anymore. It was designed for older cards that were 2-head most of the times, so we had prefixed boot optios for VGA-1-15kHz, VGA-2-15kHz, etc. That doesn't work anymore, so I've been stuck lately from testing new GA releases because my working systems are all multi-headed, so unless I rewire my monitors the way GA expects I can't launch it on the monitor I want, and that's not good. We'd need something more flexible for the boot menu, but I doubt you can implement any complex logic in there (specially one that can poll the outputs).

Once in X, we also have the problem that multi-headed configurations are not handled properly. This is fixable, but it requires changes both to Switchres/GM and to the scripts that make the X configuration.

So if I had to improvise a list of things that need to be done, this is mine:

- Move Switchres to a library (not GA specific task).
- Move GA kernel mode setting to use EDID emulation instead of fixed kernel patches.
- Handle multi-head systems properly (both in boot menu and in X).

Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 11, 2019, 01:25:41 pm
Well if that's the case, I think it'd be better to do a thorough cleanup and remove deprecated parts or fix what doesn't work. I really like the old school text menu system rather than a GUI setup, but that's me. But I do believe you need a setup system, otherwise you're restricting GA to users already familiar with Linux, which probably don't really need GA after all.
Whether gasetup is perfect ror not, it's still much more advanced than anything else to configure GA. So if it needs some fixes, the best way is to make a gasetup repo and let people report issues and contribute :)
Quote
With regards to 15 kHz kernel patches, I think we should move away from hardcoded patches and adopt EDID emulation if possible. I like to think about custom video in general rather than "15 kHz" because there are many types of monitors you can use for emulation, and Switchres/GroovyMAME supports any possible configuration, so by restricting it to 15/31 kHz you're loosing a lot of flexibility.

In my view, the problem we currently have, as I've been discussing with Ves, is that modern video cards have lots of heads, and GA boot menu can't target the required one anymore. It was designed for older cards that were 2-head most of the times, so we had prefixed boot optios for VGA-1-15kHz, VGA-2-15kHz, etc. That doesn't work anymore, so I've been stuck lately from testing new GA releases because my working systems are all multi-headed, so unless I rewire my monitors the way GA expects I can't launch it on the monitor I want, and that's not good. We'd need something more flexible for the boot menu, but I doubt you can implement any complex logic in there (specially one that can poll the outputs).

Once in X, we also have the problem that multi-headed configurations are not handled properly. This is fixable, but it requires changes both to Switchres/GM and to the scripts that make the X configuration.
now we hit a wall, and i have quite a few questions regarding the EDID way + the good arch linux documentation at https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID (https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID):
- seems like EDID can be "forced" to all connectors, not a specific one. So I guess we could have 2 EDIDs : one for 15kHz, one for 25kHz, as I suppose 31kHz screens wouldn't need a specific EDID. Now the question is : how to generate these EDIDs ? The old switchres standalone can generate some, are they reliable ? Or should we patch the kernel as suggested in the arch doc ? or just use some prebuilt ones (link ?) ?
- regarding X: could you go in more details regarding the problems with multihead ? can't ge things the way you want with just xrandr ?

Quote
So if I had to improvise a list of things that need to be done, this is mine:

- Move Switchres to a library (not GA specific task).
- Move GA kernel mode setting to use EDID emulation instead of fixed kernel patches.
- Handle multi-head systems properly (both in boot menu and in X).
I wish Ves had a little more time to give a hand on how he customized Arch to make the magic work, reverse-engineering GA is not a funny task.

Anyway, you are all free to submit issues on the gitlab repo so that I can organize my work. Beside a few things here and there regarding CI, error handling and other minor stuff, my first goal is to have the build boot X and launch GM (FEs will come later), and script some testings in virtual box to ease my pain.
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 11, 2019, 01:52:20 pm
now we hit a wall, and i have quite a few questions regarding the EDID way + the good arch linux documentation at https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID (https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID):
- seems like EDID can be "forced" to all connectors, not a specific one. So I guess we could have 2 EDIDs : one for 15kHz, one for 25kHz, as I suppose 31kHz screens wouldn't need a specific EDID. Now the question is : how to generate these EDIDs ? The old switchres standalone can generate some, are they reliable ? Or should we patch the kernel as suggested in the arch doc ? or just use some prebuilt ones (link ?) ?
- regarding X: could you go in more details regarding the problems with multihead ? can't ge things the way you want with just xrandr ?

Check this thread: http://forum.arcadecontrols.com/index.php?topic=140215.0

The target head can be a specific one, here for example VGA-1:

Code: [Select]
drm_kms_helper.edid_firmware=VGA-1:edid/edid-15khz.bin
The actual wall is how to know which outputs (VGA-1, VGA-2, etc.) your card has in order to create a practical boot menu.

Old standalone Switchres can create the edid files just fine, the new one will be better of course, anyway there was a bug with AMD's EDID code affecting interlaced modes that forced us to code a workaround in old Switchres to handle interlace properly. Now, instead of that I'd rather report the bug to AMD so they fix it and keep our Switchres code correct, so it can be used for Intel and Nvidia too.

The issue in X can be fixed with xrandr, or just from X conf files I guess, so multi head setups work as extended desktops rather than cloned displays. But GM also needs a fix, so the -screen option in mame.ini is honored.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 11, 2019, 02:03:29 pm
Not specifying an output would probably force the EDID to all outputs, wihch seems a good option to me, instead of listing VGA-n/DVI-n. But this would probablykill setups having a second LCD monitor for usual config.

A dirty trick could be:
- find connected outputs
- if a connected output can't give an EDID, then it's probably the CRT one, so adapt grub with it.

But this requires at least 1 boot cycle.

Is switchres64 the old switchres standalone found at https://github.com/Ansa89/switchres (https://github.com/Ansa89/switchres) ? If yes, I'll write a small PKGBUILD and have it compiled with GA.
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 11, 2019, 02:18:30 pm
Not specifying an output would probably force the EDID to all outputs, wihch seems a good option to me, instead of listing VGA-n/DVI-n. But this would probablykill setups having a second LCD monitor for usual config.

That's the exact issue I want to prevent. All my systems except my cabinet are dual-head these days, a decent system must allow you to choose the desired output.

Quote
A dirty trick could be:
- find connected outputs
- if a connected output can't give an EDID, then it's probably the CRT one, so adapt grub with it.

But this requires at least 1 boot cycle.

That wouldn't work if you have a PC CRT monitor, because those have EDID. Here on the other desk I have a system with 2 heads, one PC CRT (31-kHz) and a BVM (15-kHz). I'd like to be able to decide which head to boot the system on.

Quote
Is switchres64 the old switchres standalone found at https://github.com/Ansa89/switchres (https://github.com/Ansa89/switchres) ? If yes, I'll write a small PKGBUILD and have it compiled with GA.

Last version posted by me was this one (http://forum.arcadecontrols.com/index.php/topic,106405.msg1438711.html#msg1438711). IIRC Ansa took that one and fixed some bugs, etc., not sure.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 12, 2019, 06:10:59 am
Wouldn't it be better to have EDIDs generated with the kernel ? It's just some .S files to add in https://github.com/torvalds/linux/tree/master/Documentation/EDID (https://github.com/torvalds/linux/tree/master/Documentation/EDID). It looks rather easy
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 12, 2019, 07:12:09 am
Wouldn't it be better to have EDIDs generated with the kernel ? It's just some .S files to add in https://github.com/torvalds/linux/tree/master/Documentation/EDID (https://github.com/torvalds/linux/tree/master/Documentation/EDID). It looks rather easy

That code does not support interlace unfortunately.

The good thing about having the EDIDs created by Switchres is you can control the geometry also out of X. Even if no one ever will use that, I prefer that conceptually over having the EDIDs hardcoded with the kernel. If the later results to be more practical, then it's ok as long as we can add EDIDs for all the existing GM presets (e.g., ntsc, pal, arcade_15, arcade_31, etc.).
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 12, 2019, 05:21:53 pm
Wouldn't it be better to have EDIDs generated with the kernel ? It's just some .S files to add in https://github.com/torvalds/linux/tree/master/Documentation/EDID (https://github.com/torvalds/linux/tree/master/Documentation/EDID). It looks rather easy

That code does not support interlace unfortunately.

The good thing about having the EDIDs created by Switchres is you can control the geometry also out of X. Even if no one ever will use that, I prefer that conceptually over having the EDIDs hardcoded with the kernel. If the later results to be more practical, then it's ok as long as we can add EDIDs for all the existing GM presets (e.g., ntsc, pal, arcade_15, arcade_31, etc.).
Doesn't suppoer interlace ? mmhhhhh ... reading the EDID.S, it seems a bit sets interlace, but never mind, let's not waste time on this yet.

Anyway, the real problem is to set an EDID post kernel boot if you want to get rid of those VGA-n DVI-n options on grub ... except probing connectors and respective EDIDs and make a dirty assumption "this output is connected but has no edid" means "apply the edid on it, i have no idea how to make that easy. And even : edid is a kernel parameter, so it's set at boot. Unless using kexec (which is a bad idea still), i'm clueless ...
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 13, 2019, 01:59:29 pm
Doesn't suppoer interlace ? mmhhhhh ... reading the EDID.S, it seems a bit sets interlace, but never mind, let's not waste time on this yet.

If you look at the "features" byte, bit 7 is never used. I know this because I used that code as a base for my implementation.

Quote
Anyway, the real problem is to set an EDID post kernel boot if you want to get rid of those VGA-n DVI-n options on grub ... except probing connectors and respective EDIDs and make a dirty assumption "this output is connected but has no edid" means "apply the edid on it, i have no idea how to make that easy. And even : edid is a kernel parameter, so it's set at boot. Unless using kexec (which is a bad idea still), i'm clueless ...

I'm thinking probing the outputs before launching the menu is not feasible. Just wondering if there's a way to use nested menus instead of the long list we use now. GA was create when everything we cared about was VGA and DVI ports. Now we should also consider HDMI at least, as it's the only way we can get RGB from with newer cards. Anyway, maybe it's more clever to just have standard 15/25/31 kHz EDIDs built with the kernel so they're available for setting things up, the if someone wants to refine the boot picture a better EDID may be added later. IIRC the only difficulty is you need to add those EDID binaries to the initramfs later so they're available during boot.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 14, 2019, 11:13:37 am
If you look at the "features" byte, bit 7 is never used. I know this because I used that code as a base for my implementation.
OK, so i gave a try to https://github.com/akatrevorjay/edid-generator wchich bascally looks like the kernel code for EDIDs + some script around to convert a X modeline to a .S file (needs zsh). Patched the edid.S to allow external configuration of the whole byte that has the interlace bit.

So i fed the zsh modeline2edid with the result modeline of a parse-edid from a 480i 15kHz edid generated by switchres, edited the .S to enable interlace, and compiled the EDID. parse-edid gives the following result :

Code: [Select]
Checksum Correct

Section "Monitor"
Identifier "480i_15khz"
ModelName "480i_15khz"
VendorName "LNX"
# Monitor Manufactured week 5 of 2012
# EDID version 1.3
# Analog Display
DisplaySize 160 120
Gamma 2.20
Option "DPMS" "true"
Horizsync 14-16
VertRefresh 59-61
# Maximum pixel clock is 20MHz
#Not giving standard mode: 640x480, 60Hz
Modeline "Mode 0" 13.00 640 664 728 832 480 482 488 521 +hsync +vsync interlace
EndSection

Not such a bad start! I'm surprised that th epolarities are inverted, frequency ranges changed too, but it means that patching the kernel to build EDIDs can be done very easily.

By the way, the did.S patch:
Code: [Select]
--- a/edid.S
+++ b/edid.S
@@ -237,7 +237,7 @@ y_border:   .byte   0
    Bit 1       If analog sync: Sync on all 3 RGB lines (else green only)
    Digital: HSync polarity (1=positive)
    Bit 0       2-way line-interleaved stereo, if bits 4-3 are not 00. */
-features:      .byte   0x18+(VSYNC_POL<<2)+(HSYNC_POL<<1)
+features:      .byte   FEATURES+(VSYNC_POL<<2)+(HSYNC_POL<<1)
 
 descriptor2:   .byte   0,0     /* Not a detailed timing descriptor */
                .byte   0       /* Must be zero */
And in .S file, you just set
Code: [Select]
#define FEATURES 0x18 + 1<<7and voilà ! May need a little tweaking still, but it looks promising.

Quote
I'm thinking probing the outputs before launching the menu is not feasible. Just wondering if there's a way to use nested menus instead of the long list we use now. GA was create when everything we cared about was VGA and DVI ports. Now we should also consider HDMI at least, as it's the only way we can get RGB from with newer cards. Anyway, maybe it's more clever to just have standard 15/25/31 kHz EDIDs built with the kernel so they're available for setting things up, the if someone wants to refine the boot picture a better EDID may be added later. IIRC the only difficulty is you need to add those EDID binaries to the initramfs later so they're available during boot.
I'm not sure i've correctly explained what I mean. What I'm talking about is to "autoconfigure monitors" based on a simple choice : 15/25/31kHz at grub boot, no matter which outputs you're using. We can probe connected outputs using /sys/class/drm/*/status (see arch linux wiki https://wiki.archlinux.org/index.php/Kernel_mode_setting at the very end).

I naively thought "if an output is connected but has no edid, then it's the arcade monitor". But most probably not : I'm not sure a DVI2VGA would say the output is connected, and some HDMI2VGA report dummy EDID (when some do query the monitor hopefully).
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 14, 2019, 01:03:55 pm
I'm not sure i've correctly explained what I mean. What I'm talking about is to "autoconfigure monitors" based on a simple choice : 15/25/31kHz at grub boot, no matter which outputs you're using. We can probe connected outputs using /sys/class/drm/*/status (see arch linux wiki https://wiki.archlinux.org/index.php/Kernel_mode_setting at the very end).

I naively thought "if an output is connected but has no edid, then it's the arcade monitor". But most probably not : I'm not sure a DVI2VGA would say the output is connected, and some HDMI2VGA report dummy EDID (when some do query the monitor hopefully).

Hi Substring,

This was a nice pointer!

So do you think this could be scripted somehow to build the grub menu?

Code: [Select]
$ for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done
DVI-I-1: connected
HDMI-A-1: disconnected
VGA-1: disconnected

I don't care about the connected/disconnected status. Arcade monitors will often fail to get discovered by the gpu for not having the expected impedance, so we'll need to forcely enable the connection. But having the real *list* of connectors at boot time can be gold.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 14, 2019, 01:21:00 pm
I'm afraid we can't list connectors as the script uses some kernel info. And when we're on the grub menu, the kernel is not yet loaded. So we could eventually dive in the grub source direction, or any other bootloader. But gosh, that's some work.

edit1: by "So do you think this could be scripted somehow to build the grub menu?" did you mean adding generated EDIDs and auto-script a grub menu with them ? yes, probably, just give me details of what you'd expect.

edit2: grub can just read VESA modes from GPU, nothing more. So the boot menu can't be dynamic. If arcade screens are not detected by the GPU, why should we bother ? Let's just force the Horizontal frequency selected at boot (but this is once kernel is loaded, not at grub boot). The only risky case would be having 2 CRT monitors with different Hfreq (which i guess hardly ever happens)
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 15, 2019, 03:53:06 am
Hi Substring,

I'm afraid we can't list connectors as the script uses some kernel info. And when we're on the grub menu, the kernel is not yet loaded. So we could eventually dive in the grub source direction, or any other bootloader. But gosh, that's some work.

Ok, definitely, no kernel calls before kernel is loaded :) I agree, the other direction is one I don't feel like to go through, it involves a lot of work, probably real mode x86 asm, uncertain chances of success and it's not worth the effort.

Quote
edit1: by "So do you think this could be scripted somehow to build the grub menu?" did you mean adding generated EDIDs and auto-script a grub menu with them ? yes, probably, just give me details of what you'd expect.

No, I meant the dynamic menu thing, so since it's not possible we don't need to bother. I'd just make the raw .bin EDID files available to the kernel, one for each 15/25/31 kHz ranges, that's all.

Quote
edit2: grub can just read VESA modes from GPU, nothing more. So the boot menu can't be dynamic. If arcade screens are not detected by the GPU, why should we bother ? Let's just force the Horizontal frequency selected at boot (but this is once kernel is loaded, not at grub boot). The only risky case would be having 2 CRT monitors with different Hfreq (which i guess hardly ever happens)

That's exactly what I have here. I need GA to only force a certain frequency through the output I ask it for. This is not a whim of mine, it's a guideline I strongly believe the project should follow. Not only this project but all emulation software. Unfortunately we have 99% of emulators making poor assuptions about user's display setups. I suspect most emulator coders don't run multi-monitor setups themselves so they don't care or can't even test it.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 15, 2019, 04:35:53 am
Hey Calamity,

That's exactly what I have here. I need GA to only force a certain frequency through the output I ask it for. This is not a whim of mine, it's a guideline I strongly believe the project should follow. Not only this project but all emulation software. Unfortunately we have 99% of emulators making poor assuptions about user's display setups. I suspect most emulator coders don't run multi-monitor setups themselves so they don't care or can't even test it.

Well, most emulators don't need to care about screen settings as they don't need to go in depths of how the screen works. They rely on SDL2 which outputs on anything you'd wish (OpenGLES, OpenGL through X, KMS/DRM). Even SDL2 (opposite to SDL1) doesn't fool around with resolutions anymore. It's all a matter of "get the proper emulation speed" rather than "get the real video output". And emulators choice is the one for less effort with maximum result : don't care about screen resolution, just let the backend handle stretching, as long as you can have a constant FPS matching the original hardware. CRT addicts are on a whole different level ;)

Now back to the initial configuration stuff : we can't do anything at grub level, we may eventually do something with early KMS in the initramfs. But still : the EDID is already loaded, I haven't found a way to reload it once the system has booted up. Just found a virtual KMS (vkms) in the kernel doc that allows to change the EDID, but it's in the TODO ... meh ... So we're stuck with xrandr and other linux tools, no magic plug and play at boot. There is a massive Pi community that just begs for proper CRT display ;)

Side note regarding your "libswitchres" : May I suggest you consider a "fixed pixel clock" setting ? The reason is that the Raspberry Pi can generate analog signals through its GPIO (or  even HDMI), but you can't set the pixel clock you wish, It's locked to either 4.8, 6.4, 9.6, 19.2 MHz (or beyond 31MHz). Write this demand somewhere for the next years!
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 15, 2019, 05:17:52 am
Well, most emulators don't need to care about screen settings as they don't need to go in depths of how the screen works. They rely on SDL2 which outputs on anything you'd wish (OpenGLES, OpenGL through X, KMS/DRM). Even SDL2 (opposite to SDL1) doesn't fool around with resolutions anymore. It's all a matter of "get the proper emulation speed" rather than "get the real video output". And emulators choice is the one for less effort with maximum result : don't care about screen resolution, just let the backend handle stretching, as long as you can have a constant FPS matching the original hardware. CRT addicts are on a whole different level ;)

I'm not even asking coders to care about resolutions :) I'm just saying that many of us use multi-monitor setups. And just defaulting everything to run on the primary display is poor design. This is valid for LCD too.

Quote
Now back to the initial configuration stuff : we can't do anything at grub level, we may eventually do something with early KMS in the initramfs. But still : the EDID is already loaded, I haven't found a way to reload it once the system has booted up. Just found a virtual KMS (vkms) in the kernel doc that allows to change the EDID, but it's in the TODO ... meh ... So we're stuck with xrandr and other linux tools, no magic plug and play at boot. There is a massive Pi community that just begs for proper CRT display ;)

I'll try to clarify what I intend to have:

1.- We need grub to have options that can map a certain EDID to a certain output.
2.- Once the EDID is selected, it won't be changed later. It just applies to kernel mode setting (boot process and GAsetup).
3.- In X, we'll use the current xrandr implementation (this is why we need a dual video configuration, for both kernel and X independently).

We already have all this, except that #1 is currently is achieved by kernel patches (hardcaded modelines) while I'm advocating for doint it through EDID emulation instead of patches as I think it's more elegant (and while suggesting this I wondered about the possibility of having a dynamic boot menu so we could avoid the absurdly long boot menu we have now, and this is definitely not possible as you have shown).

Quote
Side note regarding your "libswitchres" : May I suggest you consider a "fixed pixel clock" setting ? The reason is that the Raspberry Pi can generate analog signals through its GPIO (or  even HDMI), but you can't set the pixel clock you wish, It's locked to either 4.8, 6.4, 9.6, 19.2 MHz (or beyond 31MHz). Write this demand somewhere for the next years!

I'll consider your suggestion, but can't promise it'll be possible since the whole modeline calculation is based on the assumption that the pixel clock is fully programmable (like it's the case on usual GPUs.) So it would involve an important rewrite of things. The Pi is a terrible platform for emulation, and to top it all off the pixel clock is limited to discrete values. Lots of wasted development hours in the wrong direction IMHO.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 15, 2019, 09:04:51 am
I'll try to clarify what I intend to have:

1.- We need grub to have options that can map a certain EDID to a certain output.
2.- Once the EDID is selected, it won't be changed later. It just applies to kernel mode setting (boot process and GAsetup).
3.- In X, we'll use the current xrandr implementation (this is why we need a dual video configuration, for both kernel and X independently).

We already have all this, except that #1 is currently is achieved by kernel patches (hardcaded modelines) while I'm advocating for doint it through EDID emulation instead of patches as I think it's more elegant (and while suggesting this I wondered about the possibility of having a dynamic boot menu so we could avoid the absurdly long boot menu we have now, and this is definitely not possible as you have shown).

OK, i'll focus on grub using EDID for now then. One step after another !
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 15, 2019, 09:26:21 am
For curious people, just found https://www.kraxel.org/blog/2019/03/edid-support-for-qemu/ -> qemu will support EDID, which is great for testing
Title: Re: Collaborative effort for GroovyArcade
Post by: cools on April 16, 2019, 07:49:53 am
Why not just have the initial boot be 15k on everything, then have a tool to configure outputs + grub menu proper?

And an alternate ISO for LCD/31k boot. Heck, make an image with a FAT partition that when written to USB can have alternate boot configs swapped in.

Of course, I'm assuming installation on writable storage, not static boot from CD/DVD.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 16, 2019, 11:52:33 am
Why not just have the initial boot be 15k on everything, then have a tool to configure outputs + grub menu proper?
Sooner or later, this is what should happen + need a panic button/combo at boot to boot with default settings. But I'm still far from that for now.

Quote
And an alternate ISO for LCD/31k boot. Heck, make an image with a FAT partition that when written to USB can have alternate boot configs swapped in.
Why not!

Quote
Of course, I'm assuming installation on writable storage, not static boot from CD/DVD.

I really wonder who is still using DVDs today. I plan on adding some .img sooner or later, so you could just burn a USB stick with it
Title: Re: Collaborative effort for GroovyArcade
Post by: Calamity on April 16, 2019, 12:32:04 pm
Why not just have the initial boot be 15k on everything, then have a tool to configure outputs + grub menu proper?
Sooner or later, this is what should happen + need a panic button/combo at boot to boot with default settings. But I'm still far from that for now.

I hate this strongly but I'm afraid it's the only way to do it. Maybe have a timeout at boot (I'm talking about the live-cd, not the installed system), so if you let it alone it'll just boot at 15 kHz through all outputs. Since boot menu is at 31 kHz, choosing an option has always been problematic on a 15 kHz monitor anyway. Optionally, you can press any key and select another boot option. This would make the 31 kHz distro unnecessary.

What needs to be checked is whether selecting an EDID without specifying an output actually enables all of them, even the ones that are NOT detected like those connected to arcade monitors through a JPAC. We might find out there was a good reason to force specific outputs on boot back in the day.

Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 16, 2019, 02:45:24 pm
Hey Calamity,

Do you have news from ves ? I haven't seen him around for a while on the forum, we do need him.

By the way : seems like we can make grub boot in 320x200, 320x240 or any VESA mode that the GPU would support. So cools' idea to have different grubs configured for various resolutions on a FAT32 boot partition is something that could be done on a .img people would burn to a USB key.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on April 23, 2019, 07:59:55 am
Just a small update : I hope i'll be able to be on par with groovyarcade soon. For now the FE won't start due to some permission problems, shouldn't be that complicated to solve. Will then need to make sure gasetup works as before + will also have to use GA's default for syslinux bootloader.
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on May 21, 2019, 11:51:34 am
Free bump for awesome project!
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on May 21, 2019, 04:22:20 pm
haha thanks for the bump @keilmillerjr

Time to give some news about the project :
- i could setup github releases to be a pacman repo, so it's fairly easy now to update the linux kernel or other packages. The kernel is patched with Doozer's patches : usual arcadevga/ati + custom resolutions for 15and 25 kHz + some patches he made for I don't remember what regarding cathode tracing position
- more frontends are available as packages, despite they are not configured yet (retrofe, mehstation, attract mode was updated), some need a little tinkering. I still have to make a package of that old advmenuPlus
- plymouth is done
- HDD installation works as before
- having some problems with X : for i don't know which reason, X is started as root in ves' groovyarcade (despite some sudo here and there). But on my build, it won't just work that way. Put in other words : it doesn't work from gasetup, but works fine from shell. This one bothers me quite much
- after some talk with calamity, i'm exploring the EDID path to set some default resolution rather using the patched ones. Haven't had much luck yet, despite it has worked for some people ...

Sooner or later, I'll have to split the project in 2 : the arch linux packages repo which will then mostly live on its own unless some update breaks everything (automatic builds, automatic deploy to the pacman repo for easy updates), and the iso repo which would be dedicated to the .iso for now (which boots on a USB key now by the way), and probably a .img sooner or later (DVD is so 90s :D)

Once I'm on par with ves' GA, i'll start reworking the gasetup scripts : clean, rewrite, enhance, new features.

Curious people can check https://gitlab.com/substring45/test/issues (also check closed issues) to see what I've been working on, what I plan to do. Sooner or later I'll have to rename that repo I guess :D
Title: Re: Collaborative effort for GroovyArcade
Post by: Doozer on June 03, 2019, 02:18:25 pm

Hi,

On the X startup issue you are experiencing, I can perhaps help you out to get it working. Let me know what you try to achieve.

Xorg is always started as root for driver access, then user space Xorg is used for individual user sessions. Attention must be given to gdm (or other) started on top or multi user and using dedicated instance for displayng initial graphical login screen.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on June 04, 2019, 09:11:16 am

Hi,

On the X startup issue you are experiencing, I can perhaps help you out to get it working. Let me know what you try to achieve.

Xorg is always started as root for driver access, then user space Xorg is used for individual user sessions. Attention must be given to gdm (or other) started on top or multi user and using dedicated instance for displayng initial graphical login screen.
Hey !

Well the problem is quite simple : X (through startx) will start perfect through autologin with the arcade user, but it won't start if launched from gasetup. gasetup is launched in sudo, then uses something like su -c arcade startx which fails with X being unable to switch VT.

The real thing would be to not start gasetup with sudo and wrap root commands in sudo, but this means breaking the logic in gasetup, and that's not what I want to achieve now.

There is no GDM or such, X is started with a minimalistic window manager and simply launches 1 app (usually the front end).
Title: Re: Collaborative effort for GroovyArcade
Post by: Doozer on June 05, 2019, 12:49:41 pm
Hi.

Not sure I understand the issue, I can start X for a user without issue from root account with the following command:

Code: [Select]
su - arcade startx

If you have a VM drive you can share I can work on the issue and provide better guidance.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on June 05, 2019, 01:22:00 pm
The real command is su arcade -c startx -- vt7. I've attached the xorg log
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on June 05, 2019, 03:38:33 pm
AT LAST I've found : was missing the /etc/X11/Xwrapper.config file ! It's not added by default in arch
Title: Re: Collaborative effort for GroovyArcade
Post by: ves on June 05, 2019, 04:34:29 pm
Good job!!
I want to be able to help as soon as possible.
You dont install vbox video driver.

Test to configure etc/X11/Xwrapper.config

"needs_root_rights = yes"
 
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on June 05, 2019, 05:58:13 pm
Good job!!
I want to be able to help as soon as possible.
You dont install vbox video driver.

Test to configure etc/X11/Xwrapper.config

"needs_root_rights = yes"

oh glad you join the fun :) The more the merrier
The vbox video driver is because i test 99.9% on Virtual Box, also sometimes QEMU, it's so much easier than burning the ISO on a key, swapping room, and test ;)

Time to give some news then :
- released today a new iso + arch packages for GA at https://github.com/substring/test/releases/tag/2019-06 (https://github.com/substring/test/releases/tag/2019-06). It's still pretty much alpha, but things are slowly getting in shape
- EDID boot has been added, need to fix a few things here and there, some part will involve gasetup which I don't want to mess around with for now
- gotta fix some samba permissions
- GM recognizes the coin key, but for God knows which reason, coins are almost never inserted
- I'm kind of embarassed with the default frontend : the config files are not for mainline advancemame's advancemenu, and my last try with advancemenuplus still requires some work. Have added other FE, most of them need a proper configuration (when they work).

Those are the main steps before reaching beta stage. I should also update the dev wiki, there were a few improvements here and there that are worth explaining.

Still have a few big ideas in mind (like a wrapper that can configure any FE, some fun with EDID, rewriting the iso process, write an img rather than a iso ... So many ideas, so little free time). And, sooner or later, i'll have to setup a definitive pacman repo for GA, the github release thing was more of a proof of concept, it can't stand daily updates once I'll set this up. Will need 1 or 2 servers to build GA and host the GA pacman repo. But that's in a distant future !

Summer is coming as well as holidays, will probably have a break during that time ;)

As usual, curious people can check https://gitlab.com/substring45/test (issues, merge requests, wiki and CI, I never commit straight to master)
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on June 16, 2019, 05:05:56 pm
Thank you for the iso. Will test soon. Interesting coun issue with groovymame.
Title: Re: Collaborative effort for GroovyArcade
Post by: keilmillerjr on July 05, 2019, 02:07:17 pm
Thank you substring for the update on the iso. It now works in virtual box.

Some help for others to download on mac. Linux should be the same to download. Windows, you would have to download curl. I then used archiver app for mac to unpack. The default app (archive utility) on newer os10 subversions should work.
Code: [Select]
curl -r 0-199999999 -L -o groovyarcade_2019-07.iso.xz.part1 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 200000000-399999999 -L -o groovyarcade_2019-07.iso.xz.part2 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 400000000-599999999 -L -o groovyarcade_2019-07.iso.xz.part3 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 600000000-799999999 -L -o groovyarcade_2019-07.iso.xz.part4 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 800000000-999999999 -L -o groovyarcade_2019-07.iso.xz.part5 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 1000000000-1199999999 -L -o groovyarcade_2019-07.iso.xz.part6 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 1200000000-1399999999 -L -o groovyarcade_2019-07.iso.xz.part7 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz
curl -r 1400000000-1599999999 -L -o groovyarcade_2019-07.iso.xz.part8 https://github.com/substring/test/releases/download/2019-07/groovyarcade_2019-07.iso.xz

cat groovyarcade_2019-07.iso.xz.part? > groovyarcade_2019-07.iso.xz

I was able to boot from iso within virtual box. Boot menu has new options. There is no option for just plain LCD. I picked DVI-1 15khz and it worked. I plan on using this with my mvs using a k7000 and a separate machine with an lcd (for a friend, I don’t do that taboo). Not sure what would be the proper thing to do for the latter case.

Thank you substring. Keep the updates going!
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on July 06, 2019, 12:26:03 pm
Thank you for testing !

There is a lcd setting that you can choose at boot, it's aoubd the 9th position i think, you must scroll down :)

Still much work to do on it, but first, i need to split the repo in 2 : one for building packages and deploying them (need to find a solution to host them). I'd like to have a testing/unstable repo + a stable repo. The other result of the split would be to solely build the iso. And i need to totally rewrite that part.

Won't spend much time on it during july though, need a well deserved holidays break ^^
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on July 13, 2019, 07:17:35 am
So, little news before holidays break !

The way I made the whole process was too monolithic. Building packages was tied to building the iso, so there was no way to build arch packages on their own. Things are solved now and available at http://https://github.com/substring/packages/releases (https://github.com/substring/packages/releases)

You'll notice a stable and a testing release. Testing is built everyday, to match as closely as possible any updates that would happen on packages that I've included. This means for example that a kernel update would be available within 24h after the official update on Arch linux side (if no patching is implied). The idea is to let that part live on its own as much as possible. Well sometimes I may need to patch here and there, but at least, it's as much "rolling release" as possible with the few server resources I have at disposal.

The next step will be to rewrite the iso building part. As for now it's just remastering the Arch linux iso, but I'm cyrrently rewriting that part to use the archiso utility. Things are going fine so far, I hope to have a working iso by the end of August.

Then, the biggest part will come : improve gasetup ! I have quite a few ideas, I'll give some news here anyway.

And finally : documentation !!! Most of the interesting ideas are summed up in http://forum.arcadecontrols.com/index.php/topic,160440.0.html so i'll setup a repo and let others easily contribute, this must be a community effort.
Title: Re: Collaborative effort for GroovyArcade
Post by: Substring on August 17, 2019, 04:49:49 am
Time for some news !

So, been working on it lately, things are in good shape for the September release:
- split packages building and iso building in 2 different repos, so 2 different CI
- I'm almost done with CI stuff and so
- UEFI boot works with the ISO, but it's definitely useless : it bypassses the boot menu, so no video configuration. This just sucks so stick to legacy BIOS boot method
- need to spend again some time with EDID at boot, it's not working as it should yet
- fixes here and there, like applying the good mame.dat file at every groovymame upgrade. This makes advancemenu+ terribly slow to load, i'm thinking about switching to attract mode for good
- add a small web server that helps user to set volumes in alsa (the audio part). This is just a pain to be done in console, abd absolutely not user friendly

At this point, I will now focus on 2 things:
- user experience through gasetup. I'm working on adding a easygashgui backend so the very same menu would work the very same way in console or desktop environment. Less effort to maintain all that, easier configuration
- have the boot menu work in 15kHz straight away. This won't be easy, it's meant to run at 61kHz no matter what, but the code looks flexible enough to allow some patching. This part will be pretty "fun" to code/patch/test/add to GA

Also need to write some basc dics for users and contributers ...

Now the important links :
- https://gitlab.com/groovyarcade for all the dev stuff
- https://github.com/substring/packages/releases for arch linux packages
- https://github.com/substring/os/releases for OS releases. Don't bother with anything else than GroovyArcade 2019.XX releases, others are made for testing, labels sometimes get messed up

Feedback is welcome