Software Support > GroovyMAME
GroovyArcade live-CD 2022 (collaborative effort)
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:
--- Quote from: 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.
--- End quote ---
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:
--- Quote from: keilmillerjr on April 11, 2019, 08:41:36 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.
--- End quote ---
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:
--- Quote from: Calamity on April 11, 2019, 10:32:53 am ---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.
--- End quote ---
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.
--- End quote ---
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 ?
--- 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).
--- End quote ---
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:
--- Quote from: Substring on April 11, 2019, 01:25:41 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:
- 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 ?
--- End quote ---
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: ---drm_kms_helper.edid_firmware=VGA-1:edid/edid-15khz.bin
--- End code ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version