Re: [RFC PATCH 0/5] Matrix and Motion Detection support
Hi Laurent, Thanks for your reviews! On Thu 18 July 2013 02:12:49 Laurent Pinchart wrote: Hello, On Sunday 07 July 2013 23:50:30 Sylwester Nawrocki wrote: On 06/28/2013 02:27 PM, Hans Verkuil wrote: This patch series adds support for matrices and motion detection and converts the solo6x10 driver to use these new APIs. See the RFCv2 for details on the motion detection API: http://www.mail-archive.com/linux-media@vger.kernel.org/msg62085.html And this RFC for details on the matrix API (which superseeds the v4l2_md_blocks in the RFC above): http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/ 65195 I have tested this with the solo card, both global motion detection and regional motion detection, and it works well. There is no documentation for the new APIs yet (other than the RFCs). I would like to know what others think of this proposal before I start work on the DocBook documentation. These 3 ioctls look pretty generic and will likely allow us to handle wide range of functionalities, similarly to what the controls framework does today. What I don't like in the current trend of the V4L2 API development though is that we have seemingly separate APIs for configuring integers, rectangles, matrices, etc. And interactions between those APIs sometimes happen to be not well defined. I'm not opposed to having this matrix API, but I would _much_ more like to see it as a starting point of a more powerful API, that would allow to model dependencies between parameters being configured and the objects more explicitly and freely (e.g. case of the per buffer controls), that would allow to pass a list of commands to the hardware for atomic re- configurations, that would allow to create hardware configuration contexts, etc., etc. But it's all song of future, requires lots of effort, founding and takes engineers with significant experience. As it likely won't happen soon I guess we can proceed with the matrix API for now. Just for the record, I second that point of view. A matrix API, even as an interim solution for the problems at hand, would be welcome. I would use it to configure various kinds of LUTs (such as gamma tables). I'm all for going to a property-based model (or at least seriously brainstorming it), but we're looking at a too long time frame. OK. Good to know. In that case I will proceed with this and start writing the documentation part as well. 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 PATCH 0/5] Matrix and Motion Detection support
Hello, On Sunday 07 July 2013 23:50:30 Sylwester Nawrocki wrote: On 06/28/2013 02:27 PM, Hans Verkuil wrote: This patch series adds support for matrices and motion detection and converts the solo6x10 driver to use these new APIs. See the RFCv2 for details on the motion detection API: http://www.mail-archive.com/linux-media@vger.kernel.org/msg62085.html And this RFC for details on the matrix API (which superseeds the v4l2_md_blocks in the RFC above): http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/ 65195 I have tested this with the solo card, both global motion detection and regional motion detection, and it works well. There is no documentation for the new APIs yet (other than the RFCs). I would like to know what others think of this proposal before I start work on the DocBook documentation. These 3 ioctls look pretty generic and will likely allow us to handle wide range of functionalities, similarly to what the controls framework does today. What I don't like in the current trend of the V4L2 API development though is that we have seemingly separate APIs for configuring integers, rectangles, matrices, etc. And interactions between those APIs sometimes happen to be not well defined. I'm not opposed to having this matrix API, but I would _much_ more like to see it as a starting point of a more powerful API, that would allow to model dependencies between parameters being configured and the objects more explicitly and freely (e.g. case of the per buffer controls), that would allow to pass a list of commands to the hardware for atomic re- configurations, that would allow to create hardware configuration contexts, etc., etc. But it's all song of future, requires lots of effort, founding and takes engineers with significant experience. As it likely won't happen soon I guess we can proceed with the matrix API for now. Just for the record, I second that point of view. A matrix API, even as an interim solution for the problems at hand, would be welcome. I would use it to configure various kinds of LUTs (such as gamma tables). I'm all for going to a property-based model (or at least seriously brainstorming it), but we're looking at a too long time frame. My tentative goal is to get this in for 3.12. Once this is in place the solo and go7007 drivers can be moved out of staging into the mainline since this is the only thing holding them back. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] Matrix and Motion Detection support
Hi Hans, On 07/08/2013 09:22 AM, Hans Verkuil wrote: On Sun July 7 2013 23:50:30 Sylwester Nawrocki wrote: On 06/28/2013 02:27 PM, Hans Verkuil wrote: This patch series adds support for matrices and motion detection and converts the solo6x10 driver to use these new APIs. See the RFCv2 for details on the motion detection API: http://www.mail-archive.com/linux-media@vger.kernel.org/msg62085.html And this RFC for details on the matrix API (which superseeds the v4l2_md_blocks in the RFC above): http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 I have tested this with the solo card, both global motion detection and regional motion detection, and it works well. There is no documentation for the new APIs yet (other than the RFCs). I would like to know what others think of this proposal before I start work on the DocBook documentation. These 3 ioctls look pretty generic and will likely allow us to handle wide range of functionalities, similarly to what the controls framework does today. What I don't like in the current trend of the V4L2 API development though is that we have seemingly separate APIs for configuring integers, rectangles, matrices, etc. And interactions between those APIs sometimes happen to be not well defined. I'm not opposed to having this matrix API, but I would _much_ more like to see it as a starting point of a more powerful API, that would allow to model dependencies between parameters being configured and the objects more explicitly and freely (e.g. case of the per buffer controls), that would allow to pass a list of commands to the hardware for atomic re-configurations, that would allow to create hardware configuration contexts, etc., etc. But it's all song of future, requires lots of effort, founding and takes engineers with significant experience. As it likely won't happen soon I guess we can proceed with the matrix API for now. Do you attend the LPC in New Orleans? I would like to discuss this further, but it is easier to do so face-to-face with a whiteboard. Alternatively, we could set up a brainstorm session somewhere. This discussion keeps cropping up time and again, perhaps we should start to do something about it :-) My apologies for the delay. I'm not planning to attend LPC, certainly discussing this in person sounds like a good idea. I will be most likely attending ELCE in Edinburg though, perhaps we could have some meeting organized there, if there are other persons interested in that. -- Regards, Sylwester -- 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/5] Matrix and Motion Detection support
On Sun July 7 2013 23:50:30 Sylwester Nawrocki wrote: Hi Hans, On 06/28/2013 02:27 PM, Hans Verkuil wrote: This patch series adds support for matrices and motion detection and converts the solo6x10 driver to use these new APIs. See the RFCv2 for details on the motion detection API: http://www.mail-archive.com/linux-media@vger.kernel.org/msg62085.html And this RFC for details on the matrix API (which superseeds the v4l2_md_blocks in the RFC above): http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 I have tested this with the solo card, both global motion detection and regional motion detection, and it works well. There is no documentation for the new APIs yet (other than the RFCs). I would like to know what others think of this proposal before I start work on the DocBook documentation. These 3 ioctls look pretty generic and will likely allow us to handle wide range of functionalities, similarly to what the controls framework does today. What I don't like in the current trend of the V4L2 API development though is that we have seemingly separate APIs for configuring integers, rectangles, matrices, etc. And interactions between those APIs sometimes happen to be not well defined. I'm not opposed to having this matrix API, but I would _much_ more like to see it as a starting point of a more powerful API, that would allow to model dependencies between parameters being configured and the objects more explicitly and freely (e.g. case of the per buffer controls), that would allow to pass a list of commands to the hardware for atomic re-configurations, that would allow to create hardware configuration contexts, etc., etc. But it's all song of future, requires lots of effort, founding and takes engineers with significant experience. As it likely won't happen soon I guess we can proceed with the matrix API for now. Do you attend the LPC in New Orleans? I would like to discuss this further, but it is easier to do so face-to-face with a whiteboard. Alternatively, we could set up a brainstorm session somewhere. This discussion keeps cropping up time and again, perhaps we should start to do something about it :-) 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 PATCH 0/5] Matrix and Motion Detection support
Hi Hans, On 06/28/2013 02:27 PM, Hans Verkuil wrote: This patch series adds support for matrices and motion detection and converts the solo6x10 driver to use these new APIs. See the RFCv2 for details on the motion detection API: http://www.mail-archive.com/linux-media@vger.kernel.org/msg62085.html And this RFC for details on the matrix API (which superseeds the v4l2_md_blocks in the RFC above): http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 I have tested this with the solo card, both global motion detection and regional motion detection, and it works well. There is no documentation for the new APIs yet (other than the RFCs). I would like to know what others think of this proposal before I start work on the DocBook documentation. These 3 ioctls look pretty generic and will likely allow us to handle wide range of functionalities, similarly to what the controls framework does today. What I don't like in the current trend of the V4L2 API development though is that we have seemingly separate APIs for configuring integers, rectangles, matrices, etc. And interactions between those APIs sometimes happen to be not well defined. I'm not opposed to having this matrix API, but I would _much_ more like to see it as a starting point of a more powerful API, that would allow to model dependencies between parameters being configured and the objects more explicitly and freely (e.g. case of the per buffer controls), that would allow to pass a list of commands to the hardware for atomic re-configurations, that would allow to create hardware configuration contexts, etc., etc. But it's all song of future, requires lots of effort, founding and takes engineers with significant experience. As it likely won't happen soon I guess we can proceed with the matrix API for now. My tentative goal is to get this in for 3.12. Once this is in place the solo and go7007 drivers can be moved out of staging into the mainline since this is the only thing holding them back. -- Regards, Sylwester -- 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/5] Matrix and Motion Detection support
This patch series adds support for matrices and motion detection and converts the solo6x10 driver to use these new APIs. See the RFCv2 for details on the motion detection API: http://www.mail-archive.com/linux-media@vger.kernel.org/msg62085.html And this RFC for details on the matrix API (which superseeds the v4l2_md_blocks in the RFC above): http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 I have tested this with the solo card, both global motion detection and regional motion detection, and it works well. There is no documentation for the new APIs yet (other than the RFCs). I would like to know what others think of this proposal before I start work on the DocBook documentation. My tentative goal is to get this in for 3.12. Once this is in place the solo and go7007 drivers can be moved out of staging into the mainline since this is the only thing holding them back. 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
