GroovyArcade live-CD 2022 (collaborative effort)

[Substring]

Hi everyone,

Here is an attemps of going a little more open source for GA. I've set up a gitlab group gitlab repo showing all projects I'm working on regarding GroovyArcade.

So the aim of this repo is to:

• give a base repo to GA iso
• be able to "easily" build GA on your computer (in my case, I'm not using Arch Linux but Ubuntu)
• setup some automatic build process -> CI kicks in!
• be able to easily add some packages to GA
• and mostly give a hand to ves who's been doing GA all alone

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):

• Add the whole gasetup thing, make it a package + a repo
• include the 15kHz linux kernel (which also means rebuild the initramfs)
• setup an AUR repo for easier updates. One point regarding that : anything required to setup a AUR repo is in the github releases page (this is why gitlab mirrors to github, and the CI does the releases to github, saving a server for now)
• write documentation, despite the .gitlab-ci.yml is quite self explanatory when reading the jobs
• make sure it can be booted from USB (.iso is so 90s ). It should be bootable, but i just couldn't test yet
• clean the repo, a few files are unnecessary
• improve the CI to only auto build the master branch when any commit is pushed, build other branches manually (with probably a basic makepkg --nobuild for a basic check) and release when tagged

For curious people

• check the buildContainer.sh + buildGA.sh scripts, they do the main job. There is also a docker file that' I've been using with the builder.sh to build locally. The CI is natively built in an arch linux docker image
• read the packages_*.lst files + the package folder. packages_arch.lst are (for now) arch packages that are patched on the fly when it's time to build them. mame is patched with groovymame and becomes a groovymame package. Same goes for liunx -> linux-15kHz. packages_native.lst are genuine arch packages that are installed. packages_aur.lst are AUR packages built and then installed in the iso. packages_local.lst is packages_arch.lst once patched, and lists packages to install in the iso (mame+linux -> groovymame+linux-15khz)
• buildContainer.sh 's job is to build all packages, and then create the necessary files for an AUR site. I've tested locally, works great. See the web-repo folder on how to host
• buildGA.sh downloads and unpacks the default ARCH iso, unsquashfs the arch suquashfs file, installs everything in it through chroot, then re-squashfs the folder, patches some names here and there for grub, and rebuilds the iso
• the pipeline that built the 2019-04 tag and deployed the release to github : https://gitlab.com/substring45/test/pipelines/55863348

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

Credits and thanks go to Calamity, ves and doozer for their respective work on groovymame, groovyarcade, linux 15kHz patches and help on questions I've been asking them.

Edit: well, all that was written months ago, erad the thread for more news. But if you want to go straight to the main stuff (download an iso and test) :
ISO DOWNLOAD LINK : https://github.com/substring/os/releases
Prefer releases in the YYYY-MM format, any other is a testing branch and will be deleted. Unless you wanna debug with me

[keilmillerjr]

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.

[Substring]

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, it should have all the info to locally build, but I may have missed some parts/pre-requisites

[cools]

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.

[Substring]

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 ?

[Calamity]

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.

[keilmillerjr]

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.

[Calamity]

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).

[Substring]

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

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:
- 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 ?

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.

[Calamity]

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:
- 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.

[Substring]

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 ? If yes, I'll write a small PKGBUILD and have it compiled with GA.

[Calamity]

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.

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.

Is switchres64 the old switchres standalone found at 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. IIRC Ansa took that one and fixed some bugs, etc., not sure.

[Substring]

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. It looks rather easy

[Calamity]

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. 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.).

[Substring]

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. 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 ...

[Calamity]

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.

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.

[Substring]

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.

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).

[Calamity]

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.

[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.

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)

[Calamity]

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.

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.

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.

[Substring]

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!

[Calamity]

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.

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).

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.

[Substring]

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 !

[Substring]

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

[cools]

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.

[Substring]

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.

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!

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

[Calamity]

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.

[Substring]

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.

[Substring]

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.

[keilmillerjr]

Free bump for awesome project!

[Substring]

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 )

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

[Doozer]

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.

[Substring]

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).

[Doozer]

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.

[Substring]

The real command is su arcade -c startx -- vt7. I've attached the xorg log

[Substring]

AT LAST I've found : was missing the /etc/X11/Xwrapper.config file ! It's not added by default in arch

[ves]

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"
 

[Substring]

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. 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)

[keilmillerjr]

Thank you for the iso. Will test soon. Interesting coun issue with groovymame.

[keilmillerjr]

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!