This screen mode is unsuitable for displaying the desktop

I just got my Pi 2 working well enough for headless operation, but there are a couple of strange things to do with display configuration. I’m using up to date boot firmware, the nightly build of RISC OS, and !Boot updated from the nightly HardDisc4 build.

I’m using a Xerox 17" 1280 × 1024 monitor from HDMI. I’ve had it for several years, and I’ve used it successfully with several RO machines. I created my own MDF. The monitor has a DVI-I input and I’m using an HDMI to DVI adaptor.

When I use Configure→Screen to choose a 1280 × 1024 resolution and click Try, it goes to a very low resolution (much less than 1280 × 1024). When I tell it to abandon and go back to the previous settings, it remains in the low resolution.

When I double-click an Obey file containg a loadmodefile command and a wimpmode command, up pops an error box with “This mode is unsuitable for displaying the desktop”. This Obey file used to work with previous Pis and is in the PreDesk folder. Why is that error generated?

Is your Boot app fully up to date? The “dropping to 640×480” issue was fixed a couple of days ago (specifically, you want ScrnSetup 0.39, included in Boot 2016-08-05).

I also use 1280×1024, but instead of using a custom MDF I just use the “Generic” option with AnyMode running.

I’ve just had a quick play with the lastest ScrnSetup (0.39) and nightly ROM (ScreenModes 0.57) and can’t spot anything obviously wrong. If you’re still having problems:

• Is the problem with all MDFs, or just your own?
• If it’s just your MDF that’s causing the problem, can you post it somewhere so that we can take a look?

I must be missing something. What is ScrnSetup, and where does it live in a normal installation of RO?

I can’t find a module called ScrnSetup or anything like it, nor can I find any file in !Boot that matches a pattern of scrn*.

It’s in !Boot.RO500Hook.Res.Configure, the tool for selecting your MDF & startup mode in Configure.

It’s the screen setup plugin. !Boot.RO500Hook.Res.Configure.!ScrnSetup

There’s another small problem. I normally use an HDMI splitter so that I have a choice of monitors. When this is in the path, the RPi ignores my monitor settings and sets up scan rates that the Xerox monitor can’t display. If I have only an HDMI switch in the path, my settings are used – even if the switch is set to display a different input.

I don’t really need the splitter, so it isn’t a big deal – but the principle of ignoring my settings in favour of something that doesn’t work, is not very clever. I presume the splitter doesn’t pass the monitor ID signalling.

AIUI good active splitters do pass through the EDID of the lower spec monitor, though this may be slower than the computer needs. I would expect Dumb splitters to avoid a clash may not connect the I2C bus of one of the sockets.