 OK, CEC, a status update. For those who don't know, CEC stands for consumer electronics control. It's a pin on the HDMI connector. And it is the thing that makes things work like you put a disk in a Blu-ray player, you close it, and automatically the AV receiver goes on, the TV goes on, and you start playing. It's probably the slowest bus in the kernel subsystem, since it's about 40 bytes per second, 40 or 40 bytes, not kilobytes, just bytes. It's faster to send messages to the Voyager 2 space probe than it is to this TV from one meter from your system. Essentially, it's kind of unexpected that I'm giving this talk because there was a cancellation, and I was asked, can you do something? So of course I can. Three years ago, I actually did my first CEC presentation at FOSSTEM as well. At that moment, it was not just in the kernel. It was version 12 of the patch series, and it took another seven versions before it finally got in about half a year later. So this is kind of a nice bookend, sort of what happened in the past three years. So as I said, there's a little framework inside the kernel. It takes most of the basics of CEC out of, usually what happened in the past, they had custom APIs, and most of the effort was in user space. And the kernel didn't do anything, almost nothing, just transmitting and receiving. It was all it did. But it's actually fairly complex, some negotiation parts. You also want to interface with the display processing, since you need to know when a display gets connected, you need to know when it gets disconnected. So it's actually, I wanted to have a kernel module for this, and it's been working out very well. So the top, we're supporting a whole bunch of HDMI transmitters, DWHMI, that's Synopsys IP that's actually used in quite a few embedded systems. So it's one driver, but it's used in a lot more places. Yeah, I'm not going to repeat that. Most interesting is probably Raspberry Pi, since that is the easiest DevKit to get. So we support CEC there. Interesting, other transmitter in quotes is DisplayPort. So DisplayPort, they have an extension, a protocol, called CEC tunneling over aux. It's part of the DisplayPort spec. And so, well, I'm CEC maintainer, so I thought let's try to implement that. So it's now actually possible to use, if you have to write adapter, DisplayPort to HDMI adapter to use this protocol, and you can control CEC over DisplayPort to the HDMI. We support it on Intel, Nouveau, and AMD GPU. So we have the insane situation that if you buy a graphics card or you have a laptop with a GPU inside, then CEC is supported on the DisplayPort outputs, but not on the HDMI outputs. I have no idea why GPU graphics cards vendors do not add CEC support for it. I know, in fact, that NVIDIA, they sell the Tegra and they have CEC there. Almost all embedded systems, as you see, they all have CEC support, but not these graphic cards. If anybody knows, let me know, because I have no clue. And it's really... Don't need to connect to a TV, is there a device? So anyway, but if you have the right adapter, then you can do it. This is actually the right adapter. And just for fun, let me just check if you see the emulator, I'll talk about that a little bit later. Yes? So let's say that I'm a playback device. Ah, I doesn't see anything. Ah, of course, so this is connected. So I now see a CEC adapter, but on the other side, CEC is not supported. So it only works if everybody supports it. If you... So another thing I'm still researching, this works for a simple adapter. If you have an MSD hub in between, then I cannot get it to work. And I am fairly certain it's actually impossible due to limitations in the protocol. Nobody ever thought about using this with an MSD hub. I still want to research a bit more. But so if you have a docking station that's most likely using an MSD hub, then this won't work. You also need to be very careful when you buy adapters. I have a status document. I'll have a link at the end where I have a list of known good working adapters. Because a lot of them, they say they support CEC, but they haven't hooked up the CEC pin. So from the point of view of a laptop, you think, hey, I have CEC. And it is CEC. The firmware doesn't accept. They didn't hook up the pin. And it's obviously, for me, no way to detect that. Visual receivers that support it, USB dongles. So they allow you to connect an HDMI cable. And they're sitting in between the TV and your PC. And you can control CEC using USB. Pulse 8 is very common, a very well-known that's supported. There is a US company, a range auto tech, that has one as well that's supported. The Vivid driver that does video capture emulation, they also emulates an HDMI connector. So I also had to emulate CEC in that case. So that's supported as well. That allows you to test this on a simple laptop with that driver. CEC GPIO, that's an interesting driver. It allows you to hook up the CEC pin to GPIO. And you can fully control it. So it basically has the bit level, bit banging inside that driver. It was originally developed for an old winner, the low end old winner, the A10. They don't have a full CEC hardware support. They just have basically a GPIO pin. But it is extremely useful on the Raspberry Pi, because you can use this to do CEC debugging. Come back to that in a moment. In progress, the Stony driver that I haven't upstreamed yet, that's for almost five. I had it almost working, except for a crash in an interrupt handler. And then they started completely reworking a display subsystem. And I've been holding up until, holding off until that's stable. And I'll give it another try. Most CEC drivers are pretty easy to make. Few days of work is a single pin. How hard can it be? It can be very hard for OMAP, because they made a complete mess of it with several layers of designs and interrupts coming from all sorts of different places. And it's by far the hardest implementation, the hardest hardware that they had to support. It's a strange design, but that's an exception, luckily. Utilities that I worked on. So to give a little bit of background, I worked for Cisco Systems Norway. We do video conferencing equipment. We make that for Cisco. We need CEC in order to do things like all your return channel, where it's a requirement to turn off TVs, turn off displays, turn them on. And we are doing more and more with CEC. So this is the reason why I started working on the framework. And the other part of that is making utilities to access it. CEC-CTL is sort of a Swiss Army Knife. It allows you to configure your adapter and see what is on the bus and send commands, receive commands, and monitor commands to do whatever you want. More interesting is CEC Compliance. It's a compliance test. Part of that is testing your own driver implementation. Much more interesting is testing another device. So you connect your laptop to the display. How well does that display conform to the CEC standard? Usually pretty bad, unfortunately. But I wanted to have a completely open source utility that anybody can use and test with. That is cheap. So you get a Raspberry Pi. You install it. And you connect it to your TV. Or you get the right adapter. And you can run this. This is running 24-7 on our test systems. We use this for continuous integration. This is not a toy project. This is really used for our systems. At the moment, it's testing every command in the CEC standard. But only does in-depth testing for those features that are important to us. It's an open-followed-year project to extend all the features. Like, we don't need a tuner. So we just test what is there. But we do very basic tests. But it would be fun to turn that compliance part of the compliance test for that into a full-featured test suite. If anybody is interested, let me know. Contact me. As I said, all you need is a Raspberry Pi and a TV with CEC support. CEC follower, it allows you to basically emulate the device that you are. So it's like, in this case, I have a laptop. I can emulate it as a playback device. So you just run it. And it will, from the remote device, it will look as a standard playback device. CEC debugging. So that's very interesting in practice if you work with weird devices that don't quite adhere to the standard. So most situations, CEC CTL minus M is sufficient. That monitors all the transmits that you do, everything you receive, and everything that was broadcast. It also, if the hardware supports this, can see the messages between two other devices. So not to you directly, but from one device to another device. They all go through the same bus. So if the hardware supports bus sniffing, then you can see those as well. But to come back to the CEC GPIO driver, you can also connect the CEC pin to pin bus arbitration errors. You can generate random pulses on the bus, see how things react. And for about 80 bucks, you have a fully featured CEC debugger. We have used this as well for debugging strange situations. I mentioned this already. So really, if you're interested in this, just let me know. I think it's kind of fun to work on this. The CEC standard, by the way, is part of the HDMI specification. The HDMI 1.3 is freely available. 1.4, use Google, let me put it that way. 2.0 or 2.1, they're not available. But the differences basically between 1.3 gives you about 90% of everything you need to know. What they did in later versions was mostly tighten the thumb screws a bit to vendors to ensure a bit better compliance. And a few new commands that we've done most of the testing for that already with the most of the tests. So actually, you have pretty much everything you need in order to work on it if you're interested. So basically, after three years, I'm actually very pleased. So it's working well. We support a wide range of hardware. It's all pretty simple to deal with from an application perspective as well. Again, we use it also in our own products. So it's not some theoretical exercise. No, this is used every day. Let me see what is most of most interest. CC status document. I keep that up to date with the latest list of drivers that are supported with any details how you make a CC debugger. It goes into detail which adapters will work. Display Portrait, my adapters will work. So look it up. I also have a Raspberry Pi image for a microSD card that you can load some microSD, put it in your Raspberry Pi, and you basically have a little Debian system that comes with all the codes and utilities in order to test this. It has the CC GPIO support as well. So you can extend it with a brand board as I showed in the picture and do the low-level CC debugging. This is a pitch for anyone looking for media, volunteer projects. A lot of these deal with virtual drivers. So all you need is a laptop or a PC. You don't need hardware. This also includes the CEC things that I was talking about. For those, you need CEC-capable hardware, so you need a little bit more. And you can always email me. Questions? So I just started playing with CEC Patrol last week. Ah, a new user, Fresh. Yes. The UI commands. Is that the list maintained in C4O U-Pills? Or is that derived from a spec? So question is, CEC-CTL has options to send commands. Those commands, CEC commands, those commands are all derived from a spec. In fact, if you look at the codes for CEC-CTL, you see that a lot of the code is generated from the CEC kernel header, which contains all the commands and all the options and arguments. So a lot of the code is just generated for you based on that. The specific issue was that Power Off doesn't work. Standby makes Power Off. But that's probably a compliance issue with the specific TV. So Power Off doesn't work. Standby tells the TV to go to turn off. And Image View On makes it wake up. But there is a very, so CEC depends on the EDID. Because the EDID contains a physical address that uniquely identifies your adapter. The EDID only gets, if the whole plug detect pin is high, because that tells the transmitter that the display has a valid EDID. A problem is that you increasingly see is that when a display goes into Standby, they pull down the hot plug detect. So at that moment, you see nothing. You're not aware that there is a display at all. But they still keep CEC working. So you can still send Image View On, even though there is no EDID to the display to wake it up. The reason behind that is increasing concerns, increasing restrictions on power usage by EU regulations and other countries. But EU is one of the main drivers for that. So when the displays are Standby, they want to have the minimum amount of power that they use. So sending a Vive Volt on a hot plug detect is then one of the things they try to save on. But the problem there is that not all CEC implementations can handle that. So specifically, display port CEC tunneling, if there is no EDID, if there's no hot plug detect, this disappears completely. It doesn't get any power. It's just done. So you can never wake up a display like that with an adapter like this. We also know that some Odroid development boards, they hook up the hot plug detect to the level shifter. So when hot plug detect goes away, then the level shifter is gone as well. And you never, it's basically disconnected. So not everybody knew about this. It's poorly stated in the specification. It's sort of very vague language that you can, in certain circumstances, do this. But I think it will be an increasing problem going forward. So if you make something with CEC, make sure you can deal with this situation. No more questions? I'm interested in testing the other side, the driver, basically. There's no regression. With Google's community, you can actually send CEC events to the driver and then go into the user test. And this is something that could be tested automatically. I missed the first part of your question. So my question is, aren't you interested in testing the driver? Because the driver, you know, it could break or something. So are you interested in testing the driver? Well, CEC compliance tests the driver as well. Yes, it goes one way, but it doesn't check that Evan's coming from the CD are actually working. And you can use the Google Chameleon. So it depends on how you run CEC compliance. So CEC compliance can also be run in such a way that you can also test commands coming in. In fact, and I will talk about it in my talk at 5 PM, I believe, when I also go into testing. So CEC compliance will also be part of regression testing. We're working on that. And it most definitely can be used in the CI environment when you have real hardware, because it was actually written with that in mind. It's really meant to test hardware. That's why we're using it internally. We test our products. We make sure that there are no regressions with some new commits that certainly break CEC. No more questions? Yeah, I was wondering if you could say that you need the EDID, because that's the way you can be understood. How does that work? If the whole project is done, then you can't create the EDID or you can't. You can't get the EDID. So what you do in that case, you send a message with a standardized message that does not depend on the physical address that you derive from the EDID. It's really weird. We've worked with some displays like that. And it's often poorly implemented. But the very first thing that you have to do when you turn on your own device is to send that message. You have no idea if anyone will respond. It's just you sort of shouting into the air and perhaps someone responds, perhaps not. If it's one of those displays, they usually will come up in a few seconds. Then suddenly you start receiving messages and EDID comes up and everything is fine. But you also have to do it as the very first message, because there are some implementations that we've seen that if you send another message first, then the second message, the image you want, disappears. Sort of ignored. So every five seconds, it seems to be an internal state machine that resets every five seconds, as long as this is the first message, then it works. And it's scary. OK, thank you very much.