Displaylink

Anything and everything about programming graphics with Ultibo
Gavinmc42
Posts: 1656
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Displaylink

Postby Gavinmc42 » Sat Mar 09, 2019 11:18 am

Displaylink came up on the Raspberry forums.

It uses a USB chip to screen, a piece of hardware running a protocol to act as external monitors.
A driver has been made for Linux, libdlo,
It does not seem much more than a pixel, line and rect render driver.
Takes a Linux framebuffer and passes it via USB to the display chip.

We should be able to do that via USB on a Zero.
When using a Pi for development I miss having a second screen.
With OpenVG we could go a bit past just pixels and lines.
With OpenGLES it could go further.

One of the drivers for fbtft LCD's only sends changed pixel data to the LCD which over SPI means higher fps.
USB hubs and lots of Zero's, what is the limit to screens?

I already use Zero's for VC4 display software development, the only thing missing is the Zero's USB OTG comms?
X11 can do remote displays, this would be a VC4 accelerated version?

Doing my SteamPunk OS for my eReader I found out how easy it is to do OpenVG,
A scripted version of that would make the display independent of the hardware?
The display commands redirect to a USB port for display on a Zero.

A google on DirectX linked to Direct2D and to the Open Source Win2D
https://github.com/Microsoft/Win2D
Does this sample look like AJStarks hello demo?
https://github.com/Microsoft/Win2D-Samp ... ge.xaml.cs
Gavinmc42
Posts: 1656
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Displaylink

Postby Gavinmc42 » Sat Mar 09, 2019 11:53 am

An Ultibo version of this?
https://symless.com/synergy

It would be great just to grab a pdf file and drag and drop it on a Zero based second screen.
User avatar
Ultibo
Site Admin
Posts: 2280
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Displaylink

Postby Ultibo » Sat Mar 09, 2019 11:57 pm

Gavinmc42 wrote:Displaylink came up on the Raspberry forums.

It uses a USB chip to screen, a piece of hardware running a protocol to act as external monitors.
A driver has been made for Linux, libdlo,
It does not seem much more than a pixel, line and rect render driver.
Takes a Linux framebuffer and passes it via USB to the display chip.

According to Wikipedia the only specifications available are reverse engineered and the open source Linux drivers only support basic functionality. Could be a good project for someone to take on but since we don't have any DisplayLink devices it's unlikely to be us.

Gavinmc42 wrote:One of the drivers for fbtft LCD's only sends changed pixel data to the LCD which over SPI means higher fps.

Of course the Ultibo TFT drivers also do that, but I think we've mentioned that previously ;)

Gavinmc42 wrote:An Ultibo version of this?
https://symless.com/synergy

Not sure how that differs from RDP, VNC, VirtualBox, VMware etc that we all use everyday.
Ultibo.org | Make something amazing
https://ultibo.org
Gavinmc42
Posts: 1656
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Displaylink

Postby Gavinmc42 » Sun Mar 10, 2019 2:04 am

since we don't have any DisplayLink devices it's unlikely to be us.

Me neither but I have a bunch of Zero's ;)

Not sure how that differs from RDP, VNC, VirtualBox, VMware etc that we all use everyday.

No idea either? Probably plenty of ways to do it already, reinventing the wheel?
After looking at AJ Starks Deck stuff it can probably be done in Go too, if it has not been done already.

But since I want to make a simple OS for the eReader, expanding it or considering from the start an abstraction of OS from the Display makes sense.
x11 was added to Linux it is not integrated like Windows.

Of course the Ultibo TFT drivers also do that, but I think we've mentioned that previously ;)

Yep and I really need to get some more LCD's to test this.
Ultibo based Zero USB displays sound like some fun things to have around.
Was thinking Uart RS485 using cat5 cable, make myself Orville door controls, which are probably done with iPads anyway.

Using the VC4 accelerated hardware for Ultilink clients means lower data rates?
USB, UART, Ethernet, WiFi, BLE are all probably usable comms methods.
Add Canbus? Two wire Ethernet?
Probably enough business there for dozens of companies in as many markets?

Anyway I would settle for a second Pi screen or a third screen, maybe a fourth?
Gavinmc42
Posts: 1656
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Displaylink

Postby Gavinmc42 » Sun Mar 10, 2019 6:46 am

Been thinking about a VGconsole unit, so had a look at the two console files.
Did not even pay much attention to these ones before .

CONSOLE_TYPE_SERIAL = 2;
CONSOLE_TYPE_REMOTE = 3;
CONSOLE_TYPE_LCD = 4;

Displaylink would be the graphical version of CONSOLE_TYPE_USB = 5;?
In the graphicsconsole there is none of these const options, for obvious reasons ;)
Not sure how the graphicsconsole could be redirected, but if it was able to be, then it already has most of the features of Displaylink.

A redirectable VGconsole would be even more fancy.

Is the CONSOLE_TYPE_SERIAL = 2; uart only or can it do USB serial?
It could end up in three stages - console USB, graphicsconsole USB and then VGconsole USB.
Or 4 stages if a 3D OpenGLES console gets made.

Would the USB versions only be Zero specific or could it be used on any Pi?
So many ideas and such a lack of time and skill :(

I can see why the Pi get used a lot in commercial display projects.
Useful little things, google to check if someone has already made a second screen with Zero's?
hippy
Posts: 38
Joined: Tue Jan 02, 2018 5:54 pm
Location: UK

Re: Displaylink

Postby hippy » Mon Mar 11, 2019 1:37 am

Gavinmc42 wrote:Probably plenty of ways to do it already, reinventing the wheel?

Definitely another reinvention of the numerous reinventions already. Arguably, yet another does no harm.

The advantage of reinventing is to make it easier to implement. Free of other people's take on it, you get to define the complete software stack and protocol. Day one, throw a frame buffer out and have that received then displayed. Day two optimise to send only changed rectangles. Day three keep optimising, making it faster. Eventually give it a snazzy brand name and declare it another 'standard' :D

This disadvantage of reinventing is incompatible with anything else. And 'anything else' is what everyone is using. Your receivers will be fine with your transmitters but what most people would prefer is something compatible with the transmitters they already have; and on the whole that's DisplayLink.

Have your receiver use DisplayLink and it works out of the box with Linux, Windows, Mac, anything with DisplayLink support. You then have no transmitter drivers to write. Except for things which don't yet support DisplayLink.

And, of course, if you have your own protocol, only your receivers will work. People couldn't use their DisplayLink monitor.

I'm not against a self-defined protocol, at least to provide Proof of Concept, or remote display by USB solely for Ultibo, but ideally a DisplayLink receiver is what the world needs. Anything less is a niche project, has only limited appeal.
Gavinmc42
Posts: 1656
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Displaylink

Postby Gavinmc42 » Mon Mar 11, 2019 7:42 am

My whole point of Pi's is to learn stuff, even if it is how to make wheels ;)
And to explore new ways of doing things.

Ultibo just makes it easier to learn to do stuff.
Doing an OpenVG accelerated remote display protocol does look like it is within my limited capabilities.

Pi as server, Pi's as clients, no need to stick with standards.
Since there does not seem to be much accelerated remote display specific to Pi's I see no reason to stick with standards.

Get it to work on Pi's in Ultibo then it should be back portable to Linux etc for those that know how to do that stuff.
Most of the existing remote desktop stuff expects windowing framed rectangles we all use.

Been on the Flightgear forums learning SVG instrumentation.
On the fly generated SVG usual the Nasal language with some sort of XML script?
Figured there must be a way to use OpenVG for the look and also the changing data.
Displaylink could be used, but Pi Zero's are cheaper.
Why play with pixels when the whole thing can be done with a graphics description protocol?

Remote displays is a subset of remote desktops?
Paul's VNC code could be used as starting point.
Apart from the comms channel what are the differences in the protocols?

But you are right, a Displaylink client on Zero's is immediately handy.
Gavinmc42
Posts: 1656
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Displaylink

Postby Gavinmc42 » Mon Mar 11, 2019 11:43 am

VNC and Displaylink, remote desktops etc all have clients/servers.
Nothing wrong with using Ultibo and Pi's at both ends.

Since I know near zero about comms protocols i will go back to my eReader Steampunk OS.
But looking at a way to script the OpenVG UI from a text file.
Make it independent of any comms protocol, but small enough and simple enough to use any known comm methods.
Easiest for me to test is serial so probably a serial port OpenVG terminal.
Now back to where I started, VGconsole terminal :D

I suppose free pascal streaming methods could be used?
Just redirect the streams? Er what are streams again :oops:
Come back here in 6 months, might know more by then?

Since I used to be able write G-code by hand for CNC machining, I might do some sort version of that.
Call it VG-Code?
Hmm Fpvectorial does G-Code, er back here again, that will be in the next Ultibo version?
User avatar
Ultibo
Site Admin
Posts: 2280
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Displaylink

Postby Ultibo » Mon Mar 11, 2019 10:38 pm

Gavinmc42 wrote:Displaylink would be the graphical version of CONSOLE_TYPE_USB = 5;?

I think you are confusing Console with Framebuffer, the DisplayLink if implemented would appear as a framebuffer device in Ultibo and the framebuffer console driver (CONSOLE_TYPE_FRAMEBUFFER) would automatically work with it the same way it does with the TFT framebuffer devices. Both console and graphics console API are automatically available on any framebuffer based device.

Gavinmc42 wrote:Is the CONSOLE_TYPE_SERIAL = 2; uart only or can it do USB serial?

That would be any serial device regardless of whether it is a UART or a USB serial, we haven't implemented either the serial console or remote console yet because they still need a complete handler for the ANSI escape sequences used by most terminal emulators (VT100 etc), it's likely that both of these will share almost identical code.
Ultibo.org | Make something amazing
https://ultibo.org
Gavinmc42
Posts: 1656
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Displaylink

Postby Gavinmc42 » Tue Mar 12, 2019 1:24 am

I think you are confusing Console with Framebuffer, the DisplayLink if implemented would appear as a framebuffer device in Ultibo and the framebuffer console driver (CONSOLE_TYPE_FRAMEBUFFER) would automatically work with it the same way it does with the TFT framebuffer devices. Both console and graphics console API are automatically available on any framebuffer based device.


Yep, I understand that, framebuffer is just pixels, console and graphics console are still framebuffer based.
Displaylink, VNC etc is still all pixels.

I am thinking about GPU based console.
Hmm wonder if OpenVG can emulate the current green framebuffer console?
This probably should be in another post, or relabelled "Displaylink type remote displays"

New chips/designs are coming out that are descriptive graphics or compressed framebuffer, these are the ones that started me thinking about this
https://think-silicon.com/
You could say the framebuffer compression is similar to Displaylink and VNC, just done in hardware.

Thanks for ANSI reminder, I need to dig that out and relearn it.

Return to “Graphics”

Who is online

Users browsing this forum: No registered users and 1 guest