Re: [RFC] HDMI-CEC proposal

2012-05-10 Thread Hans Verkuil
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

2012-05-10 Thread Florian Fainelli
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

2012-04-17 Thread Oliver Schinagl
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

2012-04-17 Thread Anssi Hannula
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

2012-04-13 Thread Florian Fainelli

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

2012-04-12 Thread Hans Verkuil
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

2012-04-12 Thread Oliver Schinagl
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

2012-04-12 Thread Florian Fainelli

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

2011-03-14 Thread Martin Bugge (marbugge)

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

2011-03-11 Thread Daniel Glöckner
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

2011-03-11 Thread Martin Bugge (marbugge)

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

2011-03-03 Thread Martin Bugge (marbugge)

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

2011-03-03 Thread Laurent Pinchart
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

2011-03-02 Thread Alex Deucher
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

2011-03-02 Thread Martin Bugge (marbugge)

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

2011-03-02 Thread Hans Verkuil
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

2011-03-01 Thread Daniel Glöckner
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

2011-03-01 Thread Alex Deucher
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

2011-03-01 Thread Hans Verkuil
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

2011-03-01 Thread Hans Verkuil
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

2011-03-01 Thread Mauro Carvalho Chehab
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

2011-03-01 Thread Hans Verkuil
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

2011-03-01 Thread Mauro Carvalho Chehab
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

2011-03-01 Thread Martin Bugge (marbugge)

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

2011-03-01 Thread Hans Verkuil
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

2011-03-01 Thread Andy Walls
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

2011-03-01 Thread Mauro Carvalho Chehab
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

2011-03-01 Thread Martin Bugge (marbugge)

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