ScreenModes/VIDC type 3 info
Jon Abbott (1421) 2651 posts |
I’m looking at adding EDID support to the GraphicsV driver/blitter in ADFFS. To do that, I require the VIDC type 3 list for a suitable mode to pass via GraphicsV 2 to the underlying GraphicsV driver running the hardware. ScreenModes does hold that info as *SaveModeFile writes it out to file. Service_EnumerateScreenModes however only returns the basic resolution info. To build a list of VIDC type 3 mode settings, is my only option to issue *SaveModeFile and scape it or is there a better way that I’ve missed? |
Jon Abbott (1421) 2651 posts |
I think I’ve concluded that I can’t use RISC OS to determine the supported resolutions/refresh rates. Using *SaveModeFile does save the mode detail of known modes, but isn’t exactly useful from a programmatical perspective. I’m leaning towards adding a mode configuration tool to ADFFS, where the end user can adjust mapping legacy modes to supported resolutions, with options to test different refresh rates. I’ll request and decode the EDID data direct from the monitor as a starting point auto-mapping to the most suitable resolution. That will get a working display, all be it with the wrong refresh rate, the user can then use the configuration app to tweak it if they want 50hz for smooth scrolling. |
Jeffrey Lee (213) 6048 posts |
Service_ModeExtension is the method that the kernel uses to map mode selector blocks (and some mode numbers) to VIDC lists. https://www.riscosopen.org/wiki/documentation/show/Service_ModeExtension However one restriction is that you can’t specify the GraphicsV driver or head – the OS will just default to the current driver + head. (By “OS”, I mean the kernel and ScreenModes, both of which are capable of responding to that service call). So if you’re implementing your own GraphicsV driver which becomes the default for the OS, you might need to generate and cache the VIDC lists before switching the OS over to your driver. |