Slashdot Mirror
DisplayLink Releases LGPL USB Graphics Code
iso writes "USB graphics should be coming to Linux soon: DisplayLink has released an LGPL library that talks to one of its graphics chips over a USB connection. DisplayLink aren't one of the big guys in graphics, but it's always nice to see a hardware manufacturer go the open source route. Now, when can I get one of these touchscreen MIMOs on my Linux HTPC?"
Are you forgetting about sisusb x.org driver ? How is this anything other than a slashvertisement?
It's always good to see more hardware developers opening their drivers to Linux development. I think more and more companies are realizing that linux desktops are not going to be the defacto standard, but that Linux will be in a lot of gear that could use their devices. Getting their drivers and devices cozy with linux only works in everybody's favor.
One of the guys here was trying DisplayLink over wireless USB - driving a high res picture at close to real time. It actually does a pretty good job, though the drivers are still a mess and really hack around the display stack.
Is it any more then a small display gimmick ?
I mean, feeding my monitor/tv through USB would be nice, but there must be some technical glitch like lack of bandwidth for higher resolutions and frame rates.
Of course it's not enough bandwidth for streaming video, but it's more than adequate for browsing the web (sans YouTube) or (gasp) working on an extra (up to 1600x1200) monitor...
More info can be found here.
np: Casiotone For The Painfully Alone - Streets Of Philedelphia (Advance Base Battery Life)
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
I use one of their units to drive a second 22" display from my Macbook Pro. It works wonderfully for everything EXCEPT watching videos. Terminal sessions, Eclipse coding environments, email etc are seamless on it. As another poster said though, it doesn't have the bandwidth to deal with video very well, but I knew that going in and that wasn't my reason for buying it.
The thing that's sucked about all this is I have the computer underneath a seat, with a regular ol' LCD panel bolted into the middle of the car, running off of a 12v/110v inverter. (the dash has been torn out so it's using the metal-reinforced parts of the car)
I've wanted to be able to throw a screen in the middle of the steering wheel (and eventually I hope to put like 4-5 of them horizontally within a new dash once I can find a fiberglass shop to do it) so I can finally rip out the instrument panel, this seems like a good solution to it.
From a quick reading of the pdf, it looks like this is just an API to draw simple shapes on the remote display, NOT do all the clever automatic smart compression stuff that their Windows driver does to provide additional monitors. Potentially useful, but nowhere near equivalent functionality to the Windows/Mac versions.
Is it any more then a small display gimmick ?
Maybe, but now that these screens seem to get linux support you can also do some pretty cool stuff with them. Get a really small ARM board like a Gumstix Overo or Beagleboard and you can make a pretty cool computer out of it that acts as a digital picture frame, clock, micro webserver, RSS reader, whatever you can think of.
I've actually been looking for a small USB screen that works with Linux for ages, so this is pretty cool news. Maybe now I can put my ARM board to use as a wireless DPF annex information display :-)
..for several reasons:
- they left out the compression
- they have deliberately obfuscated the init sequences (haha, big deal, see below)
- and they didn't put in anything beyond the stuff which we already
reverse-engineered in January (see http://floe.butterbrot.org/displaylink/ ).
Floe
I don't know what level this works in, but a decade ago we were running six X terminals with around a 1024x768[1] displays over a single, shared, 10Mb/s network. USB 1.0 gives this much bandwidth and USB 2 gives over an order of magnitude more. If you are streaming commands like 'draw line' and 'composite texture' then USB 2 provides far more than enough bandwidth. It's also enough to stream decent quality compressed video, so if the CPU can encode the video streams and the USB device can decode them you should be able to do full-motion video too.
It all depends on how the driver is written. If it looks like a dumb framebuffer thne you will need a lot more bandwidth than if it looks like a complex GPU. As a simple example, consider how text is rendered in modern X11 (and on OS X, and I think on Vista). The glyhps for the font are sent to the display, pushed into texture memory on the GPU, and then drawing them is a single command to composite the texture onto the framebuffer at a specific offset. This means that drawing an antialiased character only requires a few bytes of data to be sent to the display. The same is true for drawing common user interface elements; the images used to draw them will be cached in texture memory. Unless you are doing 3D work, you are using a lot more bandwidth between your GPU and monitor than you are between your CPU and GPU.
[1] I can't remember exactly what it was; some weird Sun single-scan monitors with a resolution I've not seen anywhere else.
I am TheRaven on Soylent News