Display scaling and other issues
Pages: 1 2
Jeffrey Lee (213) 6048 posts |
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:
My thoughts for dealing with this are along the following lines:
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. |
André Timmermans (100) 655 posts |
Some reflections: |
Tristan M. (2946) 1039 posts |
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. 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 just recalled. Doesn’t scaling only work with an un-rotated screen on an RPi? Conditional issues like that need to be dealt with. |
Jon Abbott (1421) 2641 posts |
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.
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 If these dropped support for numbered modes, it would break some software.
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. |
Jeffrey Lee (213) 6048 posts |
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)
Yes, the HAL/video driver will still receive the full set of mode timings.
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)
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.
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)
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.
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 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)
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. |
William Harden (2174) 244 posts |
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). |
Jon Abbott (1421) 2641 posts |
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.
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. |
Sprow (202) 1155 posts |
I assuming references to display scaling relate to hardware scaling, not adding software scaling or bpp conversion to the OS. 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.
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).
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)?
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. |
Steve Pampling (1551) 8155 posts |
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. 1One of those things I suppose, lots of us pre-date personal computers |
Doug Webb (190) 1158 posts |
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. |
Sprow (202) 1155 posts |
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 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 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 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. |
Clive Semmens (2335) 3276 posts |
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.) |
Doug Webb (190) 1158 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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.
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.
Yes, you’ll still be at the mercy of the hardware in terms of what will/won’t work.
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. |
Chris Evans (457) 1614 posts |
Every pi-topRO we have sold had an MDF that worked with the supplied copy of RISC OS. 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 With a plain RC15 install: 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! |
James Wheeler (3283) 344 posts |
You’re EDID in hex is
and I passed it through here no problems. |
Steve Pampling (1551) 8155 posts |
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. I went beyond the immediate requirement but apart from certain prejudices concerning open source we could still be using that setup now. How much longer would it have taken to do a proper MDF? Would it have been worth it? Probably. 1 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 |
Sprow (202) 1155 posts |
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.
Perhaps roll back up this thread to understand why? All the words are there.
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. |
Chris Hall (132) 3554 posts |
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. |
Steve Pampling (1551) 8155 posts |
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. |
Matthew Phillips (473) 719 posts |
Sprow wrote:
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). |
Jeffrey Lee (213) 6048 posts |
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) |
Steffen Huber (91) 1949 posts |
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. |
Clive Semmens (2335) 3276 posts |
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. |
Rick Murray (539) 13806 posts |
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… |
Pages: 1 2