Pi Screen limited to 1920 by RISC OS:-

We’ve just received a nice 2048 × 1152 monitor is the highest resolution the Pi’s GPU can handle. Unfortunately whilst the booting splash screen fills the screen and the GPU is running at 2048×1152 (The monitors info menu confirms this) when the Computer goes into the desktop it leaves a border down the left and truncates the desktop on the right at 1920 pixels (The first application to the left of display manager if half displayed)
The mouse will move to the screens extremities horizontally and vertically
Clicking the mouse causes actions scaled.
The monitors screen info confirms the GPU is outputting 2048×1152

I’ve done a bit of searching myself but first I should mention that 1920×1200 and 1200×1920 modes work fine!

In https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/Video/HWSupport/BCMVideo/s/BCMVideo?annotate=1.11

I found
50: ScreenSizeMax * 8*1024*1024 ; How much we’ll willingly allocate – to avoid using too much in low GPU memory setups
51: ScreenHeightMax * 4095 ; How tall we’ll willingly make the screen. 4096 seems to be too much?

but no ScreenWidthMax

Much as I know he is a very busy man I think this one might need Jeffrey’s input!

50: ScreenSizeMax * 8*1024*1024 ; How much we’ll willingly allocate – to avoid using too much in low GPU memory

Is the colour info using three or four bytes for the display? The 2048×1152 mode in full colour (4 byte) will take memory equivalent to 9,437,184 bytes which is more than the max allowed.

Much as I know he is a very busy man I think this one might need Jeffrey’s input!

The key word in those comments is “willingly”. Unless I’ve messed up somewhere, it should be possible to allocate more than 8MB of screen memory (e.g. 1920×1200×32bpp is 8.7MB), and (monitor/GPU permitting) it should be possible to use screens taller than 4095 pixels.

Those maximum values are used to help determine how many screen banks to emulate. The framebuffer interface that the GPU gives us doesn’t give us control over the screen start & end addresses, but it does allow for the monitor to display a subrectangle of a framebuffer which is larger than the screen itself (just like how a window on the desktop allows you to see a subrectangle of a larger surface). So to emulate screen buffers on the Pi we actually ask for a framebuffer which is N times taller than the requested mode, and then adjust the vertical scroll offset depending on which screen bank the OS wants to display. This works perfectly except that there’s no way of performing pseudo-horizontal scrolling; you can only scroll whole lines at a time, not partial lines.

The only restrictions that BCMVideo places on the screen mode is that it must be 8bpp or 32bpp and that the line length (in bytes) must be a multiple of 32. As long as those conditions are satisfied it will throw the request at the GPU and everything else is down to whatever the firmware does.

Time for an obvious question: Does the Pi work properly with the monitor when running Linux?

Even though I doubt it, the GPU does use some of its memory for things other than the screen frame buffer, as such have you attempted to increase the gpu_mem= Allocation?

While I doubt that this is the issue as 64MB should be more than enough for any resolution it is a thought.

And why not run at a lower resolution? 1920×1200 is a higher resolution than most use.

My monitor is capable of 1920×1200 and yet I run at 1280×1024 ( hdmi_groupe=2 hdmi_mode=35 )

Also what settings in the config.txt are you using to set the output to 2048×1152? And does it work if you set an 8bpp color mode (256 colors, or 256 greys)?

Though thank you for getting me to think about it again as I think that I am going to increase the running resolution of my monitor.

Wow, never mind.

I go up above 1280×1024 with the ROOL ROM (a couple of days old) and the USB HID problems from the RC8 RPi release come back. I had actually thought that these had been corrected by some one else so I have not used an alternate USB implementation in a while, instead sticking with the ROOL default.

Strike that last. I realized that I still had BootFX. Even though BootFX should not cause any trouble with the USB it does . I do not know why it just does , and I just unpluged it.

Sorry I should have replied at the time that linux acts similar i.e. the monitor reports it is getting 2048×1152 but it isn’t displayed properly.

Strike that last. I realized that I still had BootFX. Even though BootFX should not cause any trouble with the USB it does . I do not know why it just does , and I just unpluged it

[citation needed]

Strike that last. I realized that I still had BootFX. Even though BootFX should not cause any trouble with the USB it does . I do not know why it just does , and I just unpluged it

[citation needed]

Probably another situation where a USB memory allocation was failing due to the free pool being empty & application space being locked (as was the case here)

It looks like recent firmware versions (June 11th and newer) now allow you to override the maximum frame width/height and pixel rate settings. 4K displays work (although it looks like only at very low refresh rates), so presumably 2048×1152 will work fine now as well:

http://www.raspberrypi.org/forums/viewtopic.php?f=38&t=79330

Someone mentioned on the Pi forums two or three months ago that he had working with the latest then start.elf & XBMC so I tried then but no joy. I’ll try again when I can find time.

For those interested I think you get the latest start.elf from:
https://github.com/raspberrypi/firmware/blob/master/boot/start.elf
Click on RAW and it will prompt you to save or run.

Replaced START.ELF last night.

Adjusted config.txt to this:

disable_overscan=1
hdmi_group=2
hdmi_mode=58
max_framebuffer_width=3840
max_framebuffer_height=2160
hdmi_pixel_freq_limit=400000000

Monitor settings read through EDID so using the monitor’s own preferred settings which are CVT-derived.

The result is that I now get a useable picture in 2048 X 1152 – but one which is letterboxed vertically and horizontally.

But on the positive side I get a picture that is useable ;-).

Now…Hmm…1440p (or even 4k) for RISC OS. Yes please ;-).

Don’t you want hdmi_mode=84 for 2048×1152? 58 is 1680×1050

I haven’t changed the hdmi_mode from my old configuration. I had presumed that defined the starting mode; once I then changed the mode with display manager we would still get 2048×1152?

There is definitely a difference – before there was no useable picture whereas now the picture is useable (but it would make sense if it’s still 1680X1050 letterboxed).

Will try changing hdmi_mode and see what happens…

I haven’t changed the hdmi_mode from my old configuration. I had presumed that defined the starting mode; once I then changed the mode with display manager we would still get 2048×1152?

Nope. At the moment we don’t have any support for changing the actual display mode under RISC OS; all that happens is that the GPU scales whatever we give it to whatever mode was specified in the config.txt (or read from EDID) on startup.

Nope, using hdmi_mode=84 we get a mess across the screen :-(. Specifying a CVT mode might work – will try that later today.

What resolution does your monitor report it is getting?
What make and model monitor are you using?

A Samsung SyncMaster 2343NW. Unfortunately the monitor still reports it is 1680X1050 as Jeffrey suggested (albeit now scaling correctly when DisplayManager is set to 2048X1152).

DMT mode 84 is reduced blanking, so maybe the monitor doesn’t like that.

As you’ve got the EDID data handy, perhaps specifying the mode timings manually will work? See Dom’s post from the 12th of Dec: http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679

It’s a shame that there doesn’t seem to be any way of specifying custom mode timings at runtime – it looks like the tvservice interface that’s used to get the GPU to change mode only works with the CEA/DMT mode numbers (+ the custom mode if it was defined in the config file)

only works with the CEA/DMT mode numbers

Maybe this is why the Pi is reliable with my HDMI→VGA adaptor, while the Beagle xM struggles to display anything at all on the screen (and even then, erratically).
If the GPU is in control of all the timings, it can set itself the task of outputting solid stable and proper timing and signals. I assume RISC OS is controlling the timings of the OMAP? It’s a shame my adaptor can’t report on what exactly it is receiving to know why a particular mode is failing…

I assume RISC OS is controlling the timings of the OMAP?

Correct.

It’s a shame my adaptor can’t report on what exactly it is receiving to know why a particular mode is failing…

Are you sure it’s not a case of the adapter drawing more power than the OMAP’s video output can provide? I haven’t checked the numbers, but I’d expect the Pi’s HDMI output to be rated a bit higher, simply because it’s a proper HDMI output and not just a HDMI connector wired up to a DVI chip.

Interesting: I’ve got it working.

It does want the reduced blanking version interestingly:

Chris: Try this on your machine. Update the Start.ELF.
Use the lines above.

Remove the hdmi_mode, and instead use:
hdmi_cvt=2048 1152 60 3 0 0 1

Works a treat here (yes Jeffrey I know it’s an RB mode and it /should/ be what hdmi_mode=84 is doing… hdmi_mode 84 is obviously not what it thinks it is.)

Should mention: obviously you’ll need a suitable MDF (or EDID-enabled ScreenModes). EDID is nearly ready to go back onto the public branch – there is a fairly minimal bit of tidying up to do for it, but time has been a bit short of late. Will try and tidy it up and get it back to Steve.

Fixing that has definitely made a Pi, an X100 expansion board, and a Samsung 2343NW a killer combo :-).