Proposal

[Miss Zeliha Omer Faruk]

Hello

Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.

Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey

Proposal

[Miss Zeliha Omer Faruk]

Hello

Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.

Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey

Proposal

[Zeliha Omer Faruk]

--
Hello

Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.

Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey

Proposal

[MS Zeliha Omer Faruk]

Hello

   Greetings to you today i asked before but i did't get a response please
i know this might come to you as a surprise because you do not know me
personally i have a business proposal for you please reply for more
info.



Best Regards,

Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
 Sisli - Istanbul, Turkey

Proposal

[MS Zeliha Omer Faruk]

Hello

Greeetings to you please did you get my previous email regarding my
investment proposal last week friday ?

MS.Zeliha ömer faruk
zeliha.omer.fa...@gmail.com

business Proposal / Geschäftsvorschlag

[Anders Karlsson]

I have a business Proposal for you, contact me directly 
This business has a cash involvement of $250,000,000.00

Anders Karlsson

Ich habe einen Geschäftsvorschlag für Sie, kontaktieren Sie mich direkt

Dieses Unternehmen hat eine Beteiligung von $ 250.000.000,00

- [] Anders Karlsson

Proposal

[Melisa Mehmet]

Hello 


   
   Greetings to you today i asked before but i did't get a response please i 
know this might come to you as a surprise because you do not know me personally 
so i will give you a video call to explain more but did you get my previous 
email ? Let me know asap.





Best Regards,

Miss Melisa Mehmet 

Esentepe Mahallesi Büyükdere 

Caddesi Kristal Kule Binasi
No:215
 Sisli - Istanbul, Turkey 

Business Proposal

[Albrecht Solicitor]

Good day!

I seek your consent to present you as the beneficiary of an unclaimed financial 
estate belonging to my late client. I am contacting you because you share a 
similar name as his. Get back to me so I give you comprehensive details if 
interested.

Regards
Albrecht.

Business Proposal

[Gerald Lawson]

Hello

Thanks for accepting my connection request and how is your family? At the 
moment i have a lucrative business and my instinct make me believe that we can 
work together with understanding and sincerity.

Do contact me on my private email: geraldlawso...@gmail.com
Ones i receive your reply, i shall elaborate my proposal in details to you.

Regards,
Gerald Lawson.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

BUSINESS PROPOSAL (DATE 28/1/2018)

[50ª Vara do Trabalho de São Paulo]

 I am Mrs. Fatimah Hassan.I have picked your email address for an 
inheritance of $250,000,000 Million Dollars.Please contact me for more 
details via   
 email:   fatimahha...@hotmail.comif interested.
.

Re: [media] vimc: API proposal, configuring the topology from user space

[Helen Koike]

Hi Hans,

Thanks for your review.

On 2017-07-28 10:39 AM, Hans Verkuil wrote:
> Hi Helen,
> 
> Finally after way too long I found some time to review this. See my comments
> below.
> 
> On 04/11/2017 12:53 AM, Helen Koike wrote:
>>
>> Hi,
>>
>> Continuing the discussion about the API of the vimc driver, I made some 
>> changes
>> based on the previous comments, please see below and let me know your 
>> opinion about it.
>>
>> Helen
>>
>> /***
>> Configfs considerations:
>> /
>> Informal definitions:
>>  subsystem: the root driver folder in user space (/configfs/vimc)
>>  item: aka a folder in user space
>>  attributes: aka files in the folder
>>  group: aka a folder that can contain subfolders (parent and child 
>> relation)
>>  default group: aka a subfolder that is created automatically when the 
>> "parent" folder is created
>>  it is not considered a child in terms of rmdir
>>
>> * Performing rmdir in a group will fail if it contain children that are 
>> not default groups, i.e, if the
>> folder contain subfolders that are default group, then it can be removed 
>> with rmdir, if the
>> subfolders were created with mkdir, then rmdir in the parent will fail.
>>
>> * Configfs has the notion of committable item but it is not implemented 
>> yet. A committable item is an item
>> that can be in one of two parent folders called: live and pending. The 
>> idea is to create and modify the item
>> in the pending directory and then to move the item through a rename to 
>> the live directory where
>> it can't be modified. This seems to be a nice feature for vimc, but as 
>> it is not available yet the
>> proposal below won't be based on this.
>>
>> * Groups can be dynamically created/destroyed by the driver whenever it 
>> wants. Afaik attributes can only
>> be created when the group or item is created and symlinks can only be 
>> create from user space, i.e, the
>> driver don't know how to create/destroy attributes or symlinks in anytime.
>>
>> /***
>> The API:
>> /
>>
>> In short, a topology like this one: http://goo.gl/Y7eUfu
>> Would look like this filesystem tree: https://goo.gl/mEOmOf
> 
> This mentions 'Yellow' lines, but since you dropped symlinks these no
> longer exist. You probably need to update the legend.
> 

Yes, thanks for noticing, I'll update when including it in the docs of
the API.

>>
>> v3 core changes:
>> - I removed the use of symlinks as I wans't able to see how to do it nicely.
>> - I use the names of the folders created by user space to retrieve 
>> information at mkdir time
>> - hotplug file in each entity
>> - hotplug file in each device
>> - reset file in each device
>>
>> * The /configfs/vimc subsystem
>> empty when the driver is loaded
> 
> I'm not sure about that. I think it would make sense that vimc when loaded
> would make one instance, unless otherwise told via a module option.

I don't think it really matters, the instance would be in unplugged
state anyway and it would need to be configured, but sure, we can add a
n_devs param as you proposed, no problem.

> 
> Something like this (taken from vivid):
> 
> parm:   n_devs: number of driver instances to create (uint)
> 
> By default this is 1, but can also be 0, 2, 3, etc.
> 
>>
>> * Create a device
>> Userspace can create a new vimc device with:
>>
>>  $ mkdir /configfs/vimc/any_name
>>  Example:
>>  $ mkdir /configfs/vimc/vimc0
>>  $ ls -l /configfs/vimc/vimc0
>>  hotplug
>>  reset
>>  entities/
>>  links/
>>
>> entities/ and links/ folder are default groups, thus they don't prevent 
>> rmdir vimc0/, but
>> rmdir will fail if it has any child inside entities/ or links/.
>> hotplug is used to plug and unplug the device, it can read "plugged" or 
>> "unplugged" and user can
>> write "plug" or "unplug" to change its state.
> 
> I would also support writing "plugged" and "unplugged". I.e. support both 
> variants.
> 

So it matches the values that you can read from the file, thanks for
this suggestion.

>> Changing hotplug state will never fail as the configfs tree will always 
>> be in a valid state.
>> reset is used to easily destroy all the topology without the need to 
>> walk through all the children
>> to perform 

Re: [media] vimc: API proposal, configuring the topology from user space

[Hans Verkuil]

Hi Helen,

Finally after way too long I found some time to review this. See my comments
below.

On 04/11/2017 12:53 AM, Helen Koike wrote:
> 
> Hi,
> 
> Continuing the discussion about the API of the vimc driver, I made some 
> changes
> based on the previous comments, please see below and let me know your 
> opinion about it.
> 
> Helen
> 
> /***
> Configfs considerations:
> /
> Informal definitions:
>   subsystem: the root driver folder in user space (/configfs/vimc)
>   item: aka a folder in user space
>   attributes: aka files in the folder
>   group: aka a folder that can contain subfolders (parent and child 
> relation)
>   default group: aka a subfolder that is created automatically when the 
> "parent" folder is created
>   it is not considered a child in terms of rmdir
> 
> * Performing rmdir in a group will fail if it contain children that are 
> not default groups, i.e, if the
> folder contain subfolders that are default group, then it can be removed 
> with rmdir, if the
> subfolders were created with mkdir, then rmdir in the parent will fail.
> 
> * Configfs has the notion of committable item but it is not implemented 
> yet. A committable item is an item
> that can be in one of two parent folders called: live and pending. The 
> idea is to create and modify the item
> in the pending directory and then to move the item through a rename to 
> the live directory where
> it can't be modified. This seems to be a nice feature for vimc, but as 
> it is not available yet the
> proposal below won't be based on this.
> 
> * Groups can be dynamically created/destroyed by the driver whenever it 
> wants. Afaik attributes can only
> be created when the group or item is created and symlinks can only be 
> create from user space, i.e, the
> driver don't know how to create/destroy attributes or symlinks in anytime.
> 
> /***
> The API:
> /
> 
> In short, a topology like this one: http://goo.gl/Y7eUfu
> Would look like this filesystem tree: https://goo.gl/mEOmOf

This mentions 'Yellow' lines, but since you dropped symlinks these no
longer exist. You probably need to update the legend.

> 
> v3 core changes:
> - I removed the use of symlinks as I wans't able to see how to do it nicely.
> - I use the names of the folders created by user space to retrieve 
> information at mkdir time
> - hotplug file in each entity
> - hotplug file in each device
> - reset file in each device
> 
> * The /configfs/vimc subsystem
> empty when the driver is loaded

I'm not sure about that. I think it would make sense that vimc when loaded
would make one instance, unless otherwise told via a module option.

Something like this (taken from vivid):

parm:   n_devs: number of driver instances to create (uint)

By default this is 1, but can also be 0, 2, 3, etc.

> 
> * Create a device
> Userspace can create a new vimc device with:
> 
>   $ mkdir /configfs/vimc/any_name
>   Example:
>   $ mkdir /configfs/vimc/vimc0
>   $ ls -l /configfs/vimc/vimc0
>   hotplug
>   reset
>   entities/
>   links/
> 
> entities/ and links/ folder are default groups, thus they don't prevent 
> rmdir vimc0/, but
> rmdir will fail if it has any child inside entities/ or links/.
> hotplug is used to plug and unplug the device, it can read "plugged" or 
> "unplugged" and user can
> write "plug" or "unplug" to change its state.

I would also support writing "plugged" and "unplugged". I.e. support both 
variants.

> Changing hotplug state will never fail as the configfs tree will always 
> be in a valid state.
> reset is used to easily destroy all the topology without the need to 
> walk through all the children
> to perform rmdir, writing 1 to reset file will set hotplug to 
> "unplugged" and erase all folders
> under entities/ and links/.
> 
> * Create an entity
> Userspace can create a new entity with:
> 
>   $ mkdir /configfs/vimc/vimc0/entities/:
>   Example:
>   $ mkdir /configfs/vimc/vimc0/entities/sensor:SensorA
>   $ ls -l /configfs/vimc/vimc0/entities/sensor:SensorA
>   hotplug
>   pad:source:0/
> 
> The name of the folder needs to be in the format : or it 
> will be rejected, this allows the
> creation of the right pads according to its role at mkdir time, 
> eliminating the previously proposed role
> and name files.
> hotplug is used to plug and unplug the hw block, it can read "plugged" 
> or "unplugged" and user can
> write "plug" or "unpl

Re: [media] vimc: API proposal, configuring the topology from user space

[Helen Koike]

ping

On 2017-04-10 07:53 PM, Helen Koike wrote:


Hi,

Continuing the discussion about the API of the vimc driver, I made some
changes
based on the previous comments, please see below and let me know your
opinion about it.

Helen

/***
Configfs considerations:
/
Informal definitions:
subsystem: the root driver folder in user space (/configfs/vimc)
item: aka a folder in user space
attributes: aka files in the folder
group: aka a folder that can contain subfolders (parent and child
relation)
default group: aka a subfolder that is created automatically when
the "parent" folder is created
it is not considered a child in terms of rmdir

* Performing rmdir in a group will fail if it contain children that are
not default groups, i.e, if the
folder contain subfolders that are default group, then it can be removed
with rmdir, if the
subfolders were created with mkdir, then rmdir in the parent will fail.

* Configfs has the notion of committable item but it is not implemented
yet. A committable item is an item
that can be in one of two parent folders called: live and pending. The
idea is to create and modify the item
in the pending directory and then to move the item through a rename to
the live directory where
it can't be modified. This seems to be a nice feature for vimc, but as
it is not available yet the
proposal below won't be based on this.

* Groups can be dynamically created/destroyed by the driver whenever it
wants. Afaik attributes can only
be created when the group or item is created and symlinks can only be
create from user space, i.e, the
driver don't know how to create/destroy attributes or symlinks in anytime.

/***
The API:
/

In short, a topology like this one: http://goo.gl/Y7eUfu
Would look like this filesystem tree: https://goo.gl/mEOmOf

v3 core changes:
- I removed the use of symlinks as I wans't able to see how to do it
nicely.
- I use the names of the folders created by user space to retrieve
information at mkdir time
- hotplug file in each entity
- hotplug file in each device
- reset file in each device

* The /configfs/vimc subsystem
empty when the driver is loaded

* Create a device
Userspace can create a new vimc device with:

$ mkdir /configfs/vimc/any_name
Example:
$ mkdir /configfs/vimc/vimc0
$ ls -l /configfs/vimc/vimc0
hotplug
reset
entities/
links/

entities/ and links/ folder are default groups, thus they don't prevent
rmdir vimc0/, but
rmdir will fail if it has any child inside entities/ or links/.
hotplug is used to plug and unplug the device, it can read "plugged" or
"unplugged" and user can
write "plug" or "unplug" to change its state.
Changing hotplug state will never fail as the configfs tree will always
be in a valid state.
reset is used to easily destroy all the topology without the need to
walk through all the children
to perform rmdir, writing 1 to reset file will set hotplug to
"unplugged" and erase all folders
under entities/ and links/.

* Create an entity
Userspace can create a new entity with:

$ mkdir /configfs/vimc/vimc0/entities/:
Example:
$ mkdir /configfs/vimc/vimc0/entities/sensor:SensorA
$ ls -l /configfs/vimc/vimc0/entities/sensor:SensorA
hotplug
pad:source:0/

The name of the folder needs to be in the format : or it
will be rejected, this allows the
creation of the right pads according to its role at mkdir time,
eliminating the previously proposed role
and name files.
hotplug is used to plug and unplug the hw block, it can read "plugged"
or "unplugged" and user can
write "plug" or "unplug" to change its state. As we don't support this
yet in the media core, changing it
will only be allowed if /configfs/vimc/vimc0/hotplug is "unplugged".
hotplug file is "unplugged" by default.
Pads will be created as default groups with the name in the format
pad:: and it
will be an empty folder.
If the hw block supports different number of pads, we could expose two
files:
sinks
sources
where the user space can write the desired number of sink and source
pads and the driver will dynamically
create the folders pad::

* Create a link
User space can create a link between two entities with:

$ mkdir
/configfs/vimc/vimc0/links/:->:

Example:
$ mkdir /configfs/vimc/vimc0/links/DebayerA:1->Scaler:0
$ ls -l /configfs/vimc/vimc0/links/DebayerA:1->Scaler:0
flags

mkdir will be rejected if folder is not on the format
:->:.
mkdir will be rejected if either  or 
are not found in /configfs/vimc/vimc0/entities/
The link will only be created if both entities are in "plugged" state.
When an entity is removed from /configfs/vimc/vimc0/entities/ with
rmdir, its corresponding link folders at
/configfs/vimc/vimc0/links will be automatically removed.
If one of the e

[media] vimc: API proposal, configuring the topology from user space

[Helen Koike]

Hi,

Continuing the discussion about the API of the vimc driver, I made some 
changes
based on the previous comments, please see below and let me know your 
opinion about it.


Helen

/***
Configfs considerations:
/
Informal definitions:
subsystem: the root driver folder in user space (/configfs/vimc)
item: aka a folder in user space
attributes: aka files in the folder
group: aka a folder that can contain subfolders (parent and child 
relation)
	default group: aka a subfolder that is created automatically when the 
"parent" folder is created

it is not considered a child in terms of rmdir

* Performing rmdir in a group will fail if it contain children that are 
not default groups, i.e, if the
folder contain subfolders that are default group, then it can be removed 
with rmdir, if the

subfolders were created with mkdir, then rmdir in the parent will fail.

* Configfs has the notion of committable item but it is not implemented 
yet. A committable item is an item
that can be in one of two parent folders called: live and pending. The 
idea is to create and modify the item
in the pending directory and then to move the item through a rename to 
the live directory where
it can't be modified. This seems to be a nice feature for vimc, but as 
it is not available yet the

proposal below won't be based on this.

* Groups can be dynamically created/destroyed by the driver whenever it 
wants. Afaik attributes can only
be created when the group or item is created and symlinks can only be 
create from user space, i.e, the

driver don't know how to create/destroy attributes or symlinks in anytime.

/***
The API:
/

In short, a topology like this one: http://goo.gl/Y7eUfu
Would look like this filesystem tree: https://goo.gl/mEOmOf

v3 core changes:
- I removed the use of symlinks as I wans't able to see how to do it nicely.
- I use the names of the folders created by user space to retrieve 
information at mkdir time

- hotplug file in each entity
- hotplug file in each device
- reset file in each device

* The /configfs/vimc subsystem
empty when the driver is loaded

* Create a device
Userspace can create a new vimc device with:

$ mkdir /configfs/vimc/any_name
Example:
$ mkdir /configfs/vimc/vimc0
$ ls -l /configfs/vimc/vimc0
hotplug
reset
entities/
links/

entities/ and links/ folder are default groups, thus they don't prevent 
rmdir vimc0/, but

rmdir will fail if it has any child inside entities/ or links/.
hotplug is used to plug and unplug the device, it can read "plugged" or 
"unplugged" and user can

write "plug" or "unplug" to change its state.
Changing hotplug state will never fail as the configfs tree will always 
be in a valid state.
reset is used to easily destroy all the topology without the need to 
walk through all the children
to perform rmdir, writing 1 to reset file will set hotplug to 
"unplugged" and erase all folders

under entities/ and links/.

* Create an entity
Userspace can create a new entity with:

$ mkdir /configfs/vimc/vimc0/entities/:
Example:
$ mkdir /configfs/vimc/vimc0/entities/sensor:SensorA
$ ls -l /configfs/vimc/vimc0/entities/sensor:SensorA
hotplug
pad:source:0/

The name of the folder needs to be in the format : or it 
will be rejected, this allows the
creation of the right pads according to its role at mkdir time, 
eliminating the previously proposed role

and name files.
hotplug is used to plug and unplug the hw block, it can read "plugged" 
or "unplugged" and user can
write "plug" or "unplug" to change its state. As we don't support this 
yet in the media core, changing it

will only be allowed if /configfs/vimc/vimc0/hotplug is "unplugged".
hotplug file is "unplugged" by default.
Pads will be created as default groups with the name in the format 
pad:: and it

will be an empty folder.
If the hw block supports different number of pads, we could expose two 
files:

sinks
sources
where the user space can write the desired number of sink and source 
pads and the driver will dynamically

create the folders pad::

* Create a link
User space can create a link between two entities with:

	$ mkdir 
/configfs/vimc/vimc0/links/:->:

Example:
$ mkdir /configfs/vimc/vimc0/links/DebayerA:1->Scaler:0
$ ls -l /configfs/vimc/vimc0/links/DebayerA:1->Scaler:0
flags

mkdir will be rejected if folder is not on the format 
:->:.
mkdir will be rejected if either  or  
are not found in /configfs/vimc/vimc0/entities/

The link will only be created if both entities are in "plugged" state.
When an entity is removed from /configfs/vimc/vimc0/entities/ with 
rmdir, its corresponding lin

Re: [RFC PATCH v2 0/2] [media] tvp515p: Proposal for MC input connector support

[Javier Martinez Canillas]

On 04/12/2016 06:42 PM, Javier Martinez Canillas wrote:
> Hello,
> 
> This is a second version of an RFC patch series that adds MC input connector
> support to the tvp5150 driver. The first RFC version was [0].
> 
> The patches are RFC because a previous version was merged and later reverted
> since the approach was found to be inadequate. So I preferred to post this
> approach as RFC to discuss it first.
> 
> The main difference with v1 is that a single sink pad is used for the tvp5150
> (instead of using a pad per each input pin) as suggested by Mauro and Hans.
> 
> The mc_nextgen_test dot output after applying the series can be found at [1]
> and the graph png generated using the dot tool is at [2].
> 
> I tested these patches on an IGEPv2 by capturing using both Composite inputs.
> 
> [0]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg95389.html
> [1]: http://hastebin.com/yiduhonome.tex
> [2]: http://i.imgur.com/EyFtVtJ.png?1
> 
> Best regards,
> Javier
> 
> Changes in v2:
> - Remove from the changelog a mention of devices that multiplex the
>   physical RCA connectors to be used for the S-Video Y and C signals
>   since it's a special case and it doesn't really work on the IGEPv2.
> - Use a single sink pad for the demod and map the connectors as entities
>   so the mux is made via links. Suggested by Mauro and Hans.
> 
> Javier Martinez Canillas (2):
>   [media] tvp5150: Add input connectors DT bindings
>   [media] tvp5150: Replace connector support according to DT binding
> 
>  .../devicetree/bindings/media/i2c/tvp5150.txt  |  59 
>  drivers/media/i2c/tvp5150.c| 155 
> +++--
>  2 files changed, 170 insertions(+), 44 deletions(-)
> 

Any comments about this series?

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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] Streaming I/O: proposal to expose MMAP/USERPTR/DMABUF capabilities with QUERYCAP

[Hans Verkuil]

On 04/22/2016 10:23 AM, Jean-Michel Hautbois wrote:
> Hi Hans,
> 
> 2016-04-22 10:08 GMT+02:00 Hans Verkuil :
>> Hi all,
>>
>> I have always been unhappy with the fact that it is so hard to tell whether
>> the USERPTR and/or DMABUF modes are available with Streaming I/O. QUERYCAP
>> only tells you if Streaming I/O is available, but not in which flavors.
>>
>> So I propose the following:
>>
>> #define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING
>> #define V4L2_CAP_STREAMING_USERPTR 0x0800
>> #define V4L2_CAP_STREAMING_DMABUF  0x1000
>>
>> All drivers that currently support CAP_STREAMING also support MMAP. For 
>> userptr
>> and dmabuf support we add new caps. These can be set by the core if the 
>> driver
>> uses vb2 since the core can query the io_modes field of vb2_queue.
> 
> So, you want to make it mandatory for future drivers that they support
> MMAP. Fine with me.
> BTW, dmabuf is still marked as experimental, what would make it part
> of the API for good ?

Just laziness on our part. I think I should go through the docs and update these
things. Most things marked experimental can probably drop that designation.

> 
>> For the drivers that do not yet support vb2 we can add it manually.
>>
>> I was considering making it a requirement that the MMAP streaming mode is
>> always present, but I don't know if that works once we get drivers that 
>> operate
>> on secure memory. So I won't do that for now.
> 
> By using "#define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING" you make
> it mandatory... You would need a separate bit to indicate MMAP
> otherwise...

No: all *current* drivers marked CAP_STREAMING support MMAP. But future devices
that might not support MMAP would not set this cap.

So it is possible that in the future you'd get a driver that has just 
STREAMING_DMABUF
set. Which is something I can imagine for drivers operating on secure memory.

Regards,

Hans

> 
>> Since we are looking at device caps anyway: can we just drop 
>> V4L2_CAP_ASYNCIO?
>> It's never been implemented, nor is it likely in the future. And we don't 
>> have
>> all that many bits left before we need to use one of the reserved fields for
>> additional capabilities.
>>
>> Regards,
>>
>> Hans
>> --
>> 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] Streaming I/O: proposal to expose MMAP/USERPTR/DMABUF capabilities with QUERYCAP

[Jean-Michel Hautbois]

Hi Hans,

2016-04-22 10:08 GMT+02:00 Hans Verkuil :
> Hi all,
>
> I have always been unhappy with the fact that it is so hard to tell whether
> the USERPTR and/or DMABUF modes are available with Streaming I/O. QUERYCAP
> only tells you if Streaming I/O is available, but not in which flavors.
>
> So I propose the following:
>
> #define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING
> #define V4L2_CAP_STREAMING_USERPTR 0x0800
> #define V4L2_CAP_STREAMING_DMABUF  0x1000
>
> All drivers that currently support CAP_STREAMING also support MMAP. For 
> userptr
> and dmabuf support we add new caps. These can be set by the core if the driver
> uses vb2 since the core can query the io_modes field of vb2_queue.

So, you want to make it mandatory for future drivers that they support
MMAP. Fine with me.
BTW, dmabuf is still marked as experimental, what would make it part
of the API for good ?

> For the drivers that do not yet support vb2 we can add it manually.
>
> I was considering making it a requirement that the MMAP streaming mode is
> always present, but I don't know if that works once we get drivers that 
> operate
> on secure memory. So I won't do that for now.

By using "#define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING" you make
it mandatory... You would need a separate bit to indicate MMAP
otherwise...

> Since we are looking at device caps anyway: can we just drop V4L2_CAP_ASYNCIO?
> It's never been implemented, nor is it likely in the future. And we don't have
> all that many bits left before we need to use one of the reserved fields for
> additional capabilities.
>
> Regards,
>
> Hans
> --
> 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

[RFC] Streaming I/O: proposal to expose MMAP/USERPTR/DMABUF capabilities with QUERYCAP

[Hans Verkuil]

Hi all,

I have always been unhappy with the fact that it is so hard to tell whether
the USERPTR and/or DMABUF modes are available with Streaming I/O. QUERYCAP
only tells you if Streaming I/O is available, but not in which flavors.

So I propose the following:

#define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING
#define V4L2_CAP_STREAMING_USERPTR 0x0800
#define V4L2_CAP_STREAMING_DMABUF  0x1000

All drivers that currently support CAP_STREAMING also support MMAP. For userptr
and dmabuf support we add new caps. These can be set by the core if the driver
uses vb2 since the core can query the io_modes field of vb2_queue.

For the drivers that do not yet support vb2 we can add it manually.

I was considering making it a requirement that the MMAP streaming mode is
always present, but I don't know if that works once we get drivers that operate
on secure memory. So I won't do that for now.

Since we are looking at device caps anyway: can we just drop V4L2_CAP_ASYNCIO?
It's never been implemented, nor is it likely in the future. And we don't have
all that many bits left before we need to use one of the reserved fields for
additional capabilities.

Regards,

Hans
--
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 PATCH v2 0/2] [media] tvp515p: Proposal for MC input connector support

[Javier Martinez Canillas]

Hello,

This is a second version of an RFC patch series that adds MC input connector
support to the tvp5150 driver. The first RFC version was [0].

The patches are RFC because a previous version was merged and later reverted
since the approach was found to be inadequate. So I preferred to post this
approach as RFC to discuss it first.

The main difference with v1 is that a single sink pad is used for the tvp5150
(instead of using a pad per each input pin) as suggested by Mauro and Hans.

The mc_nextgen_test dot output after applying the series can be found at [1]
and the graph png generated using the dot tool is at [2].

I tested these patches on an IGEPv2 by capturing using both Composite inputs.

[0]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg95389.html
[1]: http://hastebin.com/yiduhonome.tex
[2]: http://i.imgur.com/EyFtVtJ.png?1

Best regards,
Javier

Changes in v2:
- Remove from the changelog a mention of devices that multiplex the
  physical RCA connectors to be used for the S-Video Y and C signals
  since it's a special case and it doesn't really work on the IGEPv2.
- Use a single sink pad for the demod and map the connectors as entities
  so the mux is made via links. Suggested by Mauro and Hans.

Javier Martinez Canillas (2):
  [media] tvp5150: Add input connectors DT bindings
  [media] tvp5150: Replace connector support according to DT binding

 .../devicetree/bindings/media/i2c/tvp5150.txt  |  59 
 drivers/media/i2c/tvp5150.c| 155 +++--
 2 files changed, 170 insertions(+), 44 deletions(-)

-- 
2.5.5

--
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 PATCH 0/3] [media] tvp515p: Proposal for MC input connector support

[Javier Martinez Canillas]

Hello,

On 03/09/2016 04:09 PM, Javier Martinez Canillas wrote:
> 
> I was waiting for the MC input connector support discussion to settle before
> attempting to propose another patch series for the tvp5150 video decoder but
> IIUC you are going to continue the discussion at ELC so I'm posting a series
> that I believe is aligned with the latest conversations.
> 
> This is of course a RFC and not meant to be merged but just to start looking
> how the DT binding using OF graph for connectors could look like and to see
> an implementation that uses a PAD (and thus link) per electrical signal (the
> 1:1 model mentioned by Laurent).
>

Any comments about this series?
 
Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 PATCH 0/3] [media] tvp515p: Proposal for MC input connector support

[Javier Martinez Canillas]

Hello,

I was waiting for the MC input connector support discussion to settle before
attempting to propose another patch series for the tvp5150 video decoder but
IIUC you are going to continue the discussion at ELC so I'm posting a series
that I believe is aligned with the latest conversations.

This is of course a RFC and not meant to be merged but just to start looking
how the DT binding using OF graph for connectors could look like and to see
an implementation that uses a PAD (and thus link) per electrical signal (the
1:1 model mentioned by Laurent).

The mc_nextgen_test dot output after applying the series can be found at [0]
and the graph png generated using the dot tool at [1].

I've also uploaded the dot files and png when the Composite0 [2,3], Composite1
[4,5] and S-Video [6,7] links are enabled.

I tested these patches on an IGEPv2 by capturing using both Composite inputs,
unfortuantely S-Video using the two RCA connectors is not working, but seems
that is a regression with the tvp5150 driver not related with these patches.

[0]: http://hastebin.com/novoxezeko.tex
[1]: http://i.imgur.com/RWZEpMn.png
[2]: http://hastebin.com/asaduyetuf.tex
[3]: http://i.imgur.com/6y7d7AS.png
[4]: http://hastebin.com/dijowanuki.tex
[5]: http://i.imgur.com/Qr1F9dL.png
[6]: http://hastebin.com/zegiwisoli.tex
[7]: http://i.imgur.com/TdrVJ0R.png

Best regards,
Javier


Javier Martinez Canillas (3):
  [media] v4l2-mc.h: Add a S-Video C input PAD to demod enum
  [media] tvp5150: Add input connectors DT bindings
  [media] tvp5150: Replace connector support according to DT binding

 .../devicetree/bindings/media/i2c/tvp5150.txt  |  59 +++
 drivers/media/i2c/tvp5150.c| 190 +++--
 include/media/v4l2-mc.h|   3 +-
 3 files changed, 203 insertions(+), 49 deletions(-)

-- 
2.5.0

--
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: VIMC: API proposal, configuring the topology through user space

[Helen Fornazier]

Hi

On Thu, Aug 20, 2015 at 8:41 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:

 Hi Mauro,

 On Thursday 20 August 2015 00:13:43 Mauro Carvalho Chehab wrote:
  Em Thu, 20 Aug 2015 02:33:15 +0300 Laurent Pinchart escreveu:
   On Tuesday 18 August 2015 07:06:36 Mauro Carvalho Chehab wrote:
   Em Tue, 18 Aug 2015 09:35:14 +0300 Laurent Pinchart escreveu:
   On Friday 14 August 2015 12:54:44 Hans Verkuil wrote:
  
   [snip]
  
   I think this is becoming too complex. How about considering deploy
   as a commit instead ? There would then be no need to undeploy, any
   modification will start a new transaction that will be applied in one
   go when committed. This includes removal of entities by removing the
   corresponding directories.
  
   Agreed. I would implement just a /configfs/vimc/commit file, instead of
   /configfs/vimc/vimc1/build_topology.
  
   any write to the commit configfs file will make all changes to all
   vimc instances to be applied, or return an error if committing is not
   possible.
  
   Wouldn't it be better to have a commit file inside each vimc[0-9]+
   directory ? vimc device instances are completely independent, I'd prefer
   having the configuration API operate per-instance as well.
 
  I have no strong preference... but see below.
 
   A read to it would return a message saying if the changes were committed
   or not.
  
   This way, an entire vimc instance could be removed with just:
  rm -rf /configfs/vimc/vimc1
  
   As we won't have unremoved files there anymore.
  
   Some files will be automatically created by the kernel, such as the flags
   file in link directories, or the name file in entity directories. rm -rf
   might thus not work. That's a technical detail though, I haven't checked
   how configfs operates.
 
  I'm not an expert on configfs either. I guess if we can put those extra
  files outside, then the interface will be better, as we can just use
  rm -rf to remove a vimc instance.
 
  The only big advantage I see on having a global commit is if we
  can make rm -rf work. Still, it would be possible to have, instead,
  commit_vimc0, commit_vimc1, ... in such case.

 I believe having the commit file inside the vimc[0-9]+ directory won't prevent
 an rmdir, but it might get in the way of rm -rf. Let's check what configfs
 allows before deciding.

rm -rf doesn't work, configfs expects rmdir. The best we can do to
remove recursively is rmdir -p vim0/entity1/pad_0, but this won't work
if there are others pads or entities folders.

A global commit file would be better to remove an instance, we could
have a script to run rmdir recursively in vimc/vimc0/ and then commit
the changes.
Otherwise, some kind of destroy command would be easier.


 By the way, the USB gadget framework uses symlinks to functions to implement
 something similar to our commit. Maybe that would be a better fit for
 configfs.

 --
 Regards,

 Laurent Pinchart


I liked the solution of having a /configfs/vimc/vimc0/links/, it seems
cleaner to me.
Inside this folder I would add a file called flags to specify the link's flags.

-- 
Helen Fornazier
--
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: VIMC: API proposal, configuring the topology through user space

[Laurent Pinchart]

Hi Mauro,

On Thursday 20 August 2015 00:13:43 Mauro Carvalho Chehab wrote:
 Em Thu, 20 Aug 2015 02:33:15 +0300 Laurent Pinchart escreveu:
  On Tuesday 18 August 2015 07:06:36 Mauro Carvalho Chehab wrote:
  Em Tue, 18 Aug 2015 09:35:14 +0300 Laurent Pinchart escreveu:
  On Friday 14 August 2015 12:54:44 Hans Verkuil wrote:
 
  [snip]
  
  I think this is becoming too complex. How about considering deploy
  as a commit instead ? There would then be no need to undeploy, any
  modification will start a new transaction that will be applied in one
  go when committed. This includes removal of entities by removing the
  corresponding directories.
  
  Agreed. I would implement just a /configfs/vimc/commit file, instead of
  /configfs/vimc/vimc1/build_topology.
  
  any write to the commit configfs file will make all changes to all
  vimc instances to be applied, or return an error if committing is not
  possible.
  
  Wouldn't it be better to have a commit file inside each vimc[0-9]+
  directory ? vimc device instances are completely independent, I'd prefer
  having the configuration API operate per-instance as well.
 
 I have no strong preference... but see below.
 
  A read to it would return a message saying if the changes were committed
  or not.
  
  This way, an entire vimc instance could be removed with just:
 rm -rf /configfs/vimc/vimc1
  
  As we won't have unremoved files there anymore.
  
  Some files will be automatically created by the kernel, such as the flags
  file in link directories, or the name file in entity directories. rm -rf
  might thus not work. That's a technical detail though, I haven't checked
  how configfs operates.
 
 I'm not an expert on configfs either. I guess if we can put those extra
 files outside, then the interface will be better, as we can just use
 rm -rf to remove a vimc instance.
 
 The only big advantage I see on having a global commit is if we
 can make rm -rf work. Still, it would be possible to have, instead,
 commit_vimc0, commit_vimc1, ... in such case.

I believe having the commit file inside the vimc[0-9]+ directory won't prevent 
an rmdir, but it might get in the way of rm -rf. Let's check what configfs 
allows before deciding.

By the way, the USB gadget framework uses symlinks to functions to implement 
something similar to our commit. Maybe that would be a better fit for 
configfs.

-- 
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: VIMC: API proposal, configuring the topology through user space

[Laurent Pinchart]

Hi Mauro,

On Tuesday 18 August 2015 07:06:36 Mauro Carvalho Chehab wrote:
 Em Tue, 18 Aug 2015 09:35:14 +0300 Laurent Pinchart escreveu:
  On Friday 14 August 2015 12:54:44 Hans Verkuil wrote:

[snip]

  I think this is becoming too complex. How about considering deploy as a
  commit instead ? There would then be no need to undeploy, any modification
  will start a new transaction that will be applied in one go when
  committed. This includes removal of entities by removing the corresponding
  directories.

 Agreed. I would implement just a /configfs/vimc/commit file, instead of
 /configfs/vimc/vimc1/build_topology.
 
 any write to the commit configfs file will make all changes to all vimc
 instances to be applied, or return an error if committing is not possible.

Wouldn't it be better to have a commit file inside each vimc[0-9]+ directory ? 
vimc device instances are completely independent, I'd prefer having the 
configuration API operate per-instance as well.

 A read to it would return a message saying if the changes were committed or
 not.
 
 This way, an entire vimc instance could be removed with just:
 
   rm -rf /configfs/vimc/vimc1
 
 As we won't have unremoved files there anymore.

Some files will be automatically created by the kernel, such as the flags file 
in link directories, or the name file in entity directories. rm -rf might thus 
not work. That's a technical detail though, I haven't checked how configfs 
operates.

 In order to remove a
 group of objects:
   rm -rf /configfs/vimc/vimc1/[files that belong to the group]
 
 The API also become simpler and clearer, IMHO.
 
 Btw, as we discussed at the userspace API RFC, if we end by having a new
 type of graph object that represents a group of objects (MEDIA_ID_T_GROUP),

Let's see about that when the userspace API will be agreed on.

 that could be used, for example, to represent a project ARA hardware module,
 it would be easier to remove an entire group by doing something like:
 
   rm -rf /configfs/vimc/vimc1/obj_group_1

[snip]

  I misunderstood your original proposal, I thought the name of the
  link_to_raw_capture_0 directory was interpreted by the driver to mean
  that a link between the pad and pad 0 of the raw_capture entity should
  be created. But you don't interpret the name at all.
  
  I think this is confusing. Wouldn't it be easier to interpret the name
  of the link directory? I.e. it has to be of the form: link_to_entity
  name_pad name.
  
  I'd rather use symlinks and no link directory at all, but then we'd have
  no place to specify link flags :-/ I believe that's the reason why a link
  directory is needed.
  
  Maybe I worry for no reason, but interpreting the name seems to me more
  error- prone than using a symlink inside the link directory.
 
 Yeah, using symlinks makes perfect sense to me, although I'm not so sure
 of adding them inside the pads (/configfs/vimc/vimc0/sensor_a/pad_0/).
 If we do that, we'll need to represent both links and backlinks, with
 makes harder to remove them.

I don't think we need to specify both, the forward link should be enough.

 I would, instead, have a separate part of the configfs for the links:
 
 /configfs/vimc/vimc0/links
 
   and a link from sensor_a/pad_0 to raw_capture_1/pad_0/ would
 be represented as:
 
 ../../sensor_a/pad_0 - /configfs/vimc/vimc0/links/link0/source
 ../../raw_capture_1/pad_0 - /configfs/vimc/vimc0/links/link0/sink
 
 This way, if one wants to remove the link, he can do just:
 
   rm -rf /configfs/vimc/vimc0/links/link0
 
 Also, the direction of the link is properly expressed by using the
 names source and sink there.

That's an interesting option. The drawback is that you can't easily see links 
in the configfs entities directory tree. I'll think about it.

-- 
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: VIMC: API proposal, configuring the topology through user space

[Mauro Carvalho Chehab]

Em Thu, 20 Aug 2015 02:33:15 +0300
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:

 Hi Mauro,
 
 On Tuesday 18 August 2015 07:06:36 Mauro Carvalho Chehab wrote:
  Em Tue, 18 Aug 2015 09:35:14 +0300 Laurent Pinchart escreveu:
   On Friday 14 August 2015 12:54:44 Hans Verkuil wrote:
 
 [snip]
 
   I think this is becoming too complex. How about considering deploy as a
   commit instead ? There would then be no need to undeploy, any modification
   will start a new transaction that will be applied in one go when
   committed. This includes removal of entities by removing the corresponding
   directories.
 
  Agreed. I would implement just a /configfs/vimc/commit file, instead of
  /configfs/vimc/vimc1/build_topology.
  
  any write to the commit configfs file will make all changes to all vimc
  instances to be applied, or return an error if committing is not possible.
 
 Wouldn't it be better to have a commit file inside each vimc[0-9]+ directory 
 ? 
 vimc device instances are completely independent, I'd prefer having the 
 configuration API operate per-instance as well.

I have no strong preference... but see below.

 
  A read to it would return a message saying if the changes were committed or
  not.
  
  This way, an entire vimc instance could be removed with just:
  
  rm -rf /configfs/vimc/vimc1
  
  As we won't have unremoved files there anymore.
 
 Some files will be automatically created by the kernel, such as the flags 
 file 
 in link directories, or the name file in entity directories. rm -rf might 
 thus 
 not work. That's a technical detail though, I haven't checked how configfs 
 operates.

I'm not an expert on configfs either. I guess if we can put those extra
files outside, then the interface will be better, as we can just use
rm -rf to remove a vimc instance.

The only big advantage I see on having a global commit is if we
can make rm -rf work. Still, it would be possible to have, instead,
commit_vimc0, commit_vimc1, ... in such case.

 
  In order to remove a
  group of objects:
  rm -rf /configfs/vimc/vimc1/[files that belong to the group]
  
  The API also become simpler and clearer, IMHO.
  
  Btw, as we discussed at the userspace API RFC, if we end by having a new
  type of graph object that represents a group of objects (MEDIA_ID_T_GROUP),
 
 Let's see about that when the userspace API will be agreed on.

Sure.

 
  that could be used, for example, to represent a project ARA hardware module,
  it would be easier to remove an entire group by doing something like:
  
  rm -rf /configfs/vimc/vimc1/obj_group_1
 
 [snip]
 
   I misunderstood your original proposal, I thought the name of the
   link_to_raw_capture_0 directory was interpreted by the driver to mean
   that a link between the pad and pad 0 of the raw_capture entity should
   be created. But you don't interpret the name at all.
   
   I think this is confusing. Wouldn't it be easier to interpret the name
   of the link directory? I.e. it has to be of the form: link_to_entity
   name_pad name.
   
   I'd rather use symlinks and no link directory at all, but then we'd have
   no place to specify link flags :-/ I believe that's the reason why a link
   directory is needed.
   
   Maybe I worry for no reason, but interpreting the name seems to me more
   error- prone than using a symlink inside the link directory.
  
  Yeah, using symlinks makes perfect sense to me, although I'm not so sure
  of adding them inside the pads (/configfs/vimc/vimc0/sensor_a/pad_0/).
  If we do that, we'll need to represent both links and backlinks, with
  makes harder to remove them.
 
 I don't think we need to specify both, the forward link should be enough.

Ok.

  I would, instead, have a separate part of the configfs for the links:
  
  /configfs/vimc/vimc0/links
  
  and a link from sensor_a/pad_0 to raw_capture_1/pad_0/ would
  be represented as:
  
  ../../sensor_a/pad_0 - /configfs/vimc/vimc0/links/link0/source
  ../../raw_capture_1/pad_0 - /configfs/vimc/vimc0/links/link0/sink
  
  This way, if one wants to remove the link, he can do just:
  
  rm -rf /configfs/vimc/vimc0/links/link0
  
  Also, the direction of the link is properly expressed by using the
  names source and sink there.
 
 That's an interesting option. The drawback is that you can't easily see links 
 in the configfs entities directory tree. I'll think about it.
 

Well, if one wants to see all links that belong to an entity
named entity_1, linked as:

sensor_a - entity_1 - raw_capture_1

He could do:

ls -lR /configfs/vimc/vimc0/links/ |grep entity_1

This is actually easier than storing it inside an entity, as the above
grep will show both links:

link1/sink - ../sensor_a/pad0
link2/source - ../raw_capture_1/pad0

and will need to seek only inside the links sub-directory.

Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More

Re: VIMC: API proposal, configuring the topology through user space

[Mauro Carvalho Chehab]

 the current topology
   
   undeploy: undeploy the current topology. but keep the topology,
   allowing the user to make changes
   
   destroy: undeploy the current topology and remove it, giving the user a
   clean slate.
   
   What do you mean by remove it in the destroy command?
   To completely remove an instance the user could just rmdir
   /configfs/vimc5, or do you see another feature?
   
   If destroy is indeed just undeploy + rmdir I wouldn't implement it.
   
   Feel free to come up with better command names :-)
   
   * Creating an entity:
   
   Use mkdir in the /configfs/vimc to create an entity representation,
   
   e.g.:
mkdir /configfs/vimc/sensor_a
   
   The attribute files will be created by the driver through configfs:
ls /configfs/vimc/sensor_a
   
   name role
   
   Configure the name that will appear to the /dev/media0 and what this
   node do (debayer, scaler, capture, input, generic)
   
echo -n Sensor A  /configfs/vimc/sensor_a/name
echo -n sensor  /configfs/vimc/sensor_a/role
   
   * Creating a pad:
   Use mkdir inside an entity's folder, the attribute called
   direction
   
   will be automatically created in the process, for example:
mkdir /configfs/vimc/sensor_a/pad_0
ls /configfs/vimc/sensor_a/pad_0
   
   direction
   
echo -n source  /configfs/vimc/sensor_a/pad_0/direction
   
   The direction attribute can be source or sink
   
   Hmm. Aren't the pads+direction dictated by the entity role? E.g. a
   sensor will only have one pad which is always a source. I think
   setting the role is what creates the pad directories + direction
   files.
   
   I thought that we could add as many pads that we want, having a scaler
   with two or more sink pads (for example) in the same format that
   scales the frames coming from any sink pad and send it to its source
   pads, no?
   Maybe it is better if we don't let this choice.
   
   I'd leave this out. Entities have a fixed number of pads that's
   determined by their IP or HW. I think we should match that in vimc. It
   also simplifies configuring the topology since these pads will appear
   automatically.
   
   I need to check if I can modify the configfs dynamically, I mean, if
   the user writes debayer to the role file, I need to create at least
   one folder (or file) to allow the user to configure the link flag
   related to its source pad, but if in the future we have another entity
   role (lets say new_entity) that has more then one source pad, and
   the user writes debayer in the role and then new_entity, we will
   need to erase the folder created by the debayer to create two new
   folders, I am still not sure if I can do that.
   
   I would expect that it's possible, but I'm not sure about it.
   
   BTW, an alternative might be to use the build_topology file build up
   the topology entirely by sending commands to it:
   
   echo add entity debayer debayer_a build_topology
   
   You can prepare a file with commands and just do:
   
   cat my-config build_topology.
   
   which would be a nice feature.
   
   yes, it would be a nice feature indeed, but the configfs doc says:
   
   Like sysfs, attributes should be ASCII text files, preferably
   with only one value per file.  The same efficiency caveats from sysfs
   apply. Don't mix more than one attribute in one attribute file
   
   That is why I thought in using the mkdir/rmdir/echo fs tree
   configuration in the first place.
  
  I didn't know about this. So I agree that (for now) we should keep with
  one value per file.
  
   It would be possible to create a single file somewhere that would accept
   text-based commands, but I'm not sure if that would be the best solution.
   configfs exists already and is used for this kind of purpose. I'm
   certainly
   open to alternative proposals, but there would need to be a good reason to
   create a custom API when a standard one already exists. Hans, what's your
   opinion on that ?
  
  I agree with Helen, just ignore my single file proposal.
  
   I'm not saying you should do this, but it is something to think about.
   
   * Creating a link between pads in two steps:
   Step 1)
   Create a folder inside the source pad folder, the attribute called
   
   flag will be automatically created in the process, for example:
mkdir /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
ls /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
   
   flags
   
echo -n enabled,immutable 
   
   /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/flags
   In the flags attribute we can have all the links attributes
   (enabled,
   immutable and dynamic) separated by comma
   
   Step 2)
   Add a symlink between the previous folder we just created in the
   source pad and the sink pad folder we want to connect. Lets say we
   want to connect

Re: VIMC: API proposal, configuring the topology through user space

[Laurent Pinchart]

  
  direction
  
   echo -n source  /configfs/vimc/sensor_a/pad_0/direction
  
  The direction attribute can be source or sink
  
  Hmm. Aren't the pads+direction dictated by the entity role? E.g. a
  sensor will only have one pad which is always a source. I think
  setting the role is what creates the pad directories + direction
  files.
  
  I thought that we could add as many pads that we want, having a scaler
  with two or more sink pads (for example) in the same format that
  scales the frames coming from any sink pad and send it to its source
  pads, no?
  Maybe it is better if we don't let this choice.
  
  I'd leave this out. Entities have a fixed number of pads that's
  determined by their IP or HW. I think we should match that in vimc. It
  also simplifies configuring the topology since these pads will appear
  automatically.
  
  I need to check if I can modify the configfs dynamically, I mean, if
  the user writes debayer to the role file, I need to create at least
  one folder (or file) to allow the user to configure the link flag
  related to its source pad, but if in the future we have another entity
  role (lets say new_entity) that has more then one source pad, and
  the user writes debayer in the role and then new_entity, we will
  need to erase the folder created by the debayer to create two new
  folders, I am still not sure if I can do that.
  
  I would expect that it's possible, but I'm not sure about it.
  
  BTW, an alternative might be to use the build_topology file build up
  the topology entirely by sending commands to it:
  
  echo add entity debayer debayer_a build_topology
  
  You can prepare a file with commands and just do:
  
  cat my-config build_topology.
  
  which would be a nice feature.
  
  yes, it would be a nice feature indeed, but the configfs doc says:
  
  Like sysfs, attributes should be ASCII text files, preferably
  with only one value per file.  The same efficiency caveats from sysfs
  apply. Don't mix more than one attribute in one attribute file
  
  That is why I thought in using the mkdir/rmdir/echo fs tree
  configuration in the first place.
 
 I didn't know about this. So I agree that (for now) we should keep with
 one value per file.
 
  It would be possible to create a single file somewhere that would accept
  text-based commands, but I'm not sure if that would be the best solution.
  configfs exists already and is used for this kind of purpose. I'm
  certainly
  open to alternative proposals, but there would need to be a good reason to
  create a custom API when a standard one already exists. Hans, what's your
  opinion on that ?
 
 I agree with Helen, just ignore my single file proposal.
 
  I'm not saying you should do this, but it is something to think about.
  
  * Creating a link between pads in two steps:
  Step 1)
  Create a folder inside the source pad folder, the attribute called
  
  flag will be automatically created in the process, for example:
   mkdir /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
   ls /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
  
  flags
  
   echo -n enabled,immutable 
  
  /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/flags
  In the flags attribute we can have all the links attributes
  (enabled,
  immutable and dynamic) separated by comma
  
  Step 2)
  Add a symlink between the previous folder we just created in the
  source pad and the sink pad folder we want to connect. Lets say we
  want to connect with the pad on the raw_capture_0 entity pad 0
  
   ln -s /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
  
  /configfs/vimc/raw_capture_0/pad_0/
  
  Can't this be created automatically? Or possibly not at all, since it
  is implicit in step 1.
  
  Do you mean, create the symlink automatically? I don't think so
  because the driver doesn't know a priori the entities you want to
  connect together.
  
  I don't follow. If I make a 'link_to_raw_capture_0' directory for pad_0
  of sensor_a, then I know there is a backlink from pad_0 of the
  raw_capture entity, right? At least, that's how I interpret this.
  
  I am not sure if I got what you say.
  The user could use the
  /configfs/vimc/vimc0/sensor_a/pad_0/link_to_raw_capture_0 directory to
  link with a debayer instead of the raw_capture node. To connect with
  the debayer, the user could:
  
  $ mkdir -p /configfs/vimc/vimc0/sensor_a/pad_0/any_name_here
  $ ln -s /configfs/vimc/vimc0/sensor_a/pad_0/any_name_here
  /configfs/vimc/vimc0/debayer_b/pad_0/
  
  But, instead of linking with the debayer, the user could link with the
  capture:
  
  $ ln -s /configfs/vimc/vimc0/sensor_a/pad_0/any_name_here
  /configfs/vimc/vimc0/raw_capture_1/pad_0/
  
  Or the user could link with the scaler:
  
  $ ln -s /configfs/vimc/vimc0/sensor_a/pad_0/any_name_here
  /configfs/vimc/vimc0/scaler/pad_0/
  
  Thus the driver can't know in advance

Re: VIMC: API proposal, configuring the topology through user space

[Hans Verkuil]

 simplifies configuring the topology since these pads will appear
 automatically.

 I need to check if I can modify the configfs dynamically, I mean, if
 the user writes debayer to the role file, I need to create at least
 one folder (or file) to allow the user to configure the link flag
 related to its source pad, but if in the future we have another entity
 role (lets say new_entity) that has more then one source pad, and
 the user writes debayer in the role and then new_entity, we will
 need to erase the folder created by the debayer to create two new
 folders, I am still not sure if I can do that.

 I would expect that it's possible, but I'm not sure about it.

 BTW, an alternative might be to use the build_topology file build up
 the topology entirely by sending commands to it:

 echo add entity debayer debayer_a build_topology

 You can prepare a file with commands and just do:

 cat my-config build_topology.

 which would be a nice feature.

 yes, it would be a nice feature indeed, but the configfs doc says:

 Like sysfs, attributes should be ASCII text files, preferably
 with only one value per file.  The same efficiency caveats from sysfs
 apply. Don't mix more than one attribute in one attribute file

 That is why I thought in using the mkdir/rmdir/echo fs tree
 configuration in the first place.

I didn't know about this. So I agree that (for now) we should keep with
one value per file.

 
 It would be possible to create a single file somewhere that would accept 
 text-based commands, but I'm not sure if that would be the best solution. 
 configfs exists already and is used for this kind of purpose. I'm certainly 
 open to alternative proposals, but there would need to be a good reason to 
 create a custom API when a standard one already exists. Hans, what's your 
 opinion on that ?

I agree with Helen, just ignore my single file proposal.

 
 I'm not saying you should do this, but it is something to think about.

 * Creating a link between pads in two steps:
 Step 1)
 Create a folder inside the source pad folder, the attribute called

 flag will be automatically created in the process, for example:
  mkdir /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
  ls /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
 flags
  echo -n enabled,immutable 

 /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/flags
 In the flags attribute we can have all the links attributes (enabled,
 immutable and dynamic) separated by comma

 Step 2)
 Add a symlink between the previous folder we just created in the
 source pad and the sink pad folder we want to connect. Lets say we
 want to connect with the pad on the raw_capture_0 entity pad 0

  ln -s /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
 /configfs/vimc/raw_capture_0/pad_0/

 Can't this be created automatically? Or possibly not at all, since it
 is implicit in step 1.

 Do you mean, create the symlink automatically? I don't think so
 because the driver doesn't know a priori the entities you want to
 connect together.

 I don't follow. If I make a 'link_to_raw_capture_0' directory for pad_0
 of sensor_a, then I know there is a backlink from pad_0 of the
 raw_capture entity, right? At least, that's how I interpret this.

 I am not sure if I got what you say.
 The user could use the
 /configfs/vimc/vimc0/sensor_a/pad_0/link_to_raw_capture_0 directory to
 link with a debayer instead of the raw_capture node. To connect with
 the debayer, the user could:

 $ mkdir -p /configfs/vimc/vimc0/sensor_a/pad_0/any_name_here
 $ ln -s /configfs/vimc/vimc0/sensor_a/pad_0/any_name_here
 /configfs/vimc/vimc0/debayer_b/pad_0/

 But, instead of linking with the debayer, the user could link with the
 capture:

 $ ln -s /configfs/vimc/vimc0/sensor_a/pad_0/any_name_here
 /configfs/vimc/vimc0/raw_capture_1/pad_0/

 Or the user could link with the scaler:

 $ ln -s /configfs/vimc/vimc0/sensor_a/pad_0/any_name_here
 /configfs/vimc/vimc0/scaler/pad_0/

 Thus the driver can't know in advance to which sink pad this link
 should be connected to when creating a link folder inside the pad
 folder
 

I misunderstood your original proposal, I thought the name of the 
link_to_raw_capture_0
directory was interpreted by the driver to mean that a link between the pad and 
pad 0 of
the raw_capture entity should be created. But you don't interpret the name at 
all.

I think this is confusing. Wouldn't it be easier to interpret the name of the 
link
directory? I.e. it has to be of the form: link_to_entity name_pad name.

No back link necessary, and if the names don't match, then the deploy command 
will
fail.

Regards,

Hans
--
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: VIMC: API proposal, configuring the topology through user space

[Laurent Pinchart]

Hello,

On Tuesday 11 August 2015 17:07:04 Helen Fornazier wrote:
 On Tue, Aug 11, 2015 at 6:36 AM, Mauro Carvalho Chehab wrote:
  Hans Verkuil hverk...@xs4all.nl escreveu:
  On 08/10/15 19:21, Helen Fornazier wrote:
  On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil wrote:
  On 08/08/2015 03:55 AM, Helen Fornazier wrote:
  Hi!
  
  I've made a first sketch about the API of the vimc driver (virtual
  media controller) to configure the topology through user space.
  As first suggested by Laurent Pinchart, it is based on configfs.
  
  I would like to know you opinion about it, if you have any suggestion
  to improve it, otherwise I'll start its implementation as soon as
  possible. This API may change with the MC changes and I may see other
  possible configurations as I implementing it but here is the first
  idea of how the API will look like.
  
  vimc project link: https://github.com/helen-fornazier/opw-staging/
  For more information: http://kernelnewbies.org/LaurentPinchart
  
  /***
  The API:
  /
  
  In short, a topology like this one: http://goo.gl/Y7eUfu
  Would look like this filesystem tree: https://goo.gl/tCZPTg
  Txt version of the filesystem tree: https://goo.gl/42KX8Y
  
  * The /configfs/vimc subsystem
  
  I haven't checked the latest vimc driver, but doesn't it support
  multiple instances, just like vivid? I would certainly recommend that.
  
  Yes, it does support
  
  And if there are multiple instances, then each instance gets its own
  entry in configfs: /configs/vimc0, /configs/vimc1, etc.
  
  You are right, I'll add those
  
  The vimc driver registers a subsystem in the configfs with the
  
  following contents:
   ls /configfs/vimc
  build_topology status
  
  The build_topology attribute file will be used to tell the driver the
  configuration is done and it can build the topology internally
  
   echo -n anything here  /configfs/vimc/build_topology
  
  Reading from the status attribute can have 3 different classes of
  outputs
  1) deployed: the current configured tree is built
  2) undeployed: no errors, the user has modified the configfs tree
  thus the topology was undeployed
  3) error error_message: the topology configuration is wrong
  
  I don't see the status file in the filesystem tree links above.
  
  Sorry, I forgot to add
  
  I actually wonder if we can't use build_topology for that: reading it
  will just return the status.
  
  Yes we can, I was just wondering what should be the name of the file,
  as getting the status from reading the build_topology file doesn't
  seem much intuitive
  
  I'm not opposed to a status file, but it would be good to know what
  Laurent thinks.
  
  What happens if it is deployed and you want to 'undeploy' it? Instead
  of writing anything to build_topology it might be useful to write a
  real command to it. E.g. 'deploy', 'destroy'.
  
  What happens when you make changes while a topology is deployed?
  Should such changes be rejected until the usecount of the driver goes
  to 0, or will it only be rejected when you try to deploy the new
  configuration?
  
  I was thinking that if the user try changing the topology, or it will
  fail (because the device instance is in use) or it will undeploy the
  old topology (if the device is not in use). Then a 'destroy' command
  won't be useful, the user can just unload the driver when it won't be
  used anymore,
  
  Well, we're planning to add support for dynamic addition/removal of
  entities, interfaces, pads and links. So, instead of undeploy the
  old topology, one could just do:
  rm -rf part of the tree
 
 I think I misunderstood the word dynamic here. Do you mean that
 entities/interfaces/pads/link could be created/removed while their
 file handlers are opened? While an instance (lets say vimc2) is being
 used?

Let's keep in mind that what can appear or disappear at runtime in an 
uncontrolled manner are hardware blocks. The associated media_entity instances 
will of course need to be created and destroyed, but we have control over that 
in the sense that the kernel controls the lifetime of those structures.

For the vimc driver hardware addition and removal is emulated using the 
userspace API. The API thus needs to support

- adding a complete device
- removing a complete device
- adding a hardware block
- removing a hardware block

The last two operations can't be implemented before we add support for them in 
the MC core, but the API needs to be designed in a way to allow them.

  If you have multiple vimc instances and you want to 'destroy' the
  topology of only one instance, then you can't rmmod the module.
  
  You can still use rm remove just one entire instance of the topology.
 
 Just to be clear:
 They way I was thinking was: the user do the mkdir/rmdir/echo/cat as
 he likes, if some file handler is opened in some device then
 rmdir/mkdir/echo would fail in the folder related to that device:
 

Re: VIMC: API proposal, configuring the topology through user space

[Laurent Pinchart]

Hello,

On Tuesday 11 August 2015 12:34:46 Hans Verkuil wrote:
 On 08/11/15 11:36, Mauro Carvalho Chehab wrote:
  Em Tue, 11 Aug 2015 11:28:25 +0200 Hans Verkuil escreveu:
  On 08/10/15 19:21, Helen Fornazier wrote:
  On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil wrote:
  On 08/08/2015 03:55 AM, Helen Fornazier wrote:
  Hi!
  
  I've made a first sketch about the API of the vimc driver (virtual
  media controller) to configure the topology through user space.
  As first suggested by Laurent Pinchart, it is based on configfs.
  
  I would like to know you opinion about it, if you have any suggestion
  to improve it, otherwise I'll start its implementation as soon as
  possible.
  This API may change with the MC changes and I may see other possible
  configurations as I implementing it but here is the first idea of how
  the API will look like.
  
  vimc project link: https://github.com/helen-fornazier/opw-staging/
  For more information: http://kernelnewbies.org/LaurentPinchart
  
  /***
  The API:
  /
  
  In short, a topology like this one: http://goo.gl/Y7eUfu
  Would look like this filesystem tree: https://goo.gl/tCZPTg
  Txt version of the filesystem tree: https://goo.gl/42KX8Y
  
  * The /configfs/vimc subsystem
  
  I haven't checked the latest vimc driver, but doesn't it support
  multiple instances, just like vivid? I would certainly recommend that.
  
  Yes, it does support
  
  And if there are multiple instances, then each instance gets its own
  entry in configfs: /configs/vimc0, /configs/vimc1, etc.
  
  You are right, I'll add those
  
  The vimc driver registers a subsystem in the configfs with the
  
  following contents:
   ls /configfs/vimc
  build_topology status
  
  The build_topology attribute file will be used to tell the driver the
  configuration is done and it can build the topology internally
  
   echo -n anything here  /configfs/vimc/build_topology
  
  Reading from the status attribute can have 3 different classes of
  outputs
  1) deployed: the current configured tree is built
  2) undeployed: no errors, the user has modified the configfs tree thus
  the topology was undeployed
  3) error error_message: the topology configuration is wrong
  
  I don't see the status file in the filesystem tree links above.
  
  Sorry, I forgot to add
  
  I actually wonder if we can't use build_topology for that: reading it
  will just return the status.
  
  Yes we can, I was just wondering what should be the name of the file,
  as getting the status from reading the build_topology file doesn't
  seem much intuitive
  
  I'm not opposed to a status file, but it would be good to know what
  Laurent thinks.

I'm fine with both solutions. What I'm wondering is 

  What happens if it is deployed and you want to 'undeploy' it? Instead
  of writing anything to build_topology it might be useful to write a
  real command to it. E.g. 'deploy', 'destroy'.
  
  What happens when you make changes while a topology is deployed? Should
  such changes be rejected until the usecount of the driver goes to 0, or
  will it only be rejected when you try to deploy the new configuration?

I believe we should restrict the changes we allow to what can be found with 
real hardware. Hardware blocks can be removed and added at any time, or at 
least a subset of them. This doesn't mean than entities (in the sense of 
struct media_entity) will need to be deleted immediately, but I believe we 
should support hot-plug and hot-unplug in the API. The implementation will of 
course have to wait until we add support for dynamic graph modifications to 
the media controller core.

Removal of a complete device should work similarly but can already be 
implemented. I'm wondering how removal of a vimc device will be implemented 
though. Will it be triggered by an rmdir of the corresponding 
/configfs/vimc/vimc[0-9] directory, assuming configfs supports removing non-
empty directory ? Or would we need a separate way to signal hot-unplug using 
an attribute in /configfs/vimc/ (I'm thinking about something similar to 'echo 
vimc1  /configfs/vimc/unplug') ?

  I was thinking that if the user try changing the topology, or it will
  fail (because the device instance is in use) or it will undeploy the
  old topology (if the device is not in use). Then a 'destroy' command
  won't be useful, the user can just unload the driver when it won't be
  used anymore,
  
  Well, we're planning to add support for dynamic addition/removal of
  entities, interfaces, pads and links. So, instead of undeploy the
  
  old topology, one could just do:
  rm -rf part of the tree
 
 Dynamic entities and interfaces yes, but dynamic pads? The entity defines
 the number of pads it has, which is related to the hardware or IP properties
 of the entity. I don't see how that can be dynamic.
 
 I certainly wouldn't bother with that in vimc.

I wouldn't either. While we might have some use cases 

Re: VIMC: API proposal, configuring the topology through user space

[Hans Verkuil]

Hi Helen,

On 08/10/15 19:21, Helen Fornazier wrote:
 Hi, thanks for your reviews
 
 On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 Hi Helen!

 On 08/08/2015 03:55 AM, Helen Fornazier wrote:
 Hi!

 I've made a first sketch about the API of the vimc driver (virtual
 media controller) to configure the topology through user space.
 As first suggested by Laurent Pinchart, it is based on configfs.

 I would like to know you opinion about it, if you have any suggestion
 to improve it, otherwise I'll start its implementation as soon as
 possible.
 This API may change with the MC changes and I may see other possible
 configurations as I implementing it but here is the first idea of how
 the API will look like.

 vimc project link: https://github.com/helen-fornazier/opw-staging/
 For more information: http://kernelnewbies.org/LaurentPinchart

 /***
 The API:
 /

 In short, a topology like this one: http://goo.gl/Y7eUfu
 Would look like this filesystem tree: https://goo.gl/tCZPTg
 Txt version of the filesystem tree: https://goo.gl/42KX8Y

 * The /configfs/vimc subsystem

 I haven't checked the latest vimc driver, but doesn't it support
 multiple instances, just like vivid? I would certainly recommend that.
 
 Yes, it does support
 

 And if there are multiple instances, then each instance gets its own
 entry in configfs: /configs/vimc0, /configs/vimc1, etc.
 
 You are right, I'll add those
 

 The vimc driver registers a subsystem in the configfs with the
 following contents:
  ls /configfs/vimc
 build_topology status
 The build_topology attribute file will be used to tell the driver the
 configuration is done and it can build the topology internally
  echo -n anything here  /configfs/vimc/build_topology
 Reading from the status attribute can have 3 different classes of outputs
 1) deployed: the current configured tree is built
 2) undeployed: no errors, the user has modified the configfs tree thus
 the topology was undeployed
 3) error error_message: the topology configuration is wrong

 I don't see the status file in the filesystem tree links above.
 
 Sorry, I forgot to add
 

 I actually wonder if we can't use build_topology for that: reading it
 will just return the status.
 
 Yes we can, I was just wondering what should be the name of the file,
 as getting the status from reading the build_topology file doesn't
 seem much intuitive

I'm not opposed to a status file, but it would be good to know what Laurent
thinks.

 

 What happens if it is deployed and you want to 'undeploy' it? Instead of
 writing anything to build_topology it might be useful to write a real
 command to it. E.g. 'deploy', 'destroy'.

 What happens when you make changes while a topology is deployed? Should
 such changes be rejected until the usecount of the driver goes to 0, or
 will it only be rejected when you try to deploy the new configuration?
 
 I was thinking that if the user try changing the topology, or it will
 fail (because the device instance is in use) or it will undeploy the
 old topology (if the device is not in use). Then a 'destroy' command
 won't be useful, the user can just unload the driver when it won't be
 used anymore,

If you have multiple vimc instances and you want to 'destroy' the topology
of only one instance, then you can't rmmod the module.

I think I would prefer to have proper commands for the build_topology
file. It would also keep the state handling of the driver simple: it's
either deployed or undeployed, and changes to the topology can only
take place if it is undeployed.

Commands for build_topology can be:

deploy: deploy the current topology

undeploy: undeploy the current topology. but keep the topology, allowing
the user to make changes

destroy: undeploy the current topology and remove it, giving the user a
clean slate.

Feel free to come up with better command names :-)

 

 * Creating an entity:
 Use mkdir in the /configfs/vimc to create an entity representation, e.g.:
  mkdir /configfs/vimc/sensor_a
 The attribute files will be created by the driver through configfs:
  ls /configfs/vimc/sensor_a
 name role
 Configure the name that will appear to the /dev/media0 and what this
 node do (debayer, scaler, capture, input, generic)
  echo -n Sensor A  /configfs/vimc/sensor_a/name
  echo -n sensor  /configfs/vimc/sensor_a/role

 * Creating a pad:
 Use mkdir inside an entity's folder, the attribute called direction
 will be automatically created in the process, for example:
  mkdir /configfs/vimc/sensor_a/pad_0
  ls /configfs/vimc/sensor_a/pad_0
 direction
  echo -n source  /configfs/vimc/sensor_a/pad_0/direction
 The direction attribute can be source or sink

 Hmm. Aren't the pads+direction dictated by the entity role? E.g. a sensor
 will only have one pad which is always a source. I think setting the role
 is what creates the pad 

Re: VIMC: API proposal, configuring the topology through user space

[Mauro Carvalho Chehab]

Em Tue, 11 Aug 2015 11:28:25 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:

 Hi Helen,
 
 On 08/10/15 19:21, Helen Fornazier wrote:
  Hi, thanks for your reviews
  
  On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil hverk...@xs4all.nl wrote:
  Hi Helen!
 
  On 08/08/2015 03:55 AM, Helen Fornazier wrote:
  Hi!
 
  I've made a first sketch about the API of the vimc driver (virtual
  media controller) to configure the topology through user space.
  As first suggested by Laurent Pinchart, it is based on configfs.
 
  I would like to know you opinion about it, if you have any suggestion
  to improve it, otherwise I'll start its implementation as soon as
  possible.
  This API may change with the MC changes and I may see other possible
  configurations as I implementing it but here is the first idea of how
  the API will look like.
 
  vimc project link: https://github.com/helen-fornazier/opw-staging/
  For more information: http://kernelnewbies.org/LaurentPinchart
 
  /***
  The API:
  /
 
  In short, a topology like this one: http://goo.gl/Y7eUfu
  Would look like this filesystem tree: https://goo.gl/tCZPTg
  Txt version of the filesystem tree: https://goo.gl/42KX8Y
 
  * The /configfs/vimc subsystem
 
  I haven't checked the latest vimc driver, but doesn't it support
  multiple instances, just like vivid? I would certainly recommend that.
  
  Yes, it does support
  
 
  And if there are multiple instances, then each instance gets its own
  entry in configfs: /configs/vimc0, /configs/vimc1, etc.
  
  You are right, I'll add those
  
 
  The vimc driver registers a subsystem in the configfs with the
  following contents:
   ls /configfs/vimc
  build_topology status
  The build_topology attribute file will be used to tell the driver the
  configuration is done and it can build the topology internally
   echo -n anything here  /configfs/vimc/build_topology
  Reading from the status attribute can have 3 different classes of outputs
  1) deployed: the current configured tree is built
  2) undeployed: no errors, the user has modified the configfs tree thus
  the topology was undeployed
  3) error error_message: the topology configuration is wrong
 
  I don't see the status file in the filesystem tree links above.
  
  Sorry, I forgot to add
  
 
  I actually wonder if we can't use build_topology for that: reading it
  will just return the status.
  
  Yes we can, I was just wondering what should be the name of the file,
  as getting the status from reading the build_topology file doesn't
  seem much intuitive
 
 I'm not opposed to a status file, but it would be good to know what Laurent
 thinks.
 
  
 
  What happens if it is deployed and you want to 'undeploy' it? Instead of
  writing anything to build_topology it might be useful to write a real
  command to it. E.g. 'deploy', 'destroy'.
 
  What happens when you make changes while a topology is deployed? Should
  such changes be rejected until the usecount of the driver goes to 0, or
  will it only be rejected when you try to deploy the new configuration?
  
  I was thinking that if the user try changing the topology, or it will
  fail (because the device instance is in use) or it will undeploy the
  old topology (if the device is not in use). Then a 'destroy' command
  won't be useful, the user can just unload the driver when it won't be
  used anymore,

Well, we're planning to add support for dynamic addition/removal of
entities, interfaces, pads and links. So, instead of undeploy the
old topology, one could just do:
rm -rf part of the tree

 
 If you have multiple vimc instances and you want to 'destroy' the topology
 of only one instance, then you can't rmmod the module.

You can still use rm remove just one entire instance of the topology.

 I think I would prefer to have proper commands for the build_topology
 file. It would also keep the state handling of the driver simple: it's
 either deployed or undeployed, and changes to the topology can only
 take place if it is undeployed.
 
 Commands for build_topology can be:
 
 deploy: deploy the current topology
 
 undeploy: undeploy the current topology. but keep the topology, allowing
 the user to make changes
 
 destroy: undeploy the current topology and remove it, giving the user a
 clean slate.
 
 Feel free to come up with better command names :-)
 
  
 
  * Creating an entity:
  Use mkdir in the /configfs/vimc to create an entity representation, e.g.:
   mkdir /configfs/vimc/sensor_a
  The attribute files will be created by the driver through configfs:
   ls /configfs/vimc/sensor_a
  name role
  Configure the name that will appear to the /dev/media0 and what this
  node do (debayer, scaler, capture, input, generic)
   echo -n Sensor A  /configfs/vimc/sensor_a/name
   echo -n sensor  /configfs/vimc/sensor_a/role
 
  * Creating a pad:
  Use mkdir inside an entity's folder, the attribute called 

Re: VIMC: API proposal, configuring the topology through user space

[Hans Verkuil]

On 08/11/15 11:36, Mauro Carvalho Chehab wrote:
 Em Tue, 11 Aug 2015 11:28:25 +0200
 Hans Verkuil hverk...@xs4all.nl escreveu:
 
 Hi Helen,

 On 08/10/15 19:21, Helen Fornazier wrote:
 Hi, thanks for your reviews

 On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 Hi Helen!

 On 08/08/2015 03:55 AM, Helen Fornazier wrote:
 Hi!

 I've made a first sketch about the API of the vimc driver (virtual
 media controller) to configure the topology through user space.
 As first suggested by Laurent Pinchart, it is based on configfs.

 I would like to know you opinion about it, if you have any suggestion
 to improve it, otherwise I'll start its implementation as soon as
 possible.
 This API may change with the MC changes and I may see other possible
 configurations as I implementing it but here is the first idea of how
 the API will look like.

 vimc project link: https://github.com/helen-fornazier/opw-staging/
 For more information: http://kernelnewbies.org/LaurentPinchart

 /***
 The API:
 /

 In short, a topology like this one: http://goo.gl/Y7eUfu
 Would look like this filesystem tree: https://goo.gl/tCZPTg
 Txt version of the filesystem tree: https://goo.gl/42KX8Y

 * The /configfs/vimc subsystem

 I haven't checked the latest vimc driver, but doesn't it support
 multiple instances, just like vivid? I would certainly recommend that.

 Yes, it does support


 And if there are multiple instances, then each instance gets its own
 entry in configfs: /configs/vimc0, /configs/vimc1, etc.

 You are right, I'll add those


 The vimc driver registers a subsystem in the configfs with the
 following contents:
  ls /configfs/vimc
 build_topology status
 The build_topology attribute file will be used to tell the driver the
 configuration is done and it can build the topology internally
  echo -n anything here  /configfs/vimc/build_topology
 Reading from the status attribute can have 3 different classes of outputs
 1) deployed: the current configured tree is built
 2) undeployed: no errors, the user has modified the configfs tree thus
 the topology was undeployed
 3) error error_message: the topology configuration is wrong

 I don't see the status file in the filesystem tree links above.

 Sorry, I forgot to add


 I actually wonder if we can't use build_topology for that: reading it
 will just return the status.

 Yes we can, I was just wondering what should be the name of the file,
 as getting the status from reading the build_topology file doesn't
 seem much intuitive

 I'm not opposed to a status file, but it would be good to know what Laurent
 thinks.



 What happens if it is deployed and you want to 'undeploy' it? Instead of
 writing anything to build_topology it might be useful to write a real
 command to it. E.g. 'deploy', 'destroy'.

 What happens when you make changes while a topology is deployed? Should
 such changes be rejected until the usecount of the driver goes to 0, or
 will it only be rejected when you try to deploy the new configuration?

 I was thinking that if the user try changing the topology, or it will
 fail (because the device instance is in use) or it will undeploy the
 old topology (if the device is not in use). Then a 'destroy' command
 won't be useful, the user can just unload the driver when it won't be
 used anymore,
 
 Well, we're planning to add support for dynamic addition/removal of
 entities, interfaces, pads and links. So, instead of undeploy the
 old topology, one could just do:
   rm -rf part of the tree

Dynamic entities and interfaces yes, but dynamic pads? The entity defines
the number of pads it has, which is related to the hardware or IP properties
of the entity. I don't see how that can be dynamic.

I certainly wouldn't bother with that in vimc.

Regards,

Hans
--
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: VIMC: API proposal, configuring the topology through user space

[Mauro Carvalho Chehab]

Em Tue, 11 Aug 2015 12:34:46 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:

 On 08/11/15 11:36, Mauro Carvalho Chehab wrote:
  Em Tue, 11 Aug 2015 11:28:25 +0200
  Hans Verkuil hverk...@xs4all.nl escreveu:
  
  Hi Helen,
 
  On 08/10/15 19:21, Helen Fornazier wrote:
  Hi, thanks for your reviews
 
  On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil hverk...@xs4all.nl wrote:
  Hi Helen!
 
  On 08/08/2015 03:55 AM, Helen Fornazier wrote:
  Hi!
 
  I've made a first sketch about the API of the vimc driver (virtual
  media controller) to configure the topology through user space.
  As first suggested by Laurent Pinchart, it is based on configfs.
 
  I would like to know you opinion about it, if you have any suggestion
  to improve it, otherwise I'll start its implementation as soon as
  possible.
  This API may change with the MC changes and I may see other possible
  configurations as I implementing it but here is the first idea of how
  the API will look like.
 
  vimc project link: https://github.com/helen-fornazier/opw-staging/
  For more information: http://kernelnewbies.org/LaurentPinchart
 
  /***
  The API:
  /
 
  In short, a topology like this one: http://goo.gl/Y7eUfu
  Would look like this filesystem tree: https://goo.gl/tCZPTg
  Txt version of the filesystem tree: https://goo.gl/42KX8Y
 
  * The /configfs/vimc subsystem
 
  I haven't checked the latest vimc driver, but doesn't it support
  multiple instances, just like vivid? I would certainly recommend that.
 
  Yes, it does support
 
 
  And if there are multiple instances, then each instance gets its own
  entry in configfs: /configs/vimc0, /configs/vimc1, etc.
 
  You are right, I'll add those
 
 
  The vimc driver registers a subsystem in the configfs with the
  following contents:
   ls /configfs/vimc
  build_topology status
  The build_topology attribute file will be used to tell the driver the
  configuration is done and it can build the topology internally
   echo -n anything here  /configfs/vimc/build_topology
  Reading from the status attribute can have 3 different classes of 
  outputs
  1) deployed: the current configured tree is built
  2) undeployed: no errors, the user has modified the configfs tree thus
  the topology was undeployed
  3) error error_message: the topology configuration is wrong
 
  I don't see the status file in the filesystem tree links above.
 
  Sorry, I forgot to add
 
 
  I actually wonder if we can't use build_topology for that: reading it
  will just return the status.
 
  Yes we can, I was just wondering what should be the name of the file,
  as getting the status from reading the build_topology file doesn't
  seem much intuitive
 
  I'm not opposed to a status file, but it would be good to know what Laurent
  thinks.
 
 
 
  What happens if it is deployed and you want to 'undeploy' it? Instead of
  writing anything to build_topology it might be useful to write a real
  command to it. E.g. 'deploy', 'destroy'.
 
  What happens when you make changes while a topology is deployed? Should
  such changes be rejected until the usecount of the driver goes to 0, or
  will it only be rejected when you try to deploy the new configuration?
 
  I was thinking that if the user try changing the topology, or it will
  fail (because the device instance is in use) or it will undeploy the
  old topology (if the device is not in use). Then a 'destroy' command
  won't be useful, the user can just unload the driver when it won't be
  used anymore,
  
  Well, we're planning to add support for dynamic addition/removal of
  entities, interfaces, pads and links. So, instead of undeploy the
  old topology, one could just do:
  rm -rf part of the tree
 
 Dynamic entities and interfaces yes, but dynamic pads? The entity defines
 the number of pads it has, which is related to the hardware or IP properties
 of the entity. I don't see how that can be dynamic.

It can be dynamic. DVB has usages for that, on two different situations:

1) DVB demux

There are some hardware that has an IP block that provides more than one
demuxes, but they share a number of TS filters. The amount of TS filters
per demux can be dynamically changed.

For example, such hardware may have 2 demuxes and 32 shared TS filters.

At DVB driver init, let's assume that each demux will have 16 filters.
So:
demux 0 - 16 TS filters = 16 pads
demux 1 - 16 TS buffers = 16 pads

On a given time, let's assume that the first demux has all 16 filters
already in usage, but the second demux is using only 4 filters. It is
possible to dynamically change the hardware to move, let's say, 4
buffers from the second demux to the first one. After such change,
we'll have:
demux 0 - 20 TS filters = 20 pads
demux 1 - 12 TS filters = 12 pads

Ok, one might think on initializing both with 32 pads, and create
32 ringbuffers at the Kernelspace for each demux, but if the number
of TS filters is 

Re: VIMC: API proposal, configuring the topology through user space

[Helen Fornazier]

Hello, thank you for your feedback

On Tue, Aug 11, 2015 at 6:36 AM, Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
 Em Tue, 11 Aug 2015 11:28:25 +0200
 Hans Verkuil hverk...@xs4all.nl escreveu:

 Hi Helen,

 On 08/10/15 19:21, Helen Fornazier wrote:
  Hi, thanks for your reviews
 
  On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil hverk...@xs4all.nl wrote:
  Hi Helen!
 
  On 08/08/2015 03:55 AM, Helen Fornazier wrote:
  Hi!
 
  I've made a first sketch about the API of the vimc driver (virtual
  media controller) to configure the topology through user space.
  As first suggested by Laurent Pinchart, it is based on configfs.
 
  I would like to know you opinion about it, if you have any suggestion
  to improve it, otherwise I'll start its implementation as soon as
  possible.
  This API may change with the MC changes and I may see other possible
  configurations as I implementing it but here is the first idea of how
  the API will look like.
 
  vimc project link: https://github.com/helen-fornazier/opw-staging/
  For more information: http://kernelnewbies.org/LaurentPinchart
 
  /***
  The API:
  /
 
  In short, a topology like this one: http://goo.gl/Y7eUfu
  Would look like this filesystem tree: https://goo.gl/tCZPTg
  Txt version of the filesystem tree: https://goo.gl/42KX8Y
 
  * The /configfs/vimc subsystem
 
  I haven't checked the latest vimc driver, but doesn't it support
  multiple instances, just like vivid? I would certainly recommend that.
 
  Yes, it does support
 
 
  And if there are multiple instances, then each instance gets its own
  entry in configfs: /configs/vimc0, /configs/vimc1, etc.
 
  You are right, I'll add those
 
 
  The vimc driver registers a subsystem in the configfs with the
  following contents:
   ls /configfs/vimc
  build_topology status
  The build_topology attribute file will be used to tell the driver the
  configuration is done and it can build the topology internally
   echo -n anything here  /configfs/vimc/build_topology
  Reading from the status attribute can have 3 different classes of outputs
  1) deployed: the current configured tree is built
  2) undeployed: no errors, the user has modified the configfs tree thus
  the topology was undeployed
  3) error error_message: the topology configuration is wrong
 
  I don't see the status file in the filesystem tree links above.
 
  Sorry, I forgot to add
 
 
  I actually wonder if we can't use build_topology for that: reading it
  will just return the status.
 
  Yes we can, I was just wondering what should be the name of the file,
  as getting the status from reading the build_topology file doesn't
  seem much intuitive

 I'm not opposed to a status file, but it would be good to know what Laurent
 thinks.

 
 
  What happens if it is deployed and you want to 'undeploy' it? Instead of
  writing anything to build_topology it might be useful to write a real
  command to it. E.g. 'deploy', 'destroy'.
 
  What happens when you make changes while a topology is deployed? Should
  such changes be rejected until the usecount of the driver goes to 0, or
  will it only be rejected when you try to deploy the new configuration?
 
  I was thinking that if the user try changing the topology, or it will
  fail (because the device instance is in use) or it will undeploy the
  old topology (if the device is not in use). Then a 'destroy' command
  won't be useful, the user can just unload the driver when it won't be
  used anymore,

 Well, we're planning to add support for dynamic addition/removal of
 entities, interfaces, pads and links. So, instead of undeploy the
 old topology, one could just do:
 rm -rf part of the tree

I think I misunderstood the word dynamic here. Do you mean that
entities/interfaces/pads/link could be created/removed while their
file handlers are opened? While an instance (lets say vimc2) is being
used?



 If you have multiple vimc instances and you want to 'destroy' the topology
 of only one instance, then you can't rmmod the module.

 You can still use rm remove just one entire instance of the topology.

Just to be clear:
They way I was thinking was: the user do the mkdir/rmdir/echo/cat as
he likes, if some file handler is opened in some device then
rmdir/mkdir/echo would fail in the folder related to that device:

Lets say we have
/configfs/vimc/vimc0/ent/name
/configfs/vimc/vimc1/ent/name
/configfs/vimc/vimc1/ent_debayer/name

if some file related to vimc0 is opened, then echo foo 
/configfs/vimc/vimc0/ent/name would fail.
But echo foo  /configfs/vimc/vimc1/ent/name would work (assuming we
are not using the filehandlers of vimc1)

If the user wants to remove vimc1 (as he is not using it anyway), then just:
$ rmdir -r /configfs/vimc/vimc1

I don't see a big reason to explicitly undeploy a topology (without
removing the folders) other then to modify the topology.
Then when the user changes the filesystem tree, it undeploys the

Re: VIMC: API proposal, configuring the topology through user space

[Helen Fornazier]

Hi, thanks for your reviews

On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 Hi Helen!

 On 08/08/2015 03:55 AM, Helen Fornazier wrote:
 Hi!

 I've made a first sketch about the API of the vimc driver (virtual
 media controller) to configure the topology through user space.
 As first suggested by Laurent Pinchart, it is based on configfs.

 I would like to know you opinion about it, if you have any suggestion
 to improve it, otherwise I'll start its implementation as soon as
 possible.
 This API may change with the MC changes and I may see other possible
 configurations as I implementing it but here is the first idea of how
 the API will look like.

 vimc project link: https://github.com/helen-fornazier/opw-staging/
 For more information: http://kernelnewbies.org/LaurentPinchart

 /***
 The API:
 /

 In short, a topology like this one: http://goo.gl/Y7eUfu
 Would look like this filesystem tree: https://goo.gl/tCZPTg
 Txt version of the filesystem tree: https://goo.gl/42KX8Y

 * The /configfs/vimc subsystem

 I haven't checked the latest vimc driver, but doesn't it support
 multiple instances, just like vivid? I would certainly recommend that.

Yes, it does support


 And if there are multiple instances, then each instance gets its own
 entry in configfs: /configs/vimc0, /configs/vimc1, etc.

You are right, I'll add those


 The vimc driver registers a subsystem in the configfs with the
 following contents:
  ls /configfs/vimc
 build_topology status
 The build_topology attribute file will be used to tell the driver the
 configuration is done and it can build the topology internally
  echo -n anything here  /configfs/vimc/build_topology
 Reading from the status attribute can have 3 different classes of outputs
 1) deployed: the current configured tree is built
 2) undeployed: no errors, the user has modified the configfs tree thus
 the topology was undeployed
 3) error error_message: the topology configuration is wrong

 I don't see the status file in the filesystem tree links above.

Sorry, I forgot to add


 I actually wonder if we can't use build_topology for that: reading it
 will just return the status.

Yes we can, I was just wondering what should be the name of the file,
as getting the status from reading the build_topology file doesn't
seem much intuitive


 What happens if it is deployed and you want to 'undeploy' it? Instead of
 writing anything to build_topology it might be useful to write a real
 command to it. E.g. 'deploy', 'destroy'.

 What happens when you make changes while a topology is deployed? Should
 such changes be rejected until the usecount of the driver goes to 0, or
 will it only be rejected when you try to deploy the new configuration?

I was thinking that if the user try changing the topology, or it will
fail (because the device instance is in use) or it will undeploy the
old topology (if the device is not in use). Then a 'destroy' command
won't be useful, the user can just unload the driver when it won't be
used anymore,


 * Creating an entity:
 Use mkdir in the /configfs/vimc to create an entity representation, e.g.:
  mkdir /configfs/vimc/sensor_a
 The attribute files will be created by the driver through configfs:
  ls /configfs/vimc/sensor_a
 name role
 Configure the name that will appear to the /dev/media0 and what this
 node do (debayer, scaler, capture, input, generic)
  echo -n Sensor A  /configfs/vimc/sensor_a/name
  echo -n sensor  /configfs/vimc/sensor_a/role

 * Creating a pad:
 Use mkdir inside an entity's folder, the attribute called direction
 will be automatically created in the process, for example:
  mkdir /configfs/vimc/sensor_a/pad_0
  ls /configfs/vimc/sensor_a/pad_0
 direction
  echo -n source  /configfs/vimc/sensor_a/pad_0/direction
 The direction attribute can be source or sink

 Hmm. Aren't the pads+direction dictated by the entity role? E.g. a sensor
 will only have one pad which is always a source. I think setting the role
 is what creates the pad directories + direction files.

I thought that we could add as many pads that we want, having a scaler
with two or more sink pads (for example) in the same format that
scales the frames coming from any sink pad and send it to its source
pads, no?
Maybe it is better if we don't let this choice.
I need to check if I can modify the configfs dynamically, I mean, if
the user writes debayer to the role file, I need to create at least
one folder (or file) to allow the user to configure the link flag
related to its source pad, but if in the future we have another entity
role (lets say new_entity) that has more then one source pad, and
the user writes debayer in the role and then new_entity, we will
need to erase the folder created by the debayer to create two new
folders, I am still not sure if I can do that.



 * Creating a link between pads in two 

Re: VIMC: API proposal, configuring the topology through user space

[Hans Verkuil]

Hi Helen!

On 08/08/2015 03:55 AM, Helen Fornazier wrote:
 Hi!
 
 I've made a first sketch about the API of the vimc driver (virtual
 media controller) to configure the topology through user space.
 As first suggested by Laurent Pinchart, it is based on configfs.
 
 I would like to know you opinion about it, if you have any suggestion
 to improve it, otherwise I'll start its implementation as soon as
 possible.
 This API may change with the MC changes and I may see other possible
 configurations as I implementing it but here is the first idea of how
 the API will look like.
 
 vimc project link: https://github.com/helen-fornazier/opw-staging/
 For more information: http://kernelnewbies.org/LaurentPinchart
 
 /***
 The API:
 /
 
 In short, a topology like this one: http://goo.gl/Y7eUfu
 Would look like this filesystem tree: https://goo.gl/tCZPTg
 Txt version of the filesystem tree: https://goo.gl/42KX8Y
 
 * The /configfs/vimc subsystem

I haven't checked the latest vimc driver, but doesn't it support
multiple instances, just like vivid? I would certainly recommend that.

And if there are multiple instances, then each instance gets its own
entry in configfs: /configs/vimc0, /configs/vimc1, etc.

 The vimc driver registers a subsystem in the configfs with the
 following contents:
  ls /configfs/vimc
 build_topology status
 The build_topology attribute file will be used to tell the driver the
 configuration is done and it can build the topology internally
  echo -n anything here  /configfs/vimc/build_topology
 Reading from the status attribute can have 3 different classes of outputs
 1) deployed: the current configured tree is built
 2) undeployed: no errors, the user has modified the configfs tree thus
 the topology was undeployed
 3) error error_message: the topology configuration is wrong

I don't see the status file in the filesystem tree links above.

I actually wonder if we can't use build_topology for that: reading it
will just return the status.

What happens if it is deployed and you want to 'undeploy' it? Instead of
writing anything to build_topology it might be useful to write a real
command to it. E.g. 'deploy', 'destroy'.

What happens when you make changes while a topology is deployed? Should
such changes be rejected until the usecount of the driver goes to 0, or
will it only be rejected when you try to deploy the new configuration?

 * Creating an entity:
 Use mkdir in the /configfs/vimc to create an entity representation, e.g.:
  mkdir /configfs/vimc/sensor_a
 The attribute files will be created by the driver through configfs:
  ls /configfs/vimc/sensor_a
 name role
 Configure the name that will appear to the /dev/media0 and what this
 node do (debayer, scaler, capture, input, generic)
  echo -n Sensor A  /configfs/vimc/sensor_a/name
  echo -n sensor  /configfs/vimc/sensor_a/role
 
 * Creating a pad:
 Use mkdir inside an entity's folder, the attribute called direction
 will be automatically created in the process, for example:
  mkdir /configfs/vimc/sensor_a/pad_0
  ls /configfs/vimc/sensor_a/pad_0
 direction
  echo -n source  /configfs/vimc/sensor_a/pad_0/direction
 The direction attribute can be source or sink

Hmm. Aren't the pads+direction dictated by the entity role? E.g. a sensor
will only have one pad which is always a source. I think setting the role
is what creates the pad directories + direction files.

 
 * Creating a link between pads in two steps:
 Step 1)
 Create a folder inside the source pad folder, the attribute called
 flag will be automatically created in the process, for example:
  mkdir /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
  ls /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
 flags
  echo -n enabled,immutable 
 /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/flags
 In the flags attribute we can have all the links attributes (enabled,
 immutable and dynamic) separated by comma
 
 Step 2)
 Add a symlink between the previous folder we just created in the
 source pad and the sink pad folder we want to connect. Lets say we
 want to connect with the pad on the raw_capture_0 entity pad 0
  ln -s /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
 /configfs/vimc/raw_capture_0/pad_0/

Can't this be created automatically? Or possibly not at all, since it is
implicit in step 1.

BTW, the direction is the wrong way around for pads 0 and 1 of the debayer
and scaler entities: pad_0 is a sink since it gets its data from a sensor
or debayer source pad.

 
 * Build the topology.
 After configuring it, tell the driver we finished:
  echo -n anything here  /configfs/vimc/build_topology
  cat /configfs/vimc/status
 
 NOTE 1: The entity's numbering, as read from /dev/media0, will be the
 order of the creation, same about the pads. Pad 0 will be the first
 pad created in an 

Re: VIMC: API proposal, configuring the topology through user space

[Mauro Carvalho Chehab]

Em Fri, 07 Aug 2015 22:55:28 -0300
Helen Fornazier helen.fornaz...@gmail.com escreveu:

 Hi!
 
 I've made a first sketch about the API of the vimc driver (virtual
 media controller) to configure the topology through user space.
 As first suggested by Laurent Pinchart, it is based on configfs.

Yeah, configfs seems a good option.

 I would like to know you opinion about it, if you have any suggestion
 to improve it, otherwise I'll start its implementation as soon as
 possible.
 This API may change with the MC changes and I may see other possible
 configurations as I implementing it but here is the first idea of how
 the API will look like.
 
 vimc project link: https://github.com/helen-fornazier/opw-staging/
 For more information: http://kernelnewbies.org/LaurentPinchart
 
 /***
 The API:
 /
 
 In short, a topology like this one: http://goo.gl/Y7eUfu
 Would look like this filesystem tree: https://goo.gl/tCZPTg
 Txt version of the filesystem tree: https://goo.gl/42KX8Y
 
 * The /configfs/vimc subsystem
 The vimc driver registers a subsystem in the configfs with the
 following contents:
  ls /configfs/vimc
 build_topology status
 The build_topology attribute file will be used to tell the driver the
 configuration is done and it can build the topology internally
  echo -n anything here  /configfs/vimc/build_topology
 Reading from the status attribute can have 3 different classes of outputs
 1) deployed: the current configured tree is built
 2) undeployed: no errors, the user has modified the configfs tree thus
 the topology was undeployed
 3) error error_message: the topology configuration is wrong
 
 * Creating an entity:
 Use mkdir in the /configfs/vimc to create an entity representation, e.g.:
  mkdir /configfs/vimc/sensor_a
 The attribute files will be created by the driver through configfs:
  ls /configfs/vimc/sensor_a
 name role
 Configure the name that will appear to the /dev/media0 and what this
 node do (debayer, scaler, capture, input, generic)
  echo -n Sensor A  /configfs/vimc/sensor_a/name
  echo -n sensor  /configfs/vimc/sensor_a/role
 
 * Creating a pad:
 Use mkdir inside an entity's folder, the attribute called direction
 will be automatically created in the process, for example:
  mkdir /configfs/vimc/sensor_a/pad_0
  ls /configfs/vimc/sensor_a/pad_0
 direction
  echo -n source  /configfs/vimc/sensor_a/pad_0/direction
 The direction attribute can be source or sink
 
 * Creating a link between pads in two steps:
 Step 1)
 Create a folder inside the source pad folder, the attribute called
 flag will be automatically created in the process, for example:
  mkdir /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
  ls /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
 flags
  echo -n enabled,immutable 
 /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/flags
 In the flags attribute we can have all the links attributes (enabled,
 immutable and dynamic) separated by comma
 
 Step 2)
 Add a symlink between the previous folder we just created in the
 source pad and the sink pad folder we want to connect. Lets say we
 want to connect with the pad on the raw_capture_0 entity pad 0
  ln -s /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
 /configfs/vimc/raw_capture_0/pad_0/
 
 * Build the topology.
 After configuring it, tell the driver we finished:
  echo -n anything here  /configfs/vimc/build_topology
  cat /configfs/vimc/status
 
 NOTE 1: The entity's numbering, as read from /dev/media0, will be the
 order of the creation, same about the pads. Pad 0 will be the first
 pad created in an entity's folder.
 
 NOTE 2: Most of the errors will be captured while configuring the
 topology, e.g., the user won't be able to setup a link if the pad
 which contains the /configfs/ent/pad/link/ folder does not have the
 direction attribute set to source and the use can't change the
 direction of a pad to sink if it already has a symlink going out of
 the current pad.
 
 NOTE 3: The user won't be able to modify the configfs tree if any
 streaming is on.
 
 
 That's it, I hope it is clear.

Seems OK. Please notice that we intend to support dynamic changes
at the pipeline. So, you may nee to support, in the future,
rm and rmmod. Patches for it still need to be written.

Regards,
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

VIMC: API proposal, configuring the topology through user space

[Helen Fornazier]

Hi!

I've made a first sketch about the API of the vimc driver (virtual
media controller) to configure the topology through user space.
As first suggested by Laurent Pinchart, it is based on configfs.

I would like to know you opinion about it, if you have any suggestion
to improve it, otherwise I'll start its implementation as soon as
possible.
This API may change with the MC changes and I may see other possible
configurations as I implementing it but here is the first idea of how
the API will look like.

vimc project link: https://github.com/helen-fornazier/opw-staging/
For more information: http://kernelnewbies.org/LaurentPinchart

/***
The API:
/

In short, a topology like this one: http://goo.gl/Y7eUfu
Would look like this filesystem tree: https://goo.gl/tCZPTg
Txt version of the filesystem tree: https://goo.gl/42KX8Y

* The /configfs/vimc subsystem
The vimc driver registers a subsystem in the configfs with the
following contents:
 ls /configfs/vimc
build_topology status
The build_topology attribute file will be used to tell the driver the
configuration is done and it can build the topology internally
 echo -n anything here  /configfs/vimc/build_topology
Reading from the status attribute can have 3 different classes of outputs
1) deployed: the current configured tree is built
2) undeployed: no errors, the user has modified the configfs tree thus
the topology was undeployed
3) error error_message: the topology configuration is wrong

* Creating an entity:
Use mkdir in the /configfs/vimc to create an entity representation, e.g.:
 mkdir /configfs/vimc/sensor_a
The attribute files will be created by the driver through configfs:
 ls /configfs/vimc/sensor_a
name role
Configure the name that will appear to the /dev/media0 and what this
node do (debayer, scaler, capture, input, generic)
 echo -n Sensor A  /configfs/vimc/sensor_a/name
 echo -n sensor  /configfs/vimc/sensor_a/role

* Creating a pad:
Use mkdir inside an entity's folder, the attribute called direction
will be automatically created in the process, for example:
 mkdir /configfs/vimc/sensor_a/pad_0
 ls /configfs/vimc/sensor_a/pad_0
direction
 echo -n source  /configfs/vimc/sensor_a/pad_0/direction
The direction attribute can be source or sink

* Creating a link between pads in two steps:
Step 1)
Create a folder inside the source pad folder, the attribute called
flag will be automatically created in the process, for example:
 mkdir /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
 ls /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
flags
 echo -n enabled,immutable 
/configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/flags
In the flags attribute we can have all the links attributes (enabled,
immutable and dynamic) separated by comma

Step 2)
Add a symlink between the previous folder we just created in the
source pad and the sink pad folder we want to connect. Lets say we
want to connect with the pad on the raw_capture_0 entity pad 0
 ln -s /configfs/vimc/sensor_a/pad_0/link_to_raw_capture_0/
/configfs/vimc/raw_capture_0/pad_0/

* Build the topology.
After configuring it, tell the driver we finished:
 echo -n anything here  /configfs/vimc/build_topology
 cat /configfs/vimc/status

NOTE 1: The entity's numbering, as read from /dev/media0, will be the
order of the creation, same about the pads. Pad 0 will be the first
pad created in an entity's folder.

NOTE 2: Most of the errors will be captured while configuring the
topology, e.g., the user won't be able to setup a link if the pad
which contains the /configfs/ent/pad/link/ folder does not have the
direction attribute set to source and the use can't change the
direction of a pad to sink if it already has a symlink going out of
the current pad.

NOTE 3: The user won't be able to modify the configfs tree if any
streaming is on.


That's it, I hope it is clear.

Regards
-- 
Helen M. Koike Fornazier
--
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

Please Acknowledge My Proposal

[Gva Abogados]

Please Acknowledge My Proposal!!

My name is Mr. Juan Martin Domingo a lawyer resident in Spain. I am
writing to let you know I have some FUNDS I want to transfer and am
seeking if you can be a beneficiary...Do not hesitate to Contact me for
more information if interested: gva_aboga...@aim.com

Sincerely
Juan Martin Domingo.
domi...@aim.com

--
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

Business Proposal From Tokyo

[Itsuki Kaito]

April 19, 2014

Konnichiwa! It is with respect to directly write this proposal letter to
you, informing you of a potential business
proposal project that can be established from your country with your help,
which will mutually be profitable to us having no risk involved.

If you are agreeable to this business proposal, please indicate your
interest by giving me a direct response email. Feel free to contact me via
electronic mail or telephone for further discussion. I look forward to
hearing from you positively on this proposal.

Domo arigato !
Suki


--
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

[Proposal] media mini-summit - Linux media power management - problems, challenges and fixes

[Shuah Khan]

I am requesting that the following presentation/discussion to be added 
to the media mini-summit agenda. The intent is to do a very short 
presentation and leave time for discussion.


Linux media power management - problems, challenges and fixes

Media devices can be very complex to support in software - for example, 
a small USB TV stick is packed with several components providing the 
functionality to tune, stream analog and/or digital video and audio. 
Some hybrid devices support both analog, and digital TV tuning 
capability with or without a remote control capability. A single TV 
device, which connects to the PC on a USB bus, could have one or more 
I2C buses internally to implement tuning and remote control features.


On Linux, several individual component drivers come together to provide 
full functionality on these media devices. For instance, a single 
digital USB TV stick will have a USB driver that acts as the front-end 
for several Linux TV media infrastructure components such as: Digital 
Video Broadcasting (dvb), Audio, and Video4linux (v4l2). Each of these 
extensions initialize and control their set of registers on the device 
with the aid of additional tuner and remote control drivers. As you can 
see, the infrastructure supporting one of these devices is complex and 
handling suspend/resume within the OS quickly becomes a challenge. It 
won't come as a too much of a surprise to hear that most media drivers 
don't handle power management properly. This is due to the lack of a 
good PM infrastructure inside the media core, as well as driver bugs in 
their suspend and resume code paths. This work also includes using 
devres infrastructure work to handle shared media resources such as 
tuner, demux etc.


In this presentation, we will discuss what is being done to address 
these issues and also present an overview of PM infrastructure being 
considered for future kernel releases.


-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
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

I HAVE A PROPOSAL FOR YOU!

[Yung kim]

Hello,

The Project is about the exportation of 100,000 barrels of Light Crude
Oil daily out from Iraq to Turkey through my client's company in Iraq
at the rate of $92.00 a barrel. This amount to $9,200,000 daily. I ask
for your support as a foreigner to handle this business project with my
client and you are not expected to invest in Iraq

If yes, let me know and we will discuss this project proper.

yung kim.

yung@qq.com

--
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

David Desmond.Business Manager Societe Generale Bank United Kingdom.I have a proposal worth £18,500,000.Get back to us for more details via david_desmon...@yahoo.com

[David Desmond.]

--
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

V4l2 Mini-summit proposal: special API for SDI

[Kieran Kunhya]

Hello,

I have been asked to propose a topic for the mini-summit regarding an
SDI (Serial Digital Interface) API of some sort. For those who are not
aware this is a professional interface used in broadcasting and CCTV.
The most serious issue is that many vendors provide Linux drivers with
V4L2 and ALSA - which is not acceptable for maintaining lipsync, let
alone maintaining the exact relationship between audio samples and
video that SDI provides.

Some other issues are mentioned here: https://wiki.videolan.org/SDI_API/
The wiki page has a very loose proposal for an API, though perhaps the
per-line idea is ambitious at this stage. Field or frame capture is
more realistic.

Regards,

Kieran Kunhya
--
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

Business Proposal.......

[Mr. Gordon Kumar]

Dear Friend,
 I must say that I have enormous respect for you considering the manner in
which I have made contact with you. My name is Mr. Gordon Kumar, The
financial controller at the RESERVE BANK OF INDIA (Main Branch) in New
Delhi, INDIA, and I am getting in touch with you regarding a business deal
worth $15,000,000.00 in my control which will be executed under a legitimate
arrangement. Reply me immediately if interested!
Yours Sincerely,
Mr. Gordon Kumar.
--
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

Proposal

[Lisbeth Karlsson]

I seek your consent to present you as the next of kin to the account  
of a deceased client for claims valued at Fourteen million, three  
hundred thousand Pounds.


Contact me through my private email for details: halawani@ovi.com

Mr. Halawani, Azhar Abdulrahim.
Solicitors Legal Services Barristers
United Kingdom

--
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Diorser]

Hello,

Please find below some news for A918R
[details @  
http://www.linuxtv.org/wiki/index.php/AVerMedia_AVerTV_HD_Express_A918R ]


* the patch proposed to automatically load the right modules for A918R  
card is not yet available

= http://www.mail-archive.com/linux-media@vger.kernel.org/msg56659.html
(I don't exactly know what is missing to make it accepted).
This patch would at least avoid having to modify dvb-usb-ids.h  af9035.c  
each time to test some git updates.


* previously, in December, the signal level detection was fuzzy and not  
reliable.
Now, the reported signal level is strictly at  (good antenna RF signal  
confirmed with other device).


I am aware A918R card is not the most requested one (Express card), but  
that's all I can add in case it can help, even for another card.


Regards.


see details below:
--
UPDATE April 8th 2013: result with modules compiled from git:

tzap -r TEST
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/home/test_r/.tzap/channels.conf'
tuning to 586167000 Hz
video pid 0x0200, audio pid 0x028a
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |

kaffeine from command line

kaffeine(1584) DvbScanFilter::timerEvent: timeout while reading section;  
type = 0 pid = 0
kaffeine(1584) DvbScanFilter::timerEvent: timeout while reading section;  
type = 2 pid = 17
demux_wavpack: (open_wv_file:127) open_wv_file: non-seekable inputs aren't  
supported yet.

net_buf_ctrl: dvbspeed mode
kaffeine(1584) DvbScanFilter::timerEvent: timeout while reading section;  
type = 0 pid = 0
kaffeine(1584) DvbScanFilter::timerEvent: timeout while reading section;  
type = 2 pid = 17

net_buf_ctrl: dvbspeed OFF
kaffeine(2186) DvbLinuxDevice::getSignal: ioctl FE_READ_SIGNAL_STRENGTH  
failed for frontend /dev/dvb/adapter0/frontend0
kaffeine(2186) DvbLinuxDevice::getSnr:ioctl FE_READ_SNR failed for  
frontend /dev/dvb/adapter0/frontend0
kaffeine(2186) DvbLinuxDevice::isTuned:   ioctl FE_READ_STATUS failed for  
frontend /dev/dvb/adapter0/frontend0

.../...
kaffeine(2186) DvbLinuxDevice::getSignal: ioctl FE_READ_SIGNAL_STRENGTH  
failed for frontend /dev/dvb/adapter0/frontend0
kaffeine(2186) DvbLinuxDevice::getSnr:ioctl FE_READ_SNR failed for  
frontend /dev/dvb/adapter0/frontend0
kaffeine(2186) DvbLinuxDevice::isTuned:   ioctl FE_READ_STATUS failed for  
frontend /dev/dvb/adapter0/frontend0


demux_wavpack: (open_wv_file:127) open_wv_file: non-seekable inputs aren't  
supported yet.

net_buf_ctrl: dvbspeed mode
net_buf_ctrl: dvbspeed OFF
kaffeine(2215) DvbDevice::frontendEvent: tuning failed
--
--
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Antti Palosaari]

On 04/09/2013 05:46 PM, Diorser wrote:

Hello,

Please find below some news for A918R
[details @
http://www.linuxtv.org/wiki/index.php/AVerMedia_AVerTV_HD_Express_A918R ]

* the patch proposed to automatically load the right modules for A918R
card is not yet available
= http://www.mail-archive.com/linux-media@vger.kernel.org/msg56659.html
(I don't exactly know what is missing to make it accepted).
This patch would at least avoid having to modify dvb-usb-ids.h 
af9035.c each time to test some git updates.

* previously, in December, the signal level detection was fuzzy and not
reliable.
Now, the reported signal level is strictly at  (good antenna RF
signal confirmed with other device).

I am aware A918R card is not the most requested one (Express card), but
that's all I can add in case it can help, even for another card.

Regards.


Patch, which adds USB ID, is not acceptable unless device is know to be 
working. It currently works only partially by loading correct modules 
but tuning does not work. Surely, it is not very many lines code to fix 
it - most likely just some GPIO setting (antenna switch?).


regards
Antti

--
http://palosaari.fi/
--
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Diorser]

With RF signal input now clearly reported at , antenna switch problem  
is a good assumption.
However, I don't have the right skills to sniff and imagine which file  
should be modified and how.

All I can do is recompiling git files and test.
If a list a GPIO values was available somewhere, and if I know where to  
modify the files, and with some luck, a miracle could may be happen.
However, I fully understand that an express card is too specific to create  
some interest.

Don't worry about this.
I just wanted to give some update on investigations done 3 months ago  
(quite some time spent on it).

Thanks.
Rgds.



Patch, which adds USB ID, is not acceptable unless device is know to be  
working. It currently works only partially by loading correct modules  
but tuning does not work. Surely, it is not very many lines code to fix  
it - most likely just some GPIO setting (antenna switch?).


regards
Antti

--
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Diorser]

 I don't know why you resists to remove antenna or unplug stick, but  
even you remove antenna I am quite sure you will see similar results.


I've been simply confused by the signal reported at  level most of the  
time, and the scanning working.
I thought the problem was a step behind with the demux error reported by  
dvbsnoop wrongly used.


Can you confirm, either you personally, or someone else you know, that  
AVerTV_Volar_HD_PRO_A835 using same components as A918R fully works  
including tuning+scanning ?
If so, it's hard to believe that Avermedia made something different when  
changing from a USB stick to Express card detected as USB, but who  
knows


Maybe there is some GPIO controlling antenna input or switching some  
other.


I've noticed that af9035.c does not contain any GPIO settings for TDA18218  
(all other tuners have).
Would it be possible to implement gpio setting for TDA18218 so that they  
are used for implementations requesting it ? (just an assumption of  
course). Don't know at all if this kind of information is easily available.


If necessary, although not familiar at all with debugging, I can try co  
compile a specific kernel with CONFIG_DEBUG_KERNEL=y option to see if I  
can grab something interesting.


Finally, it seems that fresh implementation of TDA18218 needs a bit more  
investigation checked on more devices.


BTW, is the A918R patch proposal accepted to be taken into consideration,  
or do I have to make a more formal GIT request ?


Regards.
Diorser.







--
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Antti Palosaari]

On 01/03/2013 11:24 PM, Diorser wrote:



 I don't know why you resists to remove antenna or unplug stick, but
even you remove antenna I am quite sure you will see similar results.


I've been simply confused by the signal reported at  level most of
the time, and the scanning working.


hmm, you could say it is working as you don't see errors but for me 
working means you could tune to channels and see programs. Tuning 
failed is not working for me.



I thought the problem was a step behind with the demux error reported by
dvbsnoop wrongly used.

Can you confirm, either you personally, or someone else you know, that
AVerTV_Volar_HD_PRO_A835 using same components as A918R fully works
including tuning+scanning ?
If so, it's hard to believe that Avermedia made something different when
changing from a USB stick to Express card detected as USB, but who
knows


Maybe there is some GPIO controlling antenna input or switching some
other.


I've noticed that af9035.c does not contain any GPIO settings for
TDA18218 (all other tuners have).
Would it be possible to implement gpio setting for TDA18218 so that they
are used for implementations requesting it ? (just an assumption of
course). Don't know at all if this kind of information is easily available.


I am quite 100% sure problems is GPIOs. Those could be different from 
design to design, especially in case of AverMedia



If necessary, although not familiar at all with debugging, I can try co
compile a specific kernel with CONFIG_DEBUG_KERNEL=y option to see if I
can grab something interesting.

Finally, it seems that fresh implementation of TDA18218 needs a bit more
investigation checked on more devices.

BTW, is the A918R patch proposal accepted to be taken into
consideration, or do I have to make a more formal GIT request ?

Regards.
Diorser.


Without the hardware it is hard to do anything. I don't care to spend my 
time of debugging it remotely.


Surely it is only under 10 lines of new code to support that device, but 
finding out reason is thing which took time.


regards
Antti

--
http://palosaari.fi/
--
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

AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Diorser]

Hi all,

After struggling some days trying to wake up a AVerTV_HD_Express_A918R  
DVB-T card, I am stuck with a DMX_SET_PES_FILTER error reported by  
dvbsnoop, I cannot solve (beyond my skills).
This card is based on Afatech AF9035 +  AF9033 + NXP TDA18218HN, and then  
very similar to AVerTV_Volar_HD_PRO_A835 (in term of components used).


You will find all details and current state at:
http://www.linuxtv.org/wiki/index.php/AVerMedia_AVerTV_HD_Express_A918R

In the meantime, I propose following patches to get dvb_usb_af9035  
compatible with A918R.

--
--- /drivers/media/dvb-core/dvb-usb-ids.h
+++ /drivers/media/dvb-core/dvb-usb-ids.h
  @@ -233,6 +233,7 @@
  #define USB_PID_AVERMEDIA_A835 0xa835
  #define USB_PID_AVERMEDIA_B835 0xb835
 +#define USB_PID_AVERMEDIA_A918R  0x0918
  #define USB_PID_AVERMEDIA_1867 0x1867
  #define USB_PID_AVERMEDIA_A867 0xa867
--
 --- /drivers/media/usb/dvb-usb-v2/af9035.c
 +++ /drivers/media/usb/dvb-usb-v2/af9035.c
 @@ -1125,6 +1125,8 @@
 { DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_B835,
   af9035_props, AVerMedia AVerTV Volar HD/PRO (A835),  
NULL) },

 +   { DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A918R,
 + af9035_props, AVerMedia AverTV (A918R), NULL) },
 { DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_1867,
   af9035_props, AVerMedia HD Volar (A867), NULL) },
--
If someone has some ideas to solve/understand the DMX_SET_PES_FILTER  
issue, please feel free to advise what should be tested or modified.

Thanks, and ... Happy New Year !
Diorser.
--
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Antti Palosaari]

On 01/01/2013 11:40 PM, Diorser wrote:

Hi all,

After struggling some days trying to wake up a AVerTV_HD_Express_A918R
DVB-T card, I am stuck with a DMX_SET_PES_FILTER error reported by
dvbsnoop, I cannot solve (beyond my skills).
This card is based on Afatech AF9035 +  AF9033 + NXP TDA18218HN, and
then very similar to AVerTV_Volar_HD_PRO_A835 (in term of components used).

You will find all details and current state at:
http://www.linuxtv.org/wiki/index.php/AVerMedia_AVerTV_HD_Express_A918R

In the meantime, I propose following patches to get dvb_usb_af9035
compatible with A918R.
--

--- /drivers/media/dvb-core/dvb-usb-ids.h
+++ /drivers/media/dvb-core/dvb-usb-ids.h
   @@ -233,6 +233,7 @@
   #define USB_PID_AVERMEDIA_A835 0xa835
   #define USB_PID_AVERMEDIA_B835 0xb835
  +#define USB_PID_AVERMEDIA_A918R  0x0918
   #define USB_PID_AVERMEDIA_1867 0x1867
   #define USB_PID_AVERMEDIA_A867 0xa867
--

  --- /drivers/media/usb/dvb-usb-v2/af9035.c
  +++ /drivers/media/usb/dvb-usb-v2/af9035.c
  @@ -1125,6 +1125,8 @@
  { DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_B835,
af9035_props, AVerMedia AVerTV Volar HD/PRO (A835),
NULL) },
  +   { DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A918R,
  + af9035_props, AVerMedia AverTV (A918R), NULL) },
  { DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_1867,
af9035_props, AVerMedia HD Volar (A867), NULL) },
--

If someone has some ideas to solve/understand the DMX_SET_PES_FILTER
issue, please feel free to advise what should be tested or modified.


Patch looks correct.

If you are talking of that error I saw wiki you mentioned it is not 
error. You cannot use dvbsnoop like that. You have to tune to channel 
first and only after device is tuned successfully pidscan is possible.


 # dvbsnoop -s pidscan
 dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/
 Transponder PID-Scan...
 Error(22): DMX_SET_PES_FILTER: Invalid argument

If you are really sure your antenna is good (not that small antenna 
bundled) and it does not work then there is some bug. I bet some GPIO is 
wrong. Maybe you should take some sniffs using SniffUSB2.0 and look there...




Thanks, and ... Happy New Year !
Diorser.


regards
Antti

--
http://palosaari.fi/
--
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Diorser]

Thanks for your so fast reply.
Unfortunately, scanning output is always empty with 100% signal strength   
(external antenna)
I also use a AverTV super_007 with the same external antenna on a  another  
PC with Kaffeine =Signal = 100%.


I also tried different dvb-usb-af9035-02.fw  firmware with different   
LINK/OFDM value (I don't understand but just tried.).

Never got any PID or channel.
Scanning and tuning work (or seem to with w_scan or kaffeine), but no   
data output.


I've noticed that videobuf_dvb and videobuf_dma_sg modules are need by a   
saa7134 card, and not by AF9035. (no videobuf / dvb_usb_af9035

dependency).
Don't know if it is normal or not.

A bit frustrating to be so close to the end, but also a bit pessimistic   
because really reaching the limit of my skills.
Anyway, I will stay tuned in case some values need to be modified in the   
source for test, or any updates I will try.


Many thanks.
Diorser.

On Tue, 01 Jan 2013 23:26:32 +0100, Antti Palosaari crope@iki.fiwrote


Patch looks correct.


If you are talking of that error I saw wiki you mentioned it is not  
error. You cannot use dvbsnoop like that. You have to tune to channel  
first and only after device is tuned successfully pidscan is possible.



 # dvbsnoop -s pidscan
 dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/
 Transponder PID-Scan...
 Error(22): DMX_SET_PES_FILTER: Invalid argument


If you are really sure your antenna is good (not that small antenna  
bundled) and it does not work then there is some bug. I bet some GPIO is  
wrong. Maybe you should take some sniffs using SniffUSB2.0 and look  
there...


regards
Antti

--
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Antti Palosaari]

On 01/02/2013 01:09 AM, Diorser wrote:

Thanks for your so fast reply.
Unfortunately, scanning output is always empty with 100% signal
strength  (external antenna)
I also use a AverTV super_007 with the same external antenna on a
another PC with Kaffeine =Signal = 100%.


Does it show 100% even antenna is unplugged?


I also tried different dvb-usb-af9035-02.fw  firmware with different
LINK/OFDM value (I don't understand but just tried.).


I don't know exactly what are differences between all those firmwares, 
but I know all firmwares are not working with all devices.



Never got any PID or channel.
Scanning and tuning work (or seem to with w_scan or kaffeine), but no
data output.


You mean you see LOCK flag gained, then there is maybe error pid filter 
timeouts?



I've noticed that videobuf_dvb and videobuf_dma_sg modules are need by
a  saa7134 card, and not by AF9035. (no videobuf / dvb_usb_af9035
dependency).
Don't know if it is normal or not.


It is normal.


A bit frustrating to be so close to the end, but also a bit pessimistic
because really reaching the limit of my skills.
Anyway, I will stay tuned in case some values need to be modified in
the  source for test, or any updates I will try.


Do you have some working device (saa7134?)?
If yes, use it to generate channels.conf and when you has working 
channels.conf you could use tzap to tune.


If not, then make channels conf by hand

make file .tzap/channels.conf
then add line to that file:
TEST:63400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:512:650:17

replace 63400 (634MHz) frequency of your transmitter. I think 8Mhz 
bandwidth is used for your area too, but if not change it to 7MHz. Other 
values are not critical as those are detected automatically.


After that you could tune: tzap -r TEST

Antti



Many thanks.
Diorser.

On Tue, 01 Jan 2013 23:26:32 +0100, Antti Palosaari crope@iki.fiwrote


Patch looks correct.



If you are talking of that error I saw wiki you mentioned it is not
error. You cannot use dvbsnoop like that. You have to tune to channel
first and only after device is tuned successfully pidscan is possible.



 # dvbsnoop -s pidscan
 dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/
 Transponder PID-Scan...
 Error(22): DMX_SET_PES_FILTER: Invalid argument



If you are really sure your antenna is good (not that small antenna
bundled) and it does not work then there is some bug. I bet some GPIO
is wrong. Maybe you should take some sniffs using SniffUSB2.0 and look
there...

regards
Antti

--
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



--
http://palosaari.fi/
--
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Diorser]

Does it show 100% even antenna is unplugged ?


It seems in fact that signal indicator is not reliable.
I have to sometimes reset dvb with:

for I in dvb_usb_af9035 af9033 tda18218 dvb_usb_v2 dvb_core rc_core; do   
rmmod $I; done

modprobe dvb-usb-af9035

The antenna signal input is fine, this is at least the point I am sure.

You mean you see LOCK flag gained, then there is maybe error pid filter  
timeouts ?


Not sure of that. tzap test seems to show the opposite:

tzap -r TEST
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/home/test_r/.tzap/channels.conf'
tuning to 586167000 Hz
video pid 0x0200, audio pid 0x028a
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |

I also took the kaffeine dvb files perfectly working with saa7134 card,  
but A918R card does not tune on  any channel.
Then, the lack of signal strength stability / front-end problem is may be  
the root cause.

Thanks again for your time
--
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Antti Palosaari]

On 01/02/2013 02:12 AM, Diorser wrote:

Does it show 100% even antenna is unplugged ?


It seems in fact that signal indicator is not reliable.
I have to sometimes reset dvb with:

for I in dvb_usb_af9035 af9033 tda18218 dvb_usb_v2 dvb_core rc_core; do
rmmod $I; done
modprobe dvb-usb-af9035

The antenna signal input is fine, this is at least the point I am sure.


You mean you see LOCK flag gained, then there is maybe error pid
filter timeouts ?


Not sure of that. tzap test seems to show the opposite:

tzap -r TEST
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/home/test_r/.tzap/channels.conf'
tuning to 586167000 Hz
video pid 0x0200, audio pid 0x028a
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |


This says it quite clearly, it does not work at all. I don't know why 
you resists to remove antenna or unplug stick, but even you remove 
antenna I am quite sure you will see similar results.



I also took the kaffeine dvb files perfectly working with saa7134 card,
but A918R card does not tune on  any channel.
Then, the lack of signal strength stability / front-end problem is may
be the root cause.
Thanks again for your time


Maybe there is some GPIO controlling antenna input or switching some other.

Antti

--
http://palosaari.fi/
--
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal

[Diorser]

Just to compare, this is the same tzap test made on same channel with a  
AverTV 007 (saa7134) on a another PC, with same antenna.

It works perfectly.

tzap -r TEST
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '~/.tzap/channels.conf'
tuning to 586167000 Hz
video pid 0x0200, audio pid 0x028a
status 00 | signal b2b2 | snr 2929 | ber 0001fffe | unc  |
status 1f | signal b2b2 | snr fefe | ber 004e | unc  |  
FE_HAS_LOCK
status 1f | signal b2b2 | snr fefe | ber 0050 | unc  |  
FE_HAS_LOCK
status 1f | signal b2b2 | snr fefe | ber 005c | unc  |  
FE_HAS_LOCK
status 1f | signal b1b1 | snr fefe | ber 0054 | unc  |  
FE_HAS_LOCK
status 1f | signal b2b2 | snr fefe | ber 004e | unc  |  
FE_HAS_LOCK
status 1f | signal b2b2 | snr  | ber 0050 | unc  |  
FE_HAS_LOCK
status 1f | signal b1b1 | snr  | ber 0052 | unc  |  
FE_HAS_LOCK
status 1f | signal b2b2 | snr  | ber 0050 | unc  |  
FE_HAS_LOCK
status 1f | signal b1b1 | snr  | ber 004a | unc  |  
FE_HAS_LOCK
status 1f | signal b1b1 | snr  | ber 0050 | unc  |  
FE_HAS_LOCK
status 1f | signal b1b1 | snr  | ber 004e | unc  |  
FE_HAS_LOCK
status 1f | signal b1b1 | snr  | ber 0044 | unc  |  
FE_HAS_LOCK
status 1f | signal b2b2 | snr  | ber 004a | unc  |  
FE_HAS_LOCK
status 1f | signal b2b2 | snr  | ber 004e | unc  |  
FE_HAS_LOCK

--
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: Proposal for the addition of a binary V4L2 control type

[Hans Verkuil]

On Fri October 12 2012 16:33:20 Alain VOLMAT wrote:
 Hi Hans
 
  -Original Message-
  From: Hans Verkuil [mailto:hverk...@xs4all.nl]
  Sent: Friday, October 12, 2012 8:21 AM
  To: Alain VOLMAT
  Cc: Laurent Pinchart; Linux Media Mailing List (linux-media@vger.kernel.org)
  Subject: Re: Proposal for the addition of a binary V4L2 control type
  
  On Fri October 12 2012 00:41:37 Alain VOLMAT wrote:
   Hi Laurent,
  
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: vendredi 12 octobre 2012 00:22
To: Alain VOLMAT
Cc: Linux Media Mailing List (linux-media@vger.kernel.org)
Subject: Re: Proposal for the addition of a binary V4L2 control type
   
Hi Alain,
   
On Thursday 11 October 2012 22:50:29 Alain VOLMAT wrote:
 Hi guys,

 In the context of supporting the control of our HDMI-TX via V4L2
 in our SetTopBox, we are facing interface issue with V4L2 when
 trying to set some information from the application into the H/W.

 As an example, in the HDCP context, an application controlling the
 HDMI-TX have the possibility to inform the transmitter that it
 should fail authentication to some identified HDMI-RX because for
 example they might be known to be bad HDMI receiver that cannot
  be trusted.
 This is basically done by setting the list of key (BKSV) into the 
 HDMI-TX
  H/W.

 Currently, V4L2 ext control can be of the following type:

 enum v4l2_ctrl_type {
 V4L2_CTRL_TYPE_INTEGER   = 1,
 V4L2_CTRL_TYPE_BOOLEAN   = 2,
 V4L2_CTRL_TYPE_MENU  = 3,
 V4L2_CTRL_TYPE_BUTTON= 4,
 V4L2_CTRL_TYPE_INTEGER64 = 5,
 V4L2_CTRL_TYPE_CTRL_CLASS= 6,
 V4L2_CTRL_TYPE_STRING= 7,
 V4L2_CTRL_TYPE_BITMASK   = 8,
 }

 There is nothing here than could efficiently be used to push this
 kind of long (several bytes long .. not fitting into an int64) key
  information.
 STRING exists but actually since they are supposed to be strings,
 the
 V4L2 core code (v4l2-ctrls.c) is using strlen to figure out the
 length of data to be copied and it thus cannot be used to push this 
 kind
  of blob data.

 Would you consider the addition of a new v4l2_ctrl_type, for
 example called V4L2_CTRL_TYPE_BINARY or so, that basically would
 be pointer + length. That would be helpful to pass this kind of
 control from the application to the driver. (here I took the
 example of HDCP key blob but that isn't of course the only example we
  can find of course).
   
If I remember correctly Hans Verkuil wasn't happy with the concept of
  binary controls.
  
  That's correct. Controls should be 1) fairly elementary types and 2) have 
  clear
  semantics. Binary blobs are neither.
  
While I'm
not totally against it, I agree with him that it could open the door
to abuses. There are valid use cases though, both for binary
strings (such as encryption keys) and binary arrays (such as gamma
  tables).
Completely random binary blobs are not a good idea though.
   
So far we've worked around the absence of binary controls by using
custom ioctls (or even standardizing new ioctls). It might or might
not be a good solution for your problem, depending on your exact use
  cases.
  
   Ok, at least for the HDCP keys table we could for an ioctl if that's 
   already
  the case in some other situations.
  
  Look at the EDID ioctls in v4l2-subdev.h. The HDCP ioctls should be next to
  them.
  If I remember correctly you need a get ioctl to obtains the keys from a
  receiver and a set ioctl to set the keys for a transmitter.
 
 Well, yes, if keys goes up to the user space, yes those 2 ioctls will be 
 needed.
 But another ioctl or control will also be needed to ENABLE  DiSABLE the HDCP 
 / HDCP encryption I think.

Certainly. And that can be a control.

 This doesn't always have to be enable so it should be necessary to allow 
 triggering that.
 
   I can however think about some cases where passing such binary controls is
  better than ioctl in case of it is necessary achieve several settings in an 
  atomic
  way (which is I believe one of the merit of ext_control). Still in the 
  field of
  HDMI-TX I can at least think about setting video post processing setting
  tables  mode change at the same time for example.
   If one setting is already available via a control and the other one has 
   to be
  done via an ioctl, then it becomes hard to ensure that this is done in an
  atomic way back at the driver level.
  
   So, in short, for HDCP keys, there might not be a problem with ioctl but 
   for
  other HDMI-TX settings, I'm afraid we will face problems.
  
   I am preparing some proposal for some new HDMI-TX controls (or ioctl ?)
  for things like SPD, AVMUTE, CONTENT_TYPE etc, I guess we could

Re: Proposal for the addition of a binary V4L2 control type

[Hans Verkuil]

On Fri October 12 2012 00:41:37 Alain VOLMAT wrote:
 Hi Laurent,
 
  -Original Message-
  From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
  Sent: vendredi 12 octobre 2012 00:22
  To: Alain VOLMAT
  Cc: Linux Media Mailing List (linux-media@vger.kernel.org)
  Subject: Re: Proposal for the addition of a binary V4L2 control type
  
  Hi Alain,
  
  On Thursday 11 October 2012 22:50:29 Alain VOLMAT wrote:
   Hi guys,
  
   In the context of supporting the control of our HDMI-TX via V4L2 in
   our SetTopBox, we are facing interface issue with V4L2 when trying to
   set some information from the application into the H/W.
  
   As an example, in the HDCP context, an application controlling the
   HDMI-TX have the possibility to inform the transmitter that it should
   fail authentication to some identified HDMI-RX because for example
   they might be known to be bad HDMI receiver that cannot be trusted.
   This is basically done by setting the list of key (BKSV) into the HDMI-TX 
   H/W.
  
   Currently, V4L2 ext control can be of the following type:
  
   enum v4l2_ctrl_type {
   V4L2_CTRL_TYPE_INTEGER   = 1,
   V4L2_CTRL_TYPE_BOOLEAN   = 2,
   V4L2_CTRL_TYPE_MENU  = 3,
   V4L2_CTRL_TYPE_BUTTON= 4,
   V4L2_CTRL_TYPE_INTEGER64 = 5,
   V4L2_CTRL_TYPE_CTRL_CLASS= 6,
   V4L2_CTRL_TYPE_STRING= 7,
   V4L2_CTRL_TYPE_BITMASK   = 8,
   }
  
   There is nothing here than could efficiently be used to push this kind
   of long (several bytes long .. not fitting into an int64) key information.
   STRING exists but actually since they are supposed to be strings, the
   V4L2 core code (v4l2-ctrls.c) is using strlen to figure out the length
   of data to be copied and it thus cannot be used to push this kind of blob 
   data.
  
   Would you consider the addition of a new v4l2_ctrl_type, for example
   called V4L2_CTRL_TYPE_BINARY or so, that basically would be pointer +
   length. That would be helpful to pass this kind of control from the
   application to the driver. (here I took the example of HDCP key blob
   but that isn't of course the only example we can find of course).
  
  If I remember correctly Hans Verkuil wasn't happy with the concept of 
  binary controls.

That's correct. Controls should be 1) fairly elementary types and 2) have clear
semantics. Binary blobs are neither.

  While I'm
  not totally against it, I agree with him that it could open the door to 
  abuses. There are valid use
  cases though, both for binary strings (such as encryption keys) and 
  binary arrays (such as
  gamma tables).
  Completely random binary blobs are not a good idea though.
  
  So far we've worked around the absence of binary controls by using custom 
  ioctls (or even
  standardizing new ioctls). It might or might not be a good solution for 
  your problem, depending
  on your exact use cases.
 
 Ok, at least for the HDCP keys table we could for an ioctl if that's already 
 the case in some other situations.

Look at the EDID ioctls in v4l2-subdev.h. The HDCP ioctls should be next to 
them.
If I remember correctly you need a get ioctl to obtains the keys from a receiver
and a set ioctl to set the keys for a transmitter.

 I can however think about some cases where passing such binary controls is 
 better than ioctl in case of it is necessary achieve several settings in an 
 atomic way (which is I believe one of the merit of ext_control). Still in the 
 field of HDMI-TX I can at least think about setting video post processing 
 setting tables  mode change at the same time for example.
 If one setting is already available via a control and the other one has to be 
 done via an ioctl, then it becomes hard to ensure that this is done in an 
 atomic way back at the driver level.
 
 So, in short, for HDCP keys, there might not be a problem with ioctl but for 
 other HDMI-TX settings, I'm afraid we will face problems.
 
 I am preparing some proposal for some new HDMI-TX controls (or ioctl ?) for 
 things like SPD, AVMUTE, CONTENT_TYPE etc, I guess we could discuss about 
 that problem again at that time.

A lot of the stuff that's in InfoFrames lends itself perfectly to controls.
They are both simple types and have clear semantics.

Regards,

Hans
--
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: Proposal for the addition of a binary V4L2 control type

[Alain VOLMAT]

Hi Hans

 -Original Message-
 From: Hans Verkuil [mailto:hverk...@xs4all.nl]
 Sent: Friday, October 12, 2012 8:21 AM
 To: Alain VOLMAT
 Cc: Laurent Pinchart; Linux Media Mailing List (linux-media@vger.kernel.org)
 Subject: Re: Proposal for the addition of a binary V4L2 control type
 
 On Fri October 12 2012 00:41:37 Alain VOLMAT wrote:
  Hi Laurent,
 
   -Original Message-
   From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
   Sent: vendredi 12 octobre 2012 00:22
   To: Alain VOLMAT
   Cc: Linux Media Mailing List (linux-media@vger.kernel.org)
   Subject: Re: Proposal for the addition of a binary V4L2 control type
  
   Hi Alain,
  
   On Thursday 11 October 2012 22:50:29 Alain VOLMAT wrote:
Hi guys,
   
In the context of supporting the control of our HDMI-TX via V4L2
in our SetTopBox, we are facing interface issue with V4L2 when
trying to set some information from the application into the H/W.
   
As an example, in the HDCP context, an application controlling the
HDMI-TX have the possibility to inform the transmitter that it
should fail authentication to some identified HDMI-RX because for
example they might be known to be bad HDMI receiver that cannot
 be trusted.
This is basically done by setting the list of key (BKSV) into the 
HDMI-TX
 H/W.
   
Currently, V4L2 ext control can be of the following type:
   
enum v4l2_ctrl_type {
V4L2_CTRL_TYPE_INTEGER   = 1,
V4L2_CTRL_TYPE_BOOLEAN   = 2,
V4L2_CTRL_TYPE_MENU  = 3,
V4L2_CTRL_TYPE_BUTTON= 4,
V4L2_CTRL_TYPE_INTEGER64 = 5,
V4L2_CTRL_TYPE_CTRL_CLASS= 6,
V4L2_CTRL_TYPE_STRING= 7,
V4L2_CTRL_TYPE_BITMASK   = 8,
}
   
There is nothing here than could efficiently be used to push this
kind of long (several bytes long .. not fitting into an int64) key
 information.
STRING exists but actually since they are supposed to be strings,
the
V4L2 core code (v4l2-ctrls.c) is using strlen to figure out the
length of data to be copied and it thus cannot be used to push this kind
 of blob data.
   
Would you consider the addition of a new v4l2_ctrl_type, for
example called V4L2_CTRL_TYPE_BINARY or so, that basically would
be pointer + length. That would be helpful to pass this kind of
control from the application to the driver. (here I took the
example of HDCP key blob but that isn't of course the only example we
 can find of course).
  
   If I remember correctly Hans Verkuil wasn't happy with the concept of
 binary controls.
 
 That's correct. Controls should be 1) fairly elementary types and 2) have 
 clear
 semantics. Binary blobs are neither.
 
   While I'm
   not totally against it, I agree with him that it could open the door
   to abuses. There are valid use cases though, both for binary
   strings (such as encryption keys) and binary arrays (such as gamma
 tables).
   Completely random binary blobs are not a good idea though.
  
   So far we've worked around the absence of binary controls by using
   custom ioctls (or even standardizing new ioctls). It might or might
   not be a good solution for your problem, depending on your exact use
 cases.
 
  Ok, at least for the HDCP keys table we could for an ioctl if that's already
 the case in some other situations.
 
 Look at the EDID ioctls in v4l2-subdev.h. The HDCP ioctls should be next to
 them.
 If I remember correctly you need a get ioctl to obtains the keys from a
 receiver and a set ioctl to set the keys for a transmitter.

Well, yes, if keys goes up to the user space, yes those 2 ioctls will be needed.
But another ioctl or control will also be needed to ENABLE  DiSABLE the HDCP / 
HDCP encryption I think.
This doesn't always have to be enable so it should be necessary to allow 
triggering that.

  I can however think about some cases where passing such binary controls is
 better than ioctl in case of it is necessary achieve several settings in an 
 atomic
 way (which is I believe one of the merit of ext_control). Still in the field 
 of
 HDMI-TX I can at least think about setting video post processing setting
 tables  mode change at the same time for example.
  If one setting is already available via a control and the other one has to 
  be
 done via an ioctl, then it becomes hard to ensure that this is done in an
 atomic way back at the driver level.
 
  So, in short, for HDCP keys, there might not be a problem with ioctl but for
 other HDMI-TX settings, I'm afraid we will face problems.
 
  I am preparing some proposal for some new HDMI-TX controls (or ioctl ?)
 for things like SPD, AVMUTE, CONTENT_TYPE etc, I guess we could discuss
 about that problem again at that time.
 
 A lot of the stuff that's in InfoFrames lends itself perfectly to controls.
 They are both simple types and have clear semantics.

Well at least SPD data that are (product name

Proposal for the addition of a binary V4L2 control type

[Alain VOLMAT]

Hi guys,

In the context of supporting the control of our HDMI-TX via V4L2 in our 
SetTopBox, we are facing interface issue with V4L2 when trying to set some 
information from the application into the H/W.

As an example, in the HDCP context, an application controlling the HDMI-TX have 
the possibility to inform the transmitter that it should fail authentication to 
some identified HDMI-RX because for example they might be known to be bad 
HDMI receiver that cannot be trusted. This is basically done by setting the 
list of key (BKSV) into the HDMI-TX H/W.

Currently, V4L2 ext control can be of the following type:

enum v4l2_ctrl_type {
V4L2_CTRL_TYPE_INTEGER   = 1,
V4L2_CTRL_TYPE_BOOLEAN   = 2,
V4L2_CTRL_TYPE_MENU  = 3,
V4L2_CTRL_TYPE_BUTTON= 4,
V4L2_CTRL_TYPE_INTEGER64 = 5,
V4L2_CTRL_TYPE_CTRL_CLASS= 6,
V4L2_CTRL_TYPE_STRING= 7,
V4L2_CTRL_TYPE_BITMASK   = 8,
}

There is nothing here than could efficiently be used to push this kind of long 
(several bytes long .. not fitting into an int64) key information.
STRING exists but actually since they are supposed to be strings, the V4L2 core 
code (v4l2-ctrls.c) is using strlen to figure out the length of data to be 
copied and it thus cannot be used to push this kind of blob data.

Would you consider the addition of a new v4l2_ctrl_type, for example called 
V4L2_CTRL_TYPE_BINARY or so, that basically would be pointer + length. That 
would be helpful to pass this kind of control from the application to the 
driver.
(here I took the example of HDCP key blob but that isn't of course the only 
example we can find of course).

Regards,

Alain
--
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: Proposal for the addition of a binary V4L2 control type

[Laurent Pinchart]

Hi Alain,

On Thursday 11 October 2012 22:50:29 Alain VOLMAT wrote:
 Hi guys,
 
 In the context of supporting the control of our HDMI-TX via V4L2 in our
 SetTopBox, we are facing interface issue with V4L2 when trying to set some
 information from the application into the H/W.
 
 As an example, in the HDCP context, an application controlling the HDMI-TX
 have the possibility to inform the transmitter that it should fail
 authentication to some identified HDMI-RX because for example they might be
 known to be bad HDMI receiver that cannot be trusted. This is basically
 done by setting the list of key (BKSV) into the HDMI-TX H/W.
 
 Currently, V4L2 ext control can be of the following type:
 
 enum v4l2_ctrl_type {
 V4L2_CTRL_TYPE_INTEGER   = 1,
 V4L2_CTRL_TYPE_BOOLEAN   = 2,
 V4L2_CTRL_TYPE_MENU  = 3,
 V4L2_CTRL_TYPE_BUTTON= 4,
 V4L2_CTRL_TYPE_INTEGER64 = 5,
 V4L2_CTRL_TYPE_CTRL_CLASS= 6,
 V4L2_CTRL_TYPE_STRING= 7,
 V4L2_CTRL_TYPE_BITMASK   = 8,
 }
 
 There is nothing here than could efficiently be used to push this kind of
 long (several bytes long .. not fitting into an int64) key information.
 STRING exists but actually since they are supposed to be strings, the V4L2
 core code (v4l2-ctrls.c) is using strlen to figure out the length of data
 to be copied and it thus cannot be used to push this kind of blob data.
 
 Would you consider the addition of a new v4l2_ctrl_type, for example called
 V4L2_CTRL_TYPE_BINARY or so, that basically would be pointer + length. That
 would be helpful to pass this kind of control from the application to the
 driver. (here I took the example of HDCP key blob but that isn't of course
 the only example we can find of course).

If I remember correctly Hans Verkuil wasn't happy with the concept of binary 
controls. While I'm not totally against it, I agree with him that it could 
open the door to abuses. There are valid use cases though, both for binary 
strings (such as encryption keys) and binary arrays (such as gamma tables). 
Completely random binary blobs are not a good idea though.

So far we've worked around the absence of binary controls by using custom 
ioctls (or even standardizing new ioctls). It might or might not be a good 
solution for your problem, depending on your exact use cases.

-- 
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: Proposal for the addition of a binary V4L2 control type

[Alain VOLMAT]

Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: vendredi 12 octobre 2012 00:22
 To: Alain VOLMAT
 Cc: Linux Media Mailing List (linux-media@vger.kernel.org)
 Subject: Re: Proposal for the addition of a binary V4L2 control type
 
 Hi Alain,
 
 On Thursday 11 October 2012 22:50:29 Alain VOLMAT wrote:
  Hi guys,
 
  In the context of supporting the control of our HDMI-TX via V4L2 in
  our SetTopBox, we are facing interface issue with V4L2 when trying to
  set some information from the application into the H/W.
 
  As an example, in the HDCP context, an application controlling the
  HDMI-TX have the possibility to inform the transmitter that it should
  fail authentication to some identified HDMI-RX because for example
  they might be known to be bad HDMI receiver that cannot be trusted.
  This is basically done by setting the list of key (BKSV) into the HDMI-TX 
  H/W.
 
  Currently, V4L2 ext control can be of the following type:
 
  enum v4l2_ctrl_type {
  V4L2_CTRL_TYPE_INTEGER   = 1,
  V4L2_CTRL_TYPE_BOOLEAN   = 2,
  V4L2_CTRL_TYPE_MENU  = 3,
  V4L2_CTRL_TYPE_BUTTON= 4,
  V4L2_CTRL_TYPE_INTEGER64 = 5,
  V4L2_CTRL_TYPE_CTRL_CLASS= 6,
  V4L2_CTRL_TYPE_STRING= 7,
  V4L2_CTRL_TYPE_BITMASK   = 8,
  }
 
  There is nothing here than could efficiently be used to push this kind
  of long (several bytes long .. not fitting into an int64) key information.
  STRING exists but actually since they are supposed to be strings, the
  V4L2 core code (v4l2-ctrls.c) is using strlen to figure out the length
  of data to be copied and it thus cannot be used to push this kind of blob 
  data.
 
  Would you consider the addition of a new v4l2_ctrl_type, for example
  called V4L2_CTRL_TYPE_BINARY or so, that basically would be pointer +
  length. That would be helpful to pass this kind of control from the
  application to the driver. (here I took the example of HDCP key blob
  but that isn't of course the only example we can find of course).
 
 If I remember correctly Hans Verkuil wasn't happy with the concept of binary 
 controls. While I'm
 not totally against it, I agree with him that it could open the door to 
 abuses. There are valid use
 cases though, both for binary strings (such as encryption keys) and binary 
 arrays (such as
 gamma tables).
 Completely random binary blobs are not a good idea though.
 
 So far we've worked around the absence of binary controls by using custom 
 ioctls (or even
 standardizing new ioctls). It might or might not be a good solution for your 
 problem, depending
 on your exact use cases.

Ok, at least for the HDCP keys table we could for an ioctl if that's already 
the case in some other situations.
I can however think about some cases where passing such binary controls is 
better than ioctl in case of it is necessary achieve several settings in an 
atomic way (which is I believe one of the merit of ext_control). Still in the 
field of HDMI-TX I can at least think about setting video post processing 
setting tables  mode change at the same time for example.
If one setting is already available via a control and the other one has to be 
done via an ioctl, then it becomes hard to ensure that this is done in an 
atomic way back at the driver level.

So, in short, for HDCP keys, there might not be a problem with ioctl but for 
other HDMI-TX settings, I'm afraid we will face problems.

I am preparing some proposal for some new HDMI-TX controls (or ioctl ?) for 
things like SPD, AVMUTE, CONTENT_TYPE etc, I guess we could discuss about that 
problem again at that time.

Regards,

Alain
--
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: Proposal for the addition of a binary V4L2 control type

[Laurent Pinchart]

Hi Alain,

On Friday 12 October 2012 00:41:37 Alain VOLMAT wrote:
 On Vendredi 12 octobre 2012 00:22 Laurent Pinchart wrote: 
  On Thursday 11 October 2012 22:50:29 Alain VOLMAT wrote:
   Hi guys,
   
   In the context of supporting the control of our HDMI-TX via V4L2 in
   our SetTopBox, we are facing interface issue with V4L2 when trying to
   set some information from the application into the H/W.
   
   As an example, in the HDCP context, an application controlling the
   HDMI-TX have the possibility to inform the transmitter that it should
   fail authentication to some identified HDMI-RX because for example
   they might be known to be bad HDMI receiver that cannot be trusted.
   This is basically done by setting the list of key (BKSV) into the
   HDMI-TX H/W.
   
   Currently, V4L2 ext control can be of the following type:
   
   enum v4l2_ctrl_type {
   
   V4L2_CTRL_TYPE_INTEGER   = 1,
   V4L2_CTRL_TYPE_BOOLEAN   = 2,
   V4L2_CTRL_TYPE_MENU  = 3,
   V4L2_CTRL_TYPE_BUTTON= 4,
   V4L2_CTRL_TYPE_INTEGER64 = 5,
   V4L2_CTRL_TYPE_CTRL_CLASS= 6,
   V4L2_CTRL_TYPE_STRING= 7,
   V4L2_CTRL_TYPE_BITMASK   = 8,
   
   }
   
   There is nothing here than could efficiently be used to push this kind
   of long (several bytes long .. not fitting into an int64) key
   information.
   STRING exists but actually since they are supposed to be strings, the
   V4L2 core code (v4l2-ctrls.c) is using strlen to figure out the length
   of data to be copied and it thus cannot be used to push this kind of
   blob data.
   
   Would you consider the addition of a new v4l2_ctrl_type, for example
   called V4L2_CTRL_TYPE_BINARY or so, that basically would be pointer +
   length. That would be helpful to pass this kind of control from the
   application to the driver. (here I took the example of HDCP key blob
   but that isn't of course the only example we can find of course).
  
  If I remember correctly Hans Verkuil wasn't happy with the concept of
  binary controls. While I'm not totally against it, I agree with him that
  it could open the door to abuses. There are valid use cases though, both
  for binary strings (such as encryption keys) and binary arrays (such as
  gamma tables).
  Completely random binary blobs are not a good idea though.
  
  So far we've worked around the absence of binary controls by using custom
  ioctls (or even standardizing new ioctls). It might or might not be a
  good solution for your problem, depending on your exact use cases.
 
 Ok, at least for the HDCP keys table we could for an ioctl if that's already
 the case in some other situations. I can however think about some cases
 where passing such binary controls is better than ioctl in case of it is
 necessary achieve several settings in an atomic way (which is I believe one
 of the merit of ext_control). Still in the field of HDMI-TX I can at least
 think about setting video post processing setting tables  mode change at
 the same time for example. If one setting is already available via a
 control and the other one has to be done via an ioctl, then it becomes hard
 to ensure that this is done in an atomic way back at the driver level.

I agree with you, atomic setting of parameters will be a problem. That's a 
problem I've already thought about in the past, and we've largely been able to 
ignore it so far. It could even get worse: I don't know how long we will be 
able to ignore that formats and selection rectangles will need to be set 
atomically with controls.

All this doesn't prevent me from sleeping though :-)

 So, in short, for HDCP keys, there might not be a problem with ioctl but for
 other HDMI-TX settings, I'm afraid we will face problems.
 
 I am preparing some proposal for some new HDMI-TX controls (or ioctl ?) for
 things like SPD, AVMUTE, CONTENT_TYPE etc, I guess we could discuss about
 that problem again at that time.

-- 
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: Preliminary proposal, new APIs for HDMI and DVI control in v4l2

[Martin Bugge (marbugge)]

Hi Soby

On 05/27/2012 07:30 PM, Soby Mathew wrote:

Martin Bugge (marbuggemarbuggeat  cisco.com  writes:



This is a preliminary proposal for an extension to the v4l2 api.
To be discussed at the  V4L2 'brainstorming' meeting in Warsaw, March 2011

Purpose: Provide basic controls for HDMI and DVI devices.



reposting the query since the earlier post did not appear in mailing list.

Hi Martin,
We are also in requirement of these controls as described by you. I did a
search in the archives but could not find a suitable conclusion to the RFC. I
could find that the dv_timings structure has been modified as a result of
further discussions. But for many items like S_EDID, DV_CABLE_DETECT, Info
frames etc , I could not find the logical conclusion to this RFC. Could please
let me know the further updates on these requirements?
It has been on hold for a very long time, but just last week Hans 
Verkuil posted a RFC

which is a follow up on this subject.

http://www.spinics.net/lists/linux-media/msg47671.html

So that thread has taken over.




Thanks in Advance
Best Regards
Soby Mathew



Best regards
Martin Bugge


--
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: Preliminary proposal, new APIs for HDMI and DVI control in v4l2

[Hans Verkuil]

On Wed 30 May 2012 13:13:27 Martin Bugge (marbugge) wrote:
 Hi Soby
 
 On 05/27/2012 07:30 PM, Soby Mathew wrote:
  Martin Bugge (marbuggemarbuggeat  cisco.com  writes:
 
 
  This is a preliminary proposal for an extension to the v4l2 api.
  To be discussed at the  V4L2 'brainstorming' meeting in Warsaw, March 2011
 
  Purpose: Provide basic controls for HDMI and DVI devices.
 
 
  reposting the query since the earlier post did not appear in mailing list.
 
  Hi Martin,
  We are also in requirement of these controls as described by you. I did 
  a
  search in the archives but could not find a suitable conclusion to the RFC. 
  I
  could find that the dv_timings structure has been modified as a result of
  further discussions. But for many items like S_EDID, DV_CABLE_DETECT, Info
  frames etc , I could not find the logical conclusion to this RFC. Could 
  please
  let me know the further updates on these requirements?
 It has been on hold for a very long time, but just last week Hans 
 Verkuil posted a RFC
 which is a follow up on this subject.
 
 http://www.spinics.net/lists/linux-media/msg47671.html
 
 So that thread has taken over.

And expect to see a small patch series to be posted in the next few days 
containing
a slightly changed version of the proposal, including DocBook documentation.

Please review those patches when they are posted and let us know if you are OK 
with
it or if you have additional requirements.

Regards,

Hans
--
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: Preliminary proposal, new APIs for HDMI and DVI control in v4l2

[Soby Mathew]

Martin Bugge (marbugge marbugge at cisco.com writes:

 
 
 This is a preliminary proposal for an extension to the v4l2 api.
 To be discussed at the  V4L2 'brainstorming' meeting in Warsaw, March 2011
 
 Purpose: Provide basic controls for HDMI and DVI devices.
 
 
reposting the query since the earlier post did not appear in mailing list.

Hi Martin,
   We are also in requirement of these controls as described by you. I did a 
search in the archives but could not find a suitable conclusion to the RFC. I 
could find that the dv_timings structure has been modified as a result of 
further discussions. But for many items like S_EDID, DV_CABLE_DETECT, Info 
frames etc , I could not find the logical conclusion to this RFC. Could please 
let me know the further updates on these requirements?


Thanks in Advance
Best Regards
Soby Mathew


--
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 PATCH 0/2] Proposal to deprecate four drivers

[Hans Verkuil]

Hi all,

These two patches deprecate the ISA video capture pms driver and the three
parallel port webcam drivers bw-qcam, c-qcam and w9966.

Nobody has hardware for the three parallel port webcams anymore (and we really
tried to get hold of some), and my ISA pms board also no longer works (I suspect
the Pentium motherboard I use for testing ISA cards is too fast :-) ).

I've given up on these drivers. I've posted a pull request to get these drivers
up to speed with regards to the latest frameworks (the pms update has already
been merged), and I think that should be the last change before removing them
altogether. If someone ever gets working hardware for these drivers, then they
are easy to resurrect from the git history should there be a desire to do so.

ISA and parallel port are both unsuitable for streaming video, so this hardware
is really obsolete.

Regards,

Hans

--
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

[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 f.fainelli at gmail.com
 Subject: Re: [RFC] HDMI-CEC
 proposalhttp://news.gmane.org/find-
root.php?message_id=%3c4F87F195.5080504%40gmail.com%3e
 Newsgroups: gmane.linux.drivers.video-input-
infrastructurehttp://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 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

Re: [RFC] HDMI-CEC proposal

[Hans Verkuil]

, 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* 
 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 majordomo at 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 majordomo at 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

[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

[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

[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

[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

[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

[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: Business proposal

[Laurent Pinchart]

Hi Koen,

On Thursday 16 February 2012 23:46:51 Beel, Koen wrote:
 Hi Laurent,
 
 Would it be possible to give us your number on which you can be reached next
 Monday? I prefer to init the call from our side as we will join the call
 with two people and we will be in a meeting room... (so not available on
 our desk phone)

Sure. You can call me at +32477410753.

-- 
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: Cleanup proposal for media/gspca

[Ezequiel]

On Sun, Nov 20, 2011 at 08:24:29AM +0100, Jean-Francois Moine wrote:
 
 Hi Ezequiel,
 
 It is not a minor patch, but maybe you don't know about object
 programming.
 
 As it is defined, a gspca device _is_ a video device, as a gspca
 subdriver is a gspca device, and as a video device is a device: each
 lower structure is contained in a higher one.
 
 Your patch defines the gspca structure as a separate entity which is
 somewhat related to a video device by two reverse pointers. It
 complexifies the structure accesses, adds more code and hides the
 nature of a gspca device.
 

Hi Jef, 

Thanks for the explanation, I have things much clear now.
I didn't realize linux coding style enforces so explicitly OOP.

I based my patch on tm6000 driver and your
previous mail about the -supposedly- ugly cast:

  gspca_dev = (struct gspca_dev *) video_devdata(file);

Now it doesn't seems so ugly, I guess I went too far.
Still, maybe the 'container_of' trick could make thins
easier to understand.

Thanks again for your patience,
Ezequiel.

--
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: Cleanup proposal for media/gspca

[Ezequiel]

On Thu, Nov 17, 2011 at 11:07:16AM +0100, Jean-Francois Moine wrote:
 On Wed, 16 Nov 2011 15:19:04 -0300
 Ezequiel Garc??a elezegar...@gmail.com wrote:
 
  In 'media/video/gspca/gspca.c' I really hated this cast (maybe because
  I am too dumb to understand it):
  
gspca_dev = (struct gspca_dev *) video_devdata(file);
  
  wich is only legal because a struct video_device is the first member
  of gspca_dev. IMHO, this is 'unnecesary obfuscation'.
  The thing is the driver is surely working fine and there is no good
  reasong for the change.
  
  Is it ok to submit a patchset to change this? Something like this:
  
  diff --git a/drivers/media/video/gspca/gspca.c
  b/drivers/media/video/gspca/gspca.c
  index 881e04c..5d962ce 100644
  --- a/drivers/media/video/gspca/gspca.c
  +++ b/drivers/media/video/gspca/gspca.c
  @@ -1304,9 +1306,11 @@ static void gspca_release(struct video_device *vfd)
   static int dev_open(struct file *file)
   {
  struct gspca_dev *gspca_dev;
  +   struct video_device *vdev;
  
  PDEBUG(D_STREAM, [%s] open, current-comm);
  -   gspca_dev = (struct gspca_dev *) video_devdata(file);
  +   vdev = video_devdata(file);
  +   gspca_dev = video_get_drvdata(vdev);
  if (!gspca_dev-present)
 
 Hi Ezequiel,
 
 You are right, the cast is not a good way (and there are a lot of them
 in the gspca subdrivers), but your patch does not work because the
 'private_data' of the device is not initialized (there is no call to
 video_set_drvdata).
 
 So, a possible cleanup could be:
 
  -   gspca_dev = (struct gspca_dev *) video_devdata(file);
  +   gspca_dev = container_of(video_devdata(file), struct gspca_dev, vdev);
 
 Is it OK for you?
 

Hi Jef,

I just sent a patch to linux-media for this little issue. 

I realize it is only a very minor patch, 
so I am not sure If I am helping or just annoying the developers ;)

Anyway, if you could check the patch I would appreciate it. 

A few questions arose:

* I made the patch on this tree: 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
  not sure if this is ok.

* Should I send gspca's patches to anyone else besides you and the list?

* I have this on my MAINTANIERS file: 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
  But that repo seems no longer alive, maybe MAINTAINERS need some
  updating.

Again, hope the patch helps, 

Thanks,
Ezequiel.
--
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: Cleanup proposal for media/gspca

[Jean-Francois Moine]

On Wed, 16 Nov 2011 15:19:04 -0300
Ezequiel García elezegar...@gmail.com wrote:

 In 'media/video/gspca/gspca.c' I really hated this cast (maybe because
 I am too dumb to understand it):
 
   gspca_dev = (struct gspca_dev *) video_devdata(file);
 
 wich is only legal because a struct video_device is the first member
 of gspca_dev. IMHO, this is 'unnecesary obfuscation'.
 The thing is the driver is surely working fine and there is no good
 reasong for the change.
 
 Is it ok to submit a patchset to change this? Something like this:
 
 diff --git a/drivers/media/video/gspca/gspca.c
 b/drivers/media/video/gspca/gspca.c
 index 881e04c..5d962ce 100644
 --- a/drivers/media/video/gspca/gspca.c
 +++ b/drivers/media/video/gspca/gspca.c
 @@ -1304,9 +1306,11 @@ static void gspca_release(struct video_device *vfd)
  static int dev_open(struct file *file)
  {
   struct gspca_dev *gspca_dev;
 + struct video_device *vdev;
 
   PDEBUG(D_STREAM, [%s] open, current-comm);
 - gspca_dev = (struct gspca_dev *) video_devdata(file);
 + vdev = video_devdata(file);
 + gspca_dev = video_get_drvdata(vdev);
   if (!gspca_dev-present)

Hi Ezequiel,

You are right, the cast is not a good way (and there are a lot of them
in the gspca subdrivers), but your patch does not work because the
'private_data' of the device is not initialized (there is no call to
video_set_drvdata).

So, a possible cleanup could be:

 - gspca_dev = (struct gspca_dev *) video_devdata(file);
 + gspca_dev = container_of(video_devdata(file), struct gspca_dev, vdev);

Is it OK for you?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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: Cleanup proposal for media/gspca

[Ezequiel]

On Thu, Nov 17, 2011 at 11:07:16AM +0100, Jean-Francois Moine wrote:
 On Wed, 16 Nov 2011 15:19:04 -0300
 Ezequiel Garc??a elezegar...@gmail.com wrote:
 
  In 'media/video/gspca/gspca.c' I really hated this cast (maybe because
  I am too dumb to understand it):
  
gspca_dev = (struct gspca_dev *) video_devdata(file);
  
  wich is only legal because a struct video_device is the first member
  of gspca_dev. IMHO, this is 'unnecesary obfuscation'.
  The thing is the driver is surely working fine and there is no good
  reasong for the change.
  
  Is it ok to submit a patchset to change this? Something like this:
  
  diff --git a/drivers/media/video/gspca/gspca.c
  b/drivers/media/video/gspca/gspca.c
  index 881e04c..5d962ce 100644
  --- a/drivers/media/video/gspca/gspca.c
  +++ b/drivers/media/video/gspca/gspca.c
  @@ -1304,9 +1306,11 @@ static void gspca_release(struct video_device *vfd)
   static int dev_open(struct file *file)
   {
  struct gspca_dev *gspca_dev;
  +   struct video_device *vdev;
  
  PDEBUG(D_STREAM, [%s] open, current-comm);
  -   gspca_dev = (struct gspca_dev *) video_devdata(file);
  +   vdev = video_devdata(file);
  +   gspca_dev = video_get_drvdata(vdev);
  if (!gspca_dev-present)
 
 Hi Ezequiel,
 
 You are right, the cast is not a good way (and there are a lot of them
 in the gspca subdrivers), but your patch does not work because the
 'private_data' of the device is not initialized (there is no call to
 video_set_drvdata).
 
 So, a possible cleanup could be:
 
  -   gspca_dev = (struct gspca_dev *) video_devdata(file);
  +   gspca_dev = container_of(video_devdata(file), struct gspca_dev, vdev);
 
 Is it OK for you?

Hi, and thanks a lot for your comments. Actually the _sample_ patch I sent 
was just to exemplify the real patch I had in mind, and not wasn't meant to
work.

Maybe later I can send the whole patch properly formatted. 
I know there are more of that in gspca, but right now I made 
changes just in gspca.c, tested with my pac7302 camera, 
so far so good: it is working. 

Anyway, I am _very_ noob and just starting with this kernel 
programming thing so any comments of any kind are
welcome.

Thanks,
Ezequiel.
--
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

Cleanup proposal for media/gspca

[Ezequiel García]

Hi folks,

In 'media/video/gspca/gspca.c' I really hated this cast (maybe because
I am too dumb to understand it):

  gspca_dev = (struct gspca_dev *) video_devdata(file);

wich is only legal because a struct video_device is the first member
of gspca_dev. IMHO, this is 'unnecesary obfuscation'.
The thing is the driver is surely working fine and there is no good
reasong for the change.

Is it ok to submit a patchset to change this? Something like this:

diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 881e04c..5d962ce 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1304,9 +1306,11 @@ static void gspca_release(struct video_device *vfd)
 static int dev_open(struct file *file)
 {
struct gspca_dev *gspca_dev;
+   struct video_device *vdev;

PDEBUG(D_STREAM, [%s] open, current-comm);
-   gspca_dev = (struct gspca_dev *) video_devdata(file);
+   vdev = video_devdata(file);
+   gspca_dev = video_get_drvdata(vdev);
if (!gspca_dev-present)

Thanks,
Ezequiel.
--
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: Proposal for a low-level Linux display framework

[Laurent Pinchart]

Hi Alan and Rob,

On Monday 19 September 2011 02:09:36 Rob Clark wrote:
 On Sun, Sep 18, 2011 at 5:23 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
  This would leave us with the issue of controlling formats and other
  parameters on the pipelines. We could keep separate DRM, KMS, FB and
  V4L APIs for that,
  
  There are some other differences that matter. The exact state and
  behaviour of memory, sequencing of accesses, cache control and management
  are a critical part of DRM for most GPUs, as is the ability to have them
  in swap backed objects and to do memory management of them. Fences and
  the like are a big part of the logic of many renderers and the same
  fencing has to be applied between capture and GPU, and also in some cases
  between playback accelerators (eg MP4 playback) and GPU.

That's why I believe the DRM API is our best solution to address all those 
issues.

I'm not advocating merging the DRM, FB and V4L APIs for memory management. 
What I would like to investigate is whether we can use a common API for the 
common needs, which are (in my opinion):

- reporting the entities that make up the graphics pipeline (such as planes, 
overlays, compositors, transmitters,  connectors, ...), especially when 
pipelines get more complex than the plane-crtc-encoder-connector DRM model

- configuring data routing in those complex pipelines

- and possibly configuring formats (pixel format, frame size, crop rectangle, 
composition rectangle, ...) on those entities

  To glue them together I think you'd need to support the use of GEM
  objects (maybe extended) in V4L. That may actually make life cleaner and
  simpler in some respects because GEM objects are refcounted nicely and
  have handles.
 
 fwiw, I think the dmabuf proposal that linaro GWG is working on should
 be sufficient for V4L to capture directly into a GEM buffer that can
 be scanned out (overlay) or composited by GPU, etc, in cases where the
 different dma initiators can all access some common memory:
 
 http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000616.html
 
 The idea is that you could allocate a GEM buffer, export a dmabuf
 handle for that buffer that could be passed to v4l2 camera device (ie.
 V4L2_MEMORY_DMABUF), video encoder, etc..  the importing device should
 bracket DMA to/from the buffer w/ get/put_scatterlist() so an unused
 buffer could be unpinned if needed.

I second Rob here, I think that API should be enough to solve our memory 
sharing problems between different devices. This is a bit out of scope though, 
as neither the low-level Linux display framework proposal nor my comments 
target that, but it's an important topic worth mentioning.

  DRM and KMS abstract out stuff into what is akin to V4L subdevices for
  the various objects the video card has that matter for display - from
  scanout buffers to the various video outputs, timings and the like.
  
  I don't know what it's like with OMAP but for some of the x86 stuff
  particularly low speed/power stuff the capture devices, GPU and overlays
  tend to be fairly incestuous in order to do things like 1080i/p preview
  while recording from the camera.
 
 We don't like extra memcpy's, but something like dmabuf fits us
 nicely.. and I expect it would work well in any sort of UMA system
 where camera, encoder, GPU, overlay, etc all can share the same memory
 and formats.  I suspect the situation is similar in the x86 SoC
 world.. but would be good to get some feedback on the proposal.  (I
 guess next version of the RFC would go out to more mailing lists for
 broader review.)
 
  GPU is also a bit weird in some ways because while its normally
  nonsensical to do things like use the capture facility one card to drive
  part of another, it's actually rather useful (although not supported
  really by DRM) to do exactly that with GPUs. A simple example is a dual
  headed box with a dumb frame buffer and an accelerated output both of
  which are using memory that can be hit by the accelerated card. Classic
  example being a USB plug in monitor.

-- 
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: Proposal for a low-level Linux display framework

[Laurent Pinchart]

Hi Rob,

(CC'ing linux-media, as I believe this is very on-topic)

On Sunday 18 September 2011 18:14:26 Rob Clark wrote:
 On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart wrote:
  On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
  On 09/15/2011 05:52 PM, Alex Deucher wrote:
   Please don't claim that the DRM developers do not want to cooperate.
   I realize that people have strong opinions about existing APIs, put
   there has been just as much, if not more obstinacy from the v4l and fb
   people.
  
  Well, I think it's too late to really fix this thing. We now have 3 APIs
  in the kernel that have to be kept. Probably the best we can do now is
  figure out how we can reduce code duplication and do extensions to
  those APIs in a way that they are compatible with each other or
  completely independent and can be used across the APIs.
  
  Sorry for jumping late into the discussion. Let me try to shed some new
  light on this.
  
  I've been thinking about the DRM/KMS/FB/V4L APIs overlap for quite some
  time now. All of them have their share of issues, historical nonsense
  and unique features. I don't think we can pick one of those APIs today
  and decide to drop the others, but we certainly need to make DRM, KMS,
  FB and V4L interoperable at various levels. The alternative is to keep
  ignoring each other and let the market decice.
 
 I think we need to differentiate between V4L camera, and display..
 
 MC and subdev stuff clearly seem to be the way to go for complex
 camera / imaging subsystems.  But that is a very different problem
 domain from GPU+display.  We need to stop blurring the two topics.

I would agree with you if we were only talking about GPU, but display is 
broader than that. Many hardware available today have complex display 
pipelines with deep tunneling between other IP blocks (such as the camera 
subsystem) and the display. Configuration of such pipelines isn't specific to 
DRM/KMS.

  Thinking that the market could pick something like OpenMAX
  scares me, so I'd rather find a good compromise and move forward.
  
  Disclaimer: My DRM/KMS knowledge isn't as good as my FB and V4L
  knowledge, so please feel free to correct my mistakes.
  
  All our video-related APIs started as solutions to different problems.
  They all share an important feature: they assume that the devices they
  control is more or less monolithic. For that reason they expose a single
  device to userspace, and mix device configuration and data transfer on
  the same device node.
  
  This shortcoming became painful in V4L a couple of years ago. When I
  started working on the OMAP3 ISP (camera) driver I realized that trying
  to configure a complex hardware pipeline without exposing its internals
  to userspace applications wouldn't be possible. DRM, KMS and FB ran into
  the exact same problem, just more recently, as showed by various RFCs
  ([1], [2]).
 
 But I do think that overlays need to be part of the DRM/KMS interface,
 simply because flipping still needs to be synchronized w/ the GPU.  I
 have some experience using V4L for display, and this is one (of
 several) broken aspects of that.

I agree that DRM/KMS must be used to address needs specific to display 
hardware, but I don't think *all* display needs are specific to the display.

  To fix this issue, the V4L community developed a new API called the Media
  Controller [3]. In a nutshell, the MC aims at
  
  - exposing the device topology to userspace as an oriented graph of
  entities connected with links through pads
  
  - controlling the device topology from userspace by enabling/disabling
  links
  
  - giving userspace access to per-entity controls
  
  - configuring formats at individual points in the pipeline from
  userspace.
  
  The MC API solves the first two problems. The last two require help from
  V4L (which has been extended with new MC-aware ioctls), as MC is
  media-agnostic and can't thus configure video formats.
  
  To support this, the V4L subsystem exposes an in-kernel API based around
  the concept of sub-devices. A single high-level hardware device is
  handled by multiple sub-devices, possibly controlled by different
  drivers. For instance, in the OMAP3-based N900 digital camera, the OMAP3
  ISP is made of 8 sub-devices (all controlled by the OMAP3 ISP driver),
  and the two sensors, flash controller and lens controller all have their
  own sub-device, each of them controlled by its own driver.
  
  All this infrastructure exposes the devices a the graph showed in [4] to
  applications, and the V4L sub-device API can be used to set formats at
  individual pads. This allows controlling scaling, cropping, composing and
  other video-related operations on the pipeline.
  
  With the introduction of the media controller architecture, I now see V4L
  as being made of three parts.
  
  1. The V4L video nodes streaming API, used to manage video buffers
  memory, map it to userspace, and control video 

RFC: Proposal to change the way pending events are handled

[Hans Verkuil]

While working on the control events I realized that the way we handle pending
events is rather complicated.

What currently happens internally is that you have to allocate a fixed sized
list of events. New events are queued on the 'available' list and when they
are processed by the application they are queued on the 'free' list.

If the 'free' list is empty, then no new events can be queued and you will
drop events.

Dropping events can be nasty and in the case of control events can cause a
control panel to contain stale control values if it missed a value change
event.

One option is to allocate enough events, but what is 'enough' events? That
depends on many factors. And allocating more events than is necessary wastes
memory.

But what might be a better option is this: for each event a filehandle
subscribes to there is only one internal v4l2_kevent allocated.

This struct is either marked empty (no event was raised) or contains the
latest state of this event. When the event is dequeued by the application
the struct is marked empty again.

So you never get duplicate events, instead, if a 'duplicate' event is raised
it will just overwrite the 'old' event and move it to the end of the list of
pending events. In other words, the old event is removed and the new event is
inserted instead.

The nice thing about this is that for each subscribed event type you will
never lose a raised event completely. You may lose intermediate events, but 
the latest event for that type will always be available.

E.g. supposed you subscribed to a control containing the status of the HDMI
hotplug. Connecting an HDMI cable can cause a bounce condition where the HDMI
hotplug toggles many times in quick succession. This could currently flood
the event queue and you may lose the last event. With the proposed change the
last event will always arrive, although the intermediate events will be lost.

Comments?

Regards,

Hans
--
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: Proposal to change the way pending events are handled

[David Cohen]

Hi Hans,

On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 While working on the control events I realized that the way we handle pending
 events is rather complicated.

 What currently happens internally is that you have to allocate a fixed sized
 list of events. New events are queued on the 'available' list and when they
 are processed by the application they are queued on the 'free' list.

 If the 'free' list is empty, then no new events can be queued and you will
 drop events.

 Dropping events can be nasty and in the case of control events can cause a
 control panel to contain stale control values if it missed a value change
 event.

I remember it was a topic I discussed with Sakari.


 One option is to allocate enough events, but what is 'enough' events? That
 depends on many factors. And allocating more events than is necessary wastes
 memory.

Cases where events are lost are exception and IMO enough events
would be almost always waste of memory.


 But what might be a better option is this: for each event a filehandle
 subscribes to there is only one internal v4l2_kevent allocated.

 This struct is either marked empty (no event was raised) or contains the
 latest state of this event. When the event is dequeued by the application
 the struct is marked empty again.

 So you never get duplicate events, instead, if a 'duplicate' event is raised
 it will just overwrite the 'old' event and move it to the end of the list of
 pending events. In other words, the old event is removed and the new event is
 inserted instead.

That's an interesting proposal. Currently it will have impact at least
on statistics collection OMAP3ISP driver. It brings to my mind 2
points:
 - OMAP3ISP triggers one event for each statistic buffers produced. If
we avoid events duplication, userapp will miss a statistic buffer.
It's possible to bypass this problem, but the OMAP3 ISP statistics'
private interface should be updated as well.
 - To define a standard for statistics collection is something we need
to do to avoid new ISP's to always create custom interfaces.


 The nice thing about this is that for each subscribed event type you will
 never lose a raised event completely. You may lose intermediate events, but
 the latest event for that type will always be available.

I may have a suggestion. If some event is affected by the number of
times it was triggered (like the statistic ones mentioned above),
instead of a bool empty flag, it may contain a counter. Then a
duplicated event will be raised and will still inform how many
intermediate events were lost. After event is dequeued once, the
counter could be reset.

Regards,

David Cohen


 E.g. supposed you subscribed to a control containing the status of the HDMI
 hotplug. Connecting an HDMI cable can cause a bounce condition where the HDMI
 hotplug toggles many times in quick succession. This could currently flood
 the event queue and you may lose the last event. With the proposed change the
 last event will always arrive, although the intermediate events will be lost.

 Comments?

 Regards,

        Hans
 --
 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: Proposal to change the way pending events are handled

[Laurent Pinchart]

Hi Hans and David,

On Tuesday 07 June 2011 13:51:38 David Cohen wrote:
 On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil hverk...@xs4all.nl wrote:
  While working on the control events I realized that the way we handle
  pending events is rather complicated.
  
  What currently happens internally is that you have to allocate a fixed
  sized list of events. New events are queued on the 'available' list and
  when they are processed by the application they are queued on the 'free'
  list.
  
  If the 'free' list is empty, then no new events can be queued and you
  will drop events.
  
  Dropping events can be nasty and in the case of control events can cause
  a control panel to contain stale control values if it missed a value
  change event.
 
 I remember it was a topic I discussed with Sakari.
 
  One option is to allocate enough events, but what is 'enough' events?
  That depends on many factors. And allocating more events than is
  necessary wastes memory.
 
 Cases where events are lost are exception and IMO enough events
 would be almost always waste of memory.
 
  But what might be a better option is this: for each event a filehandle
  subscribes to there is only one internal v4l2_kevent allocated.
  
  This struct is either marked empty (no event was raised) or contains the
  latest state of this event. When the event is dequeued by the application
  the struct is marked empty again.
  
  So you never get duplicate events, instead, if a 'duplicate' event is
  raised it will just overwrite the 'old' event and move it to the end of
  the list of pending events. In other words, the old event is removed and
  the new event is inserted instead.
 
 That's an interesting proposal. Currently it will have impact at least
 on statistics collection OMAP3ISP driver. It brings to my mind 2
 points:
  - OMAP3ISP triggers one event for each statistic buffers produced. If
 we avoid events duplication, userapp will miss a statistic buffer.
 It's possible to bypass this problem, but the OMAP3 ISP statistics'
 private interface should be updated as well.
  - To define a standard for statistics collection is something we need
 to do to avoid new ISP's to always create custom interfaces.
 
  The nice thing about this is that for each subscribed event type you will
  never lose a raised event completely. You may lose intermediate events,
  but the latest event for that type will always be available.
 
 I may have a suggestion. If some event is affected by the number of
 times it was triggered (like the statistic ones mentioned above),
 instead of a bool empty flag, it may contain a counter. Then a
 duplicated event will be raised and will still inform how many
 intermediate events were lost. After event is dequeued once, the
 counter could be reset.

A counter would help mitigate events loss issues, when an application is not 
only interested in the last event state (like for HDMI hotplug for 
instance), but also on the intermediate events. This isn't a perfect solution 
though, applications can still make use of detailed event informations (such 
as timestamps, and event-specific data) even if they arrive late. It really 
depends on the event type.

-- 
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: Proposal to change the way pending events are handled

[Hans Verkuil]

On Tuesday, June 07, 2011 13:51:38 David Cohen wrote:
 Hi Hans,
 
 On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil hverk...@xs4all.nl wrote:
  While working on the control events I realized that the way we handle 
  pending
  events is rather complicated.
 
  What currently happens internally is that you have to allocate a fixed sized
  list of events. New events are queued on the 'available' list and when they
  are processed by the application they are queued on the 'free' list.
 
  If the 'free' list is empty, then no new events can be queued and you will
  drop events.
 
  Dropping events can be nasty and in the case of control events can cause a
  control panel to contain stale control values if it missed a value change
  event.
 
 I remember it was a topic I discussed with Sakari.
 
 
  One option is to allocate enough events, but what is 'enough' events? That
  depends on many factors. And allocating more events than is necessary wastes
  memory.
 
 Cases where events are lost are exception and IMO enough events
 would be almost always waste of memory.

The problem with exceptions is that they *do* happen and you need a way to
deal with them sensibly. One way of doing that is to ensure that for each
subscribed event you can get at least the latest raised event of that type.

 
  But what might be a better option is this: for each event a filehandle
  subscribes to there is only one internal v4l2_kevent allocated.
 
  This struct is either marked empty (no event was raised) or contains the
  latest state of this event. When the event is dequeued by the application
  the struct is marked empty again.
 
  So you never get duplicate events, instead, if a 'duplicate' event is raised
  it will just overwrite the 'old' event and move it to the end of the list of
  pending events. In other words, the old event is removed and the new event 
  is
  inserted instead.
 
 That's an interesting proposal. Currently it will have impact at least
 on statistics collection OMAP3ISP driver. It brings to my mind 2
 points:
  - OMAP3ISP triggers one event for each statistic buffers produced. If
 we avoid events duplication, userapp will miss a statistic buffer.
 It's possible to bypass this problem, but the OMAP3 ISP statistics'
 private interface should be updated as well.

Two thoughts: first of all given the current internal event architecture
there are no guarantees that the event can even be raised (e.g. if another
event flooded the system with events). Secondly, perhaps we should allocate
events per event type. So for the statistics collection event would might
want to reserve X events. And if the app doesn't read events fast enough,
then the oldest event would be lost.

BTW, isn't statistics associated with a frame? So if you read too slow,
then does it matter that you lose the older statistics?

  - To define a standard for statistics collection is something we need
 to do to avoid new ISP's to always create custom interfaces.
 
 
  The nice thing about this is that for each subscribed event type you will
  never lose a raised event completely. You may lose intermediate events, but
  the latest event for that type will always be available.
 
 I may have a suggestion. If some event is affected by the number of
 times it was triggered (like the statistic ones mentioned above),
 instead of a bool empty flag, it may contain a counter. Then a
 duplicated event will be raised and will still inform how many
 intermediate events were lost. After event is dequeued once, the
 counter could be reset.

I'm not sure what you mean. If you mean that we can report the number of
lost events in struct v4l2_event, then I agree with that.

Regards,

Hans

 
 Regards,
 
 David Cohen
 
 
  E.g. supposed you subscribed to a control containing the status of the HDMI
  hotplug. Connecting an HDMI cable can cause a bounce condition where the 
  HDMI
  hotplug toggles many times in quick succession. This could currently flood
  the event queue and you may lose the last event. With the proposed change 
  the
  last event will always arrive, although the intermediate events will be 
  lost.
 
  Comments?
 
  Regards,
 
 Hans
  --
  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: Proposal to change the way pending events are handled

[Sakari Ailus]

Laurent Pinchart wrote:
 Hi Hans and David,
 
 On Tuesday 07 June 2011 13:51:38 David Cohen wrote:
 On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 While working on the control events I realized that the way we handle
 pending events is rather complicated.

 What currently happens internally is that you have to allocate a fixed
 sized list of events. New events are queued on the 'available' list and
 when they are processed by the application they are queued on the 'free'
 list.

 If the 'free' list is empty, then no new events can be queued and you
 will drop events.

 Dropping events can be nasty and in the case of control events can cause
 a control panel to contain stale control values if it missed a value
 change event.

 I remember it was a topic I discussed with Sakari.

 One option is to allocate enough events, but what is 'enough' events?
 That depends on many factors. And allocating more events than is
 necessary wastes memory.

 Cases where events are lost are exception and IMO enough events
 would be almost always waste of memory.

 But what might be a better option is this: for each event a filehandle
 subscribes to there is only one internal v4l2_kevent allocated.

 This struct is either marked empty (no event was raised) or contains the
 latest state of this event. When the event is dequeued by the application
 the struct is marked empty again.

 So you never get duplicate events, instead, if a 'duplicate' event is
 raised it will just overwrite the 'old' event and move it to the end of
 the list of pending events. In other words, the old event is removed and
 the new event is inserted instead.

 That's an interesting proposal. Currently it will have impact at least
 on statistics collection OMAP3ISP driver. It brings to my mind 2
 points:
  - OMAP3ISP triggers one event for each statistic buffers produced. If
 we avoid events duplication, userapp will miss a statistic buffer.
 It's possible to bypass this problem, but the OMAP3 ISP statistics'
 private interface should be updated as well.
  - To define a standard for statistics collection is something we need
 to do to avoid new ISP's to always create custom interfaces.

 The nice thing about this is that for each subscribed event type you will
 never lose a raised event completely. You may lose intermediate events,
 but the latest event for that type will always be available.

 I may have a suggestion. If some event is affected by the number of
 times it was triggered (like the statistic ones mentioned above),
 instead of a bool empty flag, it may contain a counter. Then a
 duplicated event will be raised and will still inform how many
 intermediate events were lost. After event is dequeued once, the
 counter could be reset.
 
 A counter would help mitigate events loss issues, when an application is not 
 only interested in the last event state (like for HDMI hotplug for 
 instance), but also on the intermediate events. This isn't a perfect solution 
 though, applications can still make use of detailed event informations (such 
 as timestamps, and event-specific data) even if they arrive late. It really 
 depends on the event type.

I agree with Laurent.

When the interface was originally defined, the assumption was that any
kind of event loss would be a major nuisance and should ideally never
happen. It's a good question what is best when there's not enough room
for new events.

Definitely your proposal does have its advantages, but also causes loss
of information such as timestamps much more easily in cases such as the
OMAP 3 ISP driver where many events are generated per frame, usually one
per type.

On the other hand, the importance of timestamps generally decreases when
as they get older. I'm uncertain whether such a change would actually
break something, at least I can't say it wouldn't right now.

I wonder if it would be too complicated to pre-allocate n events per
event type, n being be a small natural number. This might be wasteful,
however.

Or allow at least one event per event type in the queue. Also this
option would have the property that not all events of a specific type
would be lost.

Or, limit the number of events of certain type in queue to m, where m  n.

Regards,

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
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: Proposal to change the way pending events are handled

[David Cohen]

Hi Hans, Laurent,

On Tue, Jun 7, 2011 at 3:20 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 On Tuesday, June 07, 2011 13:51:38 David Cohen wrote:
 Hi Hans,

 On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil hverk...@xs4all.nl wrote:
  While working on the control events I realized that the way we handle 
  pending
  events is rather complicated.
 
  What currently happens internally is that you have to allocate a fixed 
  sized
  list of events. New events are queued on the 'available' list and when they
  are processed by the application they are queued on the 'free' list.
 
  If the 'free' list is empty, then no new events can be queued and you will
  drop events.
 
  Dropping events can be nasty and in the case of control events can cause a
  control panel to contain stale control values if it missed a value change
  event.

 I remember it was a topic I discussed with Sakari.

 
  One option is to allocate enough events, but what is 'enough' events? That
  depends on many factors. And allocating more events than is necessary 
  wastes
  memory.

 Cases where events are lost are exception and IMO enough events
 would be almost always waste of memory.

 The problem with exceptions is that they *do* happen and you need a way to
 deal with them sensibly. One way of doing that is to ensure that for each
 subscribed event you can get at least the latest raised event of that type.

 
  But what might be a better option is this: for each event a filehandle
  subscribes to there is only one internal v4l2_kevent allocated.
 
  This struct is either marked empty (no event was raised) or contains the
  latest state of this event. When the event is dequeued by the application
  the struct is marked empty again.
 
  So you never get duplicate events, instead, if a 'duplicate' event is 
  raised
  it will just overwrite the 'old' event and move it to the end of the list 
  of
  pending events. In other words, the old event is removed and the new event 
  is
  inserted instead.

 That's an interesting proposal. Currently it will have impact at least
 on statistics collection OMAP3ISP driver. It brings to my mind 2
 points:
  - OMAP3ISP triggers one event for each statistic buffers produced. If
 we avoid events duplication, userapp will miss a statistic buffer.
 It's possible to bypass this problem, but the OMAP3 ISP statistics'
 private interface should be updated as well.

 Two thoughts: first of all given the current internal event architecture
 there are no guarantees that the event can even be raised (e.g. if another
 event flooded the system with events). Secondly, perhaps we should allocate
 events per event type. So for the statistics collection event would might
 want to reserve X events. And if the app doesn't read events fast enough,
 then the oldest event would be lost.

Yes, the oldest event will be lost, but the driver stores N buffers
where N  1. Currently statistics' drivers depend on event
duplication. But it's not a hard dependence. It's possible and easy
to change it.


 BTW, isn't statistics associated with a frame? So if you read too slow,
 then does it matter that you lose the older statistics?

They are related but dequeued independently in userspace.


  - To define a standard for statistics collection is something we need
 to do to avoid new ISP's to always create custom interfaces.

 
  The nice thing about this is that for each subscribed event type you will
  never lose a raised event completely. You may lose intermediate events, but
  the latest event for that type will always be available.

 I may have a suggestion. If some event is affected by the number of
 times it was triggered (like the statistic ones mentioned above),
 instead of a bool empty flag, it may contain a counter. Then a
 duplicated event will be raised and will still inform how many
 intermediate events were lost. After event is dequeued once, the
 counter could be reset.

 I'm not sure what you mean. If you mean that we can report the number of
 lost events in struct v4l2_event, then I agree with that.

Yes, I mean the number of lost events. But Laurent gave a good point.
So I can identify 3 different types regarding to event duplication:
1 - Event doesn't care about duplication.
2 - Event care about duplication but doesn't care about detailed information.
3 - Event care about duplication and detailed information.

For 1, to discard all older events is enough.
For 2, to discard older events but keep a counter is enough.
For 3, it can't be infinite because the driver will have a certain
limit to store old data associated to those events, so to define a max
number of queued events and discard any older one is enough.

All cases should be possible to handle without any loss of information.


 Regards,

        Hans


 Regards,

 David Cohen

 
  E.g. supposed you subscribed to a control containing the status of the HDMI
  hotplug. Connecting an HDMI cable can cause a bounce condition where the 
  HDMI
  hotplug toggles many times

Re: RFC: Proposal to change the way pending events are handled

[Hans Verkuil]

On Tuesday, June 07, 2011 14:30:38 Sakari Ailus wrote:
 Laurent Pinchart wrote:
  Hi Hans and David,
  
  On Tuesday 07 June 2011 13:51:38 David Cohen wrote:
  On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil hverk...@xs4all.nl wrote:
  While working on the control events I realized that the way we handle
  pending events is rather complicated.
 
  What currently happens internally is that you have to allocate a fixed
  sized list of events. New events are queued on the 'available' list and
  when they are processed by the application they are queued on the 'free'
  list.
 
  If the 'free' list is empty, then no new events can be queued and you
  will drop events.
 
  Dropping events can be nasty and in the case of control events can cause
  a control panel to contain stale control values if it missed a value
  change event.
 
  I remember it was a topic I discussed with Sakari.
 
  One option is to allocate enough events, but what is 'enough' events?
  That depends on many factors. And allocating more events than is
  necessary wastes memory.
 
  Cases where events are lost are exception and IMO enough events
  would be almost always waste of memory.
 
  But what might be a better option is this: for each event a filehandle
  subscribes to there is only one internal v4l2_kevent allocated.
 
  This struct is either marked empty (no event was raised) or contains the
  latest state of this event. When the event is dequeued by the application
  the struct is marked empty again.
 
  So you never get duplicate events, instead, if a 'duplicate' event is
  raised it will just overwrite the 'old' event and move it to the end of
  the list of pending events. In other words, the old event is removed and
  the new event is inserted instead.
 
  That's an interesting proposal. Currently it will have impact at least
  on statistics collection OMAP3ISP driver. It brings to my mind 2
  points:
   - OMAP3ISP triggers one event for each statistic buffers produced. If
  we avoid events duplication, userapp will miss a statistic buffer.
  It's possible to bypass this problem, but the OMAP3 ISP statistics'
  private interface should be updated as well.
   - To define a standard for statistics collection is something we need
  to do to avoid new ISP's to always create custom interfaces.
 
  The nice thing about this is that for each subscribed event type you will
  never lose a raised event completely. You may lose intermediate events,
  but the latest event for that type will always be available.
 
  I may have a suggestion. If some event is affected by the number of
  times it was triggered (like the statistic ones mentioned above),
  instead of a bool empty flag, it may contain a counter. Then a
  duplicated event will be raised and will still inform how many
  intermediate events were lost. After event is dequeued once, the
  counter could be reset.
  
  A counter would help mitigate events loss issues, when an application is 
  not 
  only interested in the last event state (like for HDMI hotplug for 
  instance), but also on the intermediate events. This isn't a perfect 
  solution 
  though, applications can still make use of detailed event informations 
  (such 
  as timestamps, and event-specific data) even if they arrive late. It 
  really 
  depends on the event type.
 
 I agree with Laurent.
 
 When the interface was originally defined, the assumption was that any
 kind of event loss would be a major nuisance and should ideally never
 happen. It's a good question what is best when there's not enough room
 for new events.
 
 Definitely your proposal does have its advantages, but also causes loss
 of information such as timestamps much more easily in cases such as the
 OMAP 3 ISP driver where many events are generated per frame, usually one
 per type.
 
 On the other hand, the importance of timestamps generally decreases when
 as they get older. I'm uncertain whether such a change would actually
 break something, at least I can't say it wouldn't right now.
 
 I wonder if it would be too complicated to pre-allocate n events per
 event type, n being be a small natural number. This might be wasteful,
 however.

I think this is actually the best approach. It is even possible to let the
application select 'N' when subscribing an event. This ensures that you never
completely miss an event: e.g. if X events of type T are raised, then you
will at least get min(N, X) events of that type.

It's much nicer that way since it gives you useful guarantees that you don't
have today. And the allocation can be done when subscribing events instead
of having to guess some global maximum for the total number of events.

The current approach is definitely problematic since there are no guarantees
whatsoever.

Regards,

Hans

 Or allow at least one event per event type in the queue. Also this
 option would have the property that not all events of a specific type
 would be lost.
 
 Or, limit the number of events of certain type

Re: RFC: Proposal to change the way pending events are handled

[David Cohen]

On Tue, Jun 7, 2011 at 3:46 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 On Tuesday, June 07, 2011 14:30:38 Sakari Ailus wrote:
 Laurent Pinchart wrote:
  Hi Hans and David,
 
  On Tuesday 07 June 2011 13:51:38 David Cohen wrote:
  On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil hverk...@xs4all.nl wrote:
  While working on the control events I realized that the way we handle
  pending events is rather complicated.
 
  What currently happens internally is that you have to allocate a fixed
  sized list of events. New events are queued on the 'available' list and
  when they are processed by the application they are queued on the 'free'
  list.
 
  If the 'free' list is empty, then no new events can be queued and you
  will drop events.
 
  Dropping events can be nasty and in the case of control events can cause
  a control panel to contain stale control values if it missed a value
  change event.
 
  I remember it was a topic I discussed with Sakari.
 
  One option is to allocate enough events, but what is 'enough' events?
  That depends on many factors. And allocating more events than is
  necessary wastes memory.
 
  Cases where events are lost are exception and IMO enough events
  would be almost always waste of memory.
 
  But what might be a better option is this: for each event a filehandle
  subscribes to there is only one internal v4l2_kevent allocated.
 
  This struct is either marked empty (no event was raised) or contains the
  latest state of this event. When the event is dequeued by the application
  the struct is marked empty again.
 
  So you never get duplicate events, instead, if a 'duplicate' event is
  raised it will just overwrite the 'old' event and move it to the end of
  the list of pending events. In other words, the old event is removed and
  the new event is inserted instead.
 
  That's an interesting proposal. Currently it will have impact at least
  on statistics collection OMAP3ISP driver. It brings to my mind 2
  points:
   - OMAP3ISP triggers one event for each statistic buffers produced. If
  we avoid events duplication, userapp will miss a statistic buffer.
  It's possible to bypass this problem, but the OMAP3 ISP statistics'
  private interface should be updated as well.
   - To define a standard for statistics collection is something we need
  to do to avoid new ISP's to always create custom interfaces.
 
  The nice thing about this is that for each subscribed event type you will
  never lose a raised event completely. You may lose intermediate events,
  but the latest event for that type will always be available.
 
  I may have a suggestion. If some event is affected by the number of
  times it was triggered (like the statistic ones mentioned above),
  instead of a bool empty flag, it may contain a counter. Then a
  duplicated event will be raised and will still inform how many
  intermediate events were lost. After event is dequeued once, the
  counter could be reset.
 
  A counter would help mitigate events loss issues, when an application is 
  not
  only interested in the last event state (like for HDMI hotplug for
  instance), but also on the intermediate events. This isn't a perfect 
  solution
  though, applications can still make use of detailed event informations 
  (such
  as timestamps, and event-specific data) even if they arrive late. It 
  really
  depends on the event type.

 I agree with Laurent.

 When the interface was originally defined, the assumption was that any
 kind of event loss would be a major nuisance and should ideally never
 happen. It's a good question what is best when there's not enough room
 for new events.

 Definitely your proposal does have its advantages, but also causes loss
 of information such as timestamps much more easily in cases such as the
 OMAP 3 ISP driver where many events are generated per frame, usually one
 per type.

 On the other hand, the importance of timestamps generally decreases when
 as they get older. I'm uncertain whether such a change would actually
 break something, at least I can't say it wouldn't right now.

 I wonder if it would be too complicated to pre-allocate n events per
 event type, n being be a small natural number. This might be wasteful,
 however.

 I think this is actually the best approach. It is even possible to let the
 application select 'N' when subscribing an event. This ensures that you never
 completely miss an event: e.g. if X events of type T are raised, then you
 will at least get min(N, X) events of that type.

 It's much nicer that way since it gives you useful guarantees that you don't
 have today. And the allocation can be done when subscribing events instead
 of having to guess some global maximum for the total number of events.

I agree with this proposal. I won't affect OMAP3ISP statistic drivers either.

Br,

David


 The current approach is definitely problematic since there are no guarantees
 whatsoever.

 Regards,

        Hans

 Or allow at least one event per event type

Re: [RFC] HDMI-CEC proposal, ver 2

[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 

Preliminary proposal, new APIs for HDMI and DVI control in v4l2

[Martin Bugge (marbugge)]

This is a preliminary proposal for an extension to the v4l2 api.
To be discussed at the  V4L2 'brainstorming' meeting in Warsaw, March 2011


Purpose: Provide basic controls for HDMI and DVI devices.

sink  : HDMI/DVI/VGA receiver
source: HDMI/DVI/VGA transmitter


New Controls:
=

These controls rely on control events to be able to notify the
application of any change.

The idea is to create an event that will be triggered by the control
framework whenever a control changes value.


TX source:
--

Control: V4L2_CID_DV_TX_HOTPLUG
type: bitmask (output), read only
name: Hotplug
Hotplug is present on each output.

The hotplug is issued by the sink to indicate that an
edid exists and should be read by the source.
Not applicable for VGA connectors.


Control: V4L2_CID_DV_TX_RXSENSE
type: bitmask (output), read only
name: Rx Sense
Rx sense is present on each output.

Rx Sense is detection of pull-ups on the TMDS clock lines.
Normally means that the sink has left/entered standby.
Not applicable for VGA connectors.


Control: V4L2_CID_DV_TX_EDID_SEGMENT0_PRESENT
type: bitmask (output), read only
name: Edid segment 0

The source driver has read edid segment 0 from the sink.

Control: V4L2_CID_DV_TX_DVI_HDMI_MODE
type: menu, read and write
name: Hdmi/Dvi mode

Settings:
HDMI
DVI-D

RX sink:


Control: V4L2_CID_DV_RX_5V
type: bitmask (input), read only
name: Rx 5V

The source must supply the sink with a +5v via the HDMI/DVI cable.
This is often used to power an eeprom which contains edid information,
such that the source can read the edid even if the sink
is in standby/power off.


Control: V4L2_CID_DV_CABLE_DETECT
type: bitmask (input), read only
name: Cable detect

This is not a part of the HDMI/DVI standards.
But many sinks (read monitors) uses a + 5v pull-up on a
ground pin (typically pin 15 on dvi) to detect if a cable is
is connected and terminated at the source end.


Control: V4L2_CID_DV_FORMAT_STATUS
type: menu, read only
name: Format status

Format status for the current selected input.
Statuses:
No signal
Unknown
Unsupported
Encrypted
Valid/supported

The input signal has changed format or status.
In the case of a valid signal use the
vidioc_query_dv_preset to read the new format.

Alternatively this could also be implemented as a bitmask with bits
for: 'signal present', 'encrypted', 'supported format'.

Or as three separate boolean controls.


New Events:
===

V4L2_EVENT_TX_EDID
   struct v4l2_event_tx_edid {
  __u32 output;
  __u32 present;
  __u32 segment;
   }

The source driver has read an edid segment from the sink.
One segment is 256 bytes and will contain one or two 128
bytes blocks. Most HDMI and DVI sinks will have only segment 0.

The driver should read segment 0 when hotplug is detected and
report this to userspace. The application can then use the
V4L2_G_EDID ioctl to get the actual edid data.

If the EDID data indicates the presence of further extension blocks the
userspace application can use the V4L2_REQ_EDID ioctl to trigger a read.
When the driver has read that extended segment it will generate a
V4L2_EVENT_TX_EDID event.


New Ioctls:
===

TX source:
--

V4L2_REQ_EDID
   struct v4l2_req_edid {
  __u32 output;
  __u32 segment;
}
Trigger a read of a 256 bytes segment. Normally the driver will
read segment 0 by itself when hotplug is detected, But this ioctl
may also be used to trigger a re-read of segment 0.


V4L2_G_EDID
   struct v4l2_g_edid {
  __u32 output;
  __u32 segment;
  __u8 edid[256];
}
Get the edid segment indicated in the V4L2_EVENT_TX_EDID


RX sink:


V4L2_S_EDID
   struct v4l2_s_edid {
  __u32 input;
  __u32 segment;
  __u8 _edid[256];
}
Set the edid information in the source.


Additional Controls and Status:
===

Controls and statuses we want to add.
Currently based on HDMI version 1.3a, must be updated

From Info frames

*  Y0, Y1   RGB or YCBCR indicator.
* A0Active Information Present. Indicates whether field 
R0...R3 is valid. See

CEA-861-D table 8 for details.
* B0, B1Bar Info data valid. See CEA-861-D table 8 for details.
  HDMI Licensing, LLC Page 113 of 156
  High-Definition Multimedia Interface 
Specification Version 1.3a
* S0, S1Scan Information (i.e. overscan, underscan). See 
CEA-861-D table 8 for

details.
* C0, C1Colorimetry (ITU BT.601, BT.709 etc.). See CEA-861-D 
table 9 for

details.
* EC0, EC1, EC2 Extended Colorimetry (IEC 61966-2-4 etc.). See

[RFC] HDMI-CEC proposal, ver 2

[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 marbu...@cisco.com
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

Re: [RFC] HDMI-CEC proposal, ver 2

[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

Re: [RFC] HDMI-CEC proposal

[Laurent Pinchart]

Hi Martin,

On Tuesday 01 March 2011 10:59:07 Martin Bugge (marbugge) wrote:
 Author: Martin Bugge marbu...@cisco.com
 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

[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 Buggemarbu...@cisco.com
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