This screen mode is not suitable for displaying the desktop

There is still an odd issue that RISC OS (on the Pi) doesn’t like booting directly into 1360×768 (for the Pi-Top or Atrix Lapdock), I have to boot into eg. a 1280×1024 resolution first, then change to 1360×768 otherwise there is serious screen corruption and the Pi appears to crash! This seems to have been around since the Pi2 came out, and I’ve seen it mentioned a few times on here, but no real solution seems to have been found.
Edit: eg. but I’m using a Pi2

Yesterday, using the 14th Aug 2016 ROM I had the Pi configured to load a custom MDF and start the desktop in 1280×1024, then an Obeyfile in Tasks issued a “WimpMode X1360 Y768 C16M F75” to change the resolution. This has been working happily for quite a while now. However, changing to today’s ROM (19th Aug 2016) I get an error message saying “This screen mode is not suitable for displaying the desktop” and I end up at 1920×1080 using the “Built-in” MDF. The only thing to have changed is the ROM image.

If I remove my Obeyfile which changes mode, it does then boot happily to 1280×1024 using my custom MDF, and I can change to 1360×768 either from the Display Manager, or by double-clicking on my Obeyfile, so the mode is suitable for displaying the desktop after all!

Any idea what’s changed to stop my Obeyfile to change mode working, and in the bigger picture, why I can’t just boot into 1360×768 in the first place?

Disclosure: I’m posting this in my “CJE programmer” capacity, not in my more usual personal capacity!

I recall coming across this. I originally “fixed” it by Filer_Running an obey file to do the mode change (makes it happen later on after a few wimp polls). I then “fixed” it by baking my 1280×1024 mode into a custom build. ;-)

As a matter of interest – why such a high Frame rate of 75Hz?
How many colours?
Perhaps you are driving the Pi too hard.

Not driving the Pi too hard, but possibly driving the monitor too hard. An LCD panel doesn’t refresh like a CRT, so higher speed doesn’t equal less flicker.
Plus, a panel with a 16ms response time is only physically capable of changing state 60 times a second; so if the monitor accepts 75Hz, it may do so with ickiness like buffering four frames and simply discarding the fifth…

How many colours?

The C16M in the Wimpmode command stands for 16million colours.

Perhaps you are driving the Pi too hard.

I’m not driving it any harder than I was with the exact same setup yesterday when RISC OS was quite happy!

Not driving the Pi too hard, but possibly driving the monitor too hard.

On the Pi, the refresh rate reported by RISC OS is not related to the refresh rate that the GPU is driving the monitor, is it? The GPU drives the monitor as per its EDID, then RISC OS just sends the display to the GPU which scales it if necessary and then sends it to the monitor, as I understand it. I recall having an MDF we’d tweaked for the Pi which reported something like 230Hz refresh rate, and the Pi/monitor coped happily!

The MDF has a pixel rate of 78000 at 1360×768, which should be well below the maximum for that resolution, shouldn’t it? Interestingly though, dropping the pixel rate to 58000 (and hence the refresh rate to 56Hz) makes it work again, but for how long? Without knowing what caused it to stop working, I’m not very confident that this is a long-term fix.

Any ideas why you can’t seem to boot straight into 1360×768 without getting screen corruption and a crash?

This is a problem that turned up with the Emulators – when the Video bandwidth command was removed (can’t go any faster than a RPC – poor show) :-(

Have you tried a Pixel rate of about 33000 – 30Hz Bandwidth of about 132MB sec.

I’m using WimpMode X1360 Y768 C16M F60 with today’s build okay. The error This screen mode is not suitable for displaying the desktop is somewhat misleading as it hides a multiple of issues, including resolutions the hardware can’t support.

Interesting you mention screen corruption, as my Pi-Top randomly corrupts its screen (it looks like it’s halving the screen width). It will flicker in and out of being corrupt and eventually settle on either corrupt or okay. It looks to me like a fault with the screen or more likely the conversion circuit driving it. There’s no corruption or issues on the RISCOS side, as I don’t see any problems if plugged into a TV.

Interesting you mention screen corruption, as my Pi-Top randomly corrupts its screen (it looks like it’s halving the screen width).

The screen corruption is as Andy M shows in his post here The corruption is permanent and immediate. It happens on both the Pi-Top or the Atrix Lapdock.

The screen corruption is as Andy M shows in his post

I’ll grab a photo when it happens again, as looking at that photo, my issue is different and almost certainly hardware related.

Yesterday, using the 14th Aug 2016 ROM I had the Pi configured to load a custom MDF and start the desktop in 1280×1024, then an Obeyfile in Tasks issued a “WimpMode X1360 Y768 C16M F75” to change the resolution. This has been working happily for quite a while now. However, changing to today’s ROM (19th Aug 2016) I get an error message saying “This screen mode is not suitable for displaying the desktop” and I end up at 1920×1080 using the “Built-in” MDF. The only thing to have changed is the ROM image.

Remember that for the Pi the CMOS settings are held in the ROM, and (for better or worse) updating the ROM effectively triggers a CMOS reset. And on CMOS reset, !Boot.Resources.ClrMonitor will disable the monitor configuration file. So that will explain why your MDF isn’t being loaded after the update.

Frame rate, pixel rate, and other factors are irrelevant on the Pi – the only parameters that we pass to the GPU are the width, height and BPP.

For the issue with screen corruption on mode change, I think I’ve just fixed that – it looks like the GPU was being smart and trying to reuse the existing framebuffer, but without a way for the video driver to dictate the stride of the buffer to the OS that was sometimes resulting in the parameters being mismatched.

G’ah, thanks Jeffrey, that may have been it! I wish we could go back to having CMOS and ROM separated.

RISC OS does do some checking of WimpMode parameters against MDF though, doesn’t it? If I have an MDF which produces a 60Hz mode, I can’t use WimpMode with F75 as I then get the “This screen mode is unsuitable…” error.

Thanks for finding and fixing the screen corruption bug! That should make the Atrix, pi-top and others easier to configure in future! About to shut up shop and head out soon, but I’ll test the new ROM against the pi-top when I’m back in work on Monday.

Yes, the mode still needs to be in the MDF (or you need to use something like AnyMode). But for the Pi-specific checks that BCMVideo performs, it’s only the width, height and BPP that matter.

This? That doesn’t look like it would be too hard to support – it’s just a couple of VCHIQ services which we’d need to hook up. Possibly we should go the whole hog and port the entire vmcs_host library, since there’s a fair amount of useful stuff there.

Thanks for finding and fixing the screen corruption bug! That should make the Atrix, pi-top and others easier to configure in future! About to shut up shop and head out soon, but I’ll test the new ROM against the pi-top when I’m back in work on Monday.

I can confirm we can now boot directly into 1360×768 without going via an intermediate mode! The first time we’ve been able to do this since around the time the Pi2 was launched, thanks!

How do I issue a 30020 (Get EDID block) and 40003 (get physical display width/height) mailbox calls? Presumably there is a mailbox SWI?

Answering my own question I assume that this is the correct call:

SYS "BCMSupport_SendMBMessage",ch%,3,mask%,val%,a%,b%,"FNfred(RETURN c%)"

0×00030020 – Get EDID block – Already supported (GraphicsV 14)
0×00038009 – Set turbo – Not used, since the GPU will automatically enable/disable turbo in response to the set clock rate message
0×00030009 – Get turbo – See above
0×00038002 – Set clock rate – Already supported (Portable_Speed / Portable_Speed2)
0×00060001 – Get DMA channels – Already supported (GraphicsV 13 rectangle copies and DMAManager – although there’s nothing on the Pi which actually uses DMAManager at the moment)

How do I issue a 30020 (Get EDID block) and 40003 (get physical display width/height) mailbox calls? Presumably there is a mailbox SWI?

BCMSupport_SendTempPropertyBuffer is the easiest method for using the mailbox property interface. E.g. some (untested) code for 0×40003:

DIM B% 32

B%!0=32 : REM buffer size
B%!4=0 : REM buffer request/response code

B%!8=&40003 : REM get physical display width/height
B%!12=8 : REM value buffer size
B%!16=0 : REM value length
REM words at !20 and !24 are value buffer (not used on send for this message)

B%!28 = 0 : REM buffer end tag

SYS "BCMSupport_SendTempPropertyBuffer",B%,B%

PRINT "Width ";B%!20
PRINT "Height ";B%!24

but I am not sure how to set up the response function pointer.

They need to be assembler functions, not BASIC.

Many thanks.

Have written a short utility to display GPU output resolution, display native resolution (as provided by EDID), SoC temperature, CPU clock speed.

   10 REM >Info3
   20 :
   30 DIM buf% 232
   40 a%=FNask(&40003,0,0,8)
   50 IF a% THEN PRINT "Width=";!a%;" height=";a%!4
  100 a%=FNask(&40005,0,0,4)
  110 IF a% THEN PRINT "bpp=";!a%
  160 a%=FNask(&30002,4,3,8)
  170 IF a% THEN PRINT "CPU clock=";(a%!4)/1000000;"MHz"
  220 a%=FNask(&30006,4,0,8)
  230 IF a% THEN PRINT "SoC temp=";(a%!4)/1000;"C"
  280 b%=0
  290 REPEAT
  300   a%=FNask(&30020,4,b%,136)
  310   IF a% THEN
  320     i%=46
  330     REPEAT
  340       IF ((a%!i%) AND &FFFF) <> &FFFF AND ((a%!i%) AND &FFFF) <> &0101 THEN
  350         PRINT "EDID block x-res=";248+(a%?i%)*8;" aspect=";
  360         i%+=1
  370         CASE (a%?i%)AND &C0 OF
  380         WHEN &C0:PRINT "16:9";
  390         WHEN &80:PRINT "5:4";
  400         WHEN &40:PRINT "4:3";
  410         WHEN &00:PRINT "16";
  420         ENDCASE
  430         PRINT " Frame rate ";60+((a%?i%)AND &3F);"Hz bytes=";~a%?(i%-1);" ";~a%?i%
  440         i%+=1
  450       ENDIF
  460     UNTIL i%=62 OR ((a%!i%) AND &FFFF) = &FFFF OR ((a%!i%) AND &FFFF) = &0101
  490   ENDIF
  500   b%+=1
  510 UNTIL (a%!0)<>0 OR b%>3
  520 :
  530 a%=FNask(1,0,0,4)
  540 IF a% THEN PRINT "Firmware revision is ";~!a%
  590 a%=FNask(&10001,0,0,4)
  600 IF a% THEN PRINT "Board model is ";!a%
  650 a%=FNask(&10002,0,0,4)
  660 IF a% THEN PRINT "Board revision is ";!a%
  701 END
  820:
  830 DEFFNask(tag%,lrq%,req%,lrs%)
  840 DIM buf% 232
  850 buf%!0=232  :REM Buffer size
  860 buf%!4=0    :REM buffer request/response code
  870 buf%!8=tag% :REM &40003 - Get physical display width height
  880 buf%!12=lrs%:REM value buffer size
  890 buf%!16=lrq%:REM value length
  900 buf%!20=req%:REM send/rec value
  910 buf%!24=0   :REM send/rec value
  920 buf%!28=0:REM buffer end tag
  930 SYS "XBCMSupport_SendTempPropertyBuffer",buf%,buf% TO ;flag%
  940 IF flag% AND 1 THEN ERROR 0,"Requires BCM Support and 26-Mar-2016 or later Pi ROM" ELSE =buf%+20
  950 :
>RUN
Width=1920 height=1080
bpp=32
CPU clock=700MHz
SoC temp=55.686C
EDID block x-res=1152 aspect=4:3 Frame rate 75Hz bytes=71 4F
EDID block x-res=1280 aspect=5:4 Frame rate 60Hz bytes=81 80
EDID block x-res=1920 aspect=16:9 Frame rate 60Hz bytes=D1 C0
Firmware revision is 56F3DFA3
Board model is 0
Board revision is 15
>

If I run it and then shutdown and select ‘Restart’ I get the rather odd message ‘Memory cannot be moved.’ and I have to power off. I am running RC14 plus update 4 i.e. RISC OS 5.23 (02-Apr-2016) low vectors.

Have written a short utility to display GPU output resolution, display native resolution (as provided by EDID), SoC temperature, CPU clock speed.

Message 40003 doesn’t read the GPU output resolution, it reads the size of the framebuffer. Try switching into a lower resolution mode (e.g. 800×600) and you’ll see something like 800×2400 – to support multiple screen banks we ask the GPU for a tall framebuffer and then scroll it vertically, displaying a small portion of it (virtual size & virtual offset messages).

AFAIK the only way to get the actual GPU output resolution is to query it via the VCHIQ display service (e.g. vc_dispmanx_display_get_info)

If I run it and then shutdown and select ‘Restart’ I get the rather odd message ‘Memory cannot be moved.’ and I have to power off.

Try this:

920 buf%!(20+lrs%)=0 : REM buffer end tag

Try this:

920 buf%!(20+lrs%)=0 : REM buffer end tag

Still gives error ‘Memory cannot be moved.’ on selecting ‘Restart’, as does your original (untested) programme snippet.

I get that sometimes. Shutdown fails with Memory cannot be moved which is then often followed by a cascading data abort. I usually count to five then press the reset button.

Memory cannot be moved

FWIW That error does nor occur here with Info3, see above, on a Mk3 RPi OS5.23 25-Aug-2016. This subject has come up previously but was not fully resolved.

Returning tp the original subject of this thread my RPi3 driving a 1680×1050 monitor after a default 1920×1080 start up had fallen foul of the framebuffer parameters bug. I didn’t “catch on” at the time, then I saw the picture of the 1360×768 screen corruption linked to above. All good now, thanks Jeffrey.

FWIW That error does nor occur here with Info3, see above, on a Mk3 RPi OS5.23 25-Aug-2016.

It does not occur on my Pi model 3 RISC OS 5.23 (02-Apr-2016) but does occur on a Pi model 1 B 512M (revision 0F), using identical software. The only difference in hardware is a RTC board plugged into my model 1. Removing the CJE RTC board (i.e. testing one that has no RTC board fitted) and the error disappears.

AFAIK the only way to get the actual GPU output resolution is to query it via the VCHIQ display service (e.g. vc_dispmanx_display_get_info)

Not sure how to call this from BASIC. SYS "VCHIQ_BulkQueueReceive” ,then what…? Can’t seem to find any other VCHIQ_XXX SWI calls mentioned (apart from Transmit).

but does occur on a Pi model 1 B 512M (revision 0F), using identical software.

Mine’s a second revision model B (256MiB).

The only difference in hardware is a RTC board plugged into my model 1. Removing the CJE RTC board (i.e. testing one that has no RTC board fitted) and the error disappears.

Snap. Well, the CJE RTC board, that is. My Pi’s case is taped up to keep the OLED panel in place and the serial wires still, so opening it up to remove the RTC isn’t really an option.

It’s a shame there’s no indication of what is causing the Memory cannot be moved error.

Not sure how to call this from BASIC. SYS "VCHIQ_BulkQueueReceive” ,then what…? Can’t seem to find any other VCHIQ_XXX SWI calls mentioned (apart from Transmit).

Have found SYS “VCHIQ_ServiceOpen” and SYS “VCHIQ_ServiceUse” but they’re not documented in my PRM (not surprising as it has not been updated since RISC OS 3.60) nor can I find any documentation on the ROOL site. Any help please? I can’t even find any SWI of the same form – “XXXX_ServiceOpen” – to try to guess the syntax.