RC15

You create a text file and drop it in to the PC partition where the ROM/Firmware/Config files are.

I just put the the text disable_mode_changes in it and then save as CMDLINE/TXT and copy over to the Loader directory within !Boot

Seems to work for me.

Presumably in the same place as CONFIG/TXT – that is, in the Loader “directory” – I’ll try. The worst it can do is stuff this card again, and then I can just rewrite the image…

Ah – snap – thanks Doug

Yes and make sure you save it to the Loader directory within !Boot as CMDLINE/TXT.

just put the line disable_mode_changes in there.

Aah thought I lost the post but it saved as I hit the wrong text icon.

Hope it works

Yay! Many thanks both! I have a functional 3840×2160 screen AND NetSurf on the same SD card! Not tried any other software yet, but I’ll try everything tomorrow. Including !FontEd…

If this all works I might splash out on a Pi3…am I brave enough?

Clive

Good to know it is sorted for you.

It would be good to know the make of your monitor and any EDID data so ROOL can see why it failed and help improve the EDID capabilties.

If this all works I might splash out on a Pi3…am I brave enough?

Pi3 works well here for months.

good to know the make of your monitor and any EDID data

It’s a Philips 43put4900/12. Tell me how to get the EDID data and I’ll get that too. (The Mac clearly read the EDID okay – plugged it in and it worked. It wasn’t hard to make a suitable MDF for the Pi for it once I’d got the CONFIG/TXT file right.)

Get a task window up and type *help screenmodes and it will list the version and commands available.

In the latest ROM’s to save EDID data it is:

*SaveModeFile where filename is the path you want to save it to.

Might also be good to know what you have in yor CONFIG/TXT file as well.

Also did you use your old CMOS file or the RC15 one as I had an issue on one Pi that was cleared by using the supplied CMOS file and then reconfiguring a few attributes back in to the system.

I used the CMOS file that came on RC15.

I got the EDID data off the Mac – crossed in the post with your method for getting it on the Pi. It’s this:
q8-@X,E Philips FTV

?>s8-~,E??h! ,%??h! (U?h!


I suspect those ?s are something else really. I don’t think the script I found to dig out the EDID on the Mac does a very good job 8~(

Perhaps that might be better obtained off the Pi!

Will do that in a minute, and copy my CONFIG.TXT and MDF as well.

In the latest ROM’s to save EDID data it is: *SaveModeFile where filename is the path you want to save it to.

Eh? That just saved my MDF, which I wrote myself…

My CONFIG.TXT:

disable_overscan=1
hdmi_drive=2
hdmi_group=2
fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=128
init_emmc_clock=100000000
ramfsfile=CMOS
ramfsaddr=0×508000
kernel=RISCOS.IMG
hdmi_mode=87
hdmi_cvt=3840 2160 25 3 0 0 1
max_framebuffer_width=3840
max_framebuffer_height=2160
hdmi_pixel_freq_limit=400000000

My MDF:

# Exported from ScrModes 0.61
file_format:1
monitor_title:Philips 4K
DPMS_state:3

# Mode: 1600 × 1200 @ 63Hz
startmode
mode_name:1600 × 1200
x_res:1600
y_res:1200
pixel_rate:121000
h_timings:0,0,0,1600,0,0
v_timings:0,0,0,1200,0,0
sync_pol:0
endmode

# Mode: 1920 × 1080 @ 74Hz
startmode
mode_name:1920 × 1080
x_res:1920
y_res:1080
pixel_rate:154000
h_timings:0,0,0,1920,0,0
v_timings:0,0,0,1080,0,0
sync_pol:1
endmode

# Mode: 1920 × 1200 @ 67Hz
startmode
mode_name:1920 × 1200
x_res:1920
y_res:1200
pixel_rate:154000
h_timings:0,0,0,1920,0,0
v_timings:0,0,0,1200,0,0
sync_pol:1
endmode

# Mode: 2048 × 1536 @ 69Hz
startmode
mode_name:2048 × 1536
x_res:2048
y_res:1536
pixel_rate:217000
h_timings:0,0,0,2048,0,0
v_timings:0,0,0,1536,0,0
sync_pol:0
endmode

# Mode: 2560 × 1440 @ 66Hz
startmode
mode_name:2560 × 1440
x_res:2560
y_res:1440
pixel_rate:242000
h_timings:0,0,0,2560,0,0
v_timings:0,0,0,1440,0,0
sync_pol:0
endmode

# Mode: 3200 × 1800 @ 42Hz
startmode
mode_name:3200 × 1800
x_res:3200
y_res:1800
pixel_rate:242000
h_timings:0,0,0,3200,0,0
v_timings:0,0,0,1800,0,0
sync_pol:0
endmode

# Mode: 3840 × 2160 @ 29Hz
startmode
mode_name:3840 × 2160
x_res:3840
y_res:2160
pixel_rate:244000
h_timings:0,0,0,3840,0,0
v_timings:0,0,0,2160,0,0
sync_pol:0
endmode

As I understand it, because the CONFIG.TXT is setting the GPU, the pixel rate in the MDF is ignored – and the Hz figure in the comment line is meaningless.

Eh? That just saved my MDF, which I wrote myself…

Try doing ReadEDID and then the SaveModeFile next.

Also if you do *help screenmodes what is the version of the screenmode module you have in your system.

I see you have created a new mode 87 so are you sure you have not exceeded the maximum pixel clock rate limit or could this be why standard EDID fails as it ignores any modes that fall outside of limits as i found out with my lapdock/pi set up?

In the latest ROM’s to save EDID data…

From a similar thread in March the EDID data is in resources:$.resources.screenmode.monitor which can be got with the filer

I see you have created a new mode 87 so are you sure you have not exceeded the maximum pixel clock rate limit or could this be why standard EDID fails

That wasn’t there at all when I first tried RC15. First up I tried RC15 straight out of the box, none of my own files at all: started up visible, but very low res. Using !Boot’s screen configuration option I could select any monitor it offered, many of them worked fine, but the highest resolution any of them offered was 1920×1200, and even if I asked it to save the configuration, on a reboot it was back to very low res and I had to go through !Boot screen configuration again to get anything half decent.

Next thing I tried was putting in my own MDF, but not my own CONFIG/TXT. The higher resolutions still didn’t work – and the monitor said everything was still 60Hz, so it’s not surprising they didn’t.

Then I made that CONFIG/TXT file by merging the RC15 one with my old one, still nothing.

Finally I put in that CMDLINE/TXT disable_mode_changes, and hey presto! Success, all working.

Now I’ve got all that, Auto (Philips FTV) appears in the !Boot screen configuration options, with various resolutions up to the full 3840×2160, but all that it offered under Auto (Philips FTV) before I changed CONFIG/TXT and CMDLINE/TXT was “Native,” which produced just a mess on screen, a monochrome unsynced image in a fairly small letterbox. Even now, Auto (Philips FTV)’s offering of modes is only 3840×2160, 1920×1080 and a handful of lower res ones, whereas my MDF offers several between 1920×1080 and 3840×2160, all working nicely.

It sort of suggests that there are some constraints on the data that it will accept which either means modes where the screen resolution is not divisible by 4/8? which is RISCOS specific, the rates exceed what the Pi GPU says it can do i.e maximum clock rate limits etc and hence it omits them or it isn’t reading it right.

By disabling the new set up you are reverting back to the old way and it will take “malformed” MDF data as I understand it.

On the raspberry pi foundation site it sort of implies that the highest supported mode is 1920 × 1200 @ 60Mhz with blanking posted by an “engineer”

But in the list there are:
These values are valid if hdmi_group=2 (DMT)
hdmi_mode=77 2560×1600 60Hz
hdmi_mode=78 2560×1600 75Hz
hdmi_mode=79 2560×1600 85Hz
hdmi_mode=80 2560×1600 120Hz reduced blanking

What does it mean? RPi support 2560×1600?

No. That is the list of all the standard CEA/DMT modes. Additionally there is a pixel clock limit which means modes bigger than 1920×1200@60 are not supported.

[You could try overclocking the pixel clock with
hdmi_pixel_freq_limit=
int config.txt, where the default limit is 162000000, but that is untested and unsupported]

Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator

Well, the screen resolutions are all divisible by appropriate numbers: nothing works otherwise.

As regards pixel rate: that’s all true for 60Hz, which is why I’m only running at 24Hz (the 29Hz shown is just for display in the mode selection window, and doesn’t actually do anything which is why I’ve not bothered to correct it).

You could try overclocking the pixel clock with
hdmi_pixel_freq_limit=
int config.txt, where the default limit is 162000000, but that is untested and unsupported.

Yes. To get 24 Hz 3840×2160 it has to clock at 199065600. I presume this is a limit on what the system can deliver to the GPU – the GPU itself can certainly do a good bit better than that.

Anything over 1920×1200 only works 100% well at 256 colours (1 byte per pixel) – it sort of works at thousands or millions of colours, but you get occasional horizontal line flashes. I think that must be RISC OS’s problem feeding data to the GPU, since the GPU keeps up fine with 256 colours and I don’t think the GPU knows how many colours it’s displaying.

the EDID data is in resources:$.resources.screenmode.monitor which can be got with the filer

Thanks – got that now. If anyone’s interested to see it, it’s now at http://clive.semmens.org.uk/EDID0

All those initial 1. s are #es really

To include a ‘#’ character use &#35; (which won’t work inside a ‘<pre>’ tag).

Cheers – done now!

(nor in a < c o d e > tag)

Update: Interestingly, the horizontal line flashes on resolutions >1920x1200 @ >256 colours that I used to get on the nightly build (on which NetSurf didn’t work, but which allowed me to use high resolutions) seems to have disappeared on RC15, even though I’m using mostly the same CONFIG/TXT and MDF as I was.

So here I am, posting on this forum, from a 3-year-old Pi driving a display at 3840×2160 resolution, in 16 million colours.

the EDID data is in resources:$.resources.screenmode.monitor which can be got with the filer

Thanks – got that now. If anyone’s interested to see it, it’s now at EDID0

Running that through ScreenModes on a Pi 2 here shows that it’s done the business and found many lovely modes. Loading the same EDID data into Deltacast E-EDID editor on a PC shows that’s pretty much all there is to be had, I could only spot 3 modes missing (3840×2160 @ 24/25/30Hz) which appear to be DMT mode numbers 93-95 respectively and our table only has 80 entries. There’s probably a newer version of the standard somewhere.

However, since block 1 of the detailed timings already included 3840×2160 @ 30Hz, you get it in the resulting MDF anyway.

So, the next link in the chain is to run those past GraphicsV and see if the mode looks acceptable. I’ve walked through the VetModeFromVIDCList function mentally, and you’re right that the monitor is all the right multiples of 32. I think where the 3840×2160 mode gets chucked away is in GPUMode_Vet.

If I do

  *VCGenCmd get_config hdmi_pixel_freq_limit
  *VCGenCmd get_config hdmi_pixel_freq_limit_min
  *VCGenCmd get_config max_framebuffer_width
  *VCGenCmd get_config max_framebuffer_height

The mode we’re trying to vet is 3840×2160 at 297MHz, so it gets rejected on both size and pixel rate fronts. Therefore, I reckon if you start with a vanilla RC15 and stuff the appropriate overrides of max_framebuffer_width/max_framebuffer_height/hdmi_pixel_freq_limit into your config.txt you should be able to leave the rest alone (ie. letting RISC OS detect the monitor via EDID and Display Manager controlling the video timings properly).

I’ve updated the Welcome to RISC OS Pi page so that it covers most of the video-related issues.