Software Support > GroovyMAME
GroovyArcade live-CD 2022 (collaborative effort)
Substring:
Hey Calamity,
--- Quote from: Calamity on April 15, 2019, 03:53:06 am ---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.
--- End quote ---
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:
--- Quote from: Substring on April 15, 2019, 04:35:53 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 ;)
--- End quote ---
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 ;)
--- End quote ---
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!
--- End quote ---
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:
--- Quote from: Calamity on April 15, 2019, 05:17:52 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).
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version