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.
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.
Does that mean that USB docking stations are now supported?
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.
..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
Anyone have an Idea about what are system requirements?
They could have done this a few years ago before the push to HD. Now I think what you'd want to do is make a USB 3 dongle that could output HD video and audio over HDMI.
USB 3 is just around the bend with up to ~400MBPS (yes bytes) throughput. Still limited to 5v and .15A though. A lot of things that right now need a couple of PCIe lanes and an internal card are going to be very doable over USB on new computers come this time next year.
"The Adobe Updater must update itself before it can check for updates. Would you like to update the Adobe Updater now?"
IEEE1394c at S3200 or 3200Mbps using the same wiring as 9-pin IEEE1394b S800 cables, is going to be have more throughput, carry more power, and have less CPU load than USB3 at 4.8Gbs, USB3's actual rated speed. The new cable requirements applicable to USB3 also makes USB3 cables use essentially the same type of cable as IEEE1394c, negating any sort of benefit with respect to cost that USB 2.0 has. Cost refers to the cost of silicon on the device, the cost of routing the traces on a PCB, as well as the cost of the cable. I'm hoping for IEE1934c next year, but lets see if Intel can screw the market over with USB3 like it did with USB2.
Impersonating Tycho from Penny Arcade since before there was a PA.
Why not get a Chumby?
... and they already addresses all of those concerns on the first post to their mailing list.
They could have done this a few years ago before the push to HD. Now I think what you'd want to do is make a USB 3 dongle that could output HD video and audio over HDMI.
As I said in another post, it depends on how clever the drivers are. If you have HD video, you typically have it in H.264 or MPEG-2 formats, and most GPUs can decode these in hardware. If you're using the operating system's interfaces for this then the software is going to be pushing the raw compressed video stream to the driver, and the driver can just push it over the bus.
I am TheRaven on Soylent News
I've always wondered why nobody ever stepped up and this, innexpensively.
Look at TI's DaVinci lineup. It's supposed to be small enough to be used in digital cameras (I've only seen it in the OSD 2.0 preview units) and sips power, while being fast enough to encode 720p60 h.264 at real-time. I think there's a beefier DaVinci that can do 1080p30 h.264. (and some devices like Leadtek's Cell card can do it faster than real time at 1080p.)
The major problem with them, other than availability, is cost. Seriously, I'm not going to spend 300$ on a Cell card that makes no mention of an OS other than "Windows XP/Vista". I'm not going to blow 1000$ on a DSP/CPU combo that is supposed to sell for sub-10$ in bulk. And it needs to be able to transcode video using FFMpeg, and occupy a PCIEx1 or PCI slot, or heck USB or FireWire.
HD PVR-1212 http://www.hauppauge.com/site/products/data_hdpvr.html
http://www.mythtv.org/wiki/Hauppauge_HD-PVR
In GOD we trust, all others we monitor.
pl-2303 is very supported. FutureDial cables for cell phones typically use them.