 Laten we beginnen. Mijn naam is Hans Verkijl. Ik werk voor Cisco Systems Norway op videoconferensing equipment en ik ben een van de ondernemers voor de media subsystem van de kernel. Ik doe veel van het HDMI receiver en transmitter werk en een deel van de HDMI standard is een optional extension called CEC consumer electronics control. Begin met kernel 4.8, er is een nieuw framework om dat te handelen. En deze presentatie is over wat het is, waarom wil je het en hoe is het geïnplamend. Maar dat is allemaal heel moeilijk. Laten we naar autospace, de final frontier, de Pluto probe Nieuw Horizont. Zoals vorig jaar is het gewoon een tad over 5,5 miljoen kilometer van Berlin. En het is nog steeds oplodigd naar planet Earth, alle informatie en foto's die het vond van Pluto. En het doet dat op een bitrate van 1 tot 2 kilometer per seconde. Wat is op dat deel een enorme feed, dat is reale ingeëering. Dus alles wat ik vertel, dat is niets veranderd dan dat. Vooral als je kijkt naar CEC, die op 1 meter veranderd is, is het voor 100 bits per seconde. Dus dit is echt relaxe ingeëering. Je kunt de hele tijd in de wereld hebben. En hetzelfde, dit is voor HDMI, dus met een paar pinnen verder op, je krijgt data die er rond dat 600 megahertz is. Dus dit is het oude stijl. Dus wat is het? Consumerelectronisch controle. En het was, het is eigenlijk een pin op het HDMI-connector. En de devices mogen of mogen niet supporten. Het is optisch. En het loopt verschillende HDMI-consumerelectronisch, zoals DVD-plejers, tv's, audio's, AV-receivers, om te communiceren met één ander. Dus dat als je in een DVD, in een DVD-plej, de tv gaat automatisch op. En de AV-receiver gaat op en alles is opgezet correct. Het is based op de oude AV-link cardstandard. Je kan het verhaal rememberen, die echt grote connectoren. En het komt eigenlijk vanaf de tijd, toen je had je video recorder en je tv. En je wilde hetzelfde doen. Je loopt in je tape en automatisch de tv gaat op. Zoals ik kan zeggen, de fysieke protocol, elektrische protocol is precies dezelfde. De hoge niveau protocol lijkt te zijn heel anders. Je hebt eigenlijk een 1-byte header, en dan tot 15 bytes van payload. En remember, dit is 400 bits per seconde. Dus dat is about 36 bytes per seconde. Dus je hebt er echt niet veel van opgezet. Dit kan beïnpleerd worden in HDMI-receivers, HDMI-transmitters. En je hebt ook, of heb je het? Ja. USB donkers zoals dit. Dit connecteert naar je PC. Je hebt de, let me eens kijken, de PC gaat in op deze kant, de tv gaat in op deze kant, en je kunt de CEC controleren door de USB op je PC. Dit is gebruikt veel wanneer mensen want te hoeken op daar, een streaming PC, een setup box met een tv. En de graphics card doesn't support CEC. Dat is waar het is typisch gebruikt. Deze dingen zijn ongeveer 35 dollar of euro, iets in die onderzoek. Dus ze zijn te schijn, en ze zijn heel populair. De manier waar het werkt, dus elke CEC-devijs heeft een fysieke adres. En de fysieke adres is een 2-byte nummer met 4 nibbles. En iedere nibble is eigenlijk een topologie-identifier. Op de top niveau heb je de tv, dat is altijd 0, 0, 0. Als de tv heeft verschillende inputten, dan zal er 1, 0, 0, 0, 2, 0, 0, 3, 0, 0, etc. En dan een niveau onder dat, dan krijg je 1, 2, 0, 0, 0, etc. Dus je hebt een limitere nummer van devices, natuurlijk, omdat van dit. Invalid, dat betekent dat er geen CEC is, dan is het ffff. Als je je PC connectt, bijvoorbeeld op een tv, dan zal je de EDID uitregen. En de EDID zal je de fysieke adres dat is aansloten voor je. Dus dat is waar je dat informatie krijgt. Je maakt dat niet op jezelf, maar als je een tv bent, dan is het hardcoded. Je hebt ook een logische adres. De logische adres is gebruikt wanneer je een message sendt, omdat je een initiator hebt, of een source, en je hebt een destinatie, waarom je het ook sendt. En elke CEC-devij heeft het eigen logische adres, dat betekent dat in de praktijk je meer dan 15 CEC-devijs kan hebben. Of je meer kan hebben, maar dat wordt heel complex. Je hebt een erg limitele functie, in dat geval. Het is niet een adres, zoals je weet, maar als een IP-adres. Het is echt meer een nickname, waarin de nummer eigenlijk identifie wat type van device je bent. Dit is een geweldig voorbeeld van een commissie product. Ze begonnen uit met één tv, of fair enough, en dan, oh, we moeten twee recording-devijs, één tuner, een playback-devij, in het audio-system. Ja, ik heb meer tuners, dus laten we een paar meer gaan. En iemand kwam op, oh, ik heb een playback-devij, en op een gegeven moment, rond de ID12, ze gaven het en zeiden, ik heb twee reserve fields. Laten we ze terugkomen. Je kunt het voor alles gebruiken. Dit soort illustraties, de fact dat het een protocol is dat is fuzzie, dat is evolve, dat is een commissie-product, dat is niet properly designed. En dat is ook een van de grote problemen die we hebben, het CEC, het is een mess. Dus, topologie-example, je hebt de tv, dat is altijd een fixe, dat is altijd 0. En dan kun je hebben DVD-players, connecten, je kan recorden-devijs, audio-video-receivers, HDMI switches, dit is natuurlijk een extreem-example. Wat je typisch hebt in de praktijk, je hebt de tv, je hebt een audio-video-receiver voor je huis-cinema-system, en dan een DVD-blu-ray-player, een zetelboek, misschien connecten, en dat is het, dat is wat de meeste mensen hebben. God weet waarom, maar dit is, de enige die eigenlijk dit proberen, het CEC, het Hitachi, iedereen elke keer maakt zijn eigen naam. Ik weet niet waarom. Het is een complete mystery voor mij, maar als je nog een net ziet, op de Samsung TV, dat is echt CEC. Ja, wat kan ik zeggen? Waarom wil je het implementeren? Het heeft een aantal mooie features, een van die is dat, het is een bi-directionale manier om te communiceren met ontdekking en communiceren met andere devices. Als je fijn ideeën had om het te gebruiken om de firmware te uploaden, vergeet het, 400 bits per seconde, remember that. Je, ik bedoel, het is sneller om de firmware op de nieuwe horizonsprobe, dan het is om dat voor je tv te maken, op de CEC. Dus, het is erg limit. Alle deze pakken, ze tenden te zijn heel klein. En, het is meer of meer de minimum die je nodig hebt om deze equipmenten te werken samen en te gebruiken in wat de customer expect. Dus, zoals ik heb gezegd, je gaat op de DVD player, je wilt automatisch de rest van het systeem en het reverse in het stand-by gaan. Dus, de meeste van deze features en alle deze message's, zijn gegroepd op features voor verschillende producten, types en een product kan implementeren met verschillende features, wat er relevant is voor ze. Dus, als je een touch-play hebt, die automatisch start te spelen, gaan op stand-by, start recording, timer programming, play fast forward control, controlling tuners, de menu, remote control pass through. Dat is een van de meest commonly gebruikt. Je hebt één single remote en je sendt het, say, de tv. En de tv passed op volumum control tot de AV receiver. En dat is dan de een die het handelt. System audio control, dat is voor AV receivers. I'm not going through everything. Device power status, that's a fairly important one, that is it on and off, basically. Routing is relevant for HDMI switches, so you can choose the right port, so the right product is connected to the right, the right input is connected to the right output. System information is more generic stuff. Dynamic audio lip sync is very useful to get audio latencies from the device. I actually don't know why that isn't used more often. It's fairly rare, but anyone who ever hooked up a TV to your audio-video system, they often have to set up the audio latency in the AV receiver, because it takes time to process, if there's some extra processing going on for the video in the TV, the audio can be delayed if the audio goes straight to the AV receiver. And this feature was added, so you can just create the TV, give me the audio latency or video latency. It's actually quite rare. I have yet to see TVs implementing this. I don't know why, because it's an enormously useful feature. You have vendor-specific commands. This is the Achilles heel of CEC. Problem is, most vendors, they make their own vendor commands, so they work with their own products. But if you use a Sony player with a Samsung TV, it may not quite work as well as if you use both Samsung products. It completely defeats the whole purpose of CEC, which is interoperability. But things are getting better, because CEC is getting more popular. Most mid- and high-end products, they will all have it these days. At low-end, maybe, maybe not, you have to check, which is not that easy, because as I said, they never use CEC. They call it something else, so you have to know that. The Wikipedia page for CEC, they actually have a whole list of all these weird brand names. You can check there. Audio return channel, that is getting fairly popular. So normally you give video and audio to the device, but now you can get audio back as well. And that is controlled through CEC, the capability handling. You can also do ethernet. I will come back to that here a bit more. So nobody uses ethernet. It is available in CEC. So basically CEC is the configuration protocol. And then for ethernet over HDMI, they are using two pins to transport that. The protocol is horrible. Nobody is using it, because everyone either has wired ethernet or just a wifi chip. So I have yet to see a TV implementing this. I know of one AV receiver that is hideously expensive, that has it. But if there is no TV to connect it to, I'm not sure what the point is. What makes it even worse is when you use ethernet, you use two pins to transport ethernet, which is the utility pin, which is typically unused. And hotplug detect. Now anyone who knows hotplug detect, if you use that one, you can't signal, for example, that an EDID has changed. Because you would have to pull the hotplug down, but then you lose ethernet. So what they did is they added a CEC message to tell you whether hotplug goes up or not. It's a nightmare, and almost nobody uses it. Audio return channel is fairly common, and it's getting very popular. Actually you have two modes for audio return channel, one uses one pin, and I think pretty much everybody does that. And the other mode uses two pins, and then you run into the same problem with the hotplug detect, which is probably the reason why nobody uses that in practice. So the problems that you typically get when you work with CEC, first of all is optional, so you don't know if the other side implements it. But that is getting better and better. Most electronic devices, they do have it these days. There are several versions of CEC. 1.3 is still in use. 1.4 is the most common one. Very little difference between 1.3 and 1.4. 2.0, it's a much better standard because they tightened up a lot of the specs. So things that were fuzzy are now, well, let's say less fuzzy. But it is rarely used. I don't know why. It's really a lot better than the 1.4, that respect. It's a protocol that evolves. People added stuff whenever they needed it, and then it got standardized, and it's awfully slow. I have no idea when they added it to the HDMI standards, couldn't they have just clocked it up a bit? Would that be much more useful? That they just kept the old AV link standard for that. And the protocol has lots of custom requirements and custom limitations, things you can do only so often. They're mostly related to the fact that it is so slow. So you want to avoid unnecessary packets. So if you try to send something to a device en the device says, well, I don't support this message, then you're not supposed to send it again. So there are lots of special cases and it makes it a very difficult protocol to implement in software, to make the protocol stack. One reason for writing a kernel framework for this was that it allows you to have a single place where you can put not all, but most of these constraints. So how is it implemented? Actually I started on this about four years ago. So now within Cisco for video conferencing our products at that time they did use CEC, but very limited. Just basically being able to put a monitor or TV instance to stand by and power it up again. We had our own, like everybody else today, we had our own very simple CEC implementation en, well, I was a kernel developer, so that's not a good thing, of course. I decided to make a sort of a framework and I got about, at the time I thought I was 90% ready and then all the things happened and it basically was put in the fridge and it's laid dormant for two, two and a half years. Then Samsung picked it up. They wanted to use it for ActionOS 4 and Camille Debsky developed it further but then he left Samsung, so it was dormant again. But then we realized that we wanted to do a lot more with CEC, so it was a good opportunity to take it back and I started to develop it further with the goal of finally getting this into the kernel. And with 4.8 it is in the kernel, in staging. I'll talk a little bit more about that later, what is still to be done to get it out of staging. So one of the things that basically is a list of requirements that I had, because it's so slow, it is also highly asynchronous so you send a message and the reply can come back much later with lots of other messages in between. You don't want to have blocking weights, you don't want to wait for a second. It's not a good idea. Not in the kernel at least. You need to take care of those replies that are out of order so you want to be able to handle that gracefully in the framework. Where messages are handled, so things like for example a message that changes de hotplug detect state, that is something that needs to be handled in the kernel. Other things need to be in user space. Other things may depend on what you're building. So you need to have the ability to put things both in the kernel and into user space. You need to send and reparse messages both in the kernel and user space to having a single header that is accessible by both would be very useful. You need to support receivers, transmitters and these USB dongles so you have to take care of those different subsystems. And quite important is you really want to handle disconnect and connect scenarios gracefully. So if you disconnect you lose of course your physical address. If you reconnect you need to read the EDID and the physical address may have changed. You also lost your logical address after the disconnect and you need to reclaim it. And it may be different after the reconnect. If another device was connected in the meantime they may have claimed it so you need to get another one. It's really not something you want to do in user space. It's getting messy, you want the framework to do that for you so you don't have to think about it. The device node was easy, the name CEC. The driver developer can determine what level of control user space has. So if you want to do everything in kernel space, not recommended, but say you might want to do that then you can actually block user space from actually transmitting messages you want to keep everything inside. I will talk more about this is an extreme case we don't have anything like that. But you can also say I want to create remote control commands, go to a remote control device as well. There are a number of things that you can select what is allowed and what isn't. If you need to implement a driver, you just need to implement a number of low level adapter operations. Practical experience is until now that a new device takes about two days of work. They are really simple. There are some exceptions. Oma 4 was a lot more work, but there were lots of bugs elsewhere in the subsystem that took a long while for me to figure out. In general it's not very much work. The framework deals with all the details of the protocol, asynchronous stuff. It shields you from all that complexity. A lot of the core CEC messages are handled automatically by the framework. Someone gives you a new physical address. Some say some device comes up and it sends its physical address around. It will be automatically registered and things like that. There is support for monitoring CEC messages which is absolutely brilliant for debugging. It depends on the hardware support. It will always monitor messages that you transmit or that you receive. There is also the opportunity in hardware to monitor messages going from one device to another device, but not to you. If the hardware supports it, you can monitor that as well. The very nice thing, this dongle, can be put in that mode. You can put it in the middle of some setup and then use your PC to monitor what is going on over the CEC bus. Very useful for debugging. It was staged in 4.8. It was merged in staging in 4.8. The framework itself, you have one header and the header contains a user amount of static inline functions that can pass and create CEC messages. That is shared between kernel space and user space and that is everything for you. The structure, this is the main message structure. We have some timestamps, lengths of the payloads. You can set up a timeout because if you want to wait, how long you wait for a reply, for example. Sequence counter, some flags. This is the message itself. I will come back to this one later en dan een hele bunch of status and counters that help you with whether the message succeeded or not. Typical way to do this, you have this structure. You create a structure, you initialize it. This is the initiator, so who is sending it. This is where you go, who you send it to. And then you use this inline message to just fill in the whole payload. A typical static inline looks like this. It just fills in the message structure, sets up the length. It takes care of some boundary checking if that is necessary. And you have the reverse that takes the message and extracts the information from it. This is a really practical example. This is the message to get the CEC version. So it sets the length to 2, this is the command. And then the reply, this is a boolean, whether or not you want to wait for a reply. So one thing which you very often do is you send a message and you want to wait for the reply. If you set reply to true, then the reply field is filled in with the message that you expect back. And the framework will actually wait around until the time out. By default that's one second, because that's what the spec says. You need to get a reply within one second. Not that it's always one second in practice, but that's an automatter. And then the framework will just, you do the transmit and the framework will wait until the reply comes back or until the message is aborted. So the device can say I don't know this message, which would be really bad because everyone needs to support this. Or until the time out is reached. And then your transmit ends and you have the status information and you can see what you get back. This is very useful because you don't need to do all the asynchronous and out of order handling. We'll all be done by the framework. So you send this message and then the other side will then fill in the version, the right version. We'll send it back and you receive a CEC version command and you parse the version out of it. And then you know what the version is for that remote CEC device. When you write a new CEC adapter, it is basically this, this is all you need. So you make a number of operations. You need to have an adapter enabled to actually enable the hardware. This one is optional. Some devices have a special mode to enable monitor all, which means, as I said before, you can monitor messages between two different CEC devices that's not you yourself. They often come with warnings, they only use this for debugging, don't use this normally. So if that's the case, then you need to fill in this operation to actually explicitly enable this mode. I don't, they never tell you, they say that it's only for debugging, but they don't tell you what would go wrong if you always enable it. So better safe than sorry, so I made a separate operation. Logical address, so when you have claimed a new logical address, you don't need to fill it in the hardware. The transmit speaks for itself, transmit the message. This is optional, or there is a, in DebugFS, there is a status file that gives the current status of the adapter. And if you have low level information you want to add, then this operation will be called. And this is a high level callback. So when a message is received, your adapter can be called and you can process that message if you want. And you can say, okay, after processing it, you can either allow it to continue to use a space, or you can say, no, I've processed it, don't pass it on. And finally, there are two functions that you typically call from the interrupts routine. So when you transmit a message, you fill in the hardware and you say transmit it, when it's done you get an interrupt and you have to call transmit done with status information, did it succeed, what sort of error conditions are there. And the same when you receive a message, you just fill in a strict message and you pass it on to the framework. And that's all there is. And this is typically, as I said, about two days' work for reasonably sane hardware. The public API, again, is fairly simple. There is a capability, get capabilities. So what can you do with the adapter? Really the most important one is cup physical address. As I mentioned before, ideally, when you hook it up, the driver will automatically find the EDID and the physical address and set it automatically. There are cases where you cannot do this, most notably a dongle like this because you don't get EDID information. So it has to come from outside. Drivers that need that set this capability and then that means that the user space has to find the right EDID en physical address and set it up. Get set physical address, speaks for itself. This is the main power function, really. You call that. And that's what defines what sort of device you want to be. Do you want to be a tuner, a TV, a playback device? With CEC version, are you going to support 2.0 or 1.4? The default is 2.0. I see no point in default supporting an old version. You can put in defender ID, OSD name, a whole bunch of information that is fixed. So you set it, and it's all fixed, it's stored. And whenever you disconnect, then the CEC adapter will automatically be disabled and you reconnect and it finds a physical address and it will automatically reclaim logical addresses and set it up automatically again to the right device type. So you typically set this up once and you don't touch it again. Then you have get set mode. So what happens in user space? How do you typically implement this? You need to... There are two parts. One is that you try to control a remote device. The other is that you have to reply to messages that you receive. So they're in the CEC terminology. That's an initiator. You do something actively. The other is a follower where you just receive messages and you need to reply to them and take action. So if you implement it in an application, you want to... Depending on your specific use case, you may want to get exclusive access. That you're the only one who can initiate messages. Or the only one who can handle received messages. Or do you want to allow others to do it as well. So you have the mode where you can actually say, well, by default, you're just initiator. You don't have exclusive access. But you can make yourself an exclusive initiator. And then you're the only one who can send messages. And the same for follower. You can be a regular follower. Then you will receive messages. Or you can be exclusive. Then nobody else can receive messages. And then you have a special pass-through mode. As I mentioned by default, the core will handle... Or the framework will handle some core messages automatically. There are cases where you want to do that yourself. And then you put it in pass-through mode. And then except for a few documented messages where you always have to handle it in the core, they will just be passed on to you without any further processing. And you can also use it to put yourself into monitor mode. Receive and transmit. Speak for itself. DQ event that allows you to respond to... Well, basically it's disconnect and reconnect events. So you disconnect and then you get informed, okay, everything is gone. You reconnect and you get informed of your new physical and logical addresses. You can start everything up again. There are a number of utilities. This is actually... CEC is a complex protocol. So you want just making a framework is not enough. You really want to provide also a whole bunch of utilities that allow you to test things and have sort of a reference implementation. So we have three utilities and one test driver. CEC, anyone who knows the media subsystem, I've written a whole bunch of utilities for video for Linux and basically I modeled this after what I've done there. So you have a Swiss Army knife, CEC-CTL. You can send all messages, all the messages defined in the protocol you can send it with and you use it to configure the adapter to whatever, whether it's a TV or a playback, et cetera. And then there are two utilities that you can use for compliance testing. Kudos to my summer intern, Johan Fjeldfett, who did his work. So he... One of the things that we really wanted because the specification is so fuzzy. So the implementations are even fuzzier. Certainly ambiguous and non-standard. The weird thing, the HDMI standard actually has compliance tests. One of the first tests that they do is when you send a message that is not supported you need to get the feature board back. While pretty much all the implementations that I've tested, they don't do it. They just time out. Which means that if you want to discover whether someone supports something, you just send it and then you twiddle your thumbs for a second. Then it times out and then well, it's probably not supported. When it should have responded with a feature board. So I think nobody runs those tests. I don't know. I don't understand it. Anyway, the compliance test can be used to test a remote device. Or of course the other way around, your own implementation. It goes through all the features. It tries to see what is supported and what isn't. We do have coverage for all the features. But some of the features are very limited. We never use tuners. We just check if there are some tuner features support. We don't do any in-depth compliance tests. Patches are welcome. Things where we for our products are really interested in, that is done much better. We have a fairly complete test sequence there. But if you want to test, you also need a follower. So you need your own device need to reply to receive messages as if it was a playback device or a TV or whatever you try to emulate. So we made a reference implementation for a follower. So if you want to test something, you run your follower on your own system. And then you run CEC compliance to the remote system. And that way you can test how well that remote device is actually working, how well the implementation is. It's by no means complete, but at least it gives you a certain level of confidence that you otherwise would not have or you would have to buy very expensive equipment to try and test this. Finally, Vivid, this is an existing driver, a visual video. We use it for video for Linux to test, for example, an HDMI receiver without actually requiring you to have hardware for an HDMI receiver. It emulates it. So we add a support for CEC as well. So it emulates CEC adapter, including how slow it is. So it is still 400 bits per second, even though it's emulated. And you can use this to test your own application en it is very useful for testing your program without actually having the hardware. As I said, this framework is in staging. It is pretty complete. There are a few things, a few corner cases that I need to double check before it can go out of staging. I have patches for most of them. I just need some, say, two days of time to finish it. Probably the most thing that will take me the most time is to take a second look at error handling because the specification is fuzzy with respect to error handling. Actual implementations, hardware implementations are way fuzzier. There are some that just say error. There are some that actually give some more feedback what type of error it is. They say foo, without explaining what foo actually means. I would like to have a second look at this part, so that might change a little bit. Otherwise it will be unchanged, pretty much unchanged, just some corner cases to clean up. All those things to do, I have an OMAP4 implementation for the panel board, but needs to be cleaned up. Audio return channel, CDC, there may be some more kernel support necessary there, I'm not sure yet. Integrated with the media controller, so you can associate a video note with corresponding CEC note, that would be handy. And put more intelligence into the framework to handle all sorts of weird constraints that the standard has. I want to, so here are some resources. All the utilities, they are completely up to date, up to kernel 4.8, they are here. User space documentation, is in the document doc book, no longer doc book, but now Sphinx documentation in the kernel. The kernel API documentation, for some reason it doesn't turn up here, so I made my own copy, that's a book somewhere, and my email. But let me get a quick, so I have loaded the Vividriver, you can see it here. And there are two CEC notes, one is for the capture device, HDMI capture, one is for say that would be equivalent to a TV. The other is an output device, equivalent to say DVD player, and they are inside the driver, they are connected together. So, if you just run CEC CTL, it gives the information, it gives just some driver information, what is happening. Oh, it's already, okay, wait a moment. Let's make it clean slate. So, by default you can see, there are logical addresses that are assigned zero. Physical address is zero, zero, zero, so as I said, it's a capture device, so it's a TV, that's hard coded. Physical address for the outputs is one, zero, zero, zero, basically the first input port for the TV. And again, zero logical addresses, so nothing is, nobody told the CEC adapter what it is. Minus D1 by the way, so you can also write minus D slash dev slash CEC one, but I'm lazy, and I like to just provide the number of the device, which is much easier to do. A CEC device, let's make it a TV. Now it suddenly has a logical address, this is all filled in, it says, OSD name is TV, sort of the default that I gave it. It fills in various CEC types, primary devices, TV, logical address type is of the type, TV, well, all bunch of stuff. And the same you do for the playback device. Again, you have one logical address that is claimed, set up as a playback device. So one thing I want to do is to demonstrate vivid together with CEC compliance. So the help text for CEC compliance is basically you, again, the device, the remote device that you want to test. This is test adapter, there's more internal tests that actually test your own adapter. So try as all the IOCTL, see if nothing is broken. These are all the external tests. You also have an interactive mode. A lot of these tests require, say, power down the TV. Unfortunately you don't get good status information back. Yes, there is a power status command, but frankly implementations suck. So you have things like, okay, power down the device and then it asks, did it power down? Things like that. The default is that it tries to do exactly, but you're missing out from some of the tests that you can only do in interactive mode. These are basically all the features. By default it tries them all. But that can be annoying if you just want to test one specific part. In that case you can select what you want. Oh, before I forget. So CTL, CTL, CEC CTL. That was a fairly long list of options. So the top ones, this allows you to send any message. So the top ones they do all sort of global stuff including where do you want to send a message to and who is it from. Show topology is very useful. I will show that soon. Because it shows, I will do that in a minute. It shows you what devices are connected. It detects the bus. Here are where you set up what type of device you have. At the end for each feature you have an additional help text. Which you can also do through help all. Oh, without the manage aids. And then you get help for all the messages that you can send. So there are a lot of them. This is auto generated from a header. I wasn't crazy. Euclipurl script, that creates all this stuff. So if I now run cc compliance you will see here so it gets network topology that's all great. But it fills here for some of the options power status. I don't get a proper power status. It says that's here again. And what is missing is that there is no follower. So you send messages to a device. But nobody is processing. Ja, de core messages are processed with anything outside of that. There is nobody running. So if I run the cc follower explicitly and then try this again then suddenly things work again. So now I get a proper power status because the follower running there is actually receiving the messages giving the right reply and you get what you expect to see. I wanted to show topology this is very useful. It just detects all other devices so you are the TV and it's looking for other devices, finds a playback device. It also shows the topology in a more graph like structure. There are only two devices here so it's fairly simple. And if I just run the full compliance test check then you get an idea of what it's all doing. So it's a fairly extensive test suite en if you run this for a remote device you get sort of a really decent idea of the level of crap. I would like to say that it is all perfect. Well, it's nowhere near. But at least you have some idea of how bad it is. That's it for me. Questions? Yes. So did I put it in staging because I was not sure about the user space API or were there other reasons. It was partially the user space API so it was sticking in the neck as long as it's not in the kernel nobody is using it. Also at that time the compliance test was still being developed. Now I'm happy with the user space API because we have done the whole compliance test and it's all working out fine. I also knew there were some corner cases that were not handled correctly yet for which I had to think about a little bit but there were really, you know, tiny things. I think the user space API as is stands the only place where I might make changes is in error handling error status because that is I need to do another read up on the specs and the compliance test double check whether I do the right thing. So that's just some status bits with some minor changes. Is it a second question? So if you want to add support for this is it allowed for non-staging code to hook into staging. If it's a new driver that's fairly independent you would put it in staging. There are a few now in staging. I also have one case, ADV7604 and some analog devices, receivers and transmitters where that code is under an if-dev but let me see. It's under a kconfig option that is only enabled if you have staging as well. I'm taking special care. My hope is that it will go out of staging by 4.10 or 4.11 at the latest. I just need two full days to two or three days to finalize it. I know exactly what is necessary to get it out of staging. I'm going to start and I'll finish in touches. Can you use the reference implementation as SnifferMode? Yes, you can. CECCTL has a minus M mode that enables the monitoring. Or Raspberry Pi, there is no C at least I haven't seen a CEC driver using for this yet from the Raspberry Pi. So they have CEC but it's custom. Like everybody else today interestingly enough, most SSEs have CEC support but they all have their own proprietary shitty driver. They have nothing like a framework like this that shields you from a lot of the complexities. It's just very low level transmit and receive and the rest figure it out yourself. Good luck. This does not replace if I understand the question correctly is there any product that uses this compliance test? No, because this is brand new. So there's been no time for anybody to use it. Hopefully we will because we are using it in our products so hopefully we will pass but it's just too soon at this moment. Given the fact that pretty much all of the implementations I have seen and tested they all fail even this compliance test I would be really surprised if there is anyone that has proper full compliance with CEC. It's horrible. Frankly. I don't know. They fail on very basic stuff. It's not even some obscure corner case. No, you send a message that is not supported and they just time out instead of sending me a feature report that is sort of CEC 101. I don't understand this is with say almost several prominent TV vendors that we tried. I have yet to see a product that is really all we had one I think a DVD player or a Blu-ray player it was fairly decent but certainly the TV that we tested it was let's say disappointing. Well if you implement CEC then you need to adhere to the specification. Well I don't know who knows perhaps they do it for that reason that they sort of call it any link any net because hey we don't really do CEC. So what is the plan with specific vendors? So the framework so there is a Lib CEC out there that is currently that is implementing a user space stack as well for CEC using the proprietary the custom APIs that exist today because there was no standard API. I'm hoping someone, it won't be me but someone will actually add support for this as well. That library has a whole bunch of support for quirks perhaps some of those could be put into the kernel but I really did there's more a user space thing the kernels should do the core stuff what I'm hoping is that when people use this framework and use these compliance tests and use the reference code that they will actually produce something that is much closer to what the standard specifies because so much is handled by the framework, hopefully correctly it's a chicken and egg, there was no framework there were no compliance tests well not unless you bought very expensive equipment so I'm trying to resolve that by giving a good alternative by giving some compliance tests by giving some utilities and tools and code so people can do a better job Time will tell I got one new driver already for 4.9 so it seems to be a lot of interest in getting this to work I'm hoping to see more drivers if you want to do that you want to add support, just contact me there is one thing so DRM what you really want is that when you register you see C device the ID from the DRM driver Russell King made the framework for that it is not merged, it is missing a feature I hope to find some time to look at it as well because that would be really nice it would make it a lot easier to write CEC drivers for those specific devices how are we with time I think it's out of time thank you