Multiple Screens

I am looking for a way to have three monitors side by side and the mouse being able to traverse across all three.

I know how to do it with Windows XP in the middle as the primary system, with RISC OS and/or Linux on either side, ….

I don’t mind if the monitors on either side are on the same computer or different systems.

Hi Bryan,
I am personally not aware of any “native” fully built RISC OS support for multi-monitors (especially when trying to use 3).

There was a work from Sendiri done for the Iyonix, who added multi-monitor support. Now he is working on porting that work (and also extending it) to the newer ARMv7 and ARMv8 based platforms, but it’s not completed yet.

More info here: http://www.sendiri.co.uk/geminus/index.html

If someone is aware of any other tools in a more advanced state or usable, I’d be interested too, thanks.

Thanks for that. I can add that I am trying to do it on a Raspberry Pi, so additional graphics cards are no go.

So, AFAIK, the new Geminus should work without dedicated graphic card. Sendiri is porting just the software to the ARMX6 and the i.mx6.

For the Pi I am not sure.

As a ref, here there is the proposal of multi-display support native in RISC OS: https://www.riscosopen.org/wiki/documentation/show/Proposed%20Multiple%20Display%20implementation

Then there are the usual (per platform, non standard, buy the machine to use) solutions like !DualHead:

https://www.iconbar.com/articles/DualHead_in_use/index1378.html

But those falls in the 2 monitors only, no idea if they can go up to 3 (that will also depends on multiple factors, not just the software side)

As a workaround, until something better becomes available, you could have Windows or Linux in the middle screen, running a VNC client, connected to VNCserver on RISC OS.

The main limitation I have found with this is that it wil not sent F12, ctrl-F12 etc to RISC OS. (I’m using TightVNC – other clients might work better.)

The main limitation I have found with this is that it wil not sent F12, ctrl-F12 etc to RISC OS. (I’m using TightVNC – other clients might work better.)

Luckily you can get a Task Window from the switcher menu on RISC OS 5. You don’t want to ever do F12 over VNC, as the scrolling is horrifically slow.

No problem with F12 or ctrl-F12 using RealVNC (mac client) to ARMX6 VNC server
F12 scroll is similar speed to RISC OS host.
Did uncover a funny though. F12 followed by show displayed a page and then appeared to be stuck. I blamed VNC and rebooted RISC OS. However the same thing happened on RISC OS native F12. I pressed all manner of keys to get it moving again to no avail until I hit escape.

Did uncover a funny though. F12 followed by show displayed a page and then appeared to be stuck.

It stops at each page full – so you can read the output. Just press SHIFT to get the next page full.

F12 scroll is similar speed to RISC OS host.

Well now I have learnt to scroll the page (thanks Chris) I have tested the speed again.
F12 VNC show command 24 seconds. Native on RISC OS 12 seconds. Quite a difference but usable.

Luckily you can get a Task Window from the switcher menu on RISC OS 5. You don’t want to ever do F12 over VNC, as the scrolling is horrifically slow.

I did however say “etc”. The one I find most annoying is alt-break. It would sometimes be very useful to be able to send that.

And even more useful to be able send it from a RISC OS client to a RISC OS server, as that’s a combination I use quite a lot.

The one I find most annoying is alt-break. It would sometimes be very useful to be able to send that.

Maybe we need to alter the VNC server to interpret Ctrl+Alt+Delete as Alt+Break, as all clients can send that.

Maybe we need to alter the VNC server to interpret Ctrl+Alt+Delete as Alt+Break, as all clients can send that.

I was going to suggest that too, though it does presuppose that the server is able to function in a situation where you want to interrupt a looping process.

I was going to suggest that too, though it does presuppose that the server is able to function in a situation where you want to interrupt a looping process.

Well, yes, but in that circumstance does it really matter what key combo you’re using in a failed attempt to do something remotely?