Screen modes wider than 2048 on RPi 2

Using these settings in config.txt I’m able to get the full native resolution (2560×1440) on a 27 inch Viewsonic VP2770-LED monitor.

hdmi_mode=87
hdmi_cvt=2560 1440 50 3 0 0 1
max_framebuffer_width=2560
max_framebuffer_height=1440
hdmi_pixel_freq_limit=400000000

I have to use 2048×1152 to get !Boot to complete sucessfully. Using 2560×1440 gives an ‘unsupported error’ and ends up with a scaled 2048×1152 mode in the desktop.
If I press F12 and type ‘wimpmode x2560 x1440 c16m f60’ once in the desktop then i get the correct resolution. This works fine except the mouse pointer disappears if moved right past 2048 pixels. It’s quite diffcult to click on the correct icon on the iconbar with an invisible mouse pointer. :-)
I can get around it to a degree by running a dummy application enough times so the iconbar icons are shifted across into the visible pointer range.

Is the 2048 width a limit in RISC OS or is it a hardware limit on the RPi?

I have a feeling it’s an OS limit for the mouse pointer. Any ideas what is issuing the ‘unsupported error’?

Chris: What refresh rate do you get?

Very interesting, especially 1/ if the problem is solved 2/ if it works too on the Pi 1 :)
I have one question. How did you manage to boot with 2560×1440? Technically, the GPU can’t handle this (2560×1600 is OK).

I have a feeling it’s an OS limit for the mouse pointer. Any ideas what is issuing the ‘unsupported error’?

I typed it in wrong. It’s working as it should now. Boots up in 2560×1440.

What refresh rate do you get?

The refresh rate is 50Hz which is the lowest the monitor supports. The pixel clock is 200.7MHz which is well above the supported maximum of 162.0MHz.

Very interesting, especially 1/ if the problem is solved 2/ if it works too on the Pi 1 :)

I just did a quick test on a RPi 1 (Model B 256MB). While 2560×1440 appears it locks up soon after.

I have one question. How did you manage to boot with 2560×1440? Technically, the GPU can’t handle this (2560×1600 is OK).

hdmi_mode=87 is for custom modes. In theory you can set any mode you like as long as the GPU/RISC OS and the monitor supports it.

See here for documentation on all the settings.

hdmi_mode=87 is for custom modes.

Ah OK. So 2560×1400 OK, but only on Pi2. Is it fluid?

We had an original Pi driving a 4K TV at the London Show at full resolution, 3840×2160 at 15Hz. It also had the problem with the mouse pointer vanishing 2048 pixels across the screen! Use CloseUp with the cross hairs turned on to be able to click on things on the right hand side of the screen :-)

AFAIK the mouse pointer vanishing when moved beyond X=2048 is a firmware issue. But I’m willing to be proved wrong if someone with a big monitor wants to have a go at debugging the code :-)

AFAIK the mouse pointer vanishing when moved beyond X=2048 is a firmware issue.

Highly possible yes. But why about using a software pointer for resolutions > 2048?

That would solve the problem, and RISC OS will be able to do something Linux can’t :)

This is almost certainly not a RISC OS/ARM-side issue, because I drive screens wider than that on other RISC OS 5 targets. The thing to do would be to ask the Raspberry Pi people, and check whether anybody has had Linux running (if it is indeed using an hardware cursor) and wider screens. (After searching the forums/trying a Linux build yourself, of course).

Of course, normally, the Pi is not expected to go above 1920, and I have a nasty suspicion that it could even be a limitation in the hardware; it was all specified for 1080p operation, and I’m pretty sure that because of the circumstances under which the Pi2’s SoC was developed, that the VC hardware will be completely unchanged from the original Pi. So, pray that it really is an issue in the VC firmware that can be overcome.

All may not be completely lost, however, in that I did have a software mouse pointer nearly working in RISC OS, and suggested that it remain in the codebase; I don’t know whether it was ever fixed. Perhaps that could be fixed and switched into use in place of the hardware pointer down the right hand side of the screen, if necessary? This is – arguably – preferable to entirely disregarding the hardware pointer in wide modes, because the software one may well be inferior in some ways; I’ve always missed a true interrupt-driven hardware pointer on other OS platforms.

Does the pointer partially disappear as you move slowly to the right across the boundary? From the description, I’m presuming that it does disappear completely to the right of that point, and does not simply wraparound to the left, for example?

RISC OS traditionally used a hardware mouse pointer. The pointer on the Pi seems fairly fluid so I’m guessing this is some sort of hardware assist and not an early Windowsy paste-on-a-pointer kind of deal?
With that in mind, how is the pointer actually implemented? Are there known limitations of that system? It appears that the 3D engine maxes out at 2K in either dimension (the Pi’s GPU is only really specified for Full HD), I wonder if whatever is dealing with the pointer is likewise?

They have installed a 4K demo television in a local supermarket. It is pretty impressive, though I think it’ll be a long time before we can expect reliable streaming or broadcast that can make full use of the capabilities. Still, it looked a lot better than the mess of jittery aliasing effects that passes for HD (or is it just Bluray that sucks that bad? I have some HD animé and it doesn’t look anything like as bad as the picture on those big TVs).

As far as I can make out Raspian uses a software pointer. Though they seem to be working on a Hardware one. https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=69926&p=747968#p747968

The pointer works correctly in 2048 wide modes. In modes >2048 the pointer doesn’t partially disappear. It is o.k. at 2048 and disappears totally at 2049!

I’m feeding back this information to the Pi Foundation but they think, like you Adrian, that the hardware might not support it. In Pi forum thread quoted above I’ve asked Dom to check.

Andrew here remembered about !CloseUp (included in ROOL’s Pi disk image) using it means it is possible to use the area past 2048! Not ideal but a lot easier than without it. Though he has had to modify the program so that it opens its window on running (otherwise you’d be fishing blindly to try and click on its iconbar icon) He has also modified it so that it keeps bringing itself to the front as that is sometimes necessary.

With the massive display area we now have, it is very easy to lose the pointer. I remember there used to be a program on RISC OS 3.1 that enlarged the pointer whilst it was moving.
Adrian: if you do implement a software pointer could you include an option to do something similar also many people liked using the running dog and other pointers in place of hour glass. If hooks were put in for other people to play with that would be very nice:-)

The way that I implemented the software pointer for the initial port to the Pi, was in fact right down at the interface between the graphics level; in effect, the kernel simply notices that the graphics hardware says “Nope, I can’t give you a hardware pointer”, and so software steps in and does the work. This has the advantage of not interfering with hardware acceleration ops, being as responsive to mouse movement as an actual hardware pointer (still interrupt-driven in the usual fashion, unlike on other OS platforms) and means that all of the higher-level software for defining/changing pointer shapes/colours etc is completely oblivious of whether it’s really the CPU/GPU doing the actual screen operations.

It could be fun to finally get it working, and it can obviously be implemented on any hardware, so I may try to resurrect it. Luckily I never clean up my hard drive ;) … so I still have the source. The idea of keeping it in the code tree was to assist in the future bring up of new hardware targets.

many people liked using the running dog and other pointers in place of hour glass.

Mine was a glass of red wine gradually emptying and then magically replenished. Unfortunately, module was not 32-bit compatible!

many people liked using the running dog and other pointers in place of hour glass

I’m sure there are 32 bit versions around.

Mine was a glass of red wine gradually emptying and then magically replenished. Unfortunately, module was not 32-bit compatible!

If you can’t find a 32-bit one, but it’s based upon Jon Ribbins DogGlass module (http://www.armclub.org.uk/32bit/) which has been converted and you still have the module, I’m sure it could be converted in a matter of minutes. Check that the module itself is called Hourglass and says © Jon Ribbens, 1992 by dragging onto Zap/StrongED, and make it available. If you email it to a.lees at my yahoo address (hope that’s clear enough) I’ll do it. Or the 26-bit version should run under Aemulor Pro.

I’m sure it could be converted in a matter of minutes. Check that the module itself is called Hourglass and says © Jon Ribbens, 1992 by dragging onto Zap/StrongED, and make it available.

I was really just making an observation about the strange things people do to amuse themselves, but if you or anyone has the time, the module is here – oddly it doesn’t work in NetSurf if I add the trailing slash myself.

It should, of course, be typed module – I haven’t bothered with an archive!

I see from: https://www.riscosopen.org/viewer/revisions Jeffrey has just checked in support for a software pointer when it is >2048 pixels from the left! Thanks Jeffrey.

What implications does this have for other machines? Could we now use 2560×1440 monitors with, say, the IGEPv5 or the ARMx6 (subject to updated ROM being made by R-Comp)?

andym – well, I provided Jeffrey with such a monitor because even without the fixes, I could coax a 2560×1440 desktop out of my ARMX6. However, at the time, video issues occurred when pointer was in the margins of the screen (for similar reasons). Initially we thought the problem was in the pointer code which Jeffrey had kindly developed originally for ARMX6.

As it turned out, this needed the recent changes as well, which I believe prompted Jeffrey to look into it further. So, yes, my hope is to have 2560×1440 in the next ARMX6 ROM. Indeed, Jeffrey reported 2560×1440 at 60hz working when he took delivery, with just the pointer issue to resolve.

2560×1440@60 works with both Pi and Pi2? Do we have a working MDF for this?

Do we have a working MDF for this?

EDID ?

2560×1440@60 works with both Pi and Pi2? Do we have a working MDF for this?

If you don’t mind creating your own you can download a port of cvt.

Then it’s just a case of typing for e.g. a mode of 2560×1440 @50Hz with reduced blanking. The resulting MDF works fine on my RPi 2 but not Rpi 1. See further up the topic for required config.txt settings. The max pixel clock on Rpi 2 seems to be about 200MHz (Officially 162MHz).
I think the ARMX6 supports up to 260MHz so 60Hz is 241.5MHz pixel clock. The PandaBoard ES and IGEPv5 up to 186MHz. If you can find a monitor that supports down to 46Hz then 2560×1440 should be possible.

cvt 2560 1440 50 -r

If you have access to UHD tv you can use much lower refresh rates. I believe 4K is then possible.

On a RPi 2 I set gpu_mem=128 (64MB works OK) in config.txt the mouse pointer disappears as soon the the desktop appears. *hon make the hourglass appear hoff it then disappears again.
Resolution is 2560×1440 with the new mouse pointer changes.
The only reason I set it to 128 was because I was testing !Khronos. :-)