RISC OS Open
Safeguarding the past, present and future of RISC OS for everyone
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → General →

Pi Screen limited to 1920 by RISC OS:-

Subscribe to Pi Screen limited to 1920 by RISC OS:- 26 posts, 6 voices

Posts per page:

Pages: 1 2

 
Oct 15, 2013 3:16pm
Avatar Chris Evans (457) 1600 posts

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

 
Oct 22, 2013 9:05pm
Avatar Chris Evans (457) 1600 posts

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!

 
Oct 22, 2013 9:36pm
Avatar Chris Johnson (125) 787 posts

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.

 
Oct 22, 2013 11:08pm
Avatar Jeffrey Lee (213) 5982 posts

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?

 
Jun 5, 2014 8:49pm
Avatar Chris Evans (457) 1600 posts

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.

 
Jun 6, 2014 1:22pm
Avatar Steve Revill (20) 1361 posts

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]

 
Jun 6, 2014 2:20pm
Avatar Jeffrey Lee (213) 5982 posts
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)

 
Jun 25, 2014 9:17pm
Avatar Jeffrey Lee (213) 5982 posts

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

 
Jun 26, 2014 10:18am
Avatar Chris Evans (457) 1600 posts

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.

 
Jun 26, 2014 10:50pm
Avatar William Harden (2174) 244 posts

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 ;-).

 
Jun 27, 2014 9:08am
Avatar Jeffrey Lee (213) 5982 posts

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

 
Jun 27, 2014 10:41am
Avatar William Harden (2174) 244 posts

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…

 
Jun 27, 2014 11:17am
Avatar Jeffrey Lee (213) 5982 posts

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.

 
Jun 27, 2014 11:51am
Avatar William Harden (2174) 244 posts

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

 
Jun 27, 2014 5:07pm
Avatar Chris Evans (457) 1600 posts

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

 
Jun 27, 2014 7:41pm
Avatar William Harden (2174) 244 posts

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).

 
Jun 27, 2014 8:05pm
Avatar Jeffrey Lee (213) 5982 posts

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)

 
Jun 27, 2014 8:48pm
Avatar Rick Murray (539) 11557 posts

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…

 
Jun 27, 2014 9:47pm
Avatar Jeffrey Lee (213) 5982 posts

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.

 
Jun 27, 2014 11:21pm
Avatar William Harden (2174) 244 posts

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.)

 
Jun 27, 2014 11:24pm
Avatar William Harden (2174) 244 posts

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 :-).

 
Jun 28, 2014 2:06pm
Avatar Chris Evans (457) 1600 posts

On our Dell SP2309W if we leave it up to EDID or use mode 84 or cvt and mode 87 it still won’t work with the latest start.elf & riscos.img.
Infuriatingly the GPU seems to be outputting 2048×1152 as if we leave RISC OS configured to 1920×1080 it starts up full screen and the monitor reports it is getting 2048×1152 but on selecting a 2048×1152 mode, we get the desktop with a border down the left and it truncates the desktop on the right at about 1920 pixels. Whilst the monitor still reports getting 2048×1152.
I’ve tried standard and reduced blanking.
what date start.elf & RISCOS.img are you using William?

Last try was with:

fake_vsync_isr=1
gpu_mem=64
init_emmc_clock=100000000

hdmi_group=2
#hdmi_mode=35
hdmi_cvt=2048 1152 60 3 0 0 1
#hdmi_cvt=1920 1080 60 3 0 0 0
#hdmi_cvt=1280 1024 60 3 0 0 1

hdmi_mode=87
kernel=RISCOS.IMG

 
Jun 28, 2014 2:36pm
Avatar Jeffrey Lee (213) 5982 posts

To avoid the display being cropped I think you also need to specify max_framebuffer_width and max_framebuffer_height. E.g.

max_framebuffer_width=2048
max_framebuffer_height=1152

 
Jun 28, 2014 3:38pm
Avatar William Harden (2174) 244 posts

Yes you need to set the max frame buffer width, height, and the new pixel clock limits. NB the frame buffer list is maximum allowed, not the amount you want to use (hence I’ve set mine as 4K since that seems to be what the ‘real’ maximum of a Pi is likely to be.)

All three are on my earlier post.

 
Jun 28, 2014 3:39pm
Avatar William Harden (2174) 244 posts

Start.elf was one fetched yesterday (so whatever is latest); the OS is a roll-my-own from about 5 weeks ago.

Next page

Pages: 1 2

Reply

To post replies, please first log in.

Forums → General →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

General discussions.

Voices

  • Chris Evans (457)
  • Chris Johnson (125)
  • Jeffrey Lee (213)
  • Steve Revill (20)
  • William Harden (2174)
  • Rick Murray (539)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys