scaling_kernel=8 in RC15?

Hi everyone,

On my previous build (recent-ish ROM, firmware and HD4) I had the line “scaling_kernel=8” in CONFIG/TXT. This was mainly to make games look better in ADFFS but also made the bootup messages (“RISC OS 448MB” etc) appear nice and crisp.

I’ve subsequently replaced everything in Loader with the files from RC15. This means that I have a new ROM, a new CONFIG/TXT and presumably also new firmware. I then re-added “scaling_kernel=8” (along with some other lines) to CONFIG/TXT. However, it doesn’t seem to be taking effect. The text on bootup is back to the old blurry style again, and while ADFFS won’t run on RC15 I assume that games would look blurry too.

This isn’t a major issue, but I’m just wondering whether this option is working for anyone else.

Just guessing here, but maybe adding ‘disable_mode_changes’ to CMDLINE/TXT (plus setting your default hdmi_mode in CONFIG/TXT) will help.

Just guessing here, but maybe adding ‘disable_mode_changes’ to CMDLINE/TXT (plus setting your default hdmi_mode in CONFIG/TXT) will help.

If it does help then I think Chris needs to feed the details of his setup to ROOL because that sounds like a small niggle with the EDID related video code changes and the EDID is obviously still a beta feature.

I don’t even have (and have never had) a CMDLINE/TXT, and didn’t need hdmi_mode in my previous CONFIG/TXT. My previous ROM, which was probably from mid-March, had EDID support and it worked correctly.

The main difference between older and newer ROMs is that (unless you add disable_mode_changes to CMDLINE/TXT), RISC OS will now dictate the mode timings to the GPU, just like on every other RISC OS system. So blurry text in low-res modes is because your monitor is scaling the image (whereas previously the GPU would have been doing it).

An alternative to using disable_mode_changes would be to do *Configure MonitorType EDID and *Configure Mode Auto (and it would probably be a good idea to set up EDID through Configure – select the “Auto (your-monitor-here)” monitor and “Native” screen resolution). Assuming EDID is working correctly with your monitor, this should then result in the system using your monitor’s native mode during for both the desktop and the boot screens.

ADFFS is going to be a different story. AIUI recent versions of ADFFS only work with high vector ROMs, but RC15 is low vector. I’m also not sure whether ADFFS has any built-in display scaling – if it doesn’t then many games might not work because they’ll be trying to use Archimedes-era screen modes which modern monitors can’t cope with. So the solution there would be either (a) wait for display scaling support in the OS, (b) wait for display scaling support in ADFFS, or © disable_mode_changes.

An alternative to using disable_mode_changes would be to do *Configure MonitorType EDID and *Configure Mode Auto

Thanks; that’s done it! The boot text is a bit smaller, but it’s nice and crisp now :)

and it would probably be a good idea to set up EDID through Configure – select the “Auto (your-monitor-here)” monitor and “Native” screen resolution

As a curiosity, should there be an option called “Native” somewhere? The Resolution menu in Configure/Screen offers five resolutions; should there be a “Native” entry here too? I’m 90% sure that I’m running the RC15 version of the Screen configuration plugin.

As for ADFFS, I’ll wait and see what happens there.

I think ADFFS on RPi relies on AnyMode/RPi GPU scaling, because it does not have any scaling/frame interpolation.

As a curiosity, should there be an option called “Native” somewhere?

Yes. In the “Monitor type” menu, select “Auto (your-monitor-here)” (not the plain “Auto” setting). “Native” should then appear in the resolution menu.

“Native” should then appear in the resolution menu.

It doesn’t :)

I’ve noticed something though – the “Auto (Philips 170S)” option doesn’t stick; if I click on Set and then reopen the Screen window then it’s switched itself over to the entry under the Philips submenu. Should this happen?

I’ve also noticed screen configurations not sticking – but that behaviour has gone away since I put in the disable_mode_changes CMDLINE/TCT. Screen configurations now stick.

It’s the MDF that’s doing it. If I move the Philips MDF out of !Boot then I get the Native option. Put the MDF back and Native disappears. I suppose this is technically expected behaviour, since the MDF doesn’t define a “Native” option.

To put it a different way, it seems that RC15 uses EDID to determine what hardware is connected and then uses that hardware’s MDF if present. If an MDF doesn’t exist then you get a “pure EDID” solution. Is my interpretation correct?

There wasn’t an MDF for my monitor. The problem in my case seems to be that the Native option (3840×2160@24Hz,25Hz or 30Hz) is beyond what the Pi is specified to be capable of – the pixel frequency has to be overclocked by almost 25% to drive it (which works fine on either of my Pis).

it seems that RC15 uses EDID to determine what hardware is connected

FWIW I’ve found that the monitor needs to be directly connected to the Pi for this to work: it seems that interposing a KVM switch prevents the EDID data from being ‘seen’ – that’s my experience here at any rate.
EDIT: NB, once RC15 has captured the EDID data and Configure-Screen Native settings have been set up as discussed above and elsewhere, the setup seemingly survives restoration of the KVM switch.

NB, once RC15 has captured the EDID data and Configure-Screen Native settings have been set up as discussed above and elsewhere, the setup seemingly survives restoration of the KVM switch.

Not correct, sadly: the Pi failed to select the correct resolution on startup this morning (connected via KVM switch to the monitor) and on several subsequent tests. Testing with monitor connected directly worked as advertised, but as the KVM switch is an integral part of my setup, I’ve restored hdmi_group and hdmi_mode lines to Config.txt, and created Cmdline.txt as recommended here:
https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi
which seems to have done the trick.

[George] I’ve found that the monitor needs to be directly connected to the Pi for this to work: it seems that interposing a KVM switch prevents the EDID data from being ‘seen’

It’s not a very useful KVM that doesn’t pass through the EDID data. Since any computer-side ports are only ever reading the data, it’d be trivial to buffer it in something like a PIC micro with more than 1 IIC port, sub $0.90 in volume.

Anyway, junk consumer electronics aside, one option with the EDID system in RISC OS is to copy the blob when the monitor is plugged directly into the Pi (the EDID data appears as a file in Resources:$.Resources.ScreenMode.Monitors) into $.!Boot.Resources.Configure.Monitors (anywhere will do). That way, it’ll appear in the Screen Setup plugin regardless of what your KVM is up to, and at least you have the proper modes that the monitor manufacturer recommends.

[Clive] The problem in my case seems to be that the Native option (3840×2160@24Hz,25Hz or 30Hz) is beyond what the Pi is specified to be capable of – the pixel frequency has to be overclocked by almost 25% to drive it (which works fine on either of my Pis).

I analysed this in some detail but subsequent gleeful mentions of just bludgeoning in disable_mode_changes tells me I wasted my time. If you try the suggestion, you should find the native option appears and all the other views are self consistent (eg. when going into the monitor’s status menu).

…one option with the EDID system in RISC OS is to copy the blob when the monitor is plugged directly into the Pi…and at least you have the proper modes that the monitor manufacturer recommends.

Indeed. I’ll give it a go. However, I don’t know how to locate Resources:$.Resources.ScreenMode.Monitor.

Click Menu on the Apps icon on the icon bar, then select “Open ‘$’”

(this makes sense when you realise that the title of the Apps window is Resources:$.Apps; the applications are added as entries in ResourceFS)

[Sprow] I analysed this in some detail but subsequent gleeful mentions of just bludgeoning in disable_mode_changes tells me I wasted my time. If you try the suggestion, you should find the native option appears and all the other views are self consistent (eg. when going into the monitor’s status menu).

Sorry, and thanks!

I’d already done the bludgeoning in, and the setting of appropriate max_framebuffer_width/max_framebuffer_height/hdmi_pixel_freq_limit in config/txt – before you posted your piece, and if I’ve gleefully mentioned the bludgeoning in more recently, it’s because I hadn’t spotted your piece (until you linked to it just now). Since what I’ve done works, I’ll probably just leave it now (but see Edit below). It would be interesting to know whether I’d be offered a good selection of modes if I took out the disable_mode_changes and relied on Auto, but it’s not high on my priorities list since I’ve got the ones I made. So far as the monitor’s concerned, they’re all 3840×2160 anyway, so the manufacturer’s recommended modes aren’t important to me.

Edit: on the other hand, if I use Auto and the manufacturer’s recommended modes, would that mean that my GPU was being overclocked less in any but the highest resolution modes, and might that increase the life expectancy of my Pi? If so, and if I would get some useful modes > 1920×1200 but < 3840×2160, perhaps I should try?

Just checked the monitor spec. It lists:

Resolutions (amongst others)
• 640 × 480p – 60 Hz
• 800 × 600p – 60 Hz
• 1024 × 768p – 60 Hz
• 1280 × 768p – 60 Hz
• 1360 × 765p – 60 Hz
• 1360 × 768p – 60 Hz
• 1280 × 1024p – 60 Hz
• 1920 × 1080p – 60 Hz
• 3840 × 2160p – 24 Hz, 25 Hz, 30 Hz, 50 Hz, 60 Hz

So “amongst others” might include things between 1920×1080 and 3840×2160, but the only way to find out would be to try it! 8~)

Meanwhile, pending advice about the matter in the edit on my previous post, or a bit of spare time and the inclination, I’ll stick with what I’ve done already for the present.

Edit: on the other hand, if I use Auto and the manufacturer’s recommended modes, would that mean that my GPU was being overclocked less in any but the highest resolution modes, and might that increase the life expectancy of my Pi?

Yes, it will be overclocked less (and the GPU might find it slightly easier in general since it won’t have to work so hard to scale the display). But I’m not sure if it will have any significant effect on the life expectancy.

AIUI it’s the voltage that’s the main contributor to life expectancy of a CPU/GPU, rather than the frequency. When overclocking something you usually have to increase the voltage in order to make it stable (with the risk of causing permanent damage to the electronics), but unless you have explicit over_voltage settings in your config.txt the Pi will be limited to the safe design voltages anyway.

If so, and if I would get some useful modes > 1920×1200 but < 3840×2160, perhaps I should try?

I think I looked at the EDID dump for your monitor, but can’t remember the specifics for what modes it contained. There’s a good chance 2560×1440 will appear in there, but that’s really the only widescreen mode that I’d expect to see inbetween 1920×1080/1200 and 3840×2160.

I just realized that !Boot’s configure option still shows me “Auto PhilipsFTV,” so I tried choosing that – which works, and offers me some but not all the modes listed in the monitor manual. In particular, it doesn’t offer me anything at all between 1920×1080 and 3840×2160. Would that be different if I removed the disable_mode_changes?

Or do I need that in order to get my extra modes? I’ve never tried having my own MDF with the config/txt max_framebuffer_width/max_framebuffer_height/hdmi_pixel_freq_limit without disable_mode_changes – if I remember correctly!

What I actually have with my own MDF, all working fine, is 1600×1200, 1920×1080, 1920×1200, 2048×1536, 2560×1440, 2880×1620, 3200×1800, 3520×1980 & 3840×2160 – all actually 3840×2160@24Hz going to the monitor, but scaled. All useful – I use the smallest resolution that displays the level of detail I need for any particular job, because that’s easier on the eyes.

Incidentally, when I select Auto PhilipsFTV on !Boot’s configuration, it claims to be delivering 3840×2160 at 30 Hz, but the monitor says it’s 24Hz – whereas the monitor quite cheerfully reports the Mac as delivering 3840×2160 at 30Hz.

unless you have explicit over_voltage settings in your config.txt

No, I didn’t even know that was possible. I don’t think I want to know…

I just realized that !Boot’s configure option still shows me “Auto PhilipsFTV,” so I tried choosing that – which works, and offers me some but not all the modes listed in the monitor manual. In particular, it doesn’t offer me anything at all between 1920×1080 and 3840×2160. Would that be different if I removed the disable_mode_changes?

Removing disable_mode_changes won’t cause extra modes to appear.

Incidentally, when I select Auto PhilipsFTV on !Boot’s configuration, it claims to be delivering 3840×2160 at 30 Hz, but the monitor says it’s 24Hz

That’s because of disable_mode_changes. The video driver will only look at the width/height of the mode, the refresh rate and all the other timings are ignored. So the OS may think its in a 30Hz mode, but the actual video output (and the VSync interrupt) will still be at 24Hz.

Indeed. I’ll give it a go.

Copied the EDID blob into !Boot.Resources as instructed above. Removed cmdline.txt from !Loader and #’d out the hdmi_group and _mode lines in config.txt: i.e., back to the original RC15 state. Booting with KVM active now reliably loads the correct (EDID) monitor driver but in low res (640 × 480). Selecting the correct resolution on the monitor iconbar icon completes the bootup. A little longwinded but seems stable. Thanks to Sprow and Jeffrey!

Booting with KVM active now reliably loads the correct (EDID) monitor driver but in low res (640 × 480). Selecting the correct resolution on the monitor iconbar icon completes the bootup.

There shouldn’t be any extra step needed after booting. In the Screen Setup plugin (in !Configure) when you picked the monitor from the menu did you remember to set the resolution too? As the EDID blob is being loaded off disc there wont be a ‘Native’ option.

For a behind the scenes check of what it’ll do you see inside !Boot.Choices.Boot.PreDesk.Configure.Monitor, first line loads the blob, 2nd line picks the resolution, same as it has since ye olden days.