Re: Proposal for a v4l2_ctrl_new_std_compound() function
Hi Hans, I love your patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [cannot apply to v5.3-rc8 next-20190904] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Hans-Verkuil/Proposal-for-a-v4l2_ctrl_new_std_compound-function/20190913-222917 base: git://linuxtv.org/media_tree.git master reproduce: make htmldocs If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme. WARNING: dot(1) not found, for better output quality install graphviz from http://www.graphviz.org WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/w1.h:272: warning: Function parameter or member 'of_match_table' not described in 'w1_family' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'quotactl' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'quota_on' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_free_mnt_opts' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_eat_lsm_opts' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_kern_mount' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_show_options' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_add_mnt_opt' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'd_instantiate' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'getprocattr' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'setprocattr' not described in 'security_list_options' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:142: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_read_lock' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:347: warning: cannot understand function prototype: 'struct amdgpu_vm_pt_cursor ' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:348: warning: cannot understand function prototype: 'struct amdgpu_vm_pt_cursor ' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:494: warning: Function parameter or member 'start' not described in 'amdgpu_vm_pt_first_dfs' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'adev' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'vm' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'start' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'cursor' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'entry' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:823: warning: Function parameter or member 'level' not described in 'amdgpu_vm_bo_param' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'params' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'bo' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'level' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'pe' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'addr' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: w
Proposal for a v4l2_ctrl_new_std_compound() function
Hi Ricardo,
As per our irc discussion, here is a proposal how I think it can be done.
The core problem is that for compound types we want to provide a default
value that can be used in std_init_compound() without having to provide
our own type ops. The new v4l2_ctrl_new_std_compound would pass a const
pointer to the struct with the default value, and std_init_compound
should use that if p_def != NULL.
I think this is beneficial for the various codec compound types as well.
Implementing this in v4l2-ctrls.c is left as an exercise for the reader
(i.e., you!).
Regards,
Hans
Signed-off-by: Hans Verkuil
---
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 570ff4b0205a..7fdbf3abe49b 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -254,6 +254,7 @@ struct v4l2_ctrl {
s32 val;
} cur;
+ const union v4l2_ctrl_ptr p_def;
union v4l2_ctrl_ptr p_new;
union v4l2_ctrl_ptr p_cur;
};
@@ -667,6 +668,27 @@ struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct
v4l2_ctrl_handler *hdl,
u32 id, u8 max, u8 def,
const s64 *qmenu_int);
+/**
+ * v4l2_ctrl_new_std_compound() - Allocate and initialize a new standard V4L2
+ * compound control.
+ *
+ * @hdl: The control handler.
+ * @ops: The control ops.
+ * @id:The control ID.
+ * @min: The control's minimum value.
+ * @max: The control's maximum value.
+ * @step: The control's step value
+ * @p_def: The control's default value.
+ *
+ * If the &v4l2_ctrl struct could not be allocated, or the control
+ * ID is not known, then NULL is returned and @hdl->error is set to the
+ * appropriate error code (if it wasn't set already).
+ */
+struct v4l2_ctrl *v4l2_ctrl_new_std_compound(struct v4l2_ctrl_handler *hdl,
+const struct v4l2_ctrl_ops *ops,
+u32 id, s64 min, s64 max, u64 step,
+const union v4l2_ctrl_ptr p_def);
+
/**
* typedef v4l2_ctrl_filter - Typedef to define the filter function to be
* used when adding a control handler.
Business Proposal
-- Dear Sir/Madam, I am Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong Hing Bank, Hong Kong, I have a Business Proposal of USD$$38,980,369.00 (Thirty Eight Million, Nine Hundred and Eighty Thousand, Three Hundred and Sixty Nine USD) for you to transact with me Contact me via my email address if interested: cs7017...@gmail.com Yours Sincerely, Alfred Chow
MY $25,000,000.00 INVESTMENT PROPOSAL WITH YOU AND IN YOUR COUNTRY.
-- Dear, With due respect this is not spam or Scam mail, because I have contacted you before and there was no response from you,I apologise if the contents of this mail are contrary to your moral ethics, which I feel may be of great disturbance to your person, but please treat this with absolute confidentiality, believing that this email reaches you in good faith. My contacting you is not a mistake or a coincidence because God can use any person known or unknown to accomplish great things. I am a lawyer and I have an investment business proposal to offer you. It is not official but should be considered as legal and confidential business. I have a customer's deposit of $US25 million dollars ready to be moved for investment if you can partner with us. We are ready to offer you 10% of this total amount as your compensation for supporting the transaction to completion. If you are interested to help me please reply me with your full details as stated below: (1) Your full names: (2) Your address: (3) Your occupation: (4) Your mobile telephone number: (5) Your nationality: (6) Your present location: (7) Your age: So that I will provide you more details on what to do and what is required for successful completion. Note: DO NOT REPLY ME IF YOU ARE NOT INTERESTED AND WITHOUT THE ABOVE MENTIONED DETAILS Sincèrement vôtre, Avocat Etienne Eku Esq.(Lawfirm) Procureur principal. De Cabinet d’avocats de l’Afrique de l’ouest. Skype:westafricalawfirm
Proposal
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
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
-- 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
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
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
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
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
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
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)
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
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 >> wal
Re: [media] vimc: API proposal, configuring the topology from user space
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 &
Re: [media] vimc: API proposal, configuring the topology from user space
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 automati
[media] vimc: API proposal, configuring the topology from user space
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
Re: [RFC PATCH v2 0/2] [media] tvp515p: Proposal for MC input connector support
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
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
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
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
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
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
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: [alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal
Added Hans, who's working a lot on the HDMI transmitter drivers (including audio support) as well as the media list to Cc. On 10/07/2015 10:19 AM, Arnaud Pouliquen wrote: > > >>> My approach is the reverse: DRM driver does not need to know anything >>> about audio side. As ALSA is the client of DRM, seems more logical from >>> my point of view ... >>> Now if a generic solution must be found for all video drivers, sure, >>> your solution is more flexible. >>> But if i well understood fbdev drivers are no more accepted for upstream >>> (please correct me if I'm wrong). >>> So i don't know we have to keep fbdev in picture... >>> >> >> I am not promoting fbdev support. I am merely asking if we want to force >> all HDMI drivers to implement a drm_bridge if they want to support audio. >> > Yes this is a good point... My implementation is based on hypothesis that > HDMI drivers are now upstreamed as DRM drivers. The other place where you can find HDMI support is in V4L2, both receive as well as transmit. And while the hope for fbdev is that it will be phased out V4L2 will stay around for a while. And we probably want to have a common API that can take care of both DRM and V4L so we do not need two sets of helper functions for things like EDID parsing etc. - Lars -- 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
Hi On Thu, Aug 20, 2015 at 8:41 PM, Laurent Pinchart 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
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
Em Thu, 20 Aug 2015 02:33:15 +0300 Laurent Pinchart 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_ > >> 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
Re: VIMC: API proposal, configuring the topology through user space
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_ >> 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
loy 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. > > >>>> > > &g
Re: VIMC: API proposal, configuring the topology through user space
mc/vimc1/build_topology # here the topology > >> of vimc1 will be deployed > >> $ rmdir /configfs/vimc/vimc1/ent_debayer # here the topology will be > >> undeployed, or this command will fail if vimc1 is in use > >> $ echo "foo" > /configfs/vimc/vimc1/build_topology # here the topology > >> of the instance vimc1 will be deployed again without the ent_debayer > >> entity (assuming the previous command worked) > >> > >> Unless it is interesting to easy simulate a disconnect (undeploy) and > >> reconnect with the same topology (deploy) without the need to erase > >> the /configfs/vimc/vimc0 and re-construct it again, is this > >> interesting? > >> > >> If it is interesting, then an explicit command to undeploy will indeed > >> be better, otherwise we can always erase and reconstruct the folders > >> tree outside the kernel with a script. > > > > Undeploying has the advantage to make the API symmetrical, it would at > > least feel cleaner. > > I think we might need different levels of 'undeploying': undeploy the whole > graph and undeploying single entities (which is what will happen with > dynamic reconfiguration). > > And only those parts in configfs that are undeployed can be removed. > > Parts that are deployed cannot be changed with the exception of adding links > to as yet undeployed entities, but those links won't be deployed until the > undeployed entities are explicitly deployed. 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. > >>>> 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. > >> > >> This is simpler to implement, and it seems secure, I could do like > >> this in the first version and we see later how to improve it. > >> > >>>> 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. > >> > >> 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/vim
Re: VIMC: API proposal, configuring the topology through user space
metrical, it would at least > feel cleaner. I think we might need different levels of 'undeploying': undeploy the whole graph and undeploying single entities (which is what will happen with dynamic reconfiguration). And only those parts in configfs that are undeployed can be removed. Parts that are deployed cannot be changed with the exception of adding links to as yet undeployed entities, but those links won't be deployed until the undeployed entities are explicitly deployed. > >>>> 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. >> >> This is simpler to implement, and it seems secure, I could do like >> this in the first version and we see later how to improve it. >> >>>> 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. >> >> 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 on
Re: VIMC: API proposal, configuring the topology through user space
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 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 > > 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 yo
Re: VIMC: API proposal, configuring the topology through user space
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
Re: VIMC: API proposal, configuring the topology through user space
Hello, thank you for your feedback On Tue, Aug 11, 2015 at 6:36 AM, Mauro Carvalho Chehab wrote: > Em Tue, 11 Aug 2015 11:28:25 +0200 > Hans Verkuil 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 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 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 filehandler
Re: VIMC: API proposal, configuring the topology through user space
Em Tue, 11 Aug 2015 12:34:46 +0200 Hans Verkuil escreveu: > On 08/11/15 11:36, Mauro Carvalho Chehab wrote: > > Em Tue, 11 Aug 2015 11:28:25 +0200 > > Hans Verkuil 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 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 > > 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
Re: VIMC: API proposal, configuring the topology through user space
On 08/11/15 11:36, Mauro Carvalho Chehab wrote: > Em Tue, 11 Aug 2015 11:28:25 +0200 > Hans Verkuil 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 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 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
Em Tue, 11 Aug 2015 11:28:25 +0200 Hans Verkuil 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 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 > > 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
Re: VIMC: API proposal, configuring the topology through user space
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 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/
Re: VIMC: API proposal, configuring the topology through user space
Hi, thanks for your reviews On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil 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
Re: VIMC: API proposal, configuring the topology through user space
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 r
Re: VIMC: API proposal, configuring the topology through user space
Em Fri, 07 Aug 2015 22:55:28 -0300 Helen Fornazier 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
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
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
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
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
Proposal
Good day. I am Mark Reyes Guus, I work with Abn Amro Bank as an auditor. I have a proposition to discuss with you. Should you be interested, please e-mail back to me. Private Email: markreyesg...@abnmrob.co.uk OR markguus.reye...@yahoo.nl Yours Sincerely, Mark Reyes Guus. -- 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!
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
-- 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
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.......
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
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
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
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
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
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
Re: AverTV_A918R (af9035-af9033-tda18218) / patch proposal
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
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: AverTV_A918R (af9035-af9033-tda18218) / patch proposal
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
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
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 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
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 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
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
AverTV_A918R (af9035-af9033-tda18218) / patch proposal
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: Proposal for the addition of a binary V4L2 control type
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.
> >
RE: Proposal for the addition of a binary V4L2 control type
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.
> >
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.
> 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
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: Proposal for the addition of a binary V4L2 control type
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
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
Proposal for the addition of a binary V4L2 control type
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: Preliminary proposal, new APIs for HDMI and DVI control in v4l2
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 (marbugge 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
Hi Soby On 05/27/2012 07:30 PM, Soby Mathew wrote: Martin Bugge (marbugge 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
Martin Bugge (marbugge 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
Re: [RFC PATCH 0/2] Proposal to deprecate four drivers
On Mon May 14 2012 21:11:57 Hans Verkuil wrote: > 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. I'm shelving this RFC for the time being. I suddenly have leads on all three parallel port webcams so with a bit of luck I might have actual hardware to test these drivers in a few weeks time. It's still not useful to anyone of course, but as long as I can test ancient hardware I'm happy :-) 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 0/2] Proposal to deprecate four drivers
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
On Thu 10 May 2012 13:43:16 Florian Fainelli wrote: > Hello Murali, > > On Thursday 10 May 2012 12:40:05 muralidhar dixit wrote: > > Hello Florian, > > > > I do have similar implementation for my CEC driver. > > And I prefer most of the CEC messaged to be handled in the user space and > > have the kernel driver bare minimum with interfaces to > > 1) REGISTER CEC device( I have support for multiple logical devices) > > 2) SEND CEC MESSAGE > > 3) RECV CEC MESSAGE > > > > But one issue with this was the response time to the TV remote actions. > > Well, I think this is specific to your platform, because I don't have any > such > issue here with my implementation. The specification says that the desired > response time is of 200 ms and the maximum 1s, even with multiple context > switches you should be able to achieve that. Not knowing exactly how your > hardware works, maybe there is a bottleneck somewhere. > > > Initially I was sending the UI control messages also to user space but > > response time was too bad. Hence I wrote a CEC Keyboard driver which will > > process the CEC UI control messages. From the CEC driver if I recv any CEC > > UI control messages I will route it to CEC Keyboard driver in the kernel > > and all other messages have to be handled by user space application. > > This is the kind of thing that I want to avoid, on my platform, all the input > is processed in user-land and exposed as a HID device (thus self-describing), > forwarding CEC UI key codes to the kernel does not seem like a good solution > to me because it means we have to know about the CEC protocol itself. > > I fear that if we start doing this with the CEC UI codes, we end-up doing the > same for the system-related messages (Power, standby etc ...) and this is > also > to be avoided. We are also doing parsing in userspace. The CEC API just gets the hardware up and running so that we can send and receive CEC packets, but the kernel doesn't parse. The only exception to that *might* be the remote control part of the CEC specification (that's where button presses of a remote control are passed over CEC). It might make sense to pass them on to the V4L2 framework for remote controls. Then again, it might not. Or only if you set a flag or something. My personal view (but not everyone agreed at the time) is that we just need a simple API to send/receive CEC packets and do everything else in userspace. It would be nice if we have a standard library for that that everyone can use, though. Regards, Hans > > > > > Best Regards, > > Murali > > From: Florian Fainelli gmail.com> > > Subject: Re: [RFC] HDMI-CEC > > proposal<http://news.gmane.org/find- > root.php?message_id=%3c4F87F195.5080504%40gmail.com%3e> > > Newsgroups: gmane.linux.drivers.video-input- > infrastructure<http://news.gmane.org/gmane.linux.drivers.video-input- > infrastructure> > > Date: 2012-04-13 09:27:49 GMT (3 weeks, 5 days, 21 hours and 33 minutes ago) > > > > Hi Hans, > > > > Le 04/13/12 07:03, Hans Verkuil a écrit : > > > You both hit the main problem of the *CEC* support: how to implement the > API. > > > > Well, the API that I propose here [1] is quite simple: > > > > - a kernel-side API for defining *CEC* adapters drivers > > - a character device with an ioctl() control path and read/write/poll > > data-path > > > > [1]: https://github.com/ffainelli/linux-*hdmi*-*cec* > > <https://github.com/ffainelli/linux-hdmi-cec> > > > > > > > > Cisco's work on *CEC* has been stalled as we first want to get *HDMI* > support in > > > V4L. Hopefully that will happen in the next few months. After that we will > > > resume working on the *CEC* API. > > > > Well, I don't think that tighting *HDMI* into V4L is such a good idea > > either. *HDMI* is also a separate bus and deserves its own subsystem and > > even subsystems (audio, video, HDCP, *CEC*). For instance, the STB I am > > working with does not use the V4L API at all, however, I would like to > > be able to integrate within the Linux *HDMI* stack once there, think about > > nvidia's driver too. > > > > I can understand that you want to hold on your efforts on *CEC* while you > > want to get *HDMI* in, but don't make it entirely driven by Cisco and > > accept the community feedback. > > > > > > > > Regards, > > > > > > Hans > > > > > > On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: > > >> Since a lot of video cards dont' support
Re: [RFC] HDMI-CEC proposal
Hello Murali, On Thursday 10 May 2012 12:40:05 muralidhar dixit wrote: > Hello Florian, > > I do have similar implementation for my CEC driver. > And I prefer most of the CEC messaged to be handled in the user space and > have the kernel driver bare minimum with interfaces to > 1) REGISTER CEC device( I have support for multiple logical devices) > 2) SEND CEC MESSAGE > 3) RECV CEC MESSAGE > > But one issue with this was the response time to the TV remote actions. Well, I think this is specific to your platform, because I don't have any such issue here with my implementation. The specification says that the desired response time is of 200 ms and the maximum 1s, even with multiple context switches you should be able to achieve that. Not knowing exactly how your hardware works, maybe there is a bottleneck somewhere. > Initially I was sending the UI control messages also to user space but > response time was too bad. Hence I wrote a CEC Keyboard driver which will > process the CEC UI control messages. From the CEC driver if I recv any CEC > UI control messages I will route it to CEC Keyboard driver in the kernel > and all other messages have to be handled by user space application. This is the kind of thing that I want to avoid, on my platform, all the input is processed in user-land and exposed as a HID device (thus self-describing), forwarding CEC UI key codes to the kernel does not seem like a good solution to me because it means we have to know about the CEC protocol itself. I fear that if we start doing this with the CEC UI codes, we end-up doing the same for the system-related messages (Power, standby etc ...) and this is also to be avoided. > > Best Regards, > Murali > From: Florian Fainelli gmail.com> > Subject: Re: [RFC] HDMI-CEC > proposal<http://news.gmane.org/find- root.php?message_id=%3c4F87F195.5080504%40gmail.com%3e> > Newsgroups: gmane.linux.drivers.video-input- infrastructure<http://news.gmane.org/gmane.linux.drivers.video-input- infrastructure> > Date: 2012-04-13 09:27:49 GMT (3 weeks, 5 days, 21 hours and 33 minutes ago) > > Hi Hans, > > Le 04/13/12 07:03, Hans Verkuil a écrit : > > You both hit the main problem of the *CEC* support: how to implement the API. > > Well, the API that I propose here [1] is quite simple: > > - a kernel-side API for defining *CEC* adapters drivers > - a character device with an ioctl() control path and read/write/poll > data-path > > [1]: https://github.com/ffainelli/linux-*hdmi*-*cec* > <https://github.com/ffainelli/linux-hdmi-cec> > > > > > Cisco's work on *CEC* has been stalled as we first want to get *HDMI* support in > > V4L. Hopefully that will happen in the next few months. After that we will > > resume working on the *CEC* API. > > Well, I don't think that tighting *HDMI* into V4L is such a good idea > either. *HDMI* is also a separate bus and deserves its own subsystem and > even subsystems (audio, video, HDCP, *CEC*). For instance, the STB I am > working with does not use the V4L API at all, however, I would like to > be able to integrate within the Linux *HDMI* stack once there, think about > nvidia's driver too. > > I can understand that you want to hold on your efforts on *CEC* while you > want to get *HDMI* in, but don't make it entirely driven by Cisco and > accept the community feedback. > > > > > Regards, > > > > Hans > > > > On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: > >> Since a lot of video cards dont' support *CEC* at all (not even > >> connected), don't have *hdmi*, but work perfectly fine with dvi->*hdmi* > >> adapters, *CEC* can be implemented in many other ways (think media centers) > >> > >> One such exammple is using USB/Arduino > >> > >> http://code.google.com/p/*cec*-arduino/wiki/ElectricalInterface <http://code.google.com/p/cec-arduino/wiki/ElectricalInterface> > >> > >> Having an AVR with v-usb code and *cec* code doesn't look all that hard > >> nor impossible, so one could simply have a USB plug on one end, and an > >> *HDMI* plug on the other end, utilizing only the *CEC* pins. > >> > >> This would make it more something like LIRC if anything. > >> > >> On 04/12/12 17:24, Florian Fainelli wrote: > >>> Hi Hans, Martin, > >>> > >>> Sorry to jump in so late in the *HDMI*-*CEC* discussion, here are some > >>> comments from my perspective on your *proposal*: > >>> > >>> - the *HDMI*-*CEC* implementation deserves its own bus and class of devices > >>> because by definition it is a physical
Re: [RFC] HDMI-CEC proposal
Yes, the library to talk to the device is opensource, the hardware, not so much. :) On 17-04-12 15:31, Anssi Hannula wrote: 12.04.2012 23:36, Oliver Schinagl kirjoitti: Since a lot of video cards dont' support CEC at all (not even connected), don't have hdmi, but work perfectly fine with dvi->hdmi adapters, CEC can be implemented in many other ways (think media centers) One such exammple is using USB/Arduino http://code.google.com/p/cec-arduino/wiki/ElectricalInterface Having an AVR with v-usb code and cec code doesn't look all that hard nor impossible, so one could simply have a USB plug on one end, and an HDMI plug on the other end, utilizing only the CEC pins. This would make it more something like LIRC if anything. There already exists a device like this (USB CEC adapter with hdmi in/out) with open source userspace driver, developed for the XBMC Media Center (apparently MythTV is also supported): http://www.pulse-eight.com/store/products/104-usb-hdmi-cec-adapter.aspx http://libcec.pulse-eight.com/ https://github.com/Pulse-Eight/libcec -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
12.04.2012 23:36, Oliver Schinagl kirjoitti: > Since a lot of video cards dont' support CEC at all (not even > connected), don't have hdmi, but work perfectly fine with dvi->hdmi > adapters, CEC can be implemented in many other ways (think media centers) > > One such exammple is using USB/Arduino > > http://code.google.com/p/cec-arduino/wiki/ElectricalInterface > > Having an AVR with v-usb code and cec code doesn't look all that hard > nor impossible, so one could simply have a USB plug on one end, and an > HDMI plug on the other end, utilizing only the CEC pins. > > This would make it more something like LIRC if anything. There already exists a device like this (USB CEC adapter with hdmi in/out) with open source userspace driver, developed for the XBMC Media Center (apparently MythTV is also supported): http://www.pulse-eight.com/store/products/104-usb-hdmi-cec-adapter.aspx http://libcec.pulse-eight.com/ https://github.com/Pulse-Eight/libcec -- Anssi Hannula -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
Hi Hans, Le 04/13/12 07:03, Hans Verkuil a écrit : You both hit the main problem of the CEC support: how to implement the API. Well, the API that I propose here [1] is quite simple: - a kernel-side API for defining CEC adapters drivers - a character device with an ioctl() control path and read/write/poll data-path [1]: https://github.com/ffainelli/linux-hdmi-cec Cisco's work on CEC has been stalled as we first want to get HDMI support in V4L. Hopefully that will happen in the next few months. After that we will resume working on the CEC API. Well, I don't think that tighting HDMI into V4L is such a good idea either. HDMI is also a separate bus and deserves its own subsystem and even subsystems (audio, video, HDCP, CEC). For instance, the STB I am working with does not use the V4L API at all, however, I would like to be able to integrate within the Linux HDMI stack once there, think about nvidia's driver too. I can understand that you want to hold on your efforts on CEC while you want to get HDMI in, but don't make it entirely driven by Cisco and accept the community feedback. Regards, Hans On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: Since a lot of video cards dont' support CEC at all (not even connected), don't have hdmi, but work perfectly fine with dvi->hdmi adapters, CEC can be implemented in many other ways (think media centers) One such exammple is using USB/Arduino http://code.google.com/p/cec-arduino/wiki/ElectricalInterface Having an AVR with v-usb code and cec code doesn't look all that hard nor impossible, so one could simply have a USB plug on one end, and an HDMI plug on the other end, utilizing only the CEC pins. This would make it more something like LIRC if anything. On 04/12/12 17:24, Florian Fainelli wrote: Hi Hans, Martin, Sorry to jump in so late in the HDMI-CEC discussion, here are some comments from my perspective on your proposal: - the HDMI-CEC implementation deserves its own bus and class of devices because by definition it is a physical bus, which is even electrically independant from the rest of the HDMI bus (A/V path) - I don't think it is a good idea to tight it so closely to v4l, because one can perfectly have CEC-capable hardware without video, or at least not use v4l and have HDMI-CEC hardware - it was suggested to use sockets at some point, I think it is over-engineered and should only lead - processing messages in user-space is definitively the way to go, even input can be either re-injected using an uinput driver, or be handled in user-space entirely, eventually we might want to install "filters" based on opcodes to divert some opcodes to a kernel consumer, and the others to an user-space one Right now, I have a very simple implementation that I developed for the company I work for which can be found here: https://github.com/ffainelli/linux-hdmi-cec It is designed like this: 1) A core module, which registers a cec bus, and provides an abstraction for a CEC adapter (both device& driver): - basic CEC adapter operations: logical address setting, queueing management - counters, rx filtering - host attaching/detaching in case the hardware is capable of self-processing CEC messages (for wakeup in particular) 2) A character device module, which exposes a character device per CEC adapter and only allows one consumer at a time and exposes the following ioctl's: - SET_LOGICAL_ADDRESS - RESET_DEVICE - GET_COUNTERS - SET_RX_MODE (my adapter can be set in a promiscuous mode) the character device supports read/write/poll, which are the prefered ways for transfering/receiving data 3) A CEC adapter implementation which registers and calls into the core module when receiving a CEC message, and which the core module calls in response to the IOCTLs described below. At first I thought about defining a generic netlink family in order to allow multiple user-space listeners receive CEC messages, but in the end having only one consumer per adapter device is fine by me and a more traditionnal approach for programmers. I am relying on external components for knowing my HDMI physical address. Hope this is not too late to (re)start the discussion on HDMI-CEC. Thank you very much. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
You both hit the main problem of the CEC support: how to implement the API. Cisco's work on CEC has been stalled as we first want to get HDMI support in V4L. Hopefully that will happen in the next few months. After that we will resume working on the CEC API. Regards, Hans On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote: > Since a lot of video cards dont' support CEC at all (not even > connected), don't have hdmi, but work perfectly fine with dvi->hdmi > adapters, CEC can be implemented in many other ways (think media centers) > > One such exammple is using USB/Arduino > > http://code.google.com/p/cec-arduino/wiki/ElectricalInterface > > Having an AVR with v-usb code and cec code doesn't look all that hard > nor impossible, so one could simply have a USB plug on one end, and an > HDMI plug on the other end, utilizing only the CEC pins. > > This would make it more something like LIRC if anything. > > On 04/12/12 17:24, Florian Fainelli wrote: > > Hi Hans, Martin, > > > > Sorry to jump in so late in the HDMI-CEC discussion, here are some > > comments from my perspective on your proposal: > > > > - the HDMI-CEC implementation deserves its own bus and class of devices > > because by definition it is a physical bus, which is even electrically > > independant from the rest of the HDMI bus (A/V path) > > > > - I don't think it is a good idea to tight it so closely to v4l, because > > one can perfectly have CEC-capable hardware without video, or at least > > not use v4l and have HDMI-CEC hardware > > > > - it was suggested to use sockets at some point, I think it is > > over-engineered and should only lead > > > > - processing messages in user-space is definitively the way to go, even > > input can be either re-injected using an uinput driver, or be handled in > > user-space entirely, eventually we might want to install "filters" based > > on opcodes to divert some opcodes to a kernel consumer, and the others > > to an user-space one > > > > Right now, I have a very simple implementation that I developed for the > > company I work for which can be found here: > > https://github.com/ffainelli/linux-hdmi-cec > > > > It is designed like this: > > > > 1) A core module, which registers a cec bus, and provides an abstraction > > for a CEC adapter (both device & driver): > > - basic CEC adapter operations: logical address setting, queueing > > management > > - counters, rx filtering > > - host attaching/detaching in case the hardware is capable of > > self-processing CEC messages (for wakeup in particular) > > > > 2) A character device module, which exposes a character device per CEC > > adapter and only allows one consumer at a time and exposes the following > > ioctl's: > > > > - SET_LOGICAL_ADDRESS > > - RESET_DEVICE > > - GET_COUNTERS > > - SET_RX_MODE (my adapter can be set in a promiscuous mode) > > > > the character device supports read/write/poll, which are the prefered > > ways for transfering/receiving data > > > > 3) A CEC adapter implementation which registers and calls into the core > > module when receiving a CEC message, and which the core module calls in > > response to the IOCTLs described below. > > > > At first I thought about defining a generic netlink family in order to > > allow multiple user-space listeners receive CEC messages, but in the end > > having only one consumer per adapter device is fine by me and a more > > traditionnal approach for programmers. > > > > I am relying on external components for knowing my HDMI physical address. > > > > Hope this is not too late to (re)start the discussion on HDMI-CEC. > > > > Thank you very much. > > -- > > Florian > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
Since a lot of video cards dont' support CEC at all (not even connected), don't have hdmi, but work perfectly fine with dvi->hdmi adapters, CEC can be implemented in many other ways (think media centers) One such exammple is using USB/Arduino http://code.google.com/p/cec-arduino/wiki/ElectricalInterface Having an AVR with v-usb code and cec code doesn't look all that hard nor impossible, so one could simply have a USB plug on one end, and an HDMI plug on the other end, utilizing only the CEC pins. This would make it more something like LIRC if anything. On 04/12/12 17:24, Florian Fainelli wrote: Hi Hans, Martin, Sorry to jump in so late in the HDMI-CEC discussion, here are some comments from my perspective on your proposal: - the HDMI-CEC implementation deserves its own bus and class of devices because by definition it is a physical bus, which is even electrically independant from the rest of the HDMI bus (A/V path) - I don't think it is a good idea to tight it so closely to v4l, because one can perfectly have CEC-capable hardware without video, or at least not use v4l and have HDMI-CEC hardware - it was suggested to use sockets at some point, I think it is over-engineered and should only lead - processing messages in user-space is definitively the way to go, even input can be either re-injected using an uinput driver, or be handled in user-space entirely, eventually we might want to install "filters" based on opcodes to divert some opcodes to a kernel consumer, and the others to an user-space one Right now, I have a very simple implementation that I developed for the company I work for which can be found here: https://github.com/ffainelli/linux-hdmi-cec It is designed like this: 1) A core module, which registers a cec bus, and provides an abstraction for a CEC adapter (both device & driver): - basic CEC adapter operations: logical address setting, queueing management - counters, rx filtering - host attaching/detaching in case the hardware is capable of self-processing CEC messages (for wakeup in particular) 2) A character device module, which exposes a character device per CEC adapter and only allows one consumer at a time and exposes the following ioctl's: - SET_LOGICAL_ADDRESS - RESET_DEVICE - GET_COUNTERS - SET_RX_MODE (my adapter can be set in a promiscuous mode) the character device supports read/write/poll, which are the prefered ways for transfering/receiving data 3) A CEC adapter implementation which registers and calls into the core module when receiving a CEC message, and which the core module calls in response to the IOCTLs described below. At first I thought about defining a generic netlink family in order to allow multiple user-space listeners receive CEC messages, but in the end having only one consumer per adapter device is fine by me and a more traditionnal approach for programmers. I am relying on external components for knowing my HDMI physical address. Hope this is not too late to (re)start the discussion on HDMI-CEC. Thank you very much. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
Hi Hans, Martin, Sorry to jump in so late in the HDMI-CEC discussion, here are some comments from my perspective on your proposal: - the HDMI-CEC implementation deserves its own bus and class of devices because by definition it is a physical bus, which is even electrically independant from the rest of the HDMI bus (A/V path) - I don't think it is a good idea to tight it so closely to v4l, because one can perfectly have CEC-capable hardware without video, or at least not use v4l and have HDMI-CEC hardware - it was suggested to use sockets at some point, I think it is over-engineered and should only lead - processing messages in user-space is definitively the way to go, even input can be either re-injected using an uinput driver, or be handled in user-space entirely, eventually we might want to install "filters" based on opcodes to divert some opcodes to a kernel consumer, and the others to an user-space one Right now, I have a very simple implementation that I developed for the company I work for which can be found here: https://github.com/ffainelli/linux-hdmi-cec It is designed like this: 1) A core module, which registers a cec bus, and provides an abstraction for a CEC adapter (both device & driver): - basic CEC adapter operations: logical address setting, queueing management - counters, rx filtering - host attaching/detaching in case the hardware is capable of self-processing CEC messages (for wakeup in particular) 2) A character device module, which exposes a character device per CEC adapter and only allows one consumer at a time and exposes the following ioctl's: - SET_LOGICAL_ADDRESS - RESET_DEVICE - GET_COUNTERS - SET_RX_MODE (my adapter can be set in a promiscuous mode) the character device supports read/write/poll, which are the prefered ways for transfering/receiving data 3) A CEC adapter implementation which registers and calls into the core module when receiving a CEC message, and which the core module calls in response to the IOCTLs described below. At first I thought about defining a generic netlink family in order to allow multiple user-space listeners receive CEC messages, but in the end having only one consumer per adapter device is fine by me and a more traditionnal approach for programmers. I am relying on external components for knowing my HDMI physical address. Hope this is not too late to (re)start the discussion on HDMI-CEC. Thank you very much. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Business proposal
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
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
On Sat, 19 Nov 2011 15:59:50 -0300 Ezequiel wrote: > 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. [snip] > Again, hope the patch helps, 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. No, your patch does not help... -- 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
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 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
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 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
Re: Cleanup proposal for media/gspca
On Wed, 16 Nov 2011 15:19:04 -0300
Ezequiel García 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
Cleanup proposal for media/gspca
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
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 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
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
Re: RFC: Proposal to change the way pending events are handled
On Tue, Jun 7, 2011 at 3:46 PM, Hans Verkuil 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 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 wh
Re: RFC: Proposal to change the way pending events are handled
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 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 timesta
Re: RFC: Proposal to change the way pending events are handled
Hi Hans, Laurent, On Tue, Jun 7, 2011 at 3:20 PM, Hans Verkuil 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 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
Re: RFC: Proposal to change the way pending events are handled
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 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
On Tuesday, June 07, 2011 13:51:38 David Cohen wrote: > Hi Hans, > > On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil 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
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 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
