Re: [RFC] HDMI-CEC proposal
On Thu 10 May 2012 13:43:16 Florian Fainelli wrote: > Hello Murali, > > On Thursday 10 May 2012 12:40:05 muralidhar dixit wrote: > > Hello Florian, > > > > I do have similar implementation for my CEC driver. > > And I prefer most of the CEC messaged to be handled in the user space and > > have the kernel driver bare minimum with interfaces to > > 1) REGISTER CEC device( I have support for multiple logical devices) > > 2) SEND CEC MESSAGE > > 3) RECV CEC MESSAGE > > > > But one issue with this was the response time to the TV remote actions. > > Well, I think this is specific to your platform, because I don't have any > such > issue here with my implementation. The specification says that the desired > response time is of 200 ms and the maximum 1s, even with multiple context > switches you should be able to achieve that. Not knowing exactly how your > hardware works, maybe there is a bottleneck somewhere. > > > Initially I was sending the UI control messages also to user space but > > response time was too bad. Hence I wrote a CEC Keyboard driver which will > > process the CEC UI control messages. From the CEC driver if I recv any CEC > > UI control messages I will route it to CEC Keyboard driver in the kernel > > and all other messages have to be handled by user space application. > > This is the kind of thing that I want to avoid, on my platform, all the input > is processed in user-land and exposed as a HID device (thus self-describing), > forwarding CEC UI key codes to the kernel does not seem like a good solution > to me because it means we have to know about the CEC protocol itself. > > I fear that if we start doing this with the CEC UI codes, we end-up doing the > same for the system-related messages (Power, standby etc ...) and this is > also > to be avoided. We are also doing parsing in userspace. The CEC API just gets the hardware up and running so that we can send and receive CEC packets, but the kernel doesn't parse. The only exception to that *might* be the remote control part of the CEC specification (that's where button presses of a remote control are passed over CEC). It might make sense to pass them on to the V4L2 framework for remote controls. Then again, it might not. Or only if you set a flag or something. My personal view (but not everyone agreed at the time) is that we just need a simple API to send/receive CEC packets and do everything else in userspace. It would be nice if we have a standard library for that that everyone can use, though. Regards, Hans > > > > > Best Regards, > > Murali > > From: Florian Fainelli gmail.com> > > Subject: Re: [RFC] HDMI-CEC > > proposal<http://news.gmane.org/find- > root.php?message_id=%3c4F87F195.5080504%40gmail.com%3e> > > Newsgroups: gmane.linux.drivers.video-input- > infrastructure<http://news.gmane.org/gmane.linux.drivers.video-input- > infrastructure> > > Date: 2012-04-13 09:27:49 GMT (3 weeks, 5 days, 21 hours and 33 minutes ago) > > > > Hi Hans, > > > > Le 04/13/12 07:03, Hans Verkuil a écrit : > > > You both hit the main problem of the *CEC* support: how to implement the > API. > > > > Well, the API that I propose here [1] is quite simple: > > > > - a kernel-side API for defining *CEC* adapters drivers > > - a character device with an ioctl() control path and read/write/poll > > data-path > > > > [1]: https://github.com/ffainelli/linux-*hdmi*-*cec* > > <https://github.com/ffainelli/linux-hdmi-cec> > > > > > > > > Cisco's work on *CEC* has been stalled as we first want to get *HDMI* > support in > > > V4L. Hopefully that will happen in the next few months. After that we will > > > resume working on the *CEC* API. > > > > Well, I don't think that tighting *HDMI* into V4L is such a good idea > > either. *HDMI* is also a separate bus and deserves its own subsystem and > > even subsystems (audio, video, HDCP, *CEC*). For instance, the STB I am > > working with does not use the V4L API at all, however, I would like to > > be able to integrate within the Linux *HDMI* stack once there, think about > > nvidia's driver too. > > > > I can understand that you want to hold on your efforts on *CEC* while you > > want to get *HDMI* in, but don't make it entirely driven by Cisco and > > accept the community feedback. > > > > > > > > Regards, > > > > > > Hans > > > > > > On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: > > >> Since a lot of video cards dont' support
Re: [RFC] HDMI-CEC proposal
Hello Murali, On Thursday 10 May 2012 12:40:05 muralidhar dixit wrote: > Hello Florian, > > I do have similar implementation for my CEC driver. > And I prefer most of the CEC messaged to be handled in the user space and > have the kernel driver bare minimum with interfaces to > 1) REGISTER CEC device( I have support for multiple logical devices) > 2) SEND CEC MESSAGE > 3) RECV CEC MESSAGE > > But one issue with this was the response time to the TV remote actions. Well, I think this is specific to your platform, because I don't have any such issue here with my implementation. The specification says that the desired response time is of 200 ms and the maximum 1s, even with multiple context switches you should be able to achieve that. Not knowing exactly how your hardware works, maybe there is a bottleneck somewhere. > Initially I was sending the UI control messages also to user space but > response time was too bad. Hence I wrote a CEC Keyboard driver which will > process the CEC UI control messages. From the CEC driver if I recv any CEC > UI control messages I will route it to CEC Keyboard driver in the kernel > and all other messages have to be handled by user space application. This is the kind of thing that I want to avoid, on my platform, all the input is processed in user-land and exposed as a HID device (thus self-describing), forwarding CEC UI key codes to the kernel does not seem like a good solution to me because it means we have to know about the CEC protocol itself. I fear that if we start doing this with the CEC UI codes, we end-up doing the same for the system-related messages (Power, standby etc ...) and this is also to be avoided. > > Best Regards, > Murali > From: Florian Fainelli gmail.com> > Subject: Re: [RFC] HDMI-CEC > proposal<http://news.gmane.org/find- root.php?message_id=%3c4F87F195.5080504%40gmail.com%3e> > Newsgroups: gmane.linux.drivers.video-input- infrastructure<http://news.gmane.org/gmane.linux.drivers.video-input- infrastructure> > Date: 2012-04-13 09:27:49 GMT (3 weeks, 5 days, 21 hours and 33 minutes ago) > > Hi Hans, > > Le 04/13/12 07:03, Hans Verkuil a écrit : > > You both hit the main problem of the *CEC* support: how to implement the API. > > Well, the API that I propose here [1] is quite simple: > > - a kernel-side API for defining *CEC* adapters drivers > - a character device with an ioctl() control path and read/write/poll > data-path > > [1]: https://github.com/ffainelli/linux-*hdmi*-*cec* > <https://github.com/ffainelli/linux-hdmi-cec> > > > > > Cisco's work on *CEC* has been stalled as we first want to get *HDMI* support in > > V4L. Hopefully that will happen in the next few months. After that we will > > resume working on the *CEC* API. > > Well, I don't think that tighting *HDMI* into V4L is such a good idea > either. *HDMI* is also a separate bus and deserves its own subsystem and > even subsystems (audio, video, HDCP, *CEC*). For instance, the STB I am > working with does not use the V4L API at all, however, I would like to > be able to integrate within the Linux *HDMI* stack once there, think about > nvidia's driver too. > > I can understand that you want to hold on your efforts on *CEC* while you > want to get *HDMI* in, but don't make it entirely driven by Cisco and > accept the community feedback. > > > > > Regards, > > > > Hans > > > > On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: > >> Since a lot of video cards dont' support *CEC* at all (not even > >> connected), don't have *hdmi*, but work perfectly fine with dvi->*hdmi* > >> adapters, *CEC* can be implemented in many other ways (think media centers) > >> > >> One such exammple is using USB/Arduino > >> > >> http://code.google.com/p/*cec*-arduino/wiki/ElectricalInterface <http://code.google.com/p/cec-arduino/wiki/ElectricalInterface> > >> > >> Having an AVR with v-usb code and *cec* code doesn't look all that hard > >> nor impossible, so one could simply have a USB plug on one end, and an > >> *HDMI* plug on the other end, utilizing only the *CEC* pins. > >> > >> This would make it more something like LIRC if anything. > >> > >> On 04/12/12 17:24, Florian Fainelli wrote: > >>> Hi Hans, Martin, > >>> > >>> Sorry to jump in so late in the *HDMI*-*CEC* discussion, here are some > >>> comments from my perspective on your *proposal*: > >>> > >>> - the *HDMI*-*CEC* implementation deserves its own bus and class of devices > >>> because by definition it is a physical
Re: [RFC] HDMI-CEC proposal
Yes, the library to talk to the device is opensource, the hardware, not so much. :) On 17-04-12 15:31, Anssi Hannula wrote: 12.04.2012 23:36, Oliver Schinagl kirjoitti: Since a lot of video cards dont' support CEC at all (not even connected), don't have hdmi, but work perfectly fine with dvi->hdmi adapters, CEC can be implemented in many other ways (think media centers) One such exammple is using USB/Arduino http://code.google.com/p/cec-arduino/wiki/ElectricalInterface Having an AVR with v-usb code and cec code doesn't look all that hard nor impossible, so one could simply have a USB plug on one end, and an HDMI plug on the other end, utilizing only the CEC pins. This would make it more something like LIRC if anything. There already exists a device like this (USB CEC adapter with hdmi in/out) with open source userspace driver, developed for the XBMC Media Center (apparently MythTV is also supported): http://www.pulse-eight.com/store/products/104-usb-hdmi-cec-adapter.aspx http://libcec.pulse-eight.com/ https://github.com/Pulse-Eight/libcec -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
12.04.2012 23:36, Oliver Schinagl kirjoitti: > Since a lot of video cards dont' support CEC at all (not even > connected), don't have hdmi, but work perfectly fine with dvi->hdmi > adapters, CEC can be implemented in many other ways (think media centers) > > One such exammple is using USB/Arduino > > http://code.google.com/p/cec-arduino/wiki/ElectricalInterface > > Having an AVR with v-usb code and cec code doesn't look all that hard > nor impossible, so one could simply have a USB plug on one end, and an > HDMI plug on the other end, utilizing only the CEC pins. > > This would make it more something like LIRC if anything. There already exists a device like this (USB CEC adapter with hdmi in/out) with open source userspace driver, developed for the XBMC Media Center (apparently MythTV is also supported): http://www.pulse-eight.com/store/products/104-usb-hdmi-cec-adapter.aspx http://libcec.pulse-eight.com/ https://github.com/Pulse-Eight/libcec -- Anssi Hannula -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
Hi Hans, Le 04/13/12 07:03, Hans Verkuil a écrit : You both hit the main problem of the CEC support: how to implement the API. Well, the API that I propose here [1] is quite simple: - a kernel-side API for defining CEC adapters drivers - a character device with an ioctl() control path and read/write/poll data-path [1]: https://github.com/ffainelli/linux-hdmi-cec Cisco's work on CEC has been stalled as we first want to get HDMI support in V4L. Hopefully that will happen in the next few months. After that we will resume working on the CEC API. Well, I don't think that tighting HDMI into V4L is such a good idea either. HDMI is also a separate bus and deserves its own subsystem and even subsystems (audio, video, HDCP, CEC). For instance, the STB I am working with does not use the V4L API at all, however, I would like to be able to integrate within the Linux HDMI stack once there, think about nvidia's driver too. I can understand that you want to hold on your efforts on CEC while you want to get HDMI in, but don't make it entirely driven by Cisco and accept the community feedback. Regards, Hans On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: Since a lot of video cards dont' support CEC at all (not even connected), don't have hdmi, but work perfectly fine with dvi->hdmi adapters, CEC can be implemented in many other ways (think media centers) One such exammple is using USB/Arduino http://code.google.com/p/cec-arduino/wiki/ElectricalInterface Having an AVR with v-usb code and cec code doesn't look all that hard nor impossible, so one could simply have a USB plug on one end, and an HDMI plug on the other end, utilizing only the CEC pins. This would make it more something like LIRC if anything. On 04/12/12 17:24, Florian Fainelli wrote: Hi Hans, Martin, Sorry to jump in so late in the HDMI-CEC discussion, here are some comments from my perspective on your proposal: - the HDMI-CEC implementation deserves its own bus and class of devices because by definition it is a physical bus, which is even electrically independant from the rest of the HDMI bus (A/V path) - I don't think it is a good idea to tight it so closely to v4l, because one can perfectly have CEC-capable hardware without video, or at least not use v4l and have HDMI-CEC hardware - it was suggested to use sockets at some point, I think it is over-engineered and should only lead - processing messages in user-space is definitively the way to go, even input can be either re-injected using an uinput driver, or be handled in user-space entirely, eventually we might want to install "filters" based on opcodes to divert some opcodes to a kernel consumer, and the others to an user-space one Right now, I have a very simple implementation that I developed for the company I work for which can be found here: https://github.com/ffainelli/linux-hdmi-cec It is designed like this: 1) A core module, which registers a cec bus, and provides an abstraction for a CEC adapter (both device& driver): - basic CEC adapter operations: logical address setting, queueing management - counters, rx filtering - host attaching/detaching in case the hardware is capable of self-processing CEC messages (for wakeup in particular) 2) A character device module, which exposes a character device per CEC adapter and only allows one consumer at a time and exposes the following ioctl's: - SET_LOGICAL_ADDRESS - RESET_DEVICE - GET_COUNTERS - SET_RX_MODE (my adapter can be set in a promiscuous mode) the character device supports read/write/poll, which are the prefered ways for transfering/receiving data 3) A CEC adapter implementation which registers and calls into the core module when receiving a CEC message, and which the core module calls in response to the IOCTLs described below. At first I thought about defining a generic netlink family in order to allow multiple user-space listeners receive CEC messages, but in the end having only one consumer per adapter device is fine by me and a more traditionnal approach for programmers. I am relying on external components for knowing my HDMI physical address. Hope this is not too late to (re)start the discussion on HDMI-CEC. Thank you very much. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
You both hit the main problem of the CEC support: how to implement the API. Cisco's work on CEC has been stalled as we first want to get HDMI support in V4L. Hopefully that will happen in the next few months. After that we will resume working on the CEC API. Regards, Hans On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: > Since a lot of video cards dont' support CEC at all (not even > connected), don't have hdmi, but work perfectly fine with dvi->hdmi > adapters, CEC can be implemented in many other ways (think media centers) > > One such exammple is using USB/Arduino > > http://code.google.com/p/cec-arduino/wiki/ElectricalInterface > > Having an AVR with v-usb code and cec code doesn't look all that hard > nor impossible, so one could simply have a USB plug on one end, and an > HDMI plug on the other end, utilizing only the CEC pins. > > This would make it more something like LIRC if anything. > > On 04/12/12 17:24, Florian Fainelli wrote: > > Hi Hans, Martin, > > > > Sorry to jump in so late in the HDMI-CEC discussion, here are some > > comments from my perspective on your proposal: > > > > - the HDMI-CEC implementation deserves its own bus and class of devices > > because by definition it is a physical bus, which is even electrically > > independant from the rest of the HDMI bus (A/V path) > > > > - I don't think it is a good idea to tight it so closely to v4l, because > > one can perfectly have CEC-capable hardware without video, or at least > > not use v4l and have HDMI-CEC hardware > > > > - it was suggested to use sockets at some point, I think it is > > over-engineered and should only lead > > > > - processing messages in user-space is definitively the way to go, even > > input can be either re-injected using an uinput driver, or be handled in > > user-space entirely, eventually we might want to install "filters" based > > on opcodes to divert some opcodes to a kernel consumer, and the others > > to an user-space one > > > > Right now, I have a very simple implementation that I developed for the > > company I work for which can be found here: > > https://github.com/ffainelli/linux-hdmi-cec > > > > It is designed like this: > > > > 1) A core module, which registers a cec bus, and provides an abstraction > > for a CEC adapter (both device & driver): > > - basic CEC adapter operations: logical address setting, queueing > > management > > - counters, rx filtering > > - host attaching/detaching in case the hardware is capable of > > self-processing CEC messages (for wakeup in particular) > > > > 2) A character device module, which exposes a character device per CEC > > adapter and only allows one consumer at a time and exposes the following > > ioctl's: > > > > - SET_LOGICAL_ADDRESS > > - RESET_DEVICE > > - GET_COUNTERS > > - SET_RX_MODE (my adapter can be set in a promiscuous mode) > > > > the character device supports read/write/poll, which are the prefered > > ways for transfering/receiving data > > > > 3) A CEC adapter implementation which registers and calls into the core > > module when receiving a CEC message, and which the core module calls in > > response to the IOCTLs described below. > > > > At first I thought about defining a generic netlink family in order to > > allow multiple user-space listeners receive CEC messages, but in the end > > having only one consumer per adapter device is fine by me and a more > > traditionnal approach for programmers. > > > > I am relying on external components for knowing my HDMI physical address. > > > > Hope this is not too late to (re)start the discussion on HDMI-CEC. > > > > Thank you very much. > > -- > > Florian > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
Since a lot of video cards dont' support CEC at all (not even connected), don't have hdmi, but work perfectly fine with dvi->hdmi adapters, CEC can be implemented in many other ways (think media centers) One such exammple is using USB/Arduino http://code.google.com/p/cec-arduino/wiki/ElectricalInterface Having an AVR with v-usb code and cec code doesn't look all that hard nor impossible, so one could simply have a USB plug on one end, and an HDMI plug on the other end, utilizing only the CEC pins. This would make it more something like LIRC if anything. On 04/12/12 17:24, Florian Fainelli wrote: Hi Hans, Martin, Sorry to jump in so late in the HDMI-CEC discussion, here are some comments from my perspective on your proposal: - the HDMI-CEC implementation deserves its own bus and class of devices because by definition it is a physical bus, which is even electrically independant from the rest of the HDMI bus (A/V path) - I don't think it is a good idea to tight it so closely to v4l, because one can perfectly have CEC-capable hardware without video, or at least not use v4l and have HDMI-CEC hardware - it was suggested to use sockets at some point, I think it is over-engineered and should only lead - processing messages in user-space is definitively the way to go, even input can be either re-injected using an uinput driver, or be handled in user-space entirely, eventually we might want to install "filters" based on opcodes to divert some opcodes to a kernel consumer, and the others to an user-space one Right now, I have a very simple implementation that I developed for the company I work for which can be found here: https://github.com/ffainelli/linux-hdmi-cec It is designed like this: 1) A core module, which registers a cec bus, and provides an abstraction for a CEC adapter (both device & driver): - basic CEC adapter operations: logical address setting, queueing management - counters, rx filtering - host attaching/detaching in case the hardware is capable of self-processing CEC messages (for wakeup in particular) 2) A character device module, which exposes a character device per CEC adapter and only allows one consumer at a time and exposes the following ioctl's: - SET_LOGICAL_ADDRESS - RESET_DEVICE - GET_COUNTERS - SET_RX_MODE (my adapter can be set in a promiscuous mode) the character device supports read/write/poll, which are the prefered ways for transfering/receiving data 3) A CEC adapter implementation which registers and calls into the core module when receiving a CEC message, and which the core module calls in response to the IOCTLs described below. At first I thought about defining a generic netlink family in order to allow multiple user-space listeners receive CEC messages, but in the end having only one consumer per adapter device is fine by me and a more traditionnal approach for programmers. I am relying on external components for knowing my HDMI physical address. Hope this is not too late to (re)start the discussion on HDMI-CEC. Thank you very much. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
Hi Hans, Martin, Sorry to jump in so late in the HDMI-CEC discussion, here are some comments from my perspective on your proposal: - the HDMI-CEC implementation deserves its own bus and class of devices because by definition it is a physical bus, which is even electrically independant from the rest of the HDMI bus (A/V path) - I don't think it is a good idea to tight it so closely to v4l, because one can perfectly have CEC-capable hardware without video, or at least not use v4l and have HDMI-CEC hardware - it was suggested to use sockets at some point, I think it is over-engineered and should only lead - processing messages in user-space is definitively the way to go, even input can be either re-injected using an uinput driver, or be handled in user-space entirely, eventually we might want to install "filters" based on opcodes to divert some opcodes to a kernel consumer, and the others to an user-space one Right now, I have a very simple implementation that I developed for the company I work for which can be found here: https://github.com/ffainelli/linux-hdmi-cec It is designed like this: 1) A core module, which registers a cec bus, and provides an abstraction for a CEC adapter (both device & driver): - basic CEC adapter operations: logical address setting, queueing management - counters, rx filtering - host attaching/detaching in case the hardware is capable of self-processing CEC messages (for wakeup in particular) 2) A character device module, which exposes a character device per CEC adapter and only allows one consumer at a time and exposes the following ioctl's: - SET_LOGICAL_ADDRESS - RESET_DEVICE - GET_COUNTERS - SET_RX_MODE (my adapter can be set in a promiscuous mode) the character device supports read/write/poll, which are the prefered ways for transfering/receiving data 3) A CEC adapter implementation which registers and calls into the core module when receiving a CEC message, and which the core module calls in response to the IOCTLs described below. At first I thought about defining a generic netlink family in order to allow multiple user-space listeners receive CEC messages, but in the end having only one consumer per adapter device is fine by me and a more traditionnal approach for programmers. I am relying on external components for knowing my HDMI physical address. Hope this is not too late to (re)start the discussion on HDMI-CEC. Thank you very much. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal, ver 2
Hi Daniel and thank you, On 03/12/2011 01:42 AM, Daniel Glöckner wrote: Hi Martin, On Fri, Mar 11, 2011 at 12:36:09PM +0100, Martin Bugge (marbugge) wrote: Not every tx status is applicable for all modes, see table 1. |-| |Av link Mode | CEC | 1 | 2 | 3 | |-| | Status | | | | | |-| | TX_OK | a | n/a | a | n/a | |-| | TX_ARB_LOST| a | n/a | a | a | |-| | TX_RETRY_TIMEOUT| a | n/a | a | a | |-| | TX_BROADCAST_REJECT | a | n/a | a | n/a | |-| TX_ARB_LOST is applicable to mode 1. Arbitration loss will also be caused by receivers detecting a bad pulse. You are correct, a typo. However, it looks like also TX_OK will be used for Mode 3. And maybe also TX_BROADCAST_REJECT. In particular with reference to your link in below. * AV link mode 1: In mode 1 the frame length is fixed to 21 bits (including the start sequence). Some of these bits (Qty 1 - 6) can be arbitrated by the receiver to signal supported formats/standards. conf: enable: true/false upstream_Qty: QTY bits 1-6 downstream_Qty: QTY bits 1-6 || | Bits: | 31 - 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | || | Qty bits | x| x | 6 | 5 | 4 | 3 | 2 | 1 | || Qty bits 1-6 mapping (x: not used) If the Linux system is a video source, it must stop arbitrating those Qty bits as soon as another video source wants to become active. As this includes the message where the new source announces itself, this can't be handled by reconfiguration after reception of the message. If the Linux system is a video sink, the announcement of a new source should not affect the Qty bits to arbitrate. And don't get me startet about systems capable of being a video source and sink at the same time, capturing their own signal until a new source becomes active... I assume this must be handled by logic in the driver if it supports this mode. * AV link mode 1: Frame received/transmitted: head: |-| | Bits: | 31 - 4 | 3 | 2 | 1 | 0 | |-| | head bits: |x | DIR | /PAS | /NAS | /DES | |-| Qty: Quality bits 1 - 16; |---| | Bits: | 31 - 16 | 15 | 14 - 1 | 0 | |---| | Qty bits |x| 16 | 15 - 2 | 1 | |---| x: not used Is Qty-1 or Qty-16 the bit sent after /DES? Even though I find it a bit confusing in the standard, the plan was to send Qty-1 just after the /DES bit. It was an attempt to make the configuration and status the same. Such that we could use the same bit masks. In blocking mode only: tx_status: tx status. tx_status_Qty: which Qty bits 1 - 6 bits was arbitrated during transmit. It may be interesting to know what other devices did to the /PAS and /DES bits when they were sent as 1. Maybe I should change this such that we actually send up the whole frame as tx_status. In that way we will avoid the confusion of the Qty bit orders also. But then this should apply to the configuration as well. * AV link mode 3: TBD. Chances are that nobody ever used this len: length of message in bits, maximum 96 bits. msg: the raw message received/transmitted. (without the start sequence). tx_status: tx status in blocking mode. Google turned up this: http://fmt.cs.utwente.nl/publications/files/111_heerink.pdf It suggests that at least Philips' variant of AV.link mode 3 - EasyLink - is even closer to CEC than mode 2. Yes I see that. However CEC don't have the start sequence (to differenciate between mode 1 - 3), and the application id. In addition can't I see that mode 3 describe the ACK and EOM bits. It might be difficult to "force" easylink into the mode 3 as it is. If we could use the application id it might be possible for the driver to change behaviour. Or we will end up with #define AV_LINK_CAP_MODE_EASY_LINK (1 << 4) And so on, which might be ok also. Daniel -- To unsub
Re: [RFC] HDMI-CEC proposal, ver 2
Hi Martin, On Fri, Mar 11, 2011 at 12:36:09PM +0100, Martin Bugge (marbugge) wrote: > Not every tx status is applicable for all modes, see table 1. > > |-| > |Av link Mode | CEC | 1 | 2 | 3 | > |-| > | Status | | | | | > |-| > | TX_OK | a | n/a | a | n/a | > |-| > | TX_ARB_LOST| a | n/a | a | a | > |-| > | TX_RETRY_TIMEOUT| a | n/a | a | a | > |-| > | TX_BROADCAST_REJECT | a | n/a | a | n/a | > |-| TX_ARB_LOST is applicable to mode 1. Arbitration loss will also be caused by receivers detecting a bad pulse. > * AV link mode 1: > In mode 1 the frame length is fixed to 21 bits (including the > start sequence). > Some of these bits (Qty 1 - 6) can be arbitrated by the > receiver to signal supported formats/standards. > conf: > enable: true/false > upstream_Qty: QTY bits 1-6 > downstream_Qty: QTY bits 1-6 > || > | Bits: | 31 - 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | > || > | Qty bits | x| x | 6 | 5 | 4 | 3 | 2 | 1 | > || > Qty bits 1-6 mapping (x: not used) If the Linux system is a video source, it must stop arbitrating those Qty bits as soon as another video source wants to become active. As this includes the message where the new source announces itself, this can't be handled by reconfiguration after reception of the message. If the Linux system is a video sink, the announcement of a new source should not affect the Qty bits to arbitrate. And don't get me startet about systems capable of being a video source and sink at the same time, capturing their own signal until a new source becomes active... > * AV link mode 1: > Frame received/transmitted: > head: > |-| > | Bits: | 31 - 4 | 3 | 2 | 1 | 0 | > |-| > | head bits: |x | DIR | /PAS | /NAS | /DES | > |-| > Qty: Quality bits 1 - 16; > |---| > | Bits: | 31 - 16 | 15 | 14 - 1 | 0 | > |---| > | Qty bits |x| 16 | 15 - 2 | 1 | > |---| > x: not used Is Qty-1 or Qty-16 the bit sent after /DES? > In blocking mode only: > tx_status: tx status. > tx_status_Qty: which Qty bits 1 - 6 bits was arbitrated > during transmit. It may be interesting to know what other devices did to the /PAS and /DES bits when they were sent as 1. > * AV link mode 3: TBD. Chances are that nobody ever used this > len: length of message in bits, maximum 96 bits. > msg: the raw message received/transmitted. (without the start > sequence). > tx_status: tx status in blocking mode. Google turned up this: http://fmt.cs.utwente.nl/publications/files/111_heerink.pdf It suggests that at least Philips' variant of AV.link mode 3 - EasyLink - is even closer to CEC than mode 2. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] HDMI-CEC proposal, ver 2
Hi This is an updated version of the proposal for adding an api for HDMI-CEC to V4L2. Main difference is the support of AV.link EN 50157-2-[123]. (thanks to Daniel Glöckner) Author: Martin Bugge Date: Fri, 11th of March 2010 = This is a proposal for adding a Consumer Electronic Control (CEC) API to V4L2. This document describes the changes and new ioctls needed. Version 1. Initial version Version 2. Added support for AV.link EN 50157-2-[123]. Background == CEC is a protocol that provides high-level control functions between various audiovisual products. It is an optional supplement to the High-Definition Multimedia Interface Specification (HDMI). In short: CEC uses pin 13 on the HDMI connector to transmit and receive small data-packets (maximum 16 bytes including a 1 byte header) at low data rates (~400 bits/s). A CEC device may have any of 15 logical addresses (0 - 14). (address 15 is broadcast and some addresses are reserved) Physical layer is a one-wire bidirectional serial bus that uses the industry-standard AV.link, see [3]. Due to this the proposed ioctls and events are meant to cover expansion for the protocols in [3]. References == [1] High-Definition Multimedia Interface Specification version 1.3a, Supplement 1 Consumer Electronic Control (CEC). http://www.hdmi.org/manufacturer/specification.aspx [2] http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf [3] Domestic and similar electronic equipment interconnection requirements AV.link. EN 50157-2-[123] Proposed solution = Two new ioctls: VIDIOC_AV_LINK_CAP (read) VIDIOC_AV_LINK_CMD (read/write) VIDIOC_AV_LINK_CAP: --- #define AV_LINK_CAP_MODE_CEC (1 << 0) #define AV_LINK_CAP_MODE_1 (1 << 1) #define AV_LINK_CAP_MODE_2 (1 << 2) #define AV_LINK_CAP_MODE_3 (1 << 3) struct vl2_av_link_cap { __u32 capabilities; __u32 logicaldevices; __u32 reserved[14]; }; The capabilities field will indicate which protocols/formats this HW supports. * AV link mode CEC: logicaldevices: 1 -> 14, this HW supports n logical devices simultaneously. * AV link mode 1: logicaldevices: not used. * AV link mode 2: Same as AV link mode CEC. * AV link mode 3: logicaldevices: not used. reserved: for future use. VIDIOC_AV_LINK_CMD: --- The command ioctl is used both for configuration and to receive/transmit data. /* mode 1 */ struct avl_mode1_conf { __u32 enable; __u32 upstream_Qty; __u32 downstream_Qty; }; struct avl_mode1 { __u32 head; __u32 Qty; __u32 tx_status; __u32 tx_status_Qty; }; /* mode 2, 3 and CEC */ struct avl_conf { __u32 enable; __u32 index; __u32 addr; }; struct avl { __u32 len; __u8 msg[16]; __u32 tx_status; }; struct v4l2_av_link_cmd { __u32 command; __u32 mode; __u32 reserved[2]; union { struct avl_mode1_conf avlm1_conf; struct avl_mode1 avlm1; struct avl_conf conf; struct avl avl; __u32 raw[12]; }; }; /* command */ #define V4L2_AV_LINK_CMD_CONF (1) #define V4L2_AV_LINK_CMD_TX (2) #define V4L2_AV_LINK_CMD_RX (3) /* mode */ #define AV_LINK_CMD_MODE_CEC (1) #define AV_LINK_CMD_MODE_1 (2) #define AV_LINK_CMD_MODE_2 (3) #define AV_LINK_CMD_MODE_3 (4) /* Tx status */ #define V4L2_AV_LINK_STAT_TX_OK (0) #define V4L2_AV_LINK_STAT_TX_ARB_LOST (1) #define V4L2_AV_LINK_STAT_TX_RETRY_TIMEOUT (2) #define V4L2_AV_LINK_STAT_TX_BROADCAST_REJECT (3) Not every tx status is applicable for all modes, see table 1. |-| |Av link Mode | CEC | 1 | 2 | 3 | |-| | Status | | | | | |-| | TX_OK | a | n/a | a | n/a | |-| | TX_ARB_LOST| a | n/a | a | a | |-| | TX_RETRY_TIMEOUT| a | n/a | a | a | |-| | TX_BROADCAST_REJECT | a | n/a | a | n/a | |-| Table 1: tx status versus mode. a: applicable n/a: not applicable Configuration command: -- * AV link mode CEC: Must be done for each logical device address which is to be enabled on this HW. Maximum number of logical devices is found with the capability ioctl. conf: index: 0 -> number_of_logical_devices-1 enable: true/false addr: logical address * AV link mode 1: In mode 1 the frame l
Re: [RFC] HDMI-CEC proposal
On 03/03/2011 11:37 AM, Laurent Pinchart wrote: Hi Martin, On Tuesday 01 March 2011 10:59:07 Martin Bugge (marbugge) wrote: Author: Martin Bugge Date: Tue, 1 March 2010 == This is a proposal for adding a Consumer Electronic Control (CEC) API to V4L2. This document describes the changes and new ioctls needed. Version 1.0 (This is first version) Background == CEC is a protocol that provides high-level control functions between various audiovisual products. It is an optional supplement to the High-Definition Multimedia Interface Specification (HDMI). Physical layer is a one-wire bidirectional serial bus that uses the industry-standard AV.link protocol. In short: CEC uses pin 13 on the HDMI connector to transmit and receive small data-packets (maximum 16 bytes including a 1 byte header) at low data rates (~400 bits/s). A CEC device may have any of 15 logical addresses (0 - 14). (address 15 is broadcast and some addresses are reserved) References == [1] High-Definition Multimedia Interface Specification version 1.3a, Supplement 1 Consumer Electronic Control (CEC). http://www.hdmi.org/manufacturer/specification.aspx [2] http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf Proposed solution = Two new ioctls: VIDIOC_CEC_CAP (read) VIDIOC_CEC_CMD (read/write) VIDIOC_CEC_CAP: --- struct vl2_cec_cap { __u32 logicaldevices; __u32 reserved[7]; }; The capability ioctl will return the number of logical devices/addresses which can be simultaneously supported on this HW. 0: This HW don't support CEC. 1 -> 14: This HW supports n logical devices simultaneously. VIDIOC_CEC_CMD: --- struct v4l2_cec_cmd { __u32 cmd; __u32 reserved[7]; union { struct { __u32 index; __u32 enable; __u32 addr; } conf; struct { __u32 len; __u8 msg[16]; __u32 status; } data; __u32 raw[8]; }; }; Alternatively the data struct could be: struct { __u8 initiator; __u8 destination; __u8 len; __u8 msg[15]; __u32 status; } data; Commands: #define V4L2_CEC_CMD_CONF (1) #define V4L2_CEC_CMD_TX(2) #define V4L2_CEC_CMD_RX(3) Tx status field: #define V4L2_CEC_STAT_TX_OK(0) #define V4L2_CEC_STAT_TX_ARB_LOST (1) #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2) The command ioctl is used both for configuration and to receive/transmit data. * The configuration command must be done for each logical device address which is to be enabled on this HW. Maximum number of logical devices is found with the capability ioctl. conf: index: 0 -> number_of_logical_devices-1 enable: true/false addr: logical address By default all logical devices are disabled. * Tx/Rx command data: len:length of message (data + header) msg:the raw CEC message received/transmitted status: when the driver is in blocking mode it gives the result for transmit. Events -- In the case of non-blocking mode the driver will issue the following events: V4L2_EVENT_CEC_TX V4L2_EVENT_CEC_RX V4L2_EVENT_CEC_TX - * transmit is complete with the following status: Add an additional struct to the struct v4l2_event struct v4l2_event_cec_tx { __u32 status; } In non-blocking mode, will applications be able to send several messages without waiting for a transmission done event between each of them ? If so, maybe some kind of ID to correlate TX events with TX commands would be useful. Hi Laurent and thank you, No it wasn't the plan to be able to send several messages without waiting for the previous to complete. In the first test driver we have written for this, a new send while previous transmission is not complete in non-blocking mode will return -EAGAIN; Regards Martin V4L2_EVENT_CEC_RX - * received a complete message -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
Hi Martin, On Tuesday 01 March 2011 10:59:07 Martin Bugge (marbugge) wrote: > Author: Martin Bugge > Date: Tue, 1 March 2010 > == > > This is a proposal for adding a Consumer Electronic Control (CEC) API to > V4L2. > This document describes the changes and new ioctls needed. > > Version 1.0 (This is first version) > > Background > == > CEC is a protocol that provides high-level control functions between > various audiovisual products. > It is an optional supplement to the High-Definition Multimedia Interface > Specification (HDMI). > Physical layer is a one-wire bidirectional serial bus that uses the > industry-standard AV.link protocol. > > In short: CEC uses pin 13 on the HDMI connector to transmit and receive > small data-packets >(maximum 16 bytes including a 1 byte header) at low data > rates (~400 bits/s). > > A CEC device may have any of 15 logical addresses (0 - 14). > (address 15 is broadcast and some addresses are reserved) > > > References > == > [1] High-Definition Multimedia Interface Specification version 1.3a, > Supplement 1 Consumer Electronic Control (CEC). > http://www.hdmi.org/manufacturer/specification.aspx > > [2] > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf > > > Proposed solution > = > > Two new ioctls: > VIDIOC_CEC_CAP (read) > VIDIOC_CEC_CMD (read/write) > > VIDIOC_CEC_CAP: > --- > > struct vl2_cec_cap { > __u32 logicaldevices; > __u32 reserved[7]; > }; > > The capability ioctl will return the number of logical devices/addresses > which can be > simultaneously supported on this HW. > 0: This HW don't support CEC. > 1 -> 14: This HW supports n logical devices simultaneously. > > VIDIOC_CEC_CMD: > --- > > struct v4l2_cec_cmd { > __u32 cmd; > __u32 reserved[7]; > union { > struct { > __u32 index; > __u32 enable; > __u32 addr; > } conf; > struct { > __u32 len; > __u8 msg[16]; > __u32 status; > } data; > __u32 raw[8]; > }; > }; > > Alternatively the data struct could be: > struct { > __u8 initiator; > __u8 destination; > __u8 len; > __u8 msg[15]; > __u32 status; > } data; > > Commands: > > #define V4L2_CEC_CMD_CONF (1) > #define V4L2_CEC_CMD_TX(2) > #define V4L2_CEC_CMD_RX(3) > > Tx status field: > > #define V4L2_CEC_STAT_TX_OK(0) > #define V4L2_CEC_STAT_TX_ARB_LOST (1) > #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2) > > The command ioctl is used both for configuration and to receive/transmit > data. > > * The configuration command must be done for each logical device address >which is to be enabled on this HW. Maximum number of logical devices >is found with the capability ioctl. > conf: > index: 0 -> number_of_logical_devices-1 > enable: true/false > addr: logical address > >By default all logical devices are disabled. > > * Tx/Rx command > data: > len:length of message (data + header) > msg:the raw CEC message received/transmitted > status: when the driver is in blocking mode it gives the > result for transmit. > > Events > -- > > In the case of non-blocking mode the driver will issue the following > events: > > V4L2_EVENT_CEC_TX > V4L2_EVENT_CEC_RX > > V4L2_EVENT_CEC_TX > - > * transmit is complete with the following status: > Add an additional struct to the struct v4l2_event > > struct v4l2_event_cec_tx { > __u32 status; > } In non-blocking mode, will applications be able to send several messages without waiting for a transmission done event between each of them ? If so, maybe some kind of ID to correlate TX events with TX commands would be useful. > V4L2_EVENT_CEC_RX > - > * received a complete message -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
On Wed, Mar 2, 2011 at 4:13 AM, Hans Verkuil wrote: > Hi Alex, > > On Tuesday, March 01, 2011 18:52:28 Alex Deucher wrote: >> On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge) >> wrote: >> > Author: Martin Bugge >> > Date: Tue, 1 March 2010 >> > == >> > >> > This is a proposal for adding a Consumer Electronic Control (CEC) API to >> > V4L2. >> > This document describes the changes and new ioctls needed. >> > >> > Version 1.0 (This is first version) >> > >> > Background >> > == >> > CEC is a protocol that provides high-level control functions between > various >> > audiovisual products. >> > It is an optional supplement to the High-Definition Multimedia Interface >> > Specification (HDMI). >> > Physical layer is a one-wire bidirectional serial bus that uses the >> > industry-standard AV.link protocol. >> > >> > In short: CEC uses pin 13 on the HDMI connector to transmit and receive >> > small data-packets >> > (maximum 16 bytes including a 1 byte header) at low data rates >> > (~400 bits/s). >> > >> > A CEC device may have any of 15 logical addresses (0 - 14). >> > (address 15 is broadcast and some addresses are reserved) >> > >> >> It would be nice if this was not tied to v4l as we'll start seeing CEC >> support show in GPUs soon as well. > > As mentioned in other emails it is my firm believe that mixing APIs is a bad > idea. I've never seen that work in practice. That said, I do think that any > userspace CEC library shouldn't be tied to V4L allowing it to be used by GPUs. > Right. That was my concern. You are probably more of an expert on CEC so I'll leave the API to you, but as it's going to show up in GPUs, I'd rather not re-invent the wheel to support it on the GPU side in some incompatible manner if it can be avoided. > It would also be interesting to see if i2c HDMI receiver/transmitter drivers > can be used by both subsystems. This would make a lot of sense. There are already several i2c tmds drivers in the drm tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/i2c;h=9eb6dad3ffa6cac6dfc07afb0b8526049416398b;hb=HEAD And a few in the intel kms driver that could be broken out as independent drivers. See the dvo_*.c files in: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/i915;h=19e4b8fe8f5413f0c5d5059d8b2561eafab9e5dd;hb=HEAD Still they are tied to the drm as they are used as kms encoders. > > Apologies if I asked this before, but are you planning to attend the ELC in > San Francisco? If so, then we should sit together and compare the subsystems > and see if we can work something out. Probably not, but I'll know more soon. Alex > > Regards, > > Hans > >> >> Alex >> >> > >> > References >> > == >> > [1] High-Definition Multimedia Interface Specification version 1.3a, >> > Supplement 1 Consumer Electronic Control (CEC). >> > http://www.hdmi.org/manufacturer/specification.aspx >> > >> > [2] >> > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf >> > >> > >> > Proposed solution >> > = >> > >> > Two new ioctls: >> > VIDIOC_CEC_CAP (read) >> > VIDIOC_CEC_CMD (read/write) >> > >> > VIDIOC_CEC_CAP: >> > --- >> > >> > struct vl2_cec_cap { >> > __u32 logicaldevices; >> > __u32 reserved[7]; >> > }; >> > >> > The capability ioctl will return the number of logical devices/addresses >> > which can be >> > simultaneously supported on this HW. >> > 0: This HW don't support CEC. >> > 1 -> 14: This HW supports n logical devices simultaneously. >> > >> > VIDIOC_CEC_CMD: >> > --- >> > >> > struct v4l2_cec_cmd { >> > __u32 cmd; >> > __u32 reserved[7]; >> > union { >> > struct { >> > __u32 index; >> > __u32 enable; >> > __u32 addr; >> > } conf; >> > struct { >> > __u32 len; >> > __u8 msg[16]; >> > __u32 status; >> > } data; >> > __u32 raw[8]; >> > }; >> > }; >> > >> > Alternatively the data struct could be: >> > struct { >> > __u8 initiator; >> > __u8 destination; >> > __u8 len; >> > __u8 msg[15]; >> > __u32 status; >> > } data; >> > >> > Commands: >> > >> > #define V4L2_CEC_CMD_CONF (1) >> > #define V4L2_CEC_CMD_TX (2) >> > #define V4L2_CEC_CMD_RX (3) >> > >> > Tx status field: >> > >> > #define V4L2_CEC_STAT_TX_OK (0) >> > #define V4L2_CEC_STAT_TX_ARB_LOST (1) >> > #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2) >> > >> > The command ioctl is used both for configuration and to receive/transmit >> > data. >> > >> > * The configuration command must be done for each logical device address >> > which is to be enabled on this HW. Maximum number of logical devices >> > is found with the capability ioctl. >> > conf: >> > index: 0 -> number_of_logical_devic
Re: [RFC] HDMI-CEC proposal
On 03/02/2011 12:38 AM, Daniel Glöckner wrote: On Tue, Mar 01, 2011 at 10:59:07AM +0100, Martin Bugge (marbugge) wrote: CEC is a protocol that provides high-level control functions between various audiovisual products. It is an optional supplement to the High-Definition Multimedia Interface Specification (HDMI). Physical layer is a one-wire bidirectional serial bus that uses the industry-standard AV.link protocol. Apart from CEC being twice as fast as AV.link and using 3.6V instead of 5V, CEC does look like an extension to the frame format defined in EN 50157-2-2 for multiple data bytes. So, how about adding support for EN 50157-2-* messages as well? SCART isn't dead yet. EN 50157-2-1 is tricky in that it requires devices to override data bits like it is done for ack bits to announce their status. There is a single message type with 21 bits. For EN 50157-2-2 the only change necessary would be to tell the application that it has to use AV.link commands instead of CEC commands. In theory one could mix AV.link and CEC on a single wire as they can be distinguished by their start bits. EN 50157-2-3 allows 7 vendors to register their own applications with up to 100 data bits per message. I doubt we can support these if they require bits on the wire to be modified. As they still didn't make use of the reserved value to extend the application number space beyond 7, chances are no vendor ever applied for a number. Just my 2 cents. Daniel Hi Daniel and thank you. I haven't read these standards myself but will do so as soon as I get hold of them. But this sounds like a good idea since cec is based on these protocols. I will look into it. Regards, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
Hi Alex, On Tuesday, March 01, 2011 18:52:28 Alex Deucher wrote: > On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge) > wrote: > > Author: Martin Bugge > > Date: Tue, 1 March 2010 > > == > > > > This is a proposal for adding a Consumer Electronic Control (CEC) API to > > V4L2. > > This document describes the changes and new ioctls needed. > > > > Version 1.0 (This is first version) > > > > Background > > == > > CEC is a protocol that provides high-level control functions between various > > audiovisual products. > > It is an optional supplement to the High-Definition Multimedia Interface > > Specification (HDMI). > > Physical layer is a one-wire bidirectional serial bus that uses the > > industry-standard AV.link protocol. > > > > In short: CEC uses pin 13 on the HDMI connector to transmit and receive > > small data-packets > > (maximum 16 bytes including a 1 byte header) at low data rates > > (~400 bits/s). > > > > A CEC device may have any of 15 logical addresses (0 - 14). > > (address 15 is broadcast and some addresses are reserved) > > > > It would be nice if this was not tied to v4l as we'll start seeing CEC > support show in GPUs soon as well. As mentioned in other emails it is my firm believe that mixing APIs is a bad idea. I've never seen that work in practice. That said, I do think that any userspace CEC library shouldn't be tied to V4L allowing it to be used by GPUs. It would also be interesting to see if i2c HDMI receiver/transmitter drivers can be used by both subsystems. This would make a lot of sense. Apologies if I asked this before, but are you planning to attend the ELC in San Francisco? If so, then we should sit together and compare the subsystems and see if we can work something out. Regards, Hans > > Alex > > > > > References > > == > > [1] High-Definition Multimedia Interface Specification version 1.3a, > >Supplement 1 Consumer Electronic Control (CEC). > >http://www.hdmi.org/manufacturer/specification.aspx > > > > [2] > > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf > > > > > > Proposed solution > > = > > > > Two new ioctls: > >VIDIOC_CEC_CAP (read) > >VIDIOC_CEC_CMD (read/write) > > > > VIDIOC_CEC_CAP: > > --- > > > > struct vl2_cec_cap { > > __u32 logicaldevices; > > __u32 reserved[7]; > > }; > > > > The capability ioctl will return the number of logical devices/addresses > > which can be > > simultaneously supported on this HW. > >0: This HW don't support CEC. > >1 -> 14: This HW supports n logical devices simultaneously. > > > > VIDIOC_CEC_CMD: > > --- > > > > struct v4l2_cec_cmd { > >__u32 cmd; > >__u32 reserved[7]; > >union { > >struct { > >__u32 index; > >__u32 enable; > >__u32 addr; > >} conf; > >struct { > >__u32 len; > >__u8 msg[16]; > >__u32 status; > >} data; > >__u32 raw[8]; > >}; > > }; > > > > Alternatively the data struct could be: > >struct { > >__u8 initiator; > >__u8 destination; > >__u8 len; > >__u8 msg[15]; > >__u32 status; > >} data; > > > > Commands: > > > > #define V4L2_CEC_CMD_CONF (1) > > #define V4L2_CEC_CMD_TX(2) > > #define V4L2_CEC_CMD_RX(3) > > > > Tx status field: > > > > #define V4L2_CEC_STAT_TX_OK(0) > > #define V4L2_CEC_STAT_TX_ARB_LOST (1) > > #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2) > > > > The command ioctl is used both for configuration and to receive/transmit > > data. > > > > * The configuration command must be done for each logical device address > > which is to be enabled on this HW. Maximum number of logical devices > > is found with the capability ioctl. > >conf: > > index: 0 -> number_of_logical_devices-1 > > enable: true/false > > addr: logical address > > > > By default all logical devices are disabled. > > > > * Tx/Rx command > >data: > > len:length of message (data + header) > > msg:the raw CEC message received/transmitted > > status: when the driver is in blocking mode it gives the result for > > transmit. > > > > Events > > -- > > > > In the case of non-blocking mode the driver will issue the following events: > > > > V4L2_EVENT_CEC_TX > > V4L2_EVENT_CEC_RX > > > > V4L2_EVENT_CEC_TX > > - > > * transmit is complete with the following status: > > Add an additional struct to the struct v4l2_event > > > > struct v4l2_event_cec_tx { > > __u32 status; > > } > > > > V4L2_EVENT_CEC_RX > > - > > * received a complete message > > > > > > Comments ? > > > > Martin Bugge > > > > -- > > Martin Bugge - Tandberg (now a part of Cisco) > > -- > > > > -- > > To unsubscribe from this list: send the line "unsu
Re: [RFC] HDMI-CEC proposal
On Tue, Mar 01, 2011 at 10:59:07AM +0100, Martin Bugge (marbugge) wrote: > CEC is a protocol that provides high-level control functions between > various audiovisual products. > It is an optional supplement to the High-Definition Multimedia > Interface Specification (HDMI). > Physical layer is a one-wire bidirectional serial bus that uses the > industry-standard AV.link protocol. Apart from CEC being twice as fast as AV.link and using 3.6V instead of 5V, CEC does look like an extension to the frame format defined in EN 50157-2-2 for multiple data bytes. So, how about adding support for EN 50157-2-* messages as well? SCART isn't dead yet. EN 50157-2-1 is tricky in that it requires devices to override data bits like it is done for ack bits to announce their status. There is a single message type with 21 bits. For EN 50157-2-2 the only change necessary would be to tell the application that it has to use AV.link commands instead of CEC commands. In theory one could mix AV.link and CEC on a single wire as they can be distinguished by their start bits. EN 50157-2-3 allows 7 vendors to register their own applications with up to 100 data bits per message. I doubt we can support these if they require bits on the wire to be modified. As they still didn't make use of the reserved value to extend the application number space beyond 7, chances are no vendor ever applied for a number. Just my 2 cents. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge) wrote: > Author: Martin Bugge > Date: Tue, 1 March 2010 > == > > This is a proposal for adding a Consumer Electronic Control (CEC) API to > V4L2. > This document describes the changes and new ioctls needed. > > Version 1.0 (This is first version) > > Background > == > CEC is a protocol that provides high-level control functions between various > audiovisual products. > It is an optional supplement to the High-Definition Multimedia Interface > Specification (HDMI). > Physical layer is a one-wire bidirectional serial bus that uses the > industry-standard AV.link protocol. > > In short: CEC uses pin 13 on the HDMI connector to transmit and receive > small data-packets > (maximum 16 bytes including a 1 byte header) at low data rates > (~400 bits/s). > > A CEC device may have any of 15 logical addresses (0 - 14). > (address 15 is broadcast and some addresses are reserved) > It would be nice if this was not tied to v4l as we'll start seeing CEC support show in GPUs soon as well. Alex > > References > == > [1] High-Definition Multimedia Interface Specification version 1.3a, > Supplement 1 Consumer Electronic Control (CEC). > http://www.hdmi.org/manufacturer/specification.aspx > > [2] > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf > > > Proposed solution > = > > Two new ioctls: > VIDIOC_CEC_CAP (read) > VIDIOC_CEC_CMD (read/write) > > VIDIOC_CEC_CAP: > --- > > struct vl2_cec_cap { > __u32 logicaldevices; > __u32 reserved[7]; > }; > > The capability ioctl will return the number of logical devices/addresses > which can be > simultaneously supported on this HW. > 0: This HW don't support CEC. > 1 -> 14: This HW supports n logical devices simultaneously. > > VIDIOC_CEC_CMD: > --- > > struct v4l2_cec_cmd { > __u32 cmd; > __u32 reserved[7]; > union { > struct { > __u32 index; > __u32 enable; > __u32 addr; > } conf; > struct { > __u32 len; > __u8 msg[16]; > __u32 status; > } data; > __u32 raw[8]; > }; > }; > > Alternatively the data struct could be: > struct { > __u8 initiator; > __u8 destination; > __u8 len; > __u8 msg[15]; > __u32 status; > } data; > > Commands: > > #define V4L2_CEC_CMD_CONF (1) > #define V4L2_CEC_CMD_TX (2) > #define V4L2_CEC_CMD_RX (3) > > Tx status field: > > #define V4L2_CEC_STAT_TX_OK (0) > #define V4L2_CEC_STAT_TX_ARB_LOST (1) > #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2) > > The command ioctl is used both for configuration and to receive/transmit > data. > > * The configuration command must be done for each logical device address > which is to be enabled on this HW. Maximum number of logical devices > is found with the capability ioctl. > conf: > index: 0 -> number_of_logical_devices-1 > enable: true/false > addr: logical address > > By default all logical devices are disabled. > > * Tx/Rx command > data: > len: length of message (data + header) > msg: the raw CEC message received/transmitted > status: when the driver is in blocking mode it gives the result for > transmit. > > Events > -- > > In the case of non-blocking mode the driver will issue the following events: > > V4L2_EVENT_CEC_TX > V4L2_EVENT_CEC_RX > > V4L2_EVENT_CEC_TX > - > * transmit is complete with the following status: > Add an additional struct to the struct v4l2_event > > struct v4l2_event_cec_tx { > __u32 status; > } > > V4L2_EVENT_CEC_RX > - > * received a complete message > > > Comments ? > > Martin Bugge > > -- > Martin Bugge - Tandberg (now a part of Cisco) > -- > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
On Tuesday, March 01, 2011 15:59:21 Martin Bugge (marbugge) wrote: > On 03/01/2011 02:47 PM, Andy Walls wrote: > > On Tue, 2011-03-01 at 10:59 +0100, Martin Bugge (marbugge) wrote: > > > >> Author: Martin Bugge > >> Date: Tue, 1 March 2010 > >> == > >> > >> This is a proposal for adding a Consumer Electronic Control (CEC) API to > >> V4L2. > >> This document describes the changes and new ioctls needed. > >> > >> Version 1.0 (This is first version) > >> > >> Background > >> == > >> CEC is a protocol that provides high-level control functions between > >> various audiovisual products. > >> It is an optional supplement to the High-Definition Multimedia Interface > >> Specification (HDMI). > >> Physical layer is a one-wire bidirectional serial bus that uses the > >> industry-standard AV.link protocol. > >> > >> In short: CEC uses pin 13 on the HDMI connector to transmit and receive > >> small data-packets > >> (maximum 16 bytes including a 1 byte header) at low data > >> rates (~400 bits/s). > >> > >> A CEC device may have any of 15 logical addresses (0 - 14). > >> (address 15 is broadcast and some addresses are reserved) > >> > >> > >> References > >> == > >> [1] High-Definition Multimedia Interface Specification version 1.3a, > >> Supplement 1 Consumer Electronic Control (CEC). > >> http://www.hdmi.org/manufacturer/specification.aspx > >> > >> [2] > >> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf > >> > > > > Hi Martin, > > > > After reading the whitepaper, and the the general purpose nature of your > > proposed API calls, I'm wondering if a socket interface wouldn't be > > appropriate. > > > > The CEC bus seems to be designed as a network. A broadcast medium, with > > multiport devices (switches), physical (MAC) addresses in dotted decimal > > notation (1.0.0.0), dynamic logical address assignment, arbitration > > (Media Access Control), etc. The whitepaper even suggests OSI layers, > > using the term PHY in a few places. > > > > > > A network interface could be implemented something like what is done for > > SLIP in figure 2 here (compare with figure 1): > > > > http://www.linux.it/~rubini/docs/serial/serial.html > > > > > > Using that diagram as a guide, a socket interface would need a CEC tty > > line discipline, CEC network device, and code to hook the CEC serial > > device to the tty layer. Multiple CEC serial devices would show up as > > multiple network interfaces. > > > > Once a network device is available, user-space could then use AF_PACKET > > sockets. If CEC's layers are standardized enough, a new address family > > could be added to the kernel, I guess. > > > > Of course, all that is a lot of work. Since Cisco should have some > > networking experts hanging around, maybe it wouldn't be too hard. ;) > > > > > > Regards, > > Andy > > > > Hi Andy and thank you. > > I agree its always nice to strive for a generic solution, but I don't > think I'm able to > get hold of the resources required. > > In CEC the physical address is determined by the edid information from > the HDMI sink, > or for the HDMI sink its HDMI port number. > > While the logical address describes the type of device, TV, Recorder, > Tuner, etc. > > From that point of view I do think that the CEC protocol is closly > connected to the HDMI connector, > such that it belongs together with a video device. > > But I will ask my "mentor" for advice. Yes, CEC has a physical address which obtained from the EDID. It is generated via the EDID. It has nothing to do with network addresses. Instead it is a generated unique identifier. CEC also has logical addresses which is a really a 'Device Type Identifier' for want of a better name. See CEC Table 5 in the 1.3a HDMI spec. When I read through it I couldn't help wondering what to do if I have more than three playback devices or recording devices. Or more than one TV, for that matter. It also seems that the tree of connected devices can't be more than 4 or 5 levels, if I understand section 8.7.2 (Physical Address Discovery) correctly. As I mentioned in my reply to Mauro, CEC most closely resembles RDS in that the hardware/kernel part is trivial, but parsing and correctly handling it is a lot more complicated and ideal for a userspace library. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
On Tuesday, March 01, 2011 17:19:21 Mauro Carvalho Chehab wrote: > Em 01-03-2011 12:49, Hans Verkuil escreveu: > > On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote: > >> Em 01-03-2011 11:38, Hans Verkuil escreveu: > >>> Again, CEC != IR. All you need is a simple API to be able to send and > > receive > >>> CEC packets and a libcec that you can use to do the topology discovery > >>> and > >>> send/receive the commands. You don't want nor need that in the kernel. > >>> > >>> The only place where routing things to the IR core is useful is when > > someone > >>> points a remote at a TV (for example), which then passes it over CEC to > > your > >>> device which is not a repeater but can actually handle the remote command. > >>> > >>> This is a future extension, though. > >> > >> There are two separate things when dealing with CEC: the low-level kernel > >> implementation of a bus for connecting with CEC devices, and userspace APIs > >> for using its features. > >> > >> If you were needing it only internally inside the kernel, there's no need > > for > >> new ioctl's. So, your proposal seems to add a raw interface for it, and do > >> all the work in userspace. > >> > >> An alternative approach, that it is the way most Kernel API's do is to > > write/use > >> higher userspace APIs, abstracting the hardware internals. V4L, DVB and > >> RC, > > input/event, > >> vfs, tty, etc are good examples of how we do APIs in Linux. We should only > > go > >> to a raw API if the high-level ones won't work. > > > > What high-level API? There isn't much high-level about CEC. It's a very > > simplistic standard. Each packet has a source and destination address (0-14 > > which you can choose yourself), an optional command with an optional > > payload. > > You can put in pretty much what you want since you can make custom commands > > as > > well. > > I2C is even simpler in theory (1 TX wire, 1 RX wire, low speed, 7 bits for > address), > but a hole subsystem and several API's are needed in order to handle with I2C > device complexity. Nope, CEC is simpler: just one line and 400 bits per second. I win :-) More to the point: i2c is a generic protocol to communicate with hardware devices. Emphasis on 'generic'. CEC is far from generic: it is full of assumptions and specific use-cases. In that respect it closely resembles RDS: this too is a low bandwidth, application-specific protocol. For RDS the API is also at the packet level, requiring a library to make use of it. > > > You also assume that you can handle packets at a high level. But you can't, > > because what you want to do with packets depends very much on what device > > you > > are: TV, recorder, set-top, CEC switch, etc. > > Again, it sounds similar to I2C. No. The difference is that I2C is a generic protocol. For CEC these roles are hardwired in the protocol. > > >> Also, a raw-level implementation of CEC may/will interfere on higher level > >> interfaces. For example, assuming that we have both raw and RC interfaces > > using > >> HDMI-CIC, a raw access on one process during a RC reception or transmit > > could > >> interfere on another process using the high-level interface for RC (as a > >> raw > >> access to a block device may actually corrupt data). So, raw interfaces are > >> evil, and generally require CAP_SYS_ADMIN. > > > > ??? If we add a flag that causes the IR commands to go to the IR core, then > > they will obviously not appear on the normal CEC interface. > > > >> So, I think we should first discuss what are the needs, and then discuss > >> how > >> to implement them. > > > > Well, the need is to receive and transmit CEC packets. And this is a > > possible > > implementation. > > > > Don't give CEC too much status: CEC is a very simplistic, stupid and very > > low > > bandwidth protocol. It is even simpler than RDS. > > We should look what usage you have in mind for CEC, and then write an API for > it, > not the opposite. > > Usage of CEC for remote-controlling devices is one application whose usage is > clear > to me, and that we have already Kernel APIs for them. As usual, the current > API's may > need additions in order to support some features. > > What are the other use-cases? Please read the CEC standard. In particular look at the CEC 13 chapter, which is basically a list of the common use-cases. This proposed API basically handles the protocol up to section CEC 9. CEC 15 is also useful to look at. All this is highly specific to consumer electronics (and very restrictive as well: something like video conferencing equipment doesn't really fit well in this protocol). All this screams 'userspace CEC protocol library' to me, with just the hardware part of the protocol in the kernel. For exactly the same reason why RDS parsing is done in userspace. The only exception I see is the "Remote Control Pass Through" (CEC 13.13). This can optionally be routed via the IR core. Reg
Re: [RFC] HDMI-CEC proposal
Em 01-03-2011 12:49, Hans Verkuil escreveu: > On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote: >> Em 01-03-2011 11:38, Hans Verkuil escreveu: >>> Hi Mauro, >>> >>> On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote: Hi Martin, Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu: > Author: Martin Bugge > Date: Tue, 1 March 2010 > == > > This is a proposal for adding a Consumer Electronic Control (CEC) API to >>> V4L2. > This document describes the changes and new ioctls needed. > > Version 1.0 (This is first version) > > Background > == > CEC is a protocol that provides high-level control functions between >>> various audiovisual products. > It is an optional supplement to the High-Definition Multimedia Interface >>> Specification (HDMI). > Physical layer is a one-wire bidirectional serial bus that uses the >>> industry-standard AV.link protocol. > > In short: CEC uses pin 13 on the HDMI connector to transmit and receive >>> small data-packets > (maximum 16 bytes including a 1 byte header) at low data rates >>> (~400 bits/s). > > A CEC device may have any of 15 logical addresses (0 - 14). > (address 15 is broadcast and some addresses are reserved) > > > References > == > [1] High-Definition Multimedia Interface Specification version 1.3a, > Supplement 1 Consumer Electronic Control (CEC). > http://www.hdmi.org/manufacturer/specification.aspx > > [2] >>> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf > > > Proposed solution > = > > Two new ioctls: > VIDIOC_CEC_CAP (read) > VIDIOC_CEC_CMD (read/write) How this proposal will interact with RC core? The way I see it, HDMI-CEC > is >>> just a way to get/send Remote Controller data, and should be interacting with the proper Kernel >>> subsystems, e. g., with Remote Controller and input/event subsystems. >>> >>> I knew you were going to mention this :-) >>> >>> Actually, while CEC does support IR commands, this is only a very small > part >>> of the standard. Routing IR commands to the IR core is possible to do, >>> although it is not in this initial version. Should this be needed, then a > flag >>> can be created that tells V4L to route IR commands to the IR core. >>> >>> This should be optional, though, because if you are a repeater you do not > want >>> to pass such IR commands to the IR core, instead you want to retransmit > them >>> to a CEC output. >>> I don't think we need two ioctls for that, as RC capabilities are already >>> exported via sysfs, and we have two interfaces already for receiving events > (input/event >>> and lirc). For sending, lirc interface might be used, but it is currently focused > only >>> on sending raw pulse/space sequences. So, we'll need to add some capability there > for >>> IR/CEC TX. I had a few discussions about that with Jarod, but we didn't write yet an >>> interface for it. >>> >>> Again, CEC != IR. All you need is a simple API to be able to send and > receive >>> CEC packets and a libcec that you can use to do the topology discovery and >>> send/receive the commands. You don't want nor need that in the kernel. >>> >>> The only place where routing things to the IR core is useful is when > someone >>> points a remote at a TV (for example), which then passes it over CEC to > your >>> device which is not a repeater but can actually handle the remote command. >>> >>> This is a future extension, though. >> >> There are two separate things when dealing with CEC: the low-level kernel >> implementation of a bus for connecting with CEC devices, and userspace APIs >> for using its features. >> >> If you were needing it only internally inside the kernel, there's no need > for >> new ioctl's. So, your proposal seems to add a raw interface for it, and do >> all the work in userspace. >> >> An alternative approach, that it is the way most Kernel API's do is to > write/use >> higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, > input/event, >> vfs, tty, etc are good examples of how we do APIs in Linux. We should only > go >> to a raw API if the high-level ones won't work. > > What high-level API? There isn't much high-level about CEC. It's a very > simplistic standard. Each packet has a source and destination address (0-14 > which you can choose yourself), an optional command with an optional payload. > You can put in pretty much what you want since you can make custom commands > as > well. I2C is even simpler in theory (1 TX wire, 1 RX wire, low speed, 7 bits for address), but a hole subsystem and several API's are needed in order to handle with I2C device complexity. > You also assume that you can handle packets at
Re: [RFC] HDMI-CEC proposal
On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote: > Em 01-03-2011 11:38, Hans Verkuil escreveu: > > Hi Mauro, > > > > On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote: > >> Hi Martin, > >> > >> Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu: > >>> Author: Martin Bugge > >>> Date: Tue, 1 March 2010 > >>> == > >>> > >>> This is a proposal for adding a Consumer Electronic Control (CEC) API to > > V4L2. > >>> This document describes the changes and new ioctls needed. > >>> > >>> Version 1.0 (This is first version) > >>> > >>> Background > >>> == > >>> CEC is a protocol that provides high-level control functions between > > various audiovisual products. > >>> It is an optional supplement to the High-Definition Multimedia Interface > > Specification (HDMI). > >>> Physical layer is a one-wire bidirectional serial bus that uses the > > industry-standard AV.link protocol. > >>> > >>> In short: CEC uses pin 13 on the HDMI connector to transmit and receive > > small data-packets > >>> (maximum 16 bytes including a 1 byte header) at low data rates > > (~400 bits/s). > >>> > >>> A CEC device may have any of 15 logical addresses (0 - 14). > >>> (address 15 is broadcast and some addresses are reserved) > >>> > >>> > >>> References > >>> == > >>> [1] High-Definition Multimedia Interface Specification version 1.3a, > >>> Supplement 1 Consumer Electronic Control (CEC). > >>> http://www.hdmi.org/manufacturer/specification.aspx > >>> > >>> [2] > > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf > >>> > >>> > >>> Proposed solution > >>> = > >>> > >>> Two new ioctls: > >>> VIDIOC_CEC_CAP (read) > >>> VIDIOC_CEC_CMD (read/write) > >> > >> How this proposal will interact with RC core? The way I see it, HDMI-CEC is > > just a way to get/send > >> Remote Controller data, and should be interacting with the proper Kernel > > subsystems, e. g., > >> with Remote Controller and input/event subsystems. > > > > I knew you were going to mention this :-) > > > > Actually, while CEC does support IR commands, this is only a very small part > > of the standard. Routing IR commands to the IR core is possible to do, > > although it is not in this initial version. Should this be needed, then a flag > > can be created that tells V4L to route IR commands to the IR core. > > > > This should be optional, though, because if you are a repeater you do not want > > to pass such IR commands to the IR core, instead you want to retransmit them > > to a CEC output. > > > >> > >> I don't think we need two ioctls for that, as RC capabilities are already > > exported via > >> sysfs, and we have two interfaces already for receiving events (input/event > > and lirc). > >> For sending, lirc interface might be used, but it is currently focused only > > on sending > >> raw pulse/space sequences. So, we'll need to add some capability there for > > IR/CEC TX. > >> I had a few discussions about that with Jarod, but we didn't write yet an > > interface for it. > > > > Again, CEC != IR. All you need is a simple API to be able to send and receive > > CEC packets and a libcec that you can use to do the topology discovery and > > send/receive the commands. You don't want nor need that in the kernel. > > > > The only place where routing things to the IR core is useful is when someone > > points a remote at a TV (for example), which then passes it over CEC to your > > device which is not a repeater but can actually handle the remote command. > > > > This is a future extension, though. > > There are two separate things when dealing with CEC: the low-level kernel > implementation of a bus for connecting with CEC devices, and userspace APIs > for using its features. > > If you were needing it only internally inside the kernel, there's no need for > new ioctl's. So, your proposal seems to add a raw interface for it, and do > all the work in userspace. > > An alternative approach, that it is the way most Kernel API's do is to write/use > higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, input/event, > vfs, tty, etc are good examples of how we do APIs in Linux. We should only go > to a raw API if the high-level ones won't work. What high-level API? There isn't much high-level about CEC. It's a very simplistic standard. Each packet has a source and destination address (0-14 which you can choose yourself), an optional command with an optional payload. You can put in pretty much what you want since you can make custom commands as well. You also assume that you can handle packets at a high level. But you can't, because what you want to do with packets depends very much on what device you are: TV, recorder, set-top, CEC switch, etc. > Also, a raw-level implementation of CEC may/will interfere on higher level > interfaces. For example, assuming that we have bo
Re: [RFC] HDMI-CEC proposal
Em 01-03-2011 11:38, Hans Verkuil escreveu: > Hi Mauro, > > On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote: >> Hi Martin, >> >> Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu: >>> Author: Martin Bugge >>> Date: Tue, 1 March 2010 >>> == >>> >>> This is a proposal for adding a Consumer Electronic Control (CEC) API to > V4L2. >>> This document describes the changes and new ioctls needed. >>> >>> Version 1.0 (This is first version) >>> >>> Background >>> == >>> CEC is a protocol that provides high-level control functions between > various audiovisual products. >>> It is an optional supplement to the High-Definition Multimedia Interface > Specification (HDMI). >>> Physical layer is a one-wire bidirectional serial bus that uses the > industry-standard AV.link protocol. >>> >>> In short: CEC uses pin 13 on the HDMI connector to transmit and receive > small data-packets >>> (maximum 16 bytes including a 1 byte header) at low data rates > (~400 bits/s). >>> >>> A CEC device may have any of 15 logical addresses (0 - 14). >>> (address 15 is broadcast and some addresses are reserved) >>> >>> >>> References >>> == >>> [1] High-Definition Multimedia Interface Specification version 1.3a, >>> Supplement 1 Consumer Electronic Control (CEC). >>> http://www.hdmi.org/manufacturer/specification.aspx >>> >>> [2] > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf >>> >>> >>> Proposed solution >>> = >>> >>> Two new ioctls: >>> VIDIOC_CEC_CAP (read) >>> VIDIOC_CEC_CMD (read/write) >> >> How this proposal will interact with RC core? The way I see it, HDMI-CEC is > just a way to get/send >> Remote Controller data, and should be interacting with the proper Kernel > subsystems, e. g., >> with Remote Controller and input/event subsystems. > > I knew you were going to mention this :-) > > Actually, while CEC does support IR commands, this is only a very small part > of the standard. Routing IR commands to the IR core is possible to do, > although it is not in this initial version. Should this be needed, then a > flag > can be created that tells V4L to route IR commands to the IR core. > > This should be optional, though, because if you are a repeater you do not > want > to pass such IR commands to the IR core, instead you want to retransmit them > to a CEC output. > >> >> I don't think we need two ioctls for that, as RC capabilities are already > exported via >> sysfs, and we have two interfaces already for receiving events (input/event > and lirc). >> For sending, lirc interface might be used, but it is currently focused only > on sending >> raw pulse/space sequences. So, we'll need to add some capability there for > IR/CEC TX. >> I had a few discussions about that with Jarod, but we didn't write yet an > interface for it. > > Again, CEC != IR. All you need is a simple API to be able to send and receive > CEC packets and a libcec that you can use to do the topology discovery and > send/receive the commands. You don't want nor need that in the kernel. > > The only place where routing things to the IR core is useful is when someone > points a remote at a TV (for example), which then passes it over CEC to your > device which is not a repeater but can actually handle the remote command. > > This is a future extension, though. There are two separate things when dealing with CEC: the low-level kernel implementation of a bus for connecting with CEC devices, and userspace APIs for using its features. If you were needing it only internally inside the kernel, there's no need for new ioctl's. So, your proposal seems to add a raw interface for it, and do all the work in userspace. An alternative approach, that it is the way most Kernel API's do is to write/use higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, input/event, vfs, tty, etc are good examples of how we do APIs in Linux. We should only go to a raw API if the high-level ones won't work. Also, a raw-level implementation of CEC may/will interfere on higher level interfaces. For example, assuming that we have both raw and RC interfaces using HDMI-CIC, a raw access on one process during a RC reception or transmit could interfere on another process using the high-level interface for RC (as a raw access to a block device may actually corrupt data). So, raw interfaces are evil, and generally require CAP_SYS_ADMIN. So, I think we should first discuss what are the needs, and then discuss how to implement them. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
On 03/01/2011 02:47 PM, Andy Walls wrote: On Tue, 2011-03-01 at 10:59 +0100, Martin Bugge (marbugge) wrote: Author: Martin Bugge Date: Tue, 1 March 2010 == This is a proposal for adding a Consumer Electronic Control (CEC) API to V4L2. This document describes the changes and new ioctls needed. Version 1.0 (This is first version) Background == CEC is a protocol that provides high-level control functions between various audiovisual products. It is an optional supplement to the High-Definition Multimedia Interface Specification (HDMI). Physical layer is a one-wire bidirectional serial bus that uses the industry-standard AV.link protocol. In short: CEC uses pin 13 on the HDMI connector to transmit and receive small data-packets (maximum 16 bytes including a 1 byte header) at low data rates (~400 bits/s). A CEC device may have any of 15 logical addresses (0 - 14). (address 15 is broadcast and some addresses are reserved) References == [1] High-Definition Multimedia Interface Specification version 1.3a, Supplement 1 Consumer Electronic Control (CEC). http://www.hdmi.org/manufacturer/specification.aspx [2] http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf Hi Martin, After reading the whitepaper, and the the general purpose nature of your proposed API calls, I'm wondering if a socket interface wouldn't be appropriate. The CEC bus seems to be designed as a network. A broadcast medium, with multiport devices (switches), physical (MAC) addresses in dotted decimal notation (1.0.0.0), dynamic logical address assignment, arbitration (Media Access Control), etc. The whitepaper even suggests OSI layers, using the term PHY in a few places. A network interface could be implemented something like what is done for SLIP in figure 2 here (compare with figure 1): http://www.linux.it/~rubini/docs/serial/serial.html Using that diagram as a guide, a socket interface would need a CEC tty line discipline, CEC network device, and code to hook the CEC serial device to the tty layer. Multiple CEC serial devices would show up as multiple network interfaces. Once a network device is available, user-space could then use AF_PACKET sockets. If CEC's layers are standardized enough, a new address family could be added to the kernel, I guess. Of course, all that is a lot of work. Since Cisco should have some networking experts hanging around, maybe it wouldn't be too hard. ;) Regards, Andy Hi Andy and thank you. I agree its always nice to strive for a generic solution, but I don't think I'm able to get hold of the resources required. In CEC the physical address is determined by the edid information from the HDMI sink, or for the HDMI sink its HDMI port number. While the logical address describes the type of device, TV, Recorder, Tuner, etc. From that point of view I do think that the CEC protocol is closly connected to the HDMI connector, such that it belongs together with a video device. But I will ask my "mentor" for advice. Regards, Martin Proposed solution = Two new ioctls: VIDIOC_CEC_CAP (read) VIDIOC_CEC_CMD (read/write) VIDIOC_CEC_CAP: --- struct vl2_cec_cap { __u32 logicaldevices; __u32 reserved[7]; }; The capability ioctl will return the number of logical devices/addresses which can be simultaneously supported on this HW. 0: This HW don't support CEC. 1 -> 14: This HW supports n logical devices simultaneously. VIDIOC_CEC_CMD: --- struct v4l2_cec_cmd { __u32 cmd; __u32 reserved[7]; union { struct { __u32 index; __u32 enable; __u32 addr; } conf; struct { __u32 len; __u8 msg[16]; __u32 status; } data; __u32 raw[8]; }; }; Alternatively the data struct could be: struct { __u8 initiator; __u8 destination; __u8 len; __u8 msg[15]; __u32 status; } data; Commands: #define V4L2_CEC_CMD_CONF (1) #define V4L2_CEC_CMD_TX(2) #define V4L2_CEC_CMD_RX(3) Tx status field: #define V4L2_CEC_STAT_TX_OK(0) #define V4L2_CEC_STAT_TX_ARB_LOST (1) #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2) The command ioctl is used both for configuration and to receive/transmit data. * The configuration command must be done for each logical device address which is to be enabled on this HW. Maximum number of logical devices is found with the capability ioctl. conf: index: 0 -> number_of_logical_devices-1 enable: true/false addr: logical address By default all logical devices are disabled. * Tx/Rx command data: len:length of message (data + header) msg:the raw
Re: [RFC] HDMI-CEC proposal
Hi Mauro, On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote: > Hi Martin, > > Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu: > > Author: Martin Bugge > > Date: Tue, 1 March 2010 > > == > > > > This is a proposal for adding a Consumer Electronic Control (CEC) API to V4L2. > > This document describes the changes and new ioctls needed. > > > > Version 1.0 (This is first version) > > > > Background > > == > > CEC is a protocol that provides high-level control functions between various audiovisual products. > > It is an optional supplement to the High-Definition Multimedia Interface Specification (HDMI). > > Physical layer is a one-wire bidirectional serial bus that uses the industry-standard AV.link protocol. > > > > In short: CEC uses pin 13 on the HDMI connector to transmit and receive small data-packets > > (maximum 16 bytes including a 1 byte header) at low data rates (~400 bits/s). > > > > A CEC device may have any of 15 logical addresses (0 - 14). > > (address 15 is broadcast and some addresses are reserved) > > > > > > References > > == > > [1] High-Definition Multimedia Interface Specification version 1.3a, > > Supplement 1 Consumer Electronic Control (CEC). > > http://www.hdmi.org/manufacturer/specification.aspx > > > > [2] http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf > > > > > > Proposed solution > > = > > > > Two new ioctls: > > VIDIOC_CEC_CAP (read) > > VIDIOC_CEC_CMD (read/write) > > How this proposal will interact with RC core? The way I see it, HDMI-CEC is just a way to get/send > Remote Controller data, and should be interacting with the proper Kernel subsystems, e. g., > with Remote Controller and input/event subsystems. I knew you were going to mention this :-) Actually, while CEC does support IR commands, this is only a very small part of the standard. Routing IR commands to the IR core is possible to do, although it is not in this initial version. Should this be needed, then a flag can be created that tells V4L to route IR commands to the IR core. This should be optional, though, because if you are a repeater you do not want to pass such IR commands to the IR core, instead you want to retransmit them to a CEC output. > > I don't think we need two ioctls for that, as RC capabilities are already exported via > sysfs, and we have two interfaces already for receiving events (input/event and lirc). > For sending, lirc interface might be used, but it is currently focused only on sending > raw pulse/space sequences. So, we'll need to add some capability there for IR/CEC TX. > I had a few discussions about that with Jarod, but we didn't write yet an interface for it. Again, CEC != IR. All you need is a simple API to be able to send and receive CEC packets and a libcec that you can use to do the topology discovery and send/receive the commands. You don't want nor need that in the kernel. The only place where routing things to the IR core is useful is when someone points a remote at a TV (for example), which then passes it over CEC to your device which is not a repeater but can actually handle the remote command. This is a future extension, though. Regards, Hans > > > > > > VIDIOC_CEC_CAP: > > --- > > > > struct vl2_cec_cap { > >__u32 logicaldevices; > >__u32 reserved[7]; > > }; > > > > The capability ioctl will return the number of logical devices/addresses which can be > > simultaneously supported on this HW. > > 0: This HW don't support CEC. > > 1 -> 14: This HW supports n logical devices simultaneously. > > > > VIDIOC_CEC_CMD: > > --- > > > > struct v4l2_cec_cmd { > > __u32 cmd; > > __u32 reserved[7]; > > union { > > struct { > > __u32 index; > > __u32 enable; > > __u32 addr; > > } conf; > > struct { > > __u32 len; > > __u8 msg[16]; > > __u32 status; > > } data; > > __u32 raw[8]; > > }; > > }; > > > > Alternatively the data struct could be: > > struct { > > __u8 initiator; > > __u8 destination; > > __u8 len; > > __u8 msg[15]; > > __u32 status; > > } data; > > > > Commands: > > > > #define V4L2_CEC_CMD_CONF (1) > > #define V4L2_CEC_CMD_TX(2) > > #define V4L2_CEC_CMD_RX(3) > > > > Tx status field: > > > > #define V4L2_CEC_STAT_TX_OK(0) > > #define V4L2_CEC_STAT_TX_ARB_LOST (1) > > #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2) > > > > The command ioctl is used both for configuration and to receive/transmit data. > > > > * The configuration command must be done for each logical device address > > which is to be enabled on this HW. Maximum number of logical devices > > is found with the capability ioctl. > > conf
Re: [RFC] HDMI-CEC proposal
On Tue, 2011-03-01 at 10:59 +0100, Martin Bugge (marbugge) wrote: > Author: Martin Bugge > Date: Tue, 1 March 2010 > == > > This is a proposal for adding a Consumer Electronic Control (CEC) API to > V4L2. > This document describes the changes and new ioctls needed. > > Version 1.0 (This is first version) > > Background > == > CEC is a protocol that provides high-level control functions between > various audiovisual products. > It is an optional supplement to the High-Definition Multimedia Interface > Specification (HDMI). > Physical layer is a one-wire bidirectional serial bus that uses the > industry-standard AV.link protocol. > > In short: CEC uses pin 13 on the HDMI connector to transmit and receive > small data-packets >(maximum 16 bytes including a 1 byte header) at low data > rates (~400 bits/s). > > A CEC device may have any of 15 logical addresses (0 - 14). > (address 15 is broadcast and some addresses are reserved) > > > References > == > [1] High-Definition Multimedia Interface Specification version 1.3a, > Supplement 1 Consumer Electronic Control (CEC). > http://www.hdmi.org/manufacturer/specification.aspx > > [2] > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf Hi Martin, After reading the whitepaper, and the the general purpose nature of your proposed API calls, I'm wondering if a socket interface wouldn't be appropriate. The CEC bus seems to be designed as a network. A broadcast medium, with multiport devices (switches), physical (MAC) addresses in dotted decimal notation (1.0.0.0), dynamic logical address assignment, arbitration (Media Access Control), etc. The whitepaper even suggests OSI layers, using the term PHY in a few places. A network interface could be implemented something like what is done for SLIP in figure 2 here (compare with figure 1): http://www.linux.it/~rubini/docs/serial/serial.html Using that diagram as a guide, a socket interface would need a CEC tty line discipline, CEC network device, and code to hook the CEC serial device to the tty layer. Multiple CEC serial devices would show up as multiple network interfaces. Once a network device is available, user-space could then use AF_PACKET sockets. If CEC's layers are standardized enough, a new address family could be added to the kernel, I guess. Of course, all that is a lot of work. Since Cisco should have some networking experts hanging around, maybe it wouldn't be too hard. ;) Regards, Andy > Proposed solution > = > > Two new ioctls: > VIDIOC_CEC_CAP (read) > VIDIOC_CEC_CMD (read/write) > > VIDIOC_CEC_CAP: > --- > > struct vl2_cec_cap { > __u32 logicaldevices; > __u32 reserved[7]; > }; > > The capability ioctl will return the number of logical devices/addresses > which can be > simultaneously supported on this HW. > 0: This HW don't support CEC. > 1 -> 14: This HW supports n logical devices simultaneously. > > VIDIOC_CEC_CMD: > --- > > struct v4l2_cec_cmd { > __u32 cmd; > __u32 reserved[7]; > union { > struct { > __u32 index; > __u32 enable; > __u32 addr; > } conf; > struct { > __u32 len; > __u8 msg[16]; > __u32 status; > } data; > __u32 raw[8]; > }; > }; > > Alternatively the data struct could be: > struct { > __u8 initiator; > __u8 destination; > __u8 len; > __u8 msg[15]; > __u32 status; > } data; > > Commands: > > #define V4L2_CEC_CMD_CONF (1) > #define V4L2_CEC_CMD_TX(2) > #define V4L2_CEC_CMD_RX(3) > > Tx status field: > > #define V4L2_CEC_STAT_TX_OK(0) > #define V4L2_CEC_STAT_TX_ARB_LOST (1) > #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2) > > The command ioctl is used both for configuration and to receive/transmit > data. > > * The configuration command must be done for each logical device address >which is to be enabled on this HW. Maximum number of logical devices >is found with the capability ioctl. > conf: > index: 0 -> number_of_logical_devices-1 > enable: true/false > addr: logical address > >By default all logical devices are disabled. > > * Tx/Rx command > data: > len:length of message (data + header) > msg:the raw CEC message received/transmitted > status: when the driver is in blocking mode it gives the > result for transmit. > > Events > -- > > In the case of non-blocking mode the driver will issue the following events: > > V4L2_EVENT_CEC_TX > V4L2_EVENT_CEC_RX > > V4L2_EVENT_CEC_TX > - > * transmit is complete with the following status: > Add an additional struct to the struct v4l2_event > > struct v4l2_event_c
Re: [RFC] HDMI-CEC proposal
Hi Martin, Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu: > Author: Martin Bugge > Date: Tue, 1 March 2010 > == > > This is a proposal for adding a Consumer Electronic Control (CEC) API to V4L2. > This document describes the changes and new ioctls needed. > > Version 1.0 (This is first version) > > Background > == > CEC is a protocol that provides high-level control functions between various > audiovisual products. > It is an optional supplement to the High-Definition Multimedia Interface > Specification (HDMI). > Physical layer is a one-wire bidirectional serial bus that uses the > industry-standard AV.link protocol. > > In short: CEC uses pin 13 on the HDMI connector to transmit and receive small > data-packets > (maximum 16 bytes including a 1 byte header) at low data rates > (~400 bits/s). > > A CEC device may have any of 15 logical addresses (0 - 14). > (address 15 is broadcast and some addresses are reserved) > > > References > == > [1] High-Definition Multimedia Interface Specification version 1.3a, > Supplement 1 Consumer Electronic Control (CEC). > http://www.hdmi.org/manufacturer/specification.aspx > > [2] http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf > > > Proposed solution > = > > Two new ioctls: > VIDIOC_CEC_CAP (read) > VIDIOC_CEC_CMD (read/write) How this proposal will interact with RC core? The way I see it, HDMI-CEC is just a way to get/send Remote Controller data, and should be interacting with the proper Kernel subsystems, e. g., with Remote Controller and input/event subsystems. I don't think we need two ioctls for that, as RC capabilities are already exported via sysfs, and we have two interfaces already for receiving events (input/event and lirc). For sending, lirc interface might be used, but it is currently focused only on sending raw pulse/space sequences. So, we'll need to add some capability there for IR/CEC TX. I had a few discussions about that with Jarod, but we didn't write yet an interface for it. > > VIDIOC_CEC_CAP: > --- > > struct vl2_cec_cap { >__u32 logicaldevices; >__u32 reserved[7]; > }; > > The capability ioctl will return the number of logical devices/addresses > which can be > simultaneously supported on this HW. > 0: This HW don't support CEC. > 1 -> 14: This HW supports n logical devices simultaneously. > > VIDIOC_CEC_CMD: > --- > > struct v4l2_cec_cmd { > __u32 cmd; > __u32 reserved[7]; > union { > struct { > __u32 index; > __u32 enable; > __u32 addr; > } conf; > struct { > __u32 len; > __u8 msg[16]; > __u32 status; > } data; > __u32 raw[8]; > }; > }; > > Alternatively the data struct could be: > struct { > __u8 initiator; > __u8 destination; > __u8 len; > __u8 msg[15]; > __u32 status; > } data; > > Commands: > > #define V4L2_CEC_CMD_CONF (1) > #define V4L2_CEC_CMD_TX(2) > #define V4L2_CEC_CMD_RX(3) > > Tx status field: > > #define V4L2_CEC_STAT_TX_OK(0) > #define V4L2_CEC_STAT_TX_ARB_LOST (1) > #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2) > > The command ioctl is used both for configuration and to receive/transmit data. > > * The configuration command must be done for each logical device address > which is to be enabled on this HW. Maximum number of logical devices > is found with the capability ioctl. > conf: > index: 0 -> number_of_logical_devices-1 > enable: true/false > addr: logical address > > By default all logical devices are disabled. > > * Tx/Rx command > data: > len:length of message (data + header) > msg:the raw CEC message received/transmitted > status: when the driver is in blocking mode it gives the result for > transmit. > > Events > -- > > In the case of non-blocking mode the driver will issue the following events: > > V4L2_EVENT_CEC_TX > V4L2_EVENT_CEC_RX > > V4L2_EVENT_CEC_TX > - > * transmit is complete with the following status: > Add an additional struct to the struct v4l2_event > > struct v4l2_event_cec_tx { >__u32 status; > } > > V4L2_EVENT_CEC_RX > - > * received a complete message > > > Comments ? > >Martin Bugge > > -- > Martin Bugge - Tandberg (now a part of Cisco) > -- > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/ma
[RFC] HDMI-CEC proposal
Author: Martin Bugge Date: Tue, 1 March 2010 == This is a proposal for adding a Consumer Electronic Control (CEC) API to V4L2. This document describes the changes and new ioctls needed. Version 1.0 (This is first version) Background == CEC is a protocol that provides high-level control functions between various audiovisual products. It is an optional supplement to the High-Definition Multimedia Interface Specification (HDMI). Physical layer is a one-wire bidirectional serial bus that uses the industry-standard AV.link protocol. In short: CEC uses pin 13 on the HDMI connector to transmit and receive small data-packets (maximum 16 bytes including a 1 byte header) at low data rates (~400 bits/s). A CEC device may have any of 15 logical addresses (0 - 14). (address 15 is broadcast and some addresses are reserved) References == [1] High-Definition Multimedia Interface Specification version 1.3a, Supplement 1 Consumer Electronic Control (CEC). http://www.hdmi.org/manufacturer/specification.aspx [2] http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf Proposed solution = Two new ioctls: VIDIOC_CEC_CAP (read) VIDIOC_CEC_CMD (read/write) VIDIOC_CEC_CAP: --- struct vl2_cec_cap { __u32 logicaldevices; __u32 reserved[7]; }; The capability ioctl will return the number of logical devices/addresses which can be simultaneously supported on this HW. 0: This HW don't support CEC. 1 -> 14: This HW supports n logical devices simultaneously. VIDIOC_CEC_CMD: --- struct v4l2_cec_cmd { __u32 cmd; __u32 reserved[7]; union { struct { __u32 index; __u32 enable; __u32 addr; } conf; struct { __u32 len; __u8 msg[16]; __u32 status; } data; __u32 raw[8]; }; }; Alternatively the data struct could be: struct { __u8 initiator; __u8 destination; __u8 len; __u8 msg[15]; __u32 status; } data; Commands: #define V4L2_CEC_CMD_CONF (1) #define V4L2_CEC_CMD_TX(2) #define V4L2_CEC_CMD_RX(3) Tx status field: #define V4L2_CEC_STAT_TX_OK(0) #define V4L2_CEC_STAT_TX_ARB_LOST (1) #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2) The command ioctl is used both for configuration and to receive/transmit data. * The configuration command must be done for each logical device address which is to be enabled on this HW. Maximum number of logical devices is found with the capability ioctl. conf: index: 0 -> number_of_logical_devices-1 enable: true/false addr: logical address By default all logical devices are disabled. * Tx/Rx command data: len:length of message (data + header) msg:the raw CEC message received/transmitted status: when the driver is in blocking mode it gives the result for transmit. Events -- In the case of non-blocking mode the driver will issue the following events: V4L2_EVENT_CEC_TX V4L2_EVENT_CEC_RX V4L2_EVENT_CEC_TX - * transmit is complete with the following status: Add an additional struct to the struct v4l2_event struct v4l2_event_cec_tx { __u32 status; } V4L2_EVENT_CEC_RX - * received a complete message Comments ? Martin Bugge -- Martin Bugge - Tandberg (now a part of Cisco) -- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html