Re: [Workshop-2011] Media summit/KS-2012 proposals
2012/9/6 Hans Verkuil hverk...@xs4all.nl: On Thu September 6 2012 06:09:44 Jun Nie wrote: 2012/9/5 Hans Verkuil hverk...@xs4all.nl: On Wed 5 September 2012 10:04:41 Jun Nie wrote: Is there any summary for this summit or presentation material? I am looking forward for some idea on CEC. It is really complex in functionality. Maybe other guys is expecting simiar fruite from summit too. Yes, there will be a summit report. It's not quite finished yet, I think. With respect to CEC we had some useful discussions. It will have to be a new class of device (/dev/cecX), so the userspace API will be separate from drm or v4l. And the kernel will have to take care of the core CEC protocol w.r.t. control and discovery due to the HDMI 1.4a requirements. I plan on starting work on this within 1-2 weeks. My CEC presentation can be found here: http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-cec.odp Regards, Hans Thanks for quick response! It's good to know that CEC is independent with DRM/V4L for my HDMI implementation is FB/lcd-device based. CEC is also deserved to have independent management in both hardware signal and functionality. Someone also expressed similar thoughts before. Will remote control protocal parsing are done in userspace reference library? Or not decided yet? Are you referring to the remote control pass-through functionality? I don't know yet whether that will go through a userspace library or through the RC kernel subsystem, or possibly both. I mean all the feature that can involved in handhold remote control, one touch play, standby, on screen display, etc, such as play/pause/poweroff. I want to mention all non CDC features that can be implemented in user space. They are hard to be covered by any sub-system and user space library is more proper. Just like your metaphor, kitchen sink for CEC. I like your words. Most of the other non-system messages will go to a userspace library. Does routing/address is included in system message here? But I haven't started coding yet, so it is very early days :-) The main thing is that at least I now have a high-level design that I can start to work with. 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: [Workshop-2011] Media summit/KS-2012 proposals
2012/9/6 Hans Verkuil hverk...@xs4all.nl: On Thu 6 September 2012 12:29:17 Jun Nie wrote: 2012/9/6 Hans Verkuil hverk...@xs4all.nl: On Thu September 6 2012 06:09:44 Jun Nie wrote: 2012/9/5 Hans Verkuil hverk...@xs4all.nl: On Wed 5 September 2012 10:04:41 Jun Nie wrote: Is there any summary for this summit or presentation material? I am looking forward for some idea on CEC. It is really complex in functionality. Maybe other guys is expecting simiar fruite from summit too. Yes, there will be a summit report. It's not quite finished yet, I think. With respect to CEC we had some useful discussions. It will have to be a new class of device (/dev/cecX), so the userspace API will be separate from drm or v4l. And the kernel will have to take care of the core CEC protocol w.r.t. control and discovery due to the HDMI 1.4a requirements. I plan on starting work on this within 1-2 weeks. My CEC presentation can be found here: http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-cec.odp Regards, Hans Thanks for quick response! It's good to know that CEC is independent with DRM/V4L for my HDMI implementation is FB/lcd-device based. CEC is also deserved to have independent management in both hardware signal and functionality. Someone also expressed similar thoughts before. Will remote control protocal parsing are done in userspace reference library? Or not decided yet? Are you referring to the remote control pass-through functionality? I don't know yet whether that will go through a userspace library or through the RC kernel subsystem, or possibly both. I mean all the feature that can involved in handhold remote control, one touch play, standby, on screen display, etc, such as play/pause/poweroff. I want to mention all non CDC features that can be implemented in user space. They are hard to be covered by any sub-system and user space library is more proper. Just like your metaphor, kitchen sink for CEC. I like your words. Yes, that will all be userspace. My plan is to have the CEC adapter driver handle the core CEC protocol, allow other drivers to intercept messages that are relevant for them and send messages themselves, and anything that remains will be available to userspace for which a new library will be created. Now, don't ask me about any of the details, since I don't have them yet :-) My plan is to start working on this next week or the week after. Are you willing to test early versions of this work? Can you test HDMI 1.4a features as well? Testing this might well be one of the harder things to do. I am willing to test or contribute to the library. But my hardware does not include HEAC. So my test scope limites to the features that can be implemented in user space. 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: [Workshop-2011] Media summit/KS-2012 proposals
Is there any summary for this summit or presentation material? I am looking forward for some idea on CEC. It is really complex in functionality. Maybe other guys is expecting simiar fruite from summit too. B.R. Jun -- 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: [Workshop-2011] Media summit/KS-2012 proposals
2012/9/5 Hans Verkuil hverk...@xs4all.nl: On Wed 5 September 2012 10:04:41 Jun Nie wrote: Is there any summary for this summit or presentation material? I am looking forward for some idea on CEC. It is really complex in functionality. Maybe other guys is expecting simiar fruite from summit too. Yes, there will be a summit report. It's not quite finished yet, I think. With respect to CEC we had some useful discussions. It will have to be a new class of device (/dev/cecX), so the userspace API will be separate from drm or v4l. And the kernel will have to take care of the core CEC protocol w.r.t. control and discovery due to the HDMI 1.4a requirements. I plan on starting work on this within 1-2 weeks. My CEC presentation can be found here: http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-cec.odp Regards, Hans Thanks for quick response! It's good to know that CEC is independent with DRM/V4L for my HDMI implementation is FB/lcd-device based. CEC is also deserved to have independent management in both hardware signal and functionality. Someone also expressed similar thoughts before. Will remote control protocal parsing are done in userspace reference library? Or not decided yet? B.R. Jun -- 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 0/5] Generic panel framework
Hi Laurent, Do you plan to add an API to get and parse EDID to mode list? video mode is tightly coupled with panel that is capable of hot-plug. Or you are busy on modifying EDID parsing code for sharing it amoung DRM/FB/etc? I see you mentioned this in Mar. It is great if you are considering add more info into video mode, such as pixel repeating, 3D timing related parameter. I have some code for CEA modes filtering and 3D parsing, but still tight coupled with FB and with a little hack style. My HDMI driver is implemented as lcd device as you mentioned here. But more complex than other lcd devices for a kthread is handling hot-plug/EDID/HDCP/ASoC etc. I also feel a little weird to add code parsing HDMI audio related info in fbmod.c in my current implementation, thought it is the only place to handle EDID in kernel. Your panel framework provide a better place to add panel related audio/HDCP code. panel notifier can also trigger hot-plug related feature, such as HDCP start. Looking forward to your hot-plug panel patch. Or I can help add it if you would like me to. Thanks! Jun -- 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: [Workshop-2011] Media summit/KS-2012 proposals
2012/8/3 Hans Verkuil hverk...@xs4all.nl: On Fri August 3 2012 07:37:13 Jun Nie wrote: 2012/8/1 Hans Verkuil hverk...@xs4all.nl: On Tue 31 July 2012 19:58:23 Mauro Carvalho Chehab wrote: In order to sum-up the discussions around the media summit, this is what we've got so far: Proposals proposed by =|= Common device tree bindings for media devices Sylvester Nawrocki / Guennadi Liakhovetski ALSA and V4L/Media Controller Steven Toth / Laurent Pinchart ARM and needed features for V4L/DVB Steven Toth Intel media SDK Steven Toth V4L compiance tool Hans Verkuil V4L2 API ambiguities Hans Verkuil Media Controller library Laurent Pincart / Sakari Ailus SoC Vendors feedback – how to help them to go upstream – Android's V4L2 cam library Laurent Pincart / Guennadi Liakhovetski / Palash Bandyopadhyay / Naveen Krishnamurthy Synchronization, shared resource and optimizations Pawel Osciak V4L2/DVB issues from userspace perspective Rémi Denis-Courmont As we'll have only one day for the summit, we may need to remove some themes, or maybe to get an extra time during LPC for the remaining discussions. Possible attendents: === Guennadi Liakhovetski Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Naveen Krishnamurthy +1 seat from ST (waiting Naveen to define who will be the other seat) Palash Bandyopadhyay Pawel Osciak Rémi Denis-Courmont Sakari Ailus Steven Toth Sylvester Nawrocki Am I missing something? Are there other proposals or people intending to participate? Yes: I would like to discuss how to add support for HDMI CEC to the kernel. In particularly I need some feedback from the GPU driver developers on what their ideas are, since CEC is something that touches both V4L2 and GPU. I am not familiar with CEC implementation in GPU. As far as I am aware there isn't any. But CEC should be independent in functionality with audio/video though it is A/V related. I prefer to support only CEC frame TX/RX in kernel. CEC include different category features that need parsing and may need application interaction. Venders may also configure some features as not supported. If kernel support more than TX/RX, policy may be separated to user space part and kernel space part. The kernel interface also becomes complex, maybe ambiguous too. An user space library is more suitable for this task to interact with OS/media player/audio control/etc. I wish that were possible. Our current implementation internally is as you proposed, but we recently discovered that for HDMI 1.4a this won't fly. There the CEC channel is also used for control of the ethernet and audio return channel, and even for hotplug detect in some cases. That's something that has to be handled entirely in kernelspace. So some parts of the CEC protocol have to be internally processed, other parts have to be processed in userspace. Thanks for your reminder. I was not aware of HEAC/ARC dependence on CEC for our product does not include these features. Maybe we can parse CDC CEC message in kernel and leave others to user space. But it is also an ugly propose. BTW: Do you see any scenario that EDID is changed dynamically? I do not know why to add hot-plug to CEC control while no physical HPD changes. This really complicates things and it makes it even more important that the subsystems that need CEC work together on this. 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: [Workshop-2011] Media summit/KS-2012 proposals
2012/8/1 Hans Verkuil hverk...@xs4all.nl: On Tue 31 July 2012 19:58:23 Mauro Carvalho Chehab wrote: In order to sum-up the discussions around the media summit, this is what we've got so far: Proposals proposed by =|= Common device tree bindings for media devices Sylvester Nawrocki / Guennadi Liakhovetski ALSA and V4L/Media Controller Steven Toth / Laurent Pinchart ARM and needed features for V4L/DVB Steven Toth Intel media SDK Steven Toth V4L compiance tool Hans Verkuil V4L2 API ambiguities Hans Verkuil Media Controller library Laurent Pincart / Sakari Ailus SoC Vendors feedback – how to help them to go upstream – Android's V4L2 cam library Laurent Pincart / Guennadi Liakhovetski / Palash Bandyopadhyay / Naveen Krishnamurthy Synchronization, shared resource and optimizations Pawel Osciak V4L2/DVB issues from userspace perspective Rémi Denis-Courmont As we'll have only one day for the summit, we may need to remove some themes, or maybe to get an extra time during LPC for the remaining discussions. Possible attendents: === Guennadi Liakhovetski Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Naveen Krishnamurthy +1 seat from ST (waiting Naveen to define who will be the other seat) Palash Bandyopadhyay Pawel Osciak Rémi Denis-Courmont Sakari Ailus Steven Toth Sylvester Nawrocki Am I missing something? Are there other proposals or people intending to participate? Yes: I would like to discuss how to add support for HDMI CEC to the kernel. In particularly I need some feedback from the GPU driver developers on what their ideas are, since CEC is something that touches both V4L2 and GPU. I am not familiar with CEC implementation in GPU. But CEC should be independent in functionality with audio/video though it is A/V related. I prefer to support only CEC frame TX/RX in kernel. CEC include different category features that need parsing and may need application interaction. Venders may also configure some features as not supported. If kernel support more than TX/RX, policy may be separated to user space part and kernel space part. The kernel interface also becomes complex, maybe ambiguous too. An user space library is more suitable for this task to interact with OS/media player/audio control/etc. I'm not sure what the best place is to do this, it's a fairly specialized topic. It might be better suited to just get a few interested devs together in the evening or during some other suitable time and just see if we can hammer out some scheme. I'll have a presentation on the topic ready. Rob, what are your ideas on this? Who else might be interested in this? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
Is there any discussion on HDCP on the summit? It is tightly coupled with HDMI and DVI and should be managed together with the transmitter. But there is not code to handle HDCP in DRM/FB/V4L in latest kernel. Any thoughts on HDCP? Or you guys think there is risk to support it in kernel? Thanks for your comments! Jun -- 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: [PATCH] [media] videobuf2-dma-contig: return NULL if alloc fails
2011/6/23 Jun Nie niej0...@gmail.com: return NULL if alloc fails to avoid taking error code as buffer pointer Signed-off-by: Jun Nie n...@marvell.com --- drivers/media/video/videobuf2-dma-contig.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/videobuf2-dma-contig.c b/drivers/media/video/videobuf2-dma-contig.c index a790a5f..8e8c7aa 100644 --- a/drivers/media/video/videobuf2-dma-contig.c +++ b/drivers/media/video/videobuf2-dma-contig.c @@ -40,7 +40,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size) buf = kzalloc(sizeof *buf, GFP_KERNEL); if (!buf) - return ERR_PTR(-ENOMEM); + return NULL; buf-vaddr = dma_alloc_coherent(conf-dev, size, buf-paddr, GFP_KERNEL); @@ -48,7 +48,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size) dev_err(conf-dev, dma_alloc_coherent of size %ld failed\n, size); kfree(buf); - return ERR_PTR(-ENOMEM); + return NULL; } buf-conf = conf; -- 1.7.0.4 How do you think about this fix? Thanks! Jun -- 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
[PATCH] [media] videobuf2-dma-contig: return NULL if alloc fails
return NULL if alloc fails to avoid taking error code as buffer pointer Signed-off-by: Jun Nie n...@marvell.com --- drivers/media/video/videobuf2-dma-contig.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/videobuf2-dma-contig.c b/drivers/media/video/videobuf2-dma-contig.c index a790a5f..8e8c7aa 100644 --- a/drivers/media/video/videobuf2-dma-contig.c +++ b/drivers/media/video/videobuf2-dma-contig.c @@ -40,7 +40,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size) buf = kzalloc(sizeof *buf, GFP_KERNEL); if (!buf) - return ERR_PTR(-ENOMEM); + return NULL; buf-vaddr = dma_alloc_coherent(conf-dev, size, buf-paddr, GFP_KERNEL); @@ -48,7 +48,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size) dev_err(conf-dev, dma_alloc_coherent of size %ld failed\n, size); kfree(buf); - return ERR_PTR(-ENOMEM); + return NULL; } buf-conf = conf; -- 1.7.0.4 -- 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: V4L2 and framebuffer for the same controller
2010/11/15 Guennadi Liakhovetski g.liakhovet...@gmx.de: On Mon, 15 Nov 2010, Jun Nie wrote: 2010/11/8 Jun Nie niej0...@gmail.com: 2010/11/2 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Jun On Fri, 29 Oct 2010, Jun Nie wrote: Hi Guennadi, I find that your idea of provide a generic framebuffer driver that could sit on top of a v4l output driver, which may be a good solution of our LCD controller driver, or maybe much more other SOC LCD drivers. V4L2 interface support many features than framebuffer for video playback usage, such as buffer queue/dequeue, quality control, etc. However, framebuffer is common for UI display. Implement two drivers for one controller is a challenge for current architecture. I am interested in your idea. Could you elaborate it? Or do you think multifunction driver is the right solution for this the scenario? Right, we have discussed this idea at the V4L2/MC mini-summit earlier this year, there the outcome was, that the idea is not bad, but it is easy enough to create such framebuffer additions on top of specific v4l2 output drivers anyway, so, noone was interested enough to start designing and implementing such a generic wrapper driver. However, I've heard, that this topic has also been scheduled for discussion at another v4l / kernel meeting (plumbers?), so, someone might be looking into implementing this... If you yourself would like to do that - feel free to propose a design on both mailing lists (fbdev added to cc), then we can discuss it, and you can implement it;) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Good to know others are also interested in it. I surely can contribute to it. But my concern is how to support Xwindow. Android and Ubuntu should both run on our platform. Queue/deque should work well for Android UI. I still can not figure out how to support Xwindow, for it does not interact with driver after it get the mmaped buffer. Jun Guennadi, Any idea on supporting this feature with V4L2 based FB? I can not figure out any method and will adopt framebuffer for UI and V4L2 for video layer for the schedule pressure. Hi Jun Sorry, not sure I understand you right here. You are saying, that atm you don't have the time to work on a generic solution and are going for a specific one, right? Yes, that's what everybody is currently doing. And you're asking whether I am working or am going to work on such a generic solution? No, sorry, I don't think I'll have time for it either in the near future. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Hi Guennadi I mean I have no idea on how to support Xwindow's requirement if FB is based on V4L2. I can contribute on V4L2 based FB if it is clear. But I will do as everbody does currently. Jun -- 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: V4L2 and framebuffer for the same controller
2010/11/15 Guennadi Liakhovetski g.liakhovet...@gmx.de: On Mon, 15 Nov 2010, Jun Nie wrote: 2010/11/15 Guennadi Liakhovetski g.liakhovet...@gmx.de: On Mon, 15 Nov 2010, Jun Nie wrote: 2010/11/8 Jun Nie niej0...@gmail.com: 2010/11/2 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Jun On Fri, 29 Oct 2010, Jun Nie wrote: Hi Guennadi, I find that your idea of provide a generic framebuffer driver that could sit on top of a v4l output driver, which may be a good solution of our LCD controller driver, or maybe much more other SOC LCD drivers. V4L2 interface support many features than framebuffer for video playback usage, such as buffer queue/dequeue, quality control, etc. However, framebuffer is common for UI display. Implement two drivers for one controller is a challenge for current architecture. I am interested in your idea. Could you elaborate it? Or do you think multifunction driver is the right solution for this the scenario? Right, we have discussed this idea at the V4L2/MC mini-summit earlier this year, there the outcome was, that the idea is not bad, but it is easy enough to create such framebuffer additions on top of specific v4l2 output drivers anyway, so, noone was interested enough to start designing and implementing such a generic wrapper driver. However, I've heard, that this topic has also been scheduled for discussion at another v4l / kernel meeting (plumbers?), so, someone might be looking into implementing this... If you yourself would like to do that - feel free to propose a design on both mailing lists (fbdev added to cc), then we can discuss it, and you can implement it;) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Good to know others are also interested in it. I surely can contribute to it. But my concern is how to support Xwindow. Android and Ubuntu should both run on our platform. Queue/deque should work well for Android UI. I still can not figure out how to support Xwindow, for it does not interact with driver after it get the mmaped buffer. Jun Guennadi, Any idea on supporting this feature with V4L2 based FB? I can not figure out any method and will adopt framebuffer for UI and V4L2 for video layer for the schedule pressure. Hi Jun Sorry, not sure I understand you right here. You are saying, that atm you don't have the time to work on a generic solution and are going for a specific one, right? Yes, that's what everybody is currently doing. And you're asking whether I am working or am going to work on such a generic solution? No, sorry, I don't think I'll have time for it either in the near future. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Hi Guennadi I mean I have no idea on how to support Xwindow's requirement if FB is based on V4L2. I can contribute on V4L2 based FB if it is clear. But I will do as everbody does currently. Maybe you didn't understand the concept of this driver then. The shole idea is to have a v4l2 output driver as a base and add a framebuffer translation layer on the top. Which would provide two interfaces to the user: a v4l2 one with frame queuing etc, and a standard fb one, which should be usable by any fb application (X, directfb,...) natively. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ You mean fb with V4L2 interface will manage memory with video-buf and standard fb interface still handle memory independently, ie. get memory with dma_alloc_writecombine directly? Thanks! Jun -- 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: V4L2 and framebuffer for the same controller
2010/11/8 Jun Nie niej0...@gmail.com: 2010/11/2 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Jun On Fri, 29 Oct 2010, Jun Nie wrote: Hi Guennadi, I find that your idea of provide a generic framebuffer driver that could sit on top of a v4l output driver, which may be a good solution of our LCD controller driver, or maybe much more other SOC LCD drivers. V4L2 interface support many features than framebuffer for video playback usage, such as buffer queue/dequeue, quality control, etc. However, framebuffer is common for UI display. Implement two drivers for one controller is a challenge for current architecture. I am interested in your idea. Could you elaborate it? Or do you think multifunction driver is the right solution for this the scenario? Right, we have discussed this idea at the V4L2/MC mini-summit earlier this year, there the outcome was, that the idea is not bad, but it is easy enough to create such framebuffer additions on top of specific v4l2 output drivers anyway, so, noone was interested enough to start designing and implementing such a generic wrapper driver. However, I've heard, that this topic has also been scheduled for discussion at another v4l / kernel meeting (plumbers?), so, someone might be looking into implementing this... If you yourself would like to do that - feel free to propose a design on both mailing lists (fbdev added to cc), then we can discuss it, and you can implement it;) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Good to know others are also interested in it. I surely can contribute to it. But my concern is how to support Xwindow. Android and Ubuntu should both run on our platform. Queue/deque should work well for Android UI. I still can not figure out how to support Xwindow, for it does not interact with driver after it get the mmaped buffer. Jun Guennadi, Any idea on supporting this feature with V4L2 based FB? I can not figure out any method and will adopt framebuffer for UI and V4L2 for video layer for the schedule pressure. Jun -- 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: V4L2 and framebuffer for the same controller
2010/11/2 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Jun On Fri, 29 Oct 2010, Jun Nie wrote: Hi Guennadi, I find that your idea of provide a generic framebuffer driver that could sit on top of a v4l output driver, which may be a good solution of our LCD controller driver, or maybe much more other SOC LCD drivers. V4L2 interface support many features than framebuffer for video playback usage, such as buffer queue/dequeue, quality control, etc. However, framebuffer is common for UI display. Implement two drivers for one controller is a challenge for current architecture. I am interested in your idea. Could you elaborate it? Or do you think multifunction driver is the right solution for this the scenario? Right, we have discussed this idea at the V4L2/MC mini-summit earlier this year, there the outcome was, that the idea is not bad, but it is easy enough to create such framebuffer additions on top of specific v4l2 output drivers anyway, so, noone was interested enough to start designing and implementing such a generic wrapper driver. However, I've heard, that this topic has also been scheduled for discussion at another v4l / kernel meeting (plumbers?), so, someone might be looking into implementing this... If you yourself would like to do that - feel free to propose a design on both mailing lists (fbdev added to cc), then we can discuss it, and you can implement it;) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Good to know others are also interested in it. I surely can contribute to it. But my concern is how to support Xwindow. Android and Ubuntu should both run on our platform. Queue/deque should work well for Android UI. I still can not figure out how to support Xwindow, for it does not interact with driver after it get the mmaped buffer. Jun -- 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 and framebuffer for the same controller
Hi Guennadi, I find that your idea of provide a generic framebuffer driver that could sit on top of a v4l output driver, which may be a good solution of our LCD controller driver, or maybe much more other SOC LCD drivers. V4L2 interface support many features than framebuffer for video playback usage, such as buffer queue/dequeue, quality control, etc. However, framebuffer is common for UI display. Implement two drivers for one controller is a challenge for current architecture. I am interested in your idea. Could you elaborate it? Or do you think multifunction driver is the right solution for this the scenario? Jun -- 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: Is it feasible to add another driver for CCIC?
2010/7/21 Guennadi Liakhovetski g.liakhovet...@gmx.de: On Wed, 21 Jul 2010, Jun Nie wrote: Hi, I am working on CCIC camera controller driver and want to push it into kernel. This CCIC IP is similar with IP of cafe_ccic, but with lots of change: no I2C bus, embedded in SOC/no PCI, support both parallel and CSI interface. So some register definition changes. I just want to confirm that a new driver for SOC CCIC is acceptable for community. Thanks! Well, if there is a well defined common core of the both implementations, e.g., common register set (or at least most of them), then, I think, it would make sense to split the current cafe_ccic, extract that core and reuse it... It is always an interesting decision, whether two devices are similar enough or not. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ DVP parallel part registers are 90% same, about 40% same for all registers with about 5% conflict. My main concern is that cafe_ccic driver structure and application usage is much simple and have no DMA chain while SOC CCIC should support soc_camera/DMA chain/user pointer. So it will take much effort to share DVP settings, such as image size and HSYNC_PO/VSYNC_PO, etc. Is there any existing drivers with such similar abstraction for decision making reference? Thanks Jun -- 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
Is it feasible to add another driver for CCIC?
Hi, I am working on CCIC camera controller driver and want to push it into kernel. This CCIC IP is similar with IP of cafe_ccic, but with lots of change: no I2C bus, embedded in SOC/no PCI, support both parallel and CSI interface. So some register definition changes. I just want to confirm that a new driver for SOC CCIC is acceptable for community. Thanks! Jun -- 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: Support on discontinuous planer buffer and stride
2009/10/10 Hans Verkuil hverk...@xs4all.nl:
On Saturday 10 October 2009 03:34:27 Jun Nie wrote:
2009/10/9 Hans Verkuil hverk...@xs4all.nl:
On Friday 09 October 2009 07:07:32 Jun Nie wrote:
2009/9/23 Jun Nie niej0...@gmail.com:
Hi,
I re-send this email for the last one is rejected by system. I am
sorry if you guys received both.
I am optimizing video playback with overlay with V4L2 driver. The
video content is a sub-region of codec output. Thus a memory copy is
necessary.
Is there plan to support for stride and discrete YUV planer in
kernel? Such as below changes can help much for my usage case.
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -529,7 +529,20 @@ struct v4l2_buffer {
__u32 offset;
unsigned long userptr;
} m;
+ /* UV/GB location is valid only in planer case */
+ union {
+ __u32 offset_ug;
+ unsigned long userptr_ug;
+ } m_ug;
+ union {
+ __u32 offset_vb;
+ unsigned long userptr_vb;
+ } m_vb;
__u32 length;
+ /* stride of YUV or RGB */
+ __u32 stride_yr;
+ __u32 stride_ug;
+ __u32 stride_vb;
__u32 input;
__u32 reserved;
};
If such change is acceptable for everyone, I may help on the
implementation.
Any comments are welcome.
Jun
Hi, Hans/Guennadi
What do you think of supporting this feature?
Jun
Well, it is definitely not possible to do it in this manner since changing
the size of struct v4l2_buffer will break the API. Furthermore, something
like
this will only work if the DMA engine can handle strides. Is that the case
for your hardware? I don't think you mentioned what the hardware is you
use.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
Hi, Hans
Thanks for your comments. My hardware, PXA168/910 support Y/U/V,
three DMA addresses. Y and UV stride can be different with width, such
as Y_stride == 336, UV_stride == 168 while width == 320. LCD
controller will handle dropping 20 bytes for every line before new
line scanning.
Application should query driver for the sub-region capability
before use it. Driver that do not support this feature will return
false by default, application should copy the sub-region to v4l2
buffer in this case.
The v4l2_buffer size change does impact IOCTL entry index value,
application re-compilation is needed, but no code change needed. It is
a balance between exploration of hardware capability and existing
application binary compatibility. I am new to this community. Was
there similar problems in community?
It is not allowed to break application binary compatibility. That's just a
fact of life.
If you use the PXA hardware, does that mean that you use the pxa_camera
driver? (Just making sure we talk about the same thing :-) )
Anyway, what you are really trying to do is to crop before sending over the
picture.
The normal sequence for output devices is that with S_FMT you specify the
size of the input frame and with S_CROP you can specify the target 'window'
for that frame. Usually the target window is the same size as the input frame,
but it can be a different size as well and in that case the hardware will
have to scale the input frame to the size of the target window.
Note that for output windows the S_CROP command is sort of the inverse
operation of what S_CROP does for capturing. If we would redo the API I'm sure
we would implement this differently since it is pretty confusing. But so be
it.
What you want to do here is to crop the input frame. So we need either some
new S_PRECROP ioctl or perhaps some new v4l2_buf_type value and use that in
combination with S_CROP. It should definitely be the responsibility of the
driver to figure out the strides as that very much depends on the chosen pixel
format. It's bad API design to put such hardware assumptions in the API.
If we want to keep the symmetry between capture and output streams, then
S_POSTCROP might be the better name. I.e. for capture streams S_CROP
determines the source rectangle, S_FMT the output resolution of that rectangle
and S_POSTCROP the area within that output rectangle that we actually want to
use. All this reverses for an output stream, so S_POSTCROP would refer to the
part of the output frame that we want to use. Just brainstorming, mind you
:-).
BTW, I noticed you didn't reply to the linux-media list. I recommend that you
add that the next time you reply since this is of interest for everyone I
think.
Regards,
Hans
--
Hans Verkuil
Re: Support on discontinuous planer buffer and stride
2009/9/23 Jun Nie niej0...@gmail.com:
Hi,
I re-send this email for the last one is rejected by system. I am
sorry if you guys received both.
I am optimizing video playback with overlay with V4L2 driver. The
video content is a sub-region of codec output. Thus a memory copy is
necessary.
Is there plan to support for stride and discrete YUV planer in
kernel? Such as below changes can help much for my usage case.
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -529,7 +529,20 @@ struct v4l2_buffer {
__u32 offset;
unsigned long userptr;
} m;
+ /* UV/GB location is valid only in planer case */
+ union {
+ __u32 offset_ug;
+ unsigned long userptr_ug;
+ } m_ug;
+ union {
+ __u32 offset_vb;
+ unsigned long userptr_vb;
+ } m_vb;
__u32 length;
+ /* stride of YUV or RGB */
+ __u32 stride_yr;
+ __u32 stride_ug;
+ __u32 stride_vb;
__u32 input;
__u32 reserved;
};
If such change is acceptable for everyone, I may help on the
implementation.
Any comments are welcome.
Jun
Hi, Hans/Guennadi
What do you think of supporting this feature?
Jun
Support on discontinuous planer buffer and stride
Hi,
I re-send this email for the last one is rejected by system. I am
sorry if you guys received both.
I am optimizing video playback with overlay with V4L2 driver. The
video content is a sub-region of codec output. Thus a memory copy is
necessary.
Is there plan to support for stride and discrete YUV planer in
kernel? Such as below changes can help much for my usage case.
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -529,7 +529,20 @@ struct v4l2_buffer {
__u32 offset;
unsigned long userptr;
} m;
+ /* UV/GB location is valid only in planer case */
+ union {
+ __u32 offset_ug;
+ unsigned long userptr_ug;
+ } m_ug;
+ union {
+ __u32 offset_vb;
+ unsigned long userptr_vb;
+ } m_vb;
__u32 length;
+ /* stride of YUV or RGB */
+ __u32 stride_yr;
+ __u32 stride_ug;
+ __u32 stride_vb;
__u32 input;
__u32 reserved;
};
If such change is acceptable for everyone, I may help on the implementation.
Any comments are welcome.
Jun
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±çbj)í
æèw* jg¬±¨ ¶Ý¢j/êäz¹Þà2Þ¨èÚ¢)ß¡«a¶Úþø ®G«éh®æj:+v¨wèÙ¥
