DisplayLink

I believe it’s up to the monitor; this is a 30" Dell with a 16:10 ratio rather than 4:3, and obviously it can count the vertical resolution; it seems to reject anything above 1280, since 2048:1280 resamples pretty well. I did spend quite a while trying to ‘dupe’ it. I can increase the horizontal resolution but there’s little point.

What is the present state of DisplayLink support?

It’s still in the prototype stage (the build on my website is up-to-date, IIRC). The DisplayLink part of the driver is fine, but the GraphicsV part is being held back by how video memory is managed by the OS. Fixing that will take a while (my rough plan of action is to get physical memory pools finished, update GraphicsV to allow drivers to use them for managing their video memory, and then implement some kind of abort manager so the driver can detect writes to screen memory and use them to trigger updates to the remote DisplayLink framebuffer).

It probably doesn’t help that I haven’t been able to find the time to work on physical memory pools since December!

Is the DisplayLink driver still being developed?
I can see more recent versions in the ROOL GitLab, is anyone using a recent version (0.06) ?

I haven’t touched the code in years. I think the only functional difference between the old build on my website and the newer code in git is how it checks for interlaced modes (there were some changes/fixes to the way the driver checks for them).

For multi-monitor use, there’s still a fair amount of work that needs doing to make the OS multi-monitor aware (there’s still some design work to do, and some big memory management changes). Although, as with things like !DualHead on the Titanium, we could also pretty easily add support for multi-monitor setups where all the active displays are DisplayLink ones.

The driver needs to know which areas of the screen are changing, so it can send the new data to the display. The way UDLVideo currently does this is slow and inefficient – it regularly scans the entire screen to look for changes, comparing against an older copy of the screen. But if some/all of the big memory management changes are implemented then it should be pretty easy to get some significant performance gains here, by removing the scanning code and using AbortTrap to keep track of which screen memory pages are being written to.

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

My two 27" AOCs although 16:9 1440p, can do the full resolution with either of the 2x HDMI, Display Port or VGA inputs. I tried it out on my old Iyonix which was still set up for a 22" CRT at 2048×1536, which very surprising it dealt with, even showing it at the correct 4:3 aspect. I then reconfigured it for native 2560×1440 which despite being analogue was almost indistinguishable from the RISC OS Pi4 driving it via HDMI.