Software Support > GroovyMAME
GroovyArcade live-CD 2022 (collaborative effort)
Calamity:
--- Quote from: Substring on April 12, 2019, 05:21:53 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.
--- End quote ---
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 ...
--- End 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.
Substring:
--- Quote from: Calamity on April 13, 2019, 01:59:29 pm ---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.
--- End quote ---
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: ---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
--- End code ---
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: ------ 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 */
--- End code ---
And in .S file, you just set
--- Code: ---#define FEATURES 0x18 + 1<<7
--- End code ---
and 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.
--- End quote ---
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:
--- Quote from: Substring on April 14, 2019, 11:13:37 am ---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).
--- End quote ---
Hi Substring,
This was a nice pointer!
So do you think this could be scripted somehow to build the grub menu?
--- Code: ---$ 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
--- End code ---
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,
--- Quote from: 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.
--- End quote ---
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.
--- End quote ---
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)
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version