[Libdlo] Ubuntu 9.10 report

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue Nov 3 14:39:00 PST 2009


> decently performant, and ready for fbdev client applications to use
> it. Any fbdev clients anyone is using, other than X itself?

 i was thinking of running qemu direct onto fbdev screens.
 on the ARM boards, that would mean being able to run Wince
 on one screen, Android on another, ubuntu on a third etc.
 with the upcoming Cortex A9 dual-core ARM, expected to top out
 at 2ghz, that's perfectly reasonable.

 so, yeah: a smartphone, with an option chooser "heyyy, do you want
 windows, linux, or fries with that screen, dummy?" and go from there.

 be interesting to see if the idea falls over in a heap... :)


> The purpose of libdlo as a user mode library is still unclear --
> perhaps just a reference implementation

 running the tests is what got things up-and-running on my
 system.  prior to that it was a bit unhappy.

 i can think of reasons why you would want to use it (assuming
 that the xf86 displaylink driver uses it): to do "remote networking"
 over ethernet or wifi.

 i haven't checked the source yet (only got the UD-160-A yesterday as
you know bernie!) however i anticipate the following rough design:

 * X server runs on system A with a "disconnected" version of libldo
(assuming xf86 displaylink driver uses libldo) that pushes its
parameters over to system B using some lovely RPC mechanism (there's
lots of those, don't have to reinvent one...)

 * system B receives parameters from system A over
ethernet/wifi/whatever, and plops them into the _real_ version of
libldo, whereupon the data appears on-screen on system B.

in this way you can have devices disconnected from their screens,
running over ethernet, wifi or other lovely fast wireless systems
instead of USB.  the "screen" (system B) actually comprises an ARM
embedded SoC with lovely fast wireless, directly mounted onto the back
of the LCD panel, with a displaylink chipset on its USB port, makes a
nice little earner for someone doing hardware designs, somewhere.

of course the assumption here is that the displaylink protocol is more
efficient or at least more feature-rich than VNC or RDP or even the
X-Server protocol (god help us), but before you get all linux-purist
the above scheme quite happily works OS-independently.  NX / Nomachine
as we know is a bit of a pig so that's out.

so - bernie, how does the data efficiency of the displaylink algorithm
compare with VNC for example?

and... haven't i just described what the ndiyo nivo already
implements? :)  that has ethernet, doesn't it?

l.


More information about the Libdlo mailing list