hdmi

93 Articles

VGA In Memoriam

January 29, 2016 by 118 Comments

The reports of the death of the VGA connector are greatly exaggerated. Rumors of the demise of the VGA connector has been going around for a decade now, but VGA has been remarkably resiliant in the face of its impending doom; this post was written on a nine-month old laptop connected to an external monitor through the very familiar thick cable with two blue ends. VGA is a port that can still be found on the back of millions of TVs and monitors that will be shipped this year.

This year is, however, the year that VGA finally dies. After 30 years, after being depreciated by several technologies, and after it became easy to put a VGA output on everything from an eight-pin microcontroller to a Raspberry Pi, VGA has died. It’s not supported by the latest Intel chips, and it’s hard to find a motherboard with the very familiar VGA connector.

Continue reading “VGA In Memoriam” →

Video Standards Are More Than Video Signals

November 19, 2015 by 78 Comments

The number of hours we spend staring at screens is probably best unknown, but how about the technology that makes up the video on the screen? We’ve all seen a reel-to-reel projector on TV or in a movie or maybe you’re old enough to have owned one, surely some of you still have one tucked away real nice. Whether you had the pleasure of operating a projector or just watched it happen in the movies the concept is pretty straight forward. A long piece of film which contains many individual frames pass in front of a high intensity lamp while the shutter hides the film movement from our eyes and our brain draws in the imaginary motion from frame to frame. Staring at a Blu-ray player won’t offer the same intuition, while we won’t get into what must the painful detail of decoding video from a Blu-ray Disc we will look into a few video standards, and how we hack them.

Continue reading “Video Standards Are More Than Video Signals” →

Digging HDMI Out Of UDP Packets

November 4, 2015 by 24 Comments

[Danman] was looking for a way to get the HDMI output from a camera to a PC so it could be streamed over the Internet. This is a task usually done with HDMI capture cards, either PCI or even more expensive USB 3.0 HDMI capture boxes. In his searches, [danman] sumbled across an HDMI extender that transmitted HDMI signals over standard Ethernet. Surely there must be a way to capture this data and turn it back.

The extender boxes [danman] found at everyone’s favorite chinese reseller were simple – just an Ethernet port, HDMI jack, and a power connector – and cheap – just $70 USD. After connecting the two boxes to his network and setting up his camera, [danman] listened in to the packets being set with Wireshark. The basic protocol was easy enough to grok, but thanks to the Chinese engineers and an IP header that was the wrong length, [danman] had to listen to the raw socket.

Once everything was figured out, [danman] was able to recover raw frames from the HDMI extenders, recover the audio, and stream everything to his PC with VLC. All the code is available, and if you’re looking for a way to stream HDMI to multiple locations on a network, you won’t find a better solution that’s this cheap.

Hackaday Prize Semifinalist: An Open Smartphone

September 13, 2015 by 22 Comments

One of the biggest trends in DIY electronics, both now and fifty years ago, is creating at home what is usually made in a factory. Fifty years ago, this meant radios and amplifiers. Today, this means smartphones. It used to be the case that you could pull out a Heathkit catalog and find kits for every electronic gadget imaginable. There are no kits for DIY smartphones.

For [Gerard]’s entry for The Hackaday Prize, he’s tapping into the spirit of the decades-old DIY movement and building his own cell phone. He’s calling it the libresmartphone, and it’s able to make calls and send emails, just like any other portable, pocketable computer.

The libresmartphone is built around a Raspberry Pi, with a large battery, HDMI display with touchscreen, and a GSM and GPS module rounding out the build. He’s also rolling his own software to make calls, read SMS, and take a peek into some of the phone’s hardware, like the charge state of the battery.

[Gerard]’s libresmartphone is one of the purest examples of modern DIY electronics you’ll find; it’s not about building something from a kit, but instead building something that’s needed out of the parts he has on hand. That’s the purest example of the DIY movement, and a great entry to this year’s Hackaday Prize.

The 2015 Hackaday Prize is sponsored by:

DEF CON: HDMI CEC Fuzzing

August 9, 2015 by 10 Comments

HDMI is implemented on just about every piece of sufficiently advanced consumer electronics. You can find it in low-end cellphones, and a single board Linux computer without HDMI is considered crippled. There’s some interesting stuff lurking around in the HDMI spec, and at DEF CON, [Joshua Smith] laid the Consumer Electronics Control (CEC) part of HDMI out on the line, and exposed a few vulnerabilities in this protocol that’s in everything with an HDMI port.

CEC is designed to control multiple devices over an HDMI connection; it allows your TV to be controlled from your set top box, your DVD player from your TV, and passing text from one device to another for an On Screen Display. It’s a 1-wire bidirectional bus with 500bits/second of bandwidth. There are a few open source implementations like libCEC, Android HDMI-CEC, and even an Arduino implementation. The circuit to interface a microcontroller with the single CEC pin is very simple – just a handful of jellybean parts.

[Joshua]’s work is based off a talk by [Andy Davis] from Blackhat 2012 (PDF), but greatly expands on this work. After looking at a ton of devices, [Joshua] was able to find some very cool vulnerabilities in a specific Panasonic TV and a Samsung Blu-ray player.

A certain CEC command directed towards the Panasonic TV sent a command to upload new firmware from an SD card. This is somewhat odd, as you would think firmware would be automagically downloaded from an SD card, just like thousands of other consumer electronics devices. For the Samsung Blu-Ray player, a few memcpy() calls were found to be accessed by CEC commands, but they’re not easily exploitable yet.

As far as vulnerabilities go, [Joshua] has a few ideas. Game consoles and BluRay players are ubiquitous, and the holy grail – setting up a network connection over HDMI Ethernet Channel (HEC) – are the keys to the castle in a device no one  would ever think of taking a close look at.

Future work includes a refactor of the current code, and digging into more devices. There are millions of CEC-capable devices out on the market right now, and the CEC commands themselves are not standardized. The only way for HDMI CEC to be a reliable tool is to figure out commands for these devices. It’s a lot of work, but makes for a great call to action to get more people investigating this very interesting and versatile protocol.

Hackaday Prize Entry: HOMER, A 2D GPU For Microcontrollers

June 19, 2015 by 37 Comments

Just about the hardest thing you’ll ever do with a microcontroller is video. The timing must be precise, and even low-resolution video requires relatively large amounts of memory, something microcontrollers don’t generally have a lot of. HDMI? That’s getting into microcontroller wizard territory.

Despite these limitations, [monnoliv] is working on a GPU for microcontrollers. It outputs 1280×720 over HDMI, has a 24 bit palette, and 2D hardware acceleration.

It’s a very interesting project; usually, if you want graphics and a display in a project, you’re looking at a Linux system, and all the binary blobs and closed source drivers that come with that. [monnoliv]’s HOMER video card doesn’t need Linux, and it doesn’t need a very high-powered microcontroller. It’s just a simple SPI device with a bunch of memory and an FPGA that turns the most minimal microcontroller into a machine that can output full HD graphics.

This isn’t the only open source graphics card for microcontrollers in the Hackaday Prize; just a few days ago, we saw VGAtonic, another SPI-controlled video card for microcontrollers, this time outputting VGA instead of HDMI. Both are excellent projects, and if either makes it into production, they’ll both be cheap: under $100 for both of them. Just the thing if you want to play around with high-resolution video without resorting to Linux.

The 2015 Hackaday Prize is sponsored by:

HDMI Splitter Is Also A Decrypter

March 12, 2015 by 48 Comments

It warms our hearts when the community gets together. [esar] needed to get a decrypted HDMI stream for his home theater system. A tip-off in the comments and a ton of good old-fashioned hacking resulted in a HDMI splitter converted into a full-featured HDMI decrypter. Here’s the story.

His amazing custom Ambilight clone got profiled here, and someone asked him in the comments if it worked when High-bandwidth Digital Content Protection (HDCP) is on. [esar] lamented that it didn’t. Hackaday readers to the rescue. [Alan Hightower] and [RoyTheReaper] pointed [esar] to the fact that HDMI splitters need to decrypt and re-encrypt the signal to pass it on, and pointed him to a trick to knock out the on-board microcontroller. [esar] took off from there.

Unfortunately, taking the micro out of the picture messed with a lot of other HDMI functionality. So [esar] started digging in the datasheets for the HDMI splitter chip, looking for registers relevant to the re-encryption. If he could get in between the microcontroller and the splitter chip on the I2C bus and disable the re-encryption, he’d be set.

If you’re at all interested in I2C hacking or abusing HDMI splitters, you need to read his post because he details all of the tribulations and triumphs. He first tries just brute-forcing the I2C by overwriting a 1 bit with a 0. This (correctly) signals the micro that there’s been a conflict on the bus, so it re-sends the command again. Dead end.

He then found another signal that the receiver could use say that it wasn’t decrypting. He tried sending this continuously to the splitter so that it would stop encrypting. That worked, but only for one channel, some of the time. It turns out that his code was taking too long in his bit-banged I2C code. He fixes this up and all is well? Well, 90% of the way there.

To hammer down the last 10% of the functionality, [esar] buys a couple more splitters, experiments around with another splitter chipset that works with 3D, and solders some more wires to enable the Audio Return Channel. And after a ton of well-documented hard work, he wins in the end.