Display scaling and other issues

It’s something that’s been on the cards for a long time, but with the recent discussions regarding the built-in display scaling supported by the Pi’s GPU (and how mode timing support in RISC OS breaks that) it seems like now is a good time to try and work out a sensible way to add display scaling support into RISC OS itself.

Use cases that we need to consider:

• Screens which only offer a limited number of modes via EDID (e.g. pi-top/lapdock). It would be nice if display scaling could automatically kick-in in order to allow standard screen modes to be made available (both legacy RISC OS ones like 640×256 and standard ones like 640×480 or 1280×720). Ideally this should “just work” without the user needing to configure anything.
• Even with standard monitors where lots of modes are available, there are often times when people want/need to use legacy RISC OS modes that will either not be described in the monitor’s EDID or will not be supported by the monitor due to e.g. the pixel rate being too low. Ideally these legacy modes should “just work” as well.
• Display rotation. Like display scaling, this introduces a disconnect between the mode timings that are being supplied to the monitor and the dimensions of the RISC OS screen. If we’re designing a system which is capable of describing display scaling configurations then it would be sensible to allow it to describe rotation too
• Multi-monitor setups. This also introduces a disconnect between the mode timings that are being supplied to the monitors and the dimensions of the RISC OS screen.
• HDMI supports pixel repetition, which can be used as a way of supporting low clock rate modes while requiring minimal scaling support on the host machine (It can also be used as a way of boosting bandwidth available for audio, but that’s less of a concern for us). It would be nice if this feature could be exploited where possible so that systems which aren’t as flexible as the Pi can still offer some hardware display scaling functionality.

My thoughts for dealing with this are along the following lines:

• EDID and MDF will remain as-is. I.e. in all cases, EDID/MDF content will describe the mode timing parameters which are being sent to the monitor(s). Extra, virtual modes introduced by display scaling, rotation, multi-monitor, etc. will be an extra layer built ontop of the EDID/MDF system.
• To allow fine-tuning of parameters, a new text-based file format will be introduced in order to allow the “virtual” modes to be defined (let’s call this a “VMDF”)
• For each mode in a VMDF, most of the parameters will be optional. E.g. a valid VMDF entry could specify just the width and height of the mode; the system (probably ScreenModes?) will then work out the best way of supplying that mode (e.g. natively or via scaling)
• VMDF files will, for the most part, be monitor-independent. Essentially they’re user preferences for the display system. However it will be possible to tie the availability of certain modes down to certain monitors or video devices if necessary.
• VMDF parameters are expected to include:
  • Name to show in ScreenModes’ mode list. Perhaps also allow specification of a category so that modes can be grouped into sub-menus
  • Width & height of RISC OS screen
  • Eigen values of RISC OS screen (later this could be expanded to DPI values if we retire the old eigen system)
  • A list of physical display parameters:
    • For multi-monitor setups, the display output to use (e.g. driver + head identifier) and the area of the logical screen space (X,Y,W,H) which it should display
    • The rotation of the display
    • A specific mode to use, e.g. the name of an MDF entry or the width/height/refresh rate to look for. Perhaps also special keywords like “native”
  • As mentioned above, most of these parameters will be optional, with the system picking sensible values itself for any that are omitted.
  • Potentially we’d also want to support wildcards, to allow multiple modes to be defined using a single VMDF entry.
• ScreenModes / ScrnSetup will provide some form of VMDF editing functionality; if a user plugs in a second monitor they should expect to be able to configure most of the behaviour of a multi-monitor setup through the GUI rather than having to edit a VMDF file by hand.
• There’ll be a default VMDF built into the ROM which defines all the legacy RISC OS screen modes, and a selection of standard PC modes (e.g. 1280×720). This will allow the pi-top example to “just work”.
• Potentially it will be possible to overlay VMDF files ontop of each other, or to add/remove entries via a SWI interface. This would avoid the need for custom VMDF files to include specifications of all the modes offered by the builtin VMDF. It could also help deal with the use case where a program wants to use a custom mode which the user does not have already (e.g. custom mode modules from Archimedes games/demos, or MDF fragments supplied with RiscPC games/demos, or an emulator which needs to support whatever crazy modes the emulated system demands)
• Possibly it should also be possible to use the VMDF to disable support for modes which were previously defined (e.g. modes inherited from the base EDID/MDF or defined in other VMDF fragments). This could be a more user-friendly alternative to disabling modes via editing EDID/MDF.
• VMDF entries will be exposed to the OS and software via the standard Service_EnumerateScreenModes / OS_ScreenModes 2 interface.
• For the interface to the video driver, it’s expected that the basic functionality (display scaling & rotation) could be represented using extra VIDC control list items. Configuring the individual displays in multi-monitor setups could probably be handled with extra control list items too, assuming the complex memory requirements don’t get in the way.

I guess the key thing is going to be coming up with a good specification for the VMDF file format – one that’s concise and easy for humans to describe what they want, but also simple enough to not result in a slow or overly-complex implementation within the OS.

Some reflections:
- VMDF certainly seems useful for things like the Pi-Top where the single resolution reported by the EDID of its screen cannot be supported by RISC OS as is.
- Now should also be a good time to eradicate all trace of numbered mode info/timings and just have a built-in table translating mode numbers into mode definitions to pass to the video drivers.
- Is it a good idea to pass extra parameters to the video drivers to try to let him cope with a given resolution? Rotation may be useful but how do you know how the video driver will try to cope with the demanded mode definition? Pi is simple as you can let the GPU do the scaling but who knows what other drivers can do. If I take the RISC PC for example, I have written a little module which fakes missing resolutions by taking the smallest MDF entry in which the resolution fits, modifying it by moving the unneeded width/height pixels to the borders. It doesn’t provide scaling but at least it let show old games/demos in the center of my monitor. You mention yourself HDMI pixel doubling. I think it’s best to leave the video driver find the best way display/scale the demanded resolution.

- Now should also be a good time to eradicate all trace of numbered mode info/timings and just have a built-in table translating mode numbers into mode definitions to pass to the video drivers.

Please! When I was trying to work out how to get the current screen resolution for Synergy I came across the oddness of numbered modes. Thankfully it didn’t really hinder me but I agree they should function using the same system as other modes.

I wanted to get in here with discussion to make sure that the monitor definitions will still have all their details HAL readable. Last night I was staring at a bunch of video registers that want an awful lot of info for screen setup, which the mode settings have thankfully.

Scaling should probably be hardware agnostic with additional HAL entries so other devices which can use scaling can take advantage of it.

EDID needs to be reined in a bit too. Last week I spent some infuriating hours fighting with RISC OS trying to force a totally valid screen mode. Long story short, I couldn’t.
I could use WimpMode once booted to set the right resolution but the pixel clock was wrong so functionally useless.
I was forcing 576p for a video converter so it didn’t use it’s scaling. EDID kept getting in the way.

Back to this. If you have a monitor definition file set up correctly, it should be able to fill in missing modes with scaling easily enough as a fallthrough. First checking for a clean multiple, and if that fails, go for something with the least amount of offset scanlines.
I think most people would rather a slightly blurry screen than a black screen.

I just recalled. Doesn’t scaling only work with an un-rotated screen on an RPi? Conditional issues like that need to be dealt with.

I can see that VMDF might be required for multiple displays but am not convinced another text file is required for anything else. In the case of GPU’s that support hardware scaling, a simple option to “use hardware scaling” in the display control panel would suffice, which simply ignores EDID data.

Could VIDC List Type 3 be extended to support virtual resolutions, or add a Type 4?

I assuming references to display scaling relate to hardware scaling, not adding software scaling or bpp conversion to the OS.

- Now should also be a good time to eradicate all trace of numbered mode info/timings and just have a built-in table translating mode numbers into mode definitions to pass to the video drivers

GraphicsV drivers only accept VIDC List Type 3 and have no understanding of mode numbers.

I’m not sure they could be eradicated elsewhere as a lot of legacy functions used mode numbers, for example:

ColourTrans
OS_ScreenMode 0
OS_Byte 135
OS_ReadModeVariable
OS_SpriteOp 15
Service_PreModeChange
Service_ModeChanging
Service_ModeChange

If these dropped support for numbered modes, it would break some software.

EDID needs to be reined in a bit too. Last week I spent some infuriating hours fighting with RISC OS trying to force a totally valid screen mode. Long story short, I couldn’t.

Where you’re trying to set a non-EDID resolution, you have to currently disable EDID. I believe this is an example case of what Jeffrey is proposing a solution for.

- Is it a good idea to pass extra parameters to the video drivers to try to let him cope with a given resolution? Rotation may be useful but how do you know how the video driver will try to cope with the demanded mode definition? Pi is simple as you can let the GPU do the scaling but who knows what other drivers can do.

Yeah, there’ll have to be some changes to the mode vet process so that ScreenModes can work out whether the driver can support certain modes (and how). But I’m not sure yet how extensive those changes will need to be.

A naive approach would be to have ScreenModes brute-force a few different combinations until it finds a configuration that the video driver is happy with. But if there are lots of combinations to try then it would make sense to move more of the logic into the video driver – which may also involve giving the video driver more information about which mores are in the MDF/EDID (at the moment, there’s not really any legal way for a video driver to call into ScreenModes)

I wanted to get in here with discussion to make sure that the monitor definitions will still have all their details HAL readable. Last night I was staring at a bunch of video registers that want an awful lot of info for screen setup, which the mode settings have thankfully.

Yes, the HAL/video driver will still receive the full set of mode timings.

Scaling should probably be hardware agnostic with additional HAL entries so other devices which can use scaling can take advantage of it.

The HAL video entries should probably be considered deprecated. The preferred way of implementing a video driver is to write a module which interfaces with GraphicsV. This will become more important once video drivers are given more control over things like memory allocation (which the HAL is a bit too low-level for)

I could use WimpMode once booted to set the right resolution but the pixel clock was wrong so functionally useless.

That sounds like a bug. If you want to see it fixed, reporting it in a new thread or on the bug tracker would be wise.

I can see that VMDF might be required for multiple displays but am not convinced another text file is required for anything else. In the case of GPU’s that support hardware scaling, a simple option to “use hardware scaling” in the display control panel would suffice, which simply ignores EDID data.

If there’s just a checkbox to enable it, then what would the user see in the display manager’s menu? Would they only see the base modes that are listed in the MDF/EDID? Would they see every possible mode that can be supported by scaling (so, probably well over 64k modes for something like the Pi)? By explicitly listing the modes the user wants to have available in the VMDF, the display manager knows to show those modes in its menu (consider Clive’s use case)

Could VIDC List Type 3 be extended to support virtual resolutions, or add a Type 4?

I’m expecting that the virtual resolution (and any other parameters, e.g. whether to scale the display or centre it) would be defined by just adding extra control list items.

I assuming references to display scaling relate to hardware scaling, not adding software scaling or bpp conversion to the OS.

Yes, just hardware scaling for now. Software scaling, BPP conversion, software display rotation, etc. are things that I’m hoping can be dealt with by an “overlay” GraphicsV driver which sits ontop of the real driver. So as long as all the driver<→OS interaction is via GraphicsV we shouldn’t have to worry too much about how software-based solutions will be handled.

- Now should also be a good time to eradicate all trace of numbered mode info/timings and just have a built-in table translating mode numbers into mode definitions to pass to the video drivers

GraphicsV drivers only accept VIDC List Type 3 and have no understanding of mode numbers.

I think André is making reference to the fact that the kernel has lots of special-case code to deal with numbered modes, and that he’s interested in seeing that cleaned up so that they’re mostly handled the same as mode selector blocks. Or at least that’s the part of numbered modes that I hate the most.

Currently the kernel does have a big table of VIDC lists describing all of the numbered modes, but there’s no legal way for software outside of the kernel to convert a mode number to a VIDC list (unlike mode selector blocks, which can be converted via Service_ModeExtension; see previous discussion here)

Where you’re trying to set a non-EDID resolution, you have to currently disable EDID. I believe this is an example case of what Jeffrey is proposing a solution for.

Yes. The glorious dream of EDID is that people should just be able to plug in their monitor and have it work, but the desire to use custom or legacy resolutions is incompatible with that dream. One solution would be to generate extra modes based around whatever timing standard the monitor indicates it supports. But most monitors only claim that they support the modes that are listed in the EDID; other arbitrary modes might work but there’s no guarantee of this (or the monitor might detect them wrong and display them at a funny scale/offset). So the best course of action is likely to be to restrict the video output to just the modes that are defined in the EDID, and provide support for any other modes via display scaling. At the end of the day, with an LCD monitor, unless you’re using it at its native resolution there’s always going to be some scaling going on. We’re just improving the OS so that the computer can handle the scaling instead of having to rely on the limited scaling supported by the monitor.

At its simplest many of the legacy modes could probably be supported by tweaking the EDID defined modes to letterbox the eventual mode. I think all the calculation code is in there to do that already.

So – if you want 320X256, at its simplest we could letterbox that on 640×480.

Second question – do we need to define VMDF? Would it be possible instead to just permit ‘any’ screen mode smaller than the maximum (parameters are already in EDID for specified maximums), and then either scale or letterbox to get the best result? Instead of a VMDF, what you have are ‘custom’ options for the Display manager (X, Y, Colours, Pixel rate).

If there’s just a checkbox to enable it, then what would the user see in the display manager’s menu? Would they only see the base modes that are listed in the MDF/EDID?

Yes. If custom resolutions are required it could contain a tab where they can be manually added to the MDF – or preferable a user MDF/VMDF file so they’re not delete by EDID or overwriting the original MDF’s.

I’d suggest looking at how other OS display drivers handle this, such as NVidia or Intel on Windows. Most offer duplicate screens, stretched desktop and custom resolutions.

if you want 320×256, at its simplest we could letterbox that on 640×480

LCDGameModes uses that method to display legacy screen modes on Arc’s that are connected to modern monitors. ADFFS does something similar when translating VIDC to VIDC20 on RiscPC, but uses EGA on VGA (640×350) instead. For Iyonix (and I suppose other GPU’s that don’t upscale), I provided EGAonVGAMonitor.zip (see Iyonix requirements) which contains an EGA on VGA MDF file for legacy resolutions.

I assuming references to display scaling relate to hardware scaling, not adding software scaling or bpp conversion to the OS.

Yes, just hardware scaling for now. Software scaling, BPP conversion, software display rotation, etc. are things that I’m hoping can be dealt with by an “overlay” GraphicsV driver which sits ontop of the real driver. So as long as all the driver<→OS interaction is via GraphicsV we shouldn’t have to worry too much about how software-based solutions will be handled.

Jon’s beaten me to it on the question of whether it’s hard or soft scaling, so initially trying just hardware scaling seems sensible. I had a go at software scaling inside Hopper so it could use a 640×512 screen when a 320×256 was unavailable, but it turned out to be unworkably slow (at least on a Risc PC, which was its contemporary) because in effect it was having to plot 4x more data. It might not be the best example, because in trying that I discovered that Hopper plots the entire screen every flyback rather than just the bits that were moving.

To allow fine-tuning of parameters, a new text-based file format will be introduced in order to allow the “virtual” modes to be defined (let’s call this a “VMDF”)

I’m not convinced a VMDF is workable for the majority of people though. There must be dozens of threads on this forum where people have messed up their Pi config.txt, the voodoo we just got rid of by adding EDID to avoid needing MDFs, plus all the out of sync MimeMaps out there. I don’t mind it being a text file under the bonnet (like most of the control files in !Boot and !Internet) so power users can tinker, but the bulk of users either don’t care how it works or don’t know how it works.

I’m struggling to think why I would ever want my desktop in something that’s not already detected via EDID or present in an MDF, particularly on flat panel displays where I want no horrid scaling artifacts (CRT’s are more forgiving since the beam sweep is a continuous analogue affair).

Even with standard monitors where lots of modes are available, there are often times when people want/need to use legacy RISC OS modes that will either not be described in the monitor’s EDID or will not be supported by the monitor due to e.g. the pixel rate being too low. Ideally these legacy modes should “just work” as well.

Yes – I think it’s this bit. But I don’t need all these new fake modes to appear in Display Manager, I only want them faking up when I run a game that requests such a mode (I realise that currently there’s no hint to the underlying driver whether a human asked for a mode or a program). For numbered modes that’s probably doable (the numbered modes are already not in the Display Manager’s menu) so maybe if a mode selector is used the OS could try to find the corresponding numbered mode, then we only need scaling magic for numbered modes, then it can be a simple checkbox option “Try scaling when resolution unavailable”.

Presumably this scheme could still end up with a Mode not available error, if, after negotiating via GraphicsV, it turns out the scaling can’t manage what’s asked of it (eg. the controller can only do factor-of-two scaling, and a factor of 5 is needed)?

Screens which only offer a limited number of modes via EDID (e.g. pi-top/lapdock).

In the specific case of the pi-top, with 1366 pixels, I don’t get why this is a problem today. It would be the work of seconds to save out the EDID and create a proper MDF with 3 pixel left and right borders and 1360 active area, or for a few minutes edit the EDID detailed timings similarly. That CJE are selling such a unit without doing this is just laziness.

For an automagic solution, what would happen? I don’t want my screen resampling by 100.44% thank you, but a 3 pixel border would probably be invisible due to parallax error. On the other hand someone else would probably hate having borders. So now we’re back to grubbing round editing text files. Hmm.

I’m struggling to think why I would ever want my desktop in something that’s not already detected via EDID or present in an MDF, particularly on flat panel displays where I want no horrid scaling artifacts (CRT’s are more forgiving since the beam sweep is a continuous analogue affair).

I think people have rather got caught up in the idea that more pixels on screen is always good when in fact driving the display at the level at which the screen is best reproducing the intended image should be the target.

There is a certain mindset that says more is better.
Back in the 70’s¹ it was pocket calculators with hundreds of functions when most people needed basic maths and about 20 other higher level items.² They were under used but still ate the batteries.

¹One of those things I suppose, lots of us pre-date personal computers
² I have a Casio FX-115 that I’ve had from new. I’ve not used more than about 40-50% of the functions.
Best bit is the “high power solar cell” that means it works in fairly low light and I’ve never accidentally left batteries in so it still works just like it ever did.

In the specific case of the pi-top, with 1366 pixels, I don’t get why this is a problem today. It would be the work of seconds to save out the EDID and create a proper MDF with 3 pixel left and right borders and 1360 active area, or for a few minutes edit the EDID detailed timings similarly.

Well for those who have a DIY lapdock/pi-top then it might be simpler than the black art required to tune a MDF as no matter how simple it is to some it may not be that to others.

Though of course I’m personally not adverse to paying for a pre-constructed one it would be good to have the OS provide some flexibility on supporting screen modes that are not hampered by the current requirements to be divisible by a certain number.

In the specific case of the pi-top, with 1366 pixels, I don’t get why this is a problem today. It would be the work of seconds to save out the EDID and create a proper MDF

Well for those who have a DIY lapdock/pi-top then it might be simpler than the black art required to tune a MDF as no matter how simple it is to some it may not be that to others.

But the point here is that the voodoo aspect has already been done for you by EDID, so the timing parameters are already correct. If you’re used to looking at the horizontal scan on a scope (could just be me!) the h_timings parameter in MDFs is just describing the left to right scan of the electron beam in that order

h_timings:hsync_width,back_porch,left_border,display,right_border,front_porch

So let’s take a worked example. Plug in the object of interest whose EDID is correct for the panel, but can’t be driven at that size because of a constraint of the video driver.

*SaveModeFile $.MyScreenAsAnMDF

Load the file into a text editor and find the (possibly only) mode

startmode
mode_name: Pesky
x_res:1286
y_res:720
pixel_rate:34567
h_timings:40,220,0,1286,0,110
v_timings:5,5,0,720,0,20
sync_pol:3
endmode

Let’s move some of those pixels into the border so the video driver is happy again, assuming it wants them to be a multiple of 8

startmode
mode_name: Pesky
x_res:1280
y_res:720
pixel_rate:34567
h_timings:40,220,3,1280,3,110
v_timings:5,5,0,720,0,20
sync_pol:3
endmode

Save the file. Drag it to Display Manager to test. Assuming it works, add it to the MDF library on disc so it can be picked from the Screen Setup plugin.

If you’ve taken a DIY approach, I’d expect an enterprising RISC OS dealer would happily sell you a suitably tweaked MDF. For extra finesse, I’d have expected a dealer selling such a system complete to have tweaked the EDID data and saved it into the panel so everything works out of the box. DIYers might have to settle for a disc based update.

[Sprow] I’m struggling to think why I would ever want my desktop in something that’s not already detected via EDID or present in an MDF, particularly on flat panel displays where I want no horrid scaling artifacts.

I use my 3840×2160 43" flat panel TV in any of several modes between 1920×1080 and 3840×2160, depending how much detail I want on screen – I use the lowest resolution that’s sufficient to display all the detail I want to have available simultaneously. I’m not normally conscious of the scaling artifacts, although of course I can see them if I look closely. (The only apps I’m using that I want a lot of detail on screen for are Draw and StrongEd. Might be FontEd again at some point in the future, but I’ve not used that for a couple of years.)

Save the file. Drag it to Display Manager to test. Assuming it works, add it to the MDF library on disc so it can be picked from the Screen Setup plugin.

So the easy part was to modify the EDID derived MDF as you suggested but the harder part was to get some screen modes that ArcEM would work with.

So it comes back to the issue if RISCOS doesn’t support the panel screen resolutions then you have to hand craft MDF’s not just for the EDID reported stuff whereas the old behaviour just scaled things and it worked out of the box.

So all in all it has been good to know a bit more about editing MDF’s but I think I’m in the camp to support the changes including the scaling bit.

This is not saying I’m against the EDID changes , far from it, as they work out of the box in most cases but for some they don’t and it is those which the suggested updates are trying address including some long held screen constraints.

How the changes are implemented then I’ll leave it to the experts to fine tune the design spec.

I don’t mind it being a text file under the bonnet (like most of the control files in !Boot and !Internet) so power users can tinker, but the bulk of users either don’t care how it works or don’t know how it works.

Yes, that’s basically what I’m aiming for. The default settings should “just work” for the majority of people, and for the other people they should hopefully be able to do things via configuration GUIs, with editing of the file by hand a last resort.

Using a text file, as opposed to binary, has the advantage that hand-editing is more friendly, so if we release the OS update without all of the configuration GUIs being ready then people won’t have such a hard time configuring any advanced features.

But I don’t need all these new fake modes to appear in Display Manager, I only want them faking up when I run a game that requests such a mode

Easy solution – make the VMDF specify whether the mode should appear in the display manager or not. It’s not really any different to the current MDF system, where only modes with explicit names will appear in the display manager.

Presumably this scheme could still end up with a Mode not available error, if, after negotiating via GraphicsV, it turns out the scaling can’t manage what’s asked of it (eg. the controller can only do factor-of-two scaling, and a factor of 5 is needed)?

Yes, you’ll still be at the mercy of the hardware in terms of what will/won’t work.

In the specific case of the pi-top, with 1366 pixels, I don’t get why this is a problem today.

The problem with 1366-width modes is that the Pi’s GPU wants the framebuffer row stride to be a multiple of 32 bytes, but BCMVideo has no means to communicate this requirement to the OS. The solution is to improve GraphicsV and the OS so that it can deal with arbitrary row stride values correctly. Use of display scaling to resolve the problem was a workaround, not a fix.

In the specific case of the pi-top, with 1366 pixels, I don’t get why this is a problem today. It would be the work of seconds to save out the EDID and create a proper MDF with 3 pixel left and right borders and 1360 active area, or for a few minutes edit the EDID detailed timings similarly.

Every pi-topRO we have sold had an MDF that worked with the supplied copy of RISC OS.
It also worked with nightly builds until the recent unannounced dropping of support for ‘no timings’ MDFs

When we wrote the MDF (all two minutes work) nearly two years ago there was no RISC OS support for EDID and no suggestion that Pi MDF timing support was planned, so extra work at that time would have been a stupid waste of our time.

But we are where we are. So we’ve tried using EDID on a pi-top
It fails!

With a plain RC15 install:
With RISC OS set to use EDID (native), the pi-top gives no display.
Use an MDF, to get a display, then the menu entry which would say Auto(pi-top) or similar says Auto (Unidentified) and the resolution menu has no entries.
Extracting the EDID file from Resources:$.Screenmodes.EDID and putting through an online analyser says that it is not valid EDID data. Uploaded to: www.cjemicros.co.uk/Public/pi-top/EDID0

If as seems possible, support for ‘no timings MDFs (without needing to add the line disable_mode_changes to cmdline/txt inside the Loader partition) is included in the future then our time doing the above and anyone else’s time spent on it could have been better spent on other RISC OS work!

putting through an online analyser says that it is not valid EDID data

You’re EDID in hex is

0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x26 0xCF 0x33 0x05 0x00 0x00 0x00 0x00
0x00 0x16 0x01 0x03 0x80 0x1D 0x11 0x78 0x0A 0x12 0x30 0x91 0x56 0x53 0x92 0x28
0x1E 0x50 0x54 0x00 0x00 0x00 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x20 0x1C 0x56 0xA6 0x50 0x00 0x0F 0x30 0x28 0x20 
0x3C 0x00 0x25 0xA5 0x10 0x00 0x00 0x19 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFE 0x00 0x49 
0x6E 0x66 0x6F 0x56 0x69 0x73 0x69 0x6F 0x6E 0x0A 0x20 0x20 0x00 0x00 0x00 0xFE 
0x00 0x4D 0x31 0x33 0x33 0x4E 0x57 0x4E 0x31 0x20 0x52 0x33 0x20 0x0A 0x00 0x28

and I passed it through here no problems.

When we wrote the MDF (all two minutes work) nearly two years ago there was no RISC OS support for EDID and no suggestion that Pi MDF timing support was planned, so extra work at that time would have been a stupid waste of our time.

Eight years ago I was given the remit of sorting out network access security. I quickly decided on a RADIUS implementation and built a FreeRADIUS server on an old laptop to “play” with.
When I outlined my plans to the director my implementation remit was MAC auth only but I decided that full dot1x with MAC fallback was going to be almost as easy. The laptop got replaced with a simple PC and that’s what we used until someone decided that commercial was better than free because it eliminated the “single point of failure” – me.¹

I went beyond the immediate requirement but apart from certain prejudices concerning open source we could still be using that setup now.
Do it right the first time and you don’t have to re-do it.

How much longer would it have taken to do a proper MDF? Would it have been worth it? Probably.

¹ I wrote a CGI module and few scripts so that people could use WebMin to control the RADIUS server but we had to go commercial. The Single point of failure still seems to be there because no-one else seems to want to make the effort to understand the RADIUS sequence

When we wrote the MDF (all two minutes work) nearly two years ago there was no RISC OS support for EDID and no suggestion that Pi MDF timing support was planned, so extra work at that time would have been a stupid waste of our time.

I’ve no idea where you were looking, but forwarding the proper mode timings to the GPU had been on the slate since as far back as 2014, predating the pi-top.

You’re quite right that RISC OS didn’t support EDID then, but as a system integrator getting the blob (eg. from Linux ‘modetest’) would then have given you the definitive correct timings straight away. I mentioned previously I happened to pick Deltacast’s EDID editor but there are 114,000 others to choose from. You blob looks valid; the panel’s made by InfoVision and has just 1 (preferred) mode.

But we are where we are. So we’ve tried using EDID on a pi-top. It fails!

Perhaps roll back up this thread to understand why? All the words are there.

If as seems possible, support for ‘no timings MDFs (without needing to add the line disable_mode_changes to cmdline/txt inside the Loader partition) is included in the future then our time doing the above and anyone else’s time spent on it could have been better spent on other RISC OS work!

I can’t parse that many pronouns. I think you’re saying that adding hardware scaling to the OS (in future) is cheaper than your time to create 1 MDF in the past. So at that point I’ll give up. Prior to RISC OS wrestling control of the video timings back off the GPU, the Pi’s funky scaling was so confusing to people (where none of the OS dialogues reflected what your eyes saw) that a whole extra app was needed just to understand.

Getting to today’s position where setting up a Pi’s screen is like every other RISC OS machine is a great achievement.

Getting to today’s position where setting up a Pi’s screen is like every other RISC OS machine is a great achievement.

Agreed. High vector roms on Pi will probably not cause great kerfuffle as Aemulor is a paid-for app on the Pi. High vector roms on ARMX6 and other platforms where Aemulor is free might not catch on until 32 bitting of Impression is completed.

High vector roms on ARMX6 and other platforms where Aemulor is free might not catch on until 32 bitting of Impression is completed

I don’t see the connection, Ovation Pro has been 32 bit for years so I fail to see why the possible eventual completion of the process for another DTP application would be in any way a watershed.

Sprow wrote:

If you’ve taken a DIY approach, I’d expect an enterprising RISC OS dealer would happily sell you a suitably tweaked MDF. For extra finesse, I’d have expected a dealer selling such a system complete to have tweaked the EDID data and saved it into the panel so everything works out of the box. DIYers might have to settle for a disc based update.

What do you mean by “saved it into the panel”? Are you referring to some way of altering what the screen hardware declares when asked what timing and resolutions it supports?

Thank you for the worked example for adjusting an MDF from the EDID. I have a pi-top which I was about to update to RC15. I tried a couple of weeks ago but the screen came out all wrong. The MDF was probably to blame, so armed with this knowledge I will have another go.

Less sniping at CJE, please. There are plenty of explanations apart from laziness, like lack of time, lack of understanding of the implications and lack of awareness of slated future developments (which could also result from lack of time to read every web page going).

What do you mean by “saved it into the panel”? Are you referring to some way of altering what the screen hardware declares when asked what timing and resolutions it supports?

Sometimes the EEPROM that contains the EDID isn’t write protected, allowing it to be updated/overwritten via the same I2C interface that’s used for reading. Often this is a bad thing (you don’t want to accidentally erase the EDID for your monitor/TV), but if you’re trying to fix/improve the manufacturer’s EDID then it’s useful. (And if it isn’t directly writable, there might be a protection link or something you can fiddle with to allow it to be re-programmed)

I don’t see the connection, Ovation Pro has been 32 bit for years so I fail to see why the possible eventual completion of the process for another DTP application would be in any way a watershed.

Many people seem to like Impression and dislike (or simply don’t have and don’t want to buy) Ovation Pro. And at the same time, Impression is probably the only major application that is both widely used and not 32bitted. So it is entirely plausible that this is THE watershed.

In IYONIX times (15(!) years ago), Aemulor was often called (after Artworks got converted to 32bit) “the Impression emulator”. Correctly, as it seems.

I used to use Impression – we published two major academic journals, five hundred A4 pages a month with maths, chemistry, diagrams, foreign names and addresses in many languages, and photos, for five years, using it. I wrote a lot of little apps to complement it to raise productivity in the office. But that’s all water under the bridge so far as I’m concerned: I use LibreOffice on the Mac now, and only produce a book or two a year. I do rather miss some of the things I could do with Impression though.

Many people seem to like Impression and dislike (or simply don’t have and don’t want to buy) Ovation Pro.

Now, the question that I would ask is if this is really because people don’t “like” OvationPro, because they don’t want to buy OvationPro, or – the most likely option – they don’t want to be stuck with a bunch of files that they can’t do anything with, other than continue using Impression…