DisplayLink Releases LGPL USB Graphics Code 61
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?"
More the merry-er'er...er. (Score:5, Interesting)
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.
Re:max resolution? (Score:3, Interesting)
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.
Re:More the merry-er'er...er. (Score:2, Interesting)
Maybe they're starting to understand that most Linux users are just the type of people who like buying gadgets.
VERY glad this came along... (Score:2, Interesting)
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.
Re:max resolution? (Score:3, Interesting)
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 :-)
Re:"coming" (Score:3, Interesting)
This is big, because the eVGA UV Plus USB videocards are powered by this company's chips, and those cards can sometimes be found for as little as $20.
They are now (in theory) Windows, OSX, and Linux compatible.
This could potentially be a very cheap way to add more monitors to a setup, regardless of OS, for use in mostly static tasks like programming, spreadsheets, browsing websites, etc.
Re:max resolution? (Score:3, Interesting)
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.