DisplayLink

Multi-monitor support is my next big task, but it’ll be several months before I have anything ready to try. I have a rough plan of how it will work, but to do it properly we’ll need to overhaul how screen memory is managed, which will be a pretty big/tricky task as there are lots of factors to consider. Overhauling screen memory management is a key requirement for several other tasks (a non-hacky DisplayLink driver, hardware overlays, display rotation support for OMAP, etc.), so it’ll be good to get it out of the way (assuming I can arrive at something which works well!)

The following should work:
SYS “OS_CallAVector”,1,3,,,4,,,,,42

Thank you. I will try at the evening. How can I go back if I close the DL connection? Automatic? Only restart?

SYS "OS_ScreenMode",11,0 will switch back to the default display. There isn’t any automatic switching at the moment.

SYS “OS_ScreenMode”,11,0 will switch back to the default display.

This, I know. I mean the switched off Pandora Display via SYS “OS_CallAVector”. If I switched back to the default display. Sorry, I not know what SYS “OS_CallAVector” do. Maybe it is a stupid question.

The screen will turn back on when you switch back to it using OS_ScreenMode.

OS_CallAVector will call GraphicsV 4 to blank the screen.

I’ve uploaded an updated version of the driver, and have added the sources to CVS

I don’t have a list of what’s changed, but I think these were only noteworthy changes:

• Instead of using a list of known products, it uses the device descriptors and other information to identify the chip type and determine its limits.
• The re-entrancy issues in the driver should now be fixed (as long as the rules are being followed)
• There’s some basic error detection/recovery code. The error detection code should be OK, but the error recovery is a bit heavy-handed – it will try to *USBReset the device, and then give up if it doesn’t work (for the situation I was trying to fix, *USBReset simply doesn’t work – the only way I could find to reset the device was to manually unplug and reconnect it). Hopefully I’ll be able to find some simpler error cases which can be recovered from more gracefully, because the current code will result in the GraphicsV driver being re-registered and a mode change occurring.

I don’t think I’ll be doing much more work on the driver until I start work on the abort handler to trap screen writes.

I try in the morning but I have any small problems.
At first I have two small Basic_Progs with the “OS_Screenmode” inside in my main dir. This was a good idea ;-)
The DL adapter was right detected. I use it only with my Pandora.
The StartMode is ignored. It use the actually Pandora_mode. All modes I try are in the MDF.
My Monitor can not use 800 × 480. So I set 640 × 480 and switch to the DL-Display. It works. The Pandora LCD displayed a colourmix… OS_CallAVector not work.
Now I set the DL-Display to the prefered mode (1280 × 1024)… works. If I try a other resolution or if I go back to 640×480 to switch off the DL-Display, I have no Mousepointer… The only way out is the Basic-Prog in the main dir. F12 and *run Display_off. After this the Mousepointer is back on the Pandora screen.
Many thanks, no I can ready made my Pandora_Dock.

Having now had chance to do some more tests, unfortunately it seems my original ‘it works’ post was a bit over-enthusiastic. Whilst *UDLTest works and displays a spritefile, I can’t get the device to work ‘live’.

I’m using the Iyonix ROM dated 16th Jul 2014 and the latest UDLVideo module posted above. The output form *UDLDevices gives:
Device 1:
USB device: USB2
GraphicsV driver: 1
Chip: DL195 (c0030001)
Fussy huffman: No
diff_mode: 03
Max FB size: 2360000 pixels
Max FB width: 2048 pixels
Device memory: 000000-ffffff
Driver memory: 10MB @ 5fd00000
Display: blanked
Startup mode: 1280×1024 16bpp
Huffman compression: enabled
Status: f1005001

I have a BASIC file set up with just the line
SYS “OS_ScreenMode”,11,1

but when I run that file, whilst the ‘main’ display does stop being updated, it seems it crashes the Iyonix too. I get no screen output via the DisplayLink adaptor (monitor says ‘no signal’, screen is blank), and calling SYS “OS_ScreenMode”,11,0 to get back to the main display has no effect, neither does *.:0 to try and light the floppy drive (handy test to see if the command line is working when typing blind). I’ve also tried it with Huffman compression disabled.

I guess I’m doing something wrong, but what?

Andrew

What I wrote? My DL do the same because the startmodus is ignored. It use the same mode as the main display. If the DL display not understand this… blank screen.

Raik:

The StartMode is ignored. It use the actually Pandora_mode.

I think the problem there is that the Wimp will try to switch back to the mode that was previously being used by the desktop.

OS_CallAVector not work

It works for me – try making sure you have the right number of commas. However it looks like I was wrong when I said that the screen would turn back on automatically.

Try using the following in your two BASIC files. To switch to DisplayLink:

*udlstartupmode 1 1280 1024
SYS "OS_ScreenMode",11,1
*wimpmode x1280 y1024 c64k ltrgb
SYS "OS_CallAVector",1,3,0,0,4,0,0,0,0,42

And to switch back to the Pandora:

SYS "OS_ScreenMode",11,0
*wimpmode x800 y480 c16m
SYS "OS_CallAVector",0,3,0,0,4,0,0,0,0,42

These work for me with the latest ROM.

You can also use OS_CallAVector to turn the DisplayLink display on and off, e.g.

SYS "OS_CallAVector",1,3,0,0,(1<<24)+4,0,0,0,0,42 : REM turn off
SYS "OS_CallAVector",0,3,0,0,(1<<24)+4,0,0,0,0,42 : REM turn on

Chris/Andrew:

There are a couple of situations I know of which will cause a crash:

• Trying to use a numbered screen mode
• Selecting a startup mode which isn’t in the MDF

What does *Status show for your configured mode? It needs to be set to Auto, otherwise the kernel will try using that mode (and crash) instead of asking the driver what mode it wants to use.

[OS_CallAVector]

It works for me – try making sure you have the right number of commas.

I use copy & paste ;-)

Try using the following in your two BASIC files. To switch to DisplayLink:… And to switch back to the Pandora:…

Both are working fine to switch and switch back.
After any seconds, on the switched off Pandora-display came back white and black lines. Is the same if I use “Screen saver DPMS”. Is it the backlight? Can this switched off?
If I use “CallAVector” for the Displaylink-Display, the screen is off, black, dark…

Many thanks.

After any seconds, on the switched off Pandora-display came back white and black lines. Is the same if I use “Screen saver DPMS”. Is it the backlight? Can this switched off?

Yes, it’s a problem caused by the backlight + LCD power being left on. I didn’t know it caused lines to appear – for me the screen just remains black. I’ll look into fixing it.

Chris/Andrew:
There are a couple of situations I know of which will cause a crash:
*Trying to use a numbered screen mode
*Selecting a startup mode which isn’t in the MDF

Ah, that’s fixed it, thanks. For some reason the configured mode was ‘32’ not ‘Auto’. Remnants of some previous testing, I guess! All works fine now, thanks very much, great work!

I did not know that the driver has a “plug and play” support. I booted the IGEPV5 (UDLVideo is in Predesk) to the desktop. Adapter not plug, no video output, Display is in standby.
I insert my DisplayLink adapter and the screen switches to active. Press [F12] + [Return] start the video output. Very well.

Hi, I’ve only just learned of your work on a DisplayLink driver, and I have a couple of adapters myself, but didn’t realise there was any open documentation/source to assist in writing a driver. Geminus does not actually ‘assume’ that every driver is an NVidia one, per se, but the code would need altering slightly to support a USB-attached driver. I’ll have a play with your driver and see if we can combine them. Multi-monitor support, including support for portrait modes etc is a pretty significant amount of work, and of Geminus already does all that. Best wishes.

(I currently have a desktop that’s 3328×1280, formed from two large NVidia-attached monitors, on my IX PC, but I’m on a mission to attach all of my monitors and never again be able to find a window on my desktop ;) )

Would be interesting also for dual monitor support on Raspberry Pi (now possible with the VGA adapter) and PandaBoard ES (for this one, I could pay some license, even if pricey).

Hi, I’ve only just learned of your work on a DisplayLink driver, and I have a couple of adapters myself, but didn’t realise there was any open documentation/source to assist in writing a driver. Geminus does not actually ‘assume’ that every driver is an NVidia one, per se, but the code would need altering slightly to support a USB-attached driver. I’ll have a play with your driver and see if we can combine them. Multi-monitor support, including support for portrait modes etc is a pretty significant amount of work, and of Geminus already does all that. Best wishes.

Excellent. I haven’t had much time to do any GraphicsV-related stuff recently, so any input or improvements that you can bring would be most welcome.

I currently have a desktop that’s 3328×1280, formed from two large NVidia-attached monitors.

If you move the mouse, does the pointer just go off one monitor and appear on the corresponding part of the other?
Can you straddle a window over a screen join?

Yes and yes (on my 4096 × 1080 configuration).

Yes and yes (on my 4096 × 1080 configuration).

How’s that made up?
I’ve not heard of a 2048 × 1080 monitor!

I’m even more puzzled by Adrian’s 3328×1280 using two monitors

I’m even more puzzled by Adrian’s 3328×1280 using two monitors

I suspect this is as a result of one of the limitations of Geminus; these numbers are a bit made-up but it goes something like this: the total size of the frame buffer for your ‘wide’ mode needs to be a whole multiple of 256 bytes wide (or was it a quad-word, 16 bytes?). So, when you have two 1680×1050 monitors, you end up running them each at 1664 pixels wide. I also found that the height had the same restriction (although it shouldn’t AFAICT) so you end up then with your ‘wide’ mode being 1664(x2) = 3328 by 1024 pixels.

Of course, this means everything ends up looking a bit blurry and is a shame. I’ve had various monitors over the years but sadly never arrived at a combination where they were running at their native resolution in the dual-head configuration so I just got used to everything looking a bit naff. :(

I could be wrong here, but my other vague recollection was that the only reason for this limitation was due to the lack of a certain API being exposed by the NVidia driver on the Iyonix. Hopefully, now we’ve got a much more robust published codebase nowadays, we can move past all these issues and get multi-head support properly implemented and integrated in future versions of RISC OS. That will be a good day indeed. :)

I’ve not heard of a 2048 × 1080 monitor!

RISC OS can’t manage a 1920×2 framebuffer, so I use 2048×2. It’s clean with my monitors.

Steve is mostly correct in what he says. I did some work to eliminate the 256n limitation from the left and right monitors of a multi-monitor setup, and this limitation should indeed apply only to the width of the screen mode used (unless the screen is rotated into portrait mode, in which case it applies to the height of the definition, ie. the constraint applies always to the width of the physical screen as you see it in front of you). However, I could not get the NVidia module to play ball even with the API extension that I proposed having been supposedly included.

My monitors are actually 2048×1280 and 1680×1050 physically, being driven at 2048×1280 and 1280×1024, respectively. The bizarre setup is because (i) these are my two best monitors, (ii) Geminus/NVidia do not currently cope properly with the 2nd screen, (iii) The 1280×1024 signal used to go to a monitor of that physical resolution, and readily permits testing of portrait modes. The astute will note there is a ‘hole’ in the top-right corner of my desktop because of the mismatched heights; this is something I also want to make Geminus handle better.

There is no reason to constrain the other dimension, I’ll do some testing/code checking for that too.

The 256n constraint arises from the use of the MMU to map a single virtual screen across the multiple frame buffers. A possible ‘cleaner’ solution – given that applications are accustomed to drawing directly to the screen themselves – might be to present a contiguous display surface (representing all/part of the window’s work area, in effect) to the application and then, when the redraw operation is complete, blat the result to the affected physical frame buffers. Geminus took the approach of using only the video card memory.

Actually, correcting my own post blush, the first screen is physically 2560×1600 which requires dual-link DVI-D and I’m having to use the VGA input…but that’s another problem altogether!

There are some 27inch 2560×1600 60Hz – I think – monitors around – can they be driven at that rate via the VGA cable?