Mode definition files - no longer needed on RPi, with AnyMode v0.03

Ok folks, I have finally got tired of editing mode definition files single every time I want to try a different sized screen mode/attach a different monitor/new setup/etc./etc.

We shouldn’t have to do this under RISC OS on the RPi, as the graphics core scales all the RISC OS output to whatever monitor is connected. Mode definition files were a nice idea BITD, but we need to move forward.

So I have written: AnyMode v0.03

This is a 2kb module, which will only run on the Raspberry Pi (it won’t load on other hardware). It then makes use of the little-used ServiceCalls: Service_ModeExtension (type 3) and Service_EnumerateModes, in order to persuade the RPi into providing any and every combination of screen resolution you can think up.

I’ve been running my RPi all evening without any mode definition file loaded and just letting AnyMode take care of everything (currently sitting at 1360×768).

Try it now: www.pi-star.co.uk/anymode

Steve

Needless to say, this is a work-in-progress beta-release version, to gauge opinion of the idea. There may be problems (eg. MODE 13), so be careful.

Any comments, bugs, etc. please let me know.

Steve

Superb idea. Will it work with old modes? (mode 12, 15, 32, etc.).

As well as AddMode and RemoveMode, would it be possible to keep a current selection as a file in Choices to be reloaded automagically on boot-up? SaveModeChoices with an auto-LoadModeChoices on boot-up?

Such a thing could be implemented as a list of AddMode commands, though I suppose a similar obey file in Tasks would do exactly the same thing, so perhaps it’s not necessary after all.

Discuss:

Hi Steve. Any idea how this will interact with the EDID work that’s currently in progress?

We shouldn’t have to do this under RISC OS on the RPi, as the graphics core scales all the RISC OS output to whatever monitor is connected. Mode definition files were a nice idea BITD, but we need to move forward.
So I have written: AnyMode v0.03

Will this work with other hardware like the Panda and Beagle? Like you (and I suspect most everyone) I find sorting out MDFs a real PITA and my ARMiniX / monitor only just manage to meet. A simpler and more reliable way would be very welcome.

Jim

This is a 2kb module, which makes use of the little-used ServiceCalls: Service_ModeExtension (type 3) and Service_EnumerateModes, in order to persuade the RPi into providing any and every combination of screen resolution you can think up.

Would I be right in assuming that the Pi’s GPU is set to a specific type of display, and your module hijacks the service calls to say “yeah, we can do that” to let the GPU handle the scaling?

If so, it has the potential to go horribly horribly wrong on devices which require the video output to be programmed correctly (which is pretty much anything that is not a Pi).
This is why the EDID work is important. The BCM SoC is easy to configure, the OMAPs less so…

and your module hijacks the service calls to say “yeah, we can do that”

Well not really ‘hijack’, AnyMode responds to valid documented service calls in the correct documented manor. But yes, after checking a few key basics (bpp, X divisible by 16, etc.) if successful, it then tells RISC OS that the RPi can cope with that resolution, because… it can.

If so, it has the potential to go horribly horribly wrong on devices which require the video output to be programmed correctly (which is pretty much anything that is not a Pi).

Obviously, and that is why AnyMode will not run on anything which is not a Pi (see first post – I’ve made this clearer).

The purpose of AnyMode is to take better advantage of the fact that this capability exists and is currently ignored by RISC OS. The RPi was designed to be used easily with a huge variety of monitors, but RISC OS masks this benefit by retaining the mode definition file system and then supplying an outdated set of mode definition files with the release (The most recent monitors listed in the 5.19 release were over 10 years old, how can a new user be expected to find the right setup for their TV/ monitor?). I just feel that on the RPi this is a missed opportunity, hence I wrote AnyMode.

Obviously, and that is why AnyMode will not run on anything which is not a Pi (see first post).

Does it, or can it be made to, check that it’s running on a Pi and abort painlessly if not?

Will this work with other hardware like the Panda and Beagle?

No unfortunately this is likely to remain specific to the RPi. Clearly there is work going on to improve modern monitor support (EDID) on other hardware, but the best solution in the mean time for non-Pi hardware would be if a few more all-encompassing LCD monitor definition files (for popular modern screens, say 17" 4:3 and 19", 21", 22" and 24" widescreen), were provided.

Hi Steve. Any idea how this will interact with the EDID work that’s currently in progress?

AnyMode will supplement any OS-provided or ModeFile-provided modes, not replace them, so interaction with EDID should not be a problem.

SaveModeChoices with an auto-LoadModeChoices on boot-up?

Interesting thought – it would be a fair amount of work though, so would only really be justified if there was a big take-up of AnyMode … and if there was this kind of support for AnyMode then I’m sure the RISC OS folks would look at whether something similar/better could be implemented in the OS, rather than as an add-on.

Superb idea. Will it work with old modes? (mode 12, 15, 32, etc.).

That’s certainly the intention, if you find it doesn’t (and I am aware of possible problems in MODE 13), please let me know.

Steve

Does it, or can it be made to, check that it’s running on a Pi and abort painlessly if not?

Maybe I could have been clearer, but yes – it can, and it does check that it’s running on a Pi, and if it isn’t on a Pi, then it will not run.

Obviously, and that is why AnyMode will not run on anything which is not a Pi (see first post – I’ve made this clearer).

In that case: It gets a thumbs up from me. ;-)

Obviously, and that is why AnyMode will not run on anything which is not a Pi (see first post).
Does it, or can it be made to, check that it’s running on a Pi and abort painlessly if not?

Self-evident?

I’m sure the RISC OS folks would look at whether something similar/better could be implemented in the OS, rather than as an add-on.

RISC OS is modular, don’t forget…

it does check that it’s running on a Pi

Out of interest, what mechanism are you using for this?

Out of interest, what mechanism are you using for this?

Ahh… Now that is a good question. Well I assumed there would be no ‘correct’ way of doing this, so I made an assumption that if the BCMVideo module was present then the technique used here would work – and I check accordingly.

Is there a better/correct method?

Steve H: I’d suggest the best approach would be a flag from GraphicsV indicating that the display driver provides ‘scaling support for non-standard modes’. After all, a ‘Pi Mk II’ might provide exactly the same thing.

If that flag is not set, we could take another approach: expand ScreenModes to support all modes. Use the ReadEDID/ LoadModeFile functions to read the available mode data and populate the VIDC list. If a non-standard screen mode is requested, select the nearest native mode bigger than we need, and then letterbox it by adjusting the borders to achieve the desired size. e.g.. 600 X 400 might take a 640X480 screen, chop 20 pixels left and right, 40 pixels top and bottom and keep all other parameters the same. The display would then use a ‘native’ resolution, and RISC OS would be happy. I suspect a bit of code reorganisation required, but that process will need review when multiple display support is reviewed anyway.

Is there a better/correct method?

You can identify the Pi through SWI “OS_Hardware”. You could look at the source to Tank’s GPIO module for some pointers, or my own MCPIO module, which only works on a Pi.

Is there a better/correct method?

Roughly:

• Ensure this is a HAL capable machine.
• Read the CPU/platform information.
• Interpret it.

To my mind, this ought to be an OS_ReadSysInfo call to return the board type directly, but… not as yet. ;-)

        ; We ought to check this is really RISC OS 5.
        ; For now, we'll just assume that if these calls
        ; all work, then it probably is...

        ; We need a Platform class of 5 (HAL) at least.
        MOV      R0, #8
        SWI      XOS_ReadSysInfo
        ; [ In: R0;   Out: R0, R1, R2 ]
        BVS      hardware_error    ; code 8 failed? give up
        CMP      R0, #5
        BNE      hardware_error    ; not HAL version? give up

        ; Now ask the OS (via HAL) to what sort of platform this is
        MOV      R0, #1024         ; HALDeviceType_Comms
        ADD      R0, R0, #3        ; HALDeviceComms_GPIO
        MOV      R1, #0            ; is our first call (to enum)
        MOV      R8, #4
        SWI      XOS_Hardware      ; OS_Hardware 4 - enumerate devices
        ; [ In: R0, R1, R8;   Out: R1, R2 ]
        BVS      hardware_error    ; fail? abort!

        CMP      R1, #-1           ; no match?
        BEQ      hardware_error    ; abort if no match

        ; Extract the information
        LDRB     R0, [R2, #2]      ; processor type
        LDRB     R1, [R2, #64]     ; board type
        LDRB     R2, [R2, #68]     ; board revision

If CPU is zero then it is an OMAP3 board.
If CPU is one then it is an OMAP4 board.
If CPU is two then it is a Pi.
RiscPC and Iyonix (and Psion, etc) do not have GPIO, so they will fail at the enumeration stage.

You’ll need to use the board type/revision for finer detection, if necessary. But since there is currently only the Pi, probably it would suffice to check that the CPU is 2 and the board is 0…

PS: The CMP R1,#-1 assembles correctly with objasm. With something else, you will probably need to use the correct CMN opcode. I think it is CMN R3,#0 but since I can never remember, I just let objasm worry about it for me.

Great methods.

But is there actually anything wrong with just checking for the BCMVideo module? At least in this case?

I like simplicity. This module should only be present on the RPi, or future equivalent hardware…

I think your method is absolutely fine for now, but (typically nice as Rick’s post was) I think the best method would be William’s suggestion, as it goes off a feature of the hardware, rather than a specific item of hardware:

I’d suggest the best approach would be a flag from GraphicsV indicating that the display driver provides ‘scaling support for non-standard modes’.

I know nothing about this – does GraphicsV already offer some kind of ‘features flags’?

But is there actually anything wrong with just checking for the BCMVideo module? At least in this case?

There is the important part – the italicised part. For a one-off specific case, then checking for “BCMVideo” would suffice; although my code suggestion can pass/fail the hardware in only 16 instructions (64 bytes) – for just detecting a Pi you could discard the last two LDRBs, replace with CMP R0, #2 and then BNE hardware_error if you should drop out.

In this case either method will work. In a future case when we have RISC OS on GPUs a little smarter than anything Texas, I believe that my CPU/board/revision code would be more easily adapted than “is this module? is this module? is…”. :-)

Well, in any case, bookmark this in case you need code to detect what board you’re running on. Or maybe paste it into the Wiki description of the GPIO board type (example code is good!).

Will that enable me to use an HDMI 1920×1080 monitor on its side?

i.e. rotated through 90degrees to 1080×1920.

I’d suggest the best approach would be a flag from GraphicsV indicating that the display driver provides ‘scaling support for non-standard modes’.

I know nothing about this – does GraphicsV already offer some kind of ‘features flags’?

Yes – GraphicsV 8

Somewhere buried in the GraphicsV todo list is support for hardware scaling, so I’ll be adding a flag of some kind whenever I get around to implementing that. Support for display rotation is on there too!

Will that enable me to use an HDMI 1920×1080 monitor on its side?

You should be able to use it to generate a 1080×1920 mode but you will also need to tell the GPU which I think at present can only be done by adding display_rotate=x into the config.txt file:

display_rotate=0 Normal
display_rotate=1 90 degrees
display_rotate=2 180 degrees
display_rotate=3 270 degrees
display_rotate=0×10000 horizontal flip
display_rotate=0×20000 vertical flip

does GraphicsV already offer some kind of ‘features flags’?

Yes – GraphicsV 8

Then would it be sensible to add a flag that says “driver can handle scaling itself”, as William suggested above?

Chris: I /think/ you would keep the monitor definition the same, but you do need to change the rotation flag (so that the graphics firmware knows to rotate the image).

After all – what is being sent /to/ the monitor is the same – it’s still 1920 X 1080 by the time it gets to the monitor, not 1080X1920. The issue is more how RISC OS plots it and how the user thinks they are using a 1080X1920 screen. The rotation has to be handled internally by the GPU or somewhere else within the OS I suspect (not quite sure where precisely).