[PATCH] [media] convert drivers/media/* to use module_platform_driver()
This patch converts the drivers in drivers/media/* to use the
module_platform_driver() macro which makes the code smaller and a bit
simpler.
Cc: Mauro Carvalho Chehab
Cc: Laurent Pinchart
Cc: Kyungmin Park
Cc: Hans Verkuil
Cc: "Richard Röjfors"
Cc: "Matti J. Aaltonen"
Cc: Lucas De Marchi
Cc: Manjunath Hadli
Cc: Muralidharan Karicheri
Cc: Anatolij Gustschin
Cc: Guennadi Liakhovetski
Cc: Marek Szyprowski
Cc: Robert Jarzmik
Cc: Jonathan Corbet
Cc: Daniel Drake
Signed-off-by: Axel Lin
---
drivers/media/radio/radio-si4713.c | 15 +--
drivers/media/radio/radio-timb.c | 15 +--
drivers/media/radio/radio-wl1273.c | 17 +---
drivers/media/video/davinci/dm355_ccdc.c | 13 +-
drivers/media/video/davinci/dm644x_ccdc.c | 13 +-
drivers/media/video/davinci/isif.c | 13 +-
drivers/media/video/davinci/vpbe.c | 24 +-
drivers/media/video/davinci/vpbe_display.c | 38 +---
drivers/media/video/davinci/vpbe_osd.c | 18 +
drivers/media/video/davinci/vpbe_venc.c| 18 +
drivers/media/video/davinci/vpfe_capture.c | 18 +
drivers/media/video/fsl-viu.c | 13 +-
drivers/media/video/mx3_camera.c | 14 +-
drivers/media/video/omap1_camera.c | 12 +
drivers/media/video/omap24xxcam.c | 19 +-
drivers/media/video/omap3isp/isp.c | 19 +-
drivers/media/video/pxa_camera.c | 14 +-
drivers/media/video/s5p-g2d/g2d.c | 16 +---
drivers/media/video/s5p-mfc/s5p_mfc.c | 22 +---
drivers/media/video/s5p-tv/hdmi_drv.c | 26 +--
drivers/media/video/s5p-tv/sdo_drv.c | 22 +---
drivers/media/video/sh_mobile_csi2.c | 13 +-
drivers/media/video/soc_camera_platform.c | 13 +-
drivers/media/video/timblogiw.c| 15 +--
drivers/media/video/via-camera.c | 12 +
25 files changed, 26 insertions(+), 406 deletions(-)
diff --git a/drivers/media/radio/radio-si4713.c
b/drivers/media/radio/radio-si4713.c
index d1fab58..c54210c 100644
--- a/drivers/media/radio/radio-si4713.c
+++ b/drivers/media/radio/radio-si4713.c
@@ -355,17 +355,4 @@ static struct platform_driver radio_si4713_pdriver = {
.remove = __exit_p(radio_si4713_pdriver_remove),
};
-/* Module Interface */
-static int __init radio_si4713_module_init(void)
-{
- return platform_driver_register(&radio_si4713_pdriver);
-}
-
-static void __exit radio_si4713_module_exit(void)
-{
- platform_driver_unregister(&radio_si4713_pdriver);
-}
-
-module_init(radio_si4713_module_init);
-module_exit(radio_si4713_module_exit);
-
+module_platform_driver(radio_si4713_pdriver);
diff --git a/drivers/media/radio/radio-timb.c b/drivers/media/radio/radio-timb.c
index 3e9209f..5d9a90a 100644
--- a/drivers/media/radio/radio-timb.c
+++ b/drivers/media/radio/radio-timb.c
@@ -226,20 +226,7 @@ static struct platform_driver timbradio_platform_driver = {
.remove = timbradio_remove,
};
-/*--*/
-
-static int __init timbradio_init(void)
-{
- return platform_driver_register(&timbradio_platform_driver);
-}
-
-static void __exit timbradio_exit(void)
-{
- platform_driver_unregister(&timbradio_platform_driver);
-}
-
-module_init(timbradio_init);
-module_exit(timbradio_exit);
+module_platform_driver(timbradio_platform_driver);
MODULE_DESCRIPTION("Timberdale Radio driver");
MODULE_AUTHOR("Mocean Laboratories ");
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
index 8aa4968..f1b6070 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -2148,8 +2148,6 @@ pdata_err:
return r;
}
-MODULE_ALIAS("platform:wl1273_fm_radio");
-
static struct platform_driver wl1273_fm_radio_driver = {
.probe = wl1273_fm_radio_probe,
.remove = __devexit_p(wl1273_fm_radio_remove),
@@ -2159,20 +2157,9 @@ static struct platform_driver wl1273_fm_radio_driver = {
},
};
-static int __init wl1273_fm_module_init(void)
-{
- pr_info("%s\n", __func__);
- return platform_driver_register(&wl1273_fm_radio_driver);
-}
-module_init(wl1273_fm_module_init);
-
-static void __exit wl1273_fm_module_exit(void)
-{
- platform_driver_unregister(&wl1273_fm_radio_driver);
- pr_info(DRIVER_DESC ", Exiting.\n");
-}
-module_exit(wl1273_fm_module_exit);
+module_platform_driver(wl1273_fm_radio_driver);
MODULE_AUTHOR("Matti Aaltonen ");
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:wl1273_fm_radio");
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
index
Trident TVMaster TM6000 USB2 Module DVB-S Part Support
Hello I have Geniatech satbox for more info : http://linuxtv.org/wiki/index.php/Geniatech_Satbox it's dvb-s device and it has tm6000 chip with cx24123/cx24109 tm6000 module only has dvb-t/analog support dvb-s feature to support in future will be or only just to be dvb-t part Regards. -- Olcay K. -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Sat, Nov 26, 2011 at 11:25 AM, Oliver Endriss wrote: > On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote: >> On 25.11.2011 17:51, Manu Abraham wrote: >> > On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab >> > wrote: >> >> Em 25-11-2011 14:03, Andreas Oberritter escreveu: >> >>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote: >> Em 25-11-2011 12:41, Andreas Oberritter escreveu: >> > On 25.11.2011 14:48, Mauro Carvalho Chehab wrote: >> >> If your complain is about the removal of audio.h, video.h >> > >> > We're back on topic, thank you! >> > >> >> and osd.h, then my proposal is >> >> to keep it there, writing a text that they are part of a deprecated >> >> API, >> > >> > That's exactly what I proposed. Well, you shouldn't write "deprecated", >> > because it's not. Just explain - inside this text - when V4L2 should be >> > preferred over DVB. >> >> It is deprecated, as the API is not growing to fulfill today's needs, >> and >> no patches adding new stuff to it to it will be accepted anymore. >> >>> >> >>> Haha, nice one. "It doesn't grow because I don't allow it to." Great! >> >> >> >> No. It didn't grow because nobody cared with it for years: >> >> >> >> Since 2.6.12-rc2 (start of git history), no changes ever happened at >> >> osd.h. >> >> >> >> Excluding Hans changes for using it on a pure V4L device, and other >> >> trivial >> >> patches not related to API changes, the last API change on audio.h and >> >> video.h >> >> was this patch: >> >> commit f05cce863fa399dd79c5aa3896d608b8b86d8030 >> >> Author: Andreas Oberritter >> >> Date: Mon Feb 27 00:09:00 2006 -0300 >> >> >> >> V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls >> >> >> >> (yet not used on any upstream driver) >> >> >> >> An then: >> >> commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 >> >> Author: Linus Torvalds >> >> Date: Sat Apr 16 15:20:36 2005 -0700 >> >> >> >> Linux-2.6.12-rc2 >> >> >> >> No changes adding support for any in-kernel driver were ever added there. >> >> >> >> So, it didn't grow over the last 5 or 6 years because nobody submitted >> >> driver patches requiring new things or _even_ using it. >> >> >> >>> >> >> but keeping >> >> the rest of the patches >> > >> > Which ones? >> >> V4L2, ivtv and DocBook patches. >> >>> >> >>> Fine. >> >>> >> >> and not accepting anymore any submission using them >> > >> > Why? First you complain about missing users and then don't want to >> > allow >> > any new ones. >> >> I didn't complain about missing users. What I've said is that, between a >> one-user API and broad used APIs like ALSA and V4L2, the choice is to >> freeze >> the one-user API and mark it as deprecated. >> >>> >> >>> Your assumtion about only one user still isn't true. >> >>> >> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev. >> It is easier to add what's missing there for DVB than to work the other >> way around, and deprecate V4L2/ALSA/MC/subdev. >> >>> >> >>> Yes. Please! Add it! But leave the DVB API alone! >> >>> >> >> , removing >> >> the ioctl's that aren't used by av7110 from them. >> > >> > That's just stupid. I can easily provide a list of used and valuable >> > ioctls, which need to remain present in order to not break userspace >> > applications. >> >> Those ioctl's aren't used by any Kernel driver, and not even documented. >> So, why to keep/maintain them? >> >>> >> >>> If you already deprecated it, why bother deleting random stuff from it >> >>> that people are using? >> >>> >> >>> There's a difference in keeping and maintaining something. You don't >> >>> need to maintain ioctls that haven't changed in years. Deleting >> >>> something is more work than letting it there to be used by those who >> >>> want to. >> >> >> >> Ok. Let's just keep the headers as is, just adding a comment that it is >> >> now >> >> considered superseded. >> >> Thank you! This is a step into the right direction. >> >> > http://dictionary.reference.com/browse/superseded >> > >> > to set aside or cause to be set aside as void, useless, or obsolete, >> > usually >> > in favor of something mentioned; make obsolete: They superseded the >> > old statute with a new one. >> > >> > No, that's not acceptable. New DVB devices as they come will make use >> > of the API and API changes might be applied. >> >> Honestly, I think we all should accept this proposal and just hope that >> the comment is going to be written objectively. > > 'Hoping' is not enough for me anymore. I am deeply disappointed. > Mauro and Hans have severely damaged my trust, that v4ldvb APIs are > stable in Linux, and how things are handled in this project. > > So I request a public statement from the subsystem maintainer that > 1. The DVB Decod
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote: > On 25.11.2011 17:51, Manu Abraham wrote: > > On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab > > wrote: > >> Em 25-11-2011 14:03, Andreas Oberritter escreveu: > >>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote: > Em 25-11-2011 12:41, Andreas Oberritter escreveu: > > On 25.11.2011 14:48, Mauro Carvalho Chehab wrote: > >> If your complain is about the removal of audio.h, video.h > > > > We're back on topic, thank you! > > > >> and osd.h, then my proposal is > >> to keep it there, writing a text that they are part of a deprecated > >> API, > > > > That's exactly what I proposed. Well, you shouldn't write "deprecated", > > because it's not. Just explain - inside this text - when V4L2 should be > > preferred over DVB. > > It is deprecated, as the API is not growing to fulfill today's needs, and > no patches adding new stuff to it to it will be accepted anymore. > >>> > >>> Haha, nice one. "It doesn't grow because I don't allow it to." Great! > >> > >> No. It didn't grow because nobody cared with it for years: > >> > >> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h. > >> > >> Excluding Hans changes for using it on a pure V4L device, and other trivial > >> patches not related to API changes, the last API change on audio.h and > >> video.h > >> was this patch: > >>commit f05cce863fa399dd79c5aa3896d608b8b86d8030 > >>Author: Andreas Oberritter > >>Date: Mon Feb 27 00:09:00 2006 -0300 > >> > >>V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls > >> > >>(yet not used on any upstream driver) > >> > >> An then: > >>commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 > >>Author: Linus Torvalds > >>Date: Sat Apr 16 15:20:36 2005 -0700 > >> > >>Linux-2.6.12-rc2 > >> > >> No changes adding support for any in-kernel driver were ever added there. > >> > >> So, it didn't grow over the last 5 or 6 years because nobody submitted > >> driver patches requiring new things or _even_ using it. > >> > >>> > >> but keeping > >> the rest of the patches > > > > Which ones? > > V4L2, ivtv and DocBook patches. > >>> > >>> Fine. > >>> > >> and not accepting anymore any submission using them > > > > Why? First you complain about missing users and then don't want to allow > > any new ones. > > I didn't complain about missing users. What I've said is that, between a > one-user API and broad used APIs like ALSA and V4L2, the choice is to > freeze > the one-user API and mark it as deprecated. > >>> > >>> Your assumtion about only one user still isn't true. > >>> > Also, today's needs are properly already covered by V4L/ALSA/MC/subdev. > It is easier to add what's missing there for DVB than to work the other > way around, and deprecate V4L2/ALSA/MC/subdev. > >>> > >>> Yes. Please! Add it! But leave the DVB API alone! > >>> > >> , removing > >> the ioctl's that aren't used by av7110 from them. > > > > That's just stupid. I can easily provide a list of used and valuable > > ioctls, which need to remain present in order to not break userspace > > applications. > > Those ioctl's aren't used by any Kernel driver, and not even documented. > So, why to keep/maintain them? > >>> > >>> If you already deprecated it, why bother deleting random stuff from it > >>> that people are using? > >>> > >>> There's a difference in keeping and maintaining something. You don't > >>> need to maintain ioctls that haven't changed in years. Deleting > >>> something is more work than letting it there to be used by those who > >>> want to. > >> > >> Ok. Let's just keep the headers as is, just adding a comment that it is now > >> considered superseded. > > Thank you! This is a step into the right direction. > > > http://dictionary.reference.com/browse/superseded > > > > to set aside or cause to be set aside as void, useless, or obsolete, usually > > in favor of something mentioned; make obsolete: They superseded the > > old statute with a new one. > > > > No, that's not acceptable. New DVB devices as they come will make use > > of the API and API changes might be applied. > > Honestly, I think we all should accept this proposal and just hope that > the comment is going to be written objectively. 'Hoping' is not enough for me anymore. I am deeply disappointed. Mauro and Hans have severely damaged my trust, that v4ldvb APIs are stable in Linux, and how things are handled in this project. So I request a public statement from the subsystem maintainer that 1. The DVB Decoder API will not be removed. 2. It can be updated if required (e.g. adding a missing function). 3. New drivers are allowed to use this architecture. 4. These driver will be accepted, if they follow the kernel standards. The re
Re: Hauppauge HVR-900 HD
On Fri, Nov 25, 2011 at 3:54 PM, Fredrik Lingvall wrote: > Hi All, > > I have a Hauppauge HVR-900 HD with ID 2040:b138. Is this device supported, > and if so, which driver and firmware do I need? Hi Frank, It's not currently supported under Linux as it uses a demodulator that there is currently no driver for. As far as I know, nobody's working on it. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: [PATCH v3 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On 11/24/2011 10:50 AM, Laurent Pinchart wrote:
> Hi Florian,
>
> Gentle ping ?
Sorry, but I'm very busy at the moment and therefore time-consuming things, like
solving challenging problems, are delayed for some time.
>
> On Sunday 20 November 2011 11:55:22 Laurent Pinchart wrote:
>> On Sunday 20 November 2011 03:00:33 Florian Tobias Schandinat wrote:
>>> Hi Laurent,
>>>
>>> On 08/31/2011 11:18 AM, Laurent Pinchart wrote:
This API will be used to support YUV frame buffer formats in a standard
way.
>>>
>>> looks like the union is causing problems. With this patch applied I get
>>>
>>> errors like this:
>>> CC [M] drivers/auxdisplay/cfag12864bfb.o
>>>
>>> drivers/auxdisplay/cfag12864bfb.c:57: error: unknown field ‘red’
>>> specified in initializer
>>
>> *ouch*
>>
>> gcc < 4.6 chokes on anonymous unions initializers :-/
>>
>> [snip]
>>
@@ -246,12 +251,23 @@ struct fb_var_screeninfo {
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
- __u32 grayscale;/* != 0 Graylevels instead of colors */
- struct fb_bitfield red; /* bitfield in fb mem if true color, */
- struct fb_bitfield green; /* else only length is significant */
- struct fb_bitfield blue;
- struct fb_bitfield transp; /* transparency */
+ union {
+ struct {/* Legacy format API*/
+ __u32 grayscale; /* 0 = color, 1 = grayscale*/
+ /* bitfields in fb mem if true color, else only */
+ /* length is significant*/
+ struct fb_bitfield red;
+ struct fb_bitfield green;
+ struct fb_bitfield blue;
+ struct fb_bitfield transp; /* transparency */
+ };
+ struct {/* FOURCC-based format API */
+ __u32 fourcc; /* FOURCC format*/
+ __u32 colorspace;
+ __u32 reserved[11];
+ } fourcc;
+ };
>>
>> We can't name the union, otherwise this will change the userspace API.
>>
>> We could "fix" the problem on the kernel side with
>>
>> #ifdef __KERNEL__
>> } color;
>> #else
>> };
>> #endif
>
> (and the structure that contains the grayscale, red, green, blue and transp
> fields would need to be similarly named, the "rgb" name comes to mind)
Which, I guess, would require modifying all drivers?
I don't consider that a good idea. Maybe the simplest solution would be to drop
the union idea and just accept an utterly misleading name "grayscale" for
setting the FOURCC value. The colorspace could use one of the reserved fields at
the end or do you worry that we need to add a lot of other things?
Best regards,
Florian Tobias Schandinat
>
>> That's quite hackish though... What's your opinion ?
>>
>> It would also not handle userspace code that initializes an
>> fb_var_screeninfo structure with named initializers, but that shouldn't
>> happen, as application should read fb_var_screeninfo , modify it and write
>> it back.
>>
__u32 nonstd; /* != 0 Non standard pixel format */
>
--
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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On 25.11.2011 17:51, Manu Abraham wrote: > On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab > wrote: >> Em 25-11-2011 14:03, Andreas Oberritter escreveu: >>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote: Em 25-11-2011 12:41, Andreas Oberritter escreveu: > On 25.11.2011 14:48, Mauro Carvalho Chehab wrote: >> If your complain is about the removal of audio.h, video.h > > We're back on topic, thank you! > >> and osd.h, then my proposal is >> to keep it there, writing a text that they are part of a deprecated API, > > That's exactly what I proposed. Well, you shouldn't write "deprecated", > because it's not. Just explain - inside this text - when V4L2 should be > preferred over DVB. It is deprecated, as the API is not growing to fulfill today's needs, and no patches adding new stuff to it to it will be accepted anymore. >>> >>> Haha, nice one. "It doesn't grow because I don't allow it to." Great! >> >> No. It didn't grow because nobody cared with it for years: >> >> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h. >> >> Excluding Hans changes for using it on a pure V4L device, and other trivial >> patches not related to API changes, the last API change on audio.h and >> video.h >> was this patch: >>commit f05cce863fa399dd79c5aa3896d608b8b86d8030 >>Author: Andreas Oberritter >>Date: Mon Feb 27 00:09:00 2006 -0300 >> >>V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls >> >>(yet not used on any upstream driver) >> >> An then: >>commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 >>Author: Linus Torvalds >>Date: Sat Apr 16 15:20:36 2005 -0700 >> >>Linux-2.6.12-rc2 >> >> No changes adding support for any in-kernel driver were ever added there. >> >> So, it didn't grow over the last 5 or 6 years because nobody submitted >> driver patches requiring new things or _even_ using it. >> >>> >> but keeping >> the rest of the patches > > Which ones? V4L2, ivtv and DocBook patches. >>> >>> Fine. >>> >> and not accepting anymore any submission using them > > Why? First you complain about missing users and then don't want to allow > any new ones. I didn't complain about missing users. What I've said is that, between a one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze the one-user API and mark it as deprecated. >>> >>> Your assumtion about only one user still isn't true. >>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev. It is easier to add what's missing there for DVB than to work the other way around, and deprecate V4L2/ALSA/MC/subdev. >>> >>> Yes. Please! Add it! But leave the DVB API alone! >>> >> , removing >> the ioctl's that aren't used by av7110 from them. > > That's just stupid. I can easily provide a list of used and valuable > ioctls, which need to remain present in order to not break userspace > applications. Those ioctl's aren't used by any Kernel driver, and not even documented. So, why to keep/maintain them? >>> >>> If you already deprecated it, why bother deleting random stuff from it >>> that people are using? >>> >>> There's a difference in keeping and maintaining something. You don't >>> need to maintain ioctls that haven't changed in years. Deleting >>> something is more work than letting it there to be used by those who >>> want to. >> >> Ok. Let's just keep the headers as is, just adding a comment that it is now >> considered superseded. Thank you! This is a step into the right direction. > http://dictionary.reference.com/browse/superseded > > to set aside or cause to be set aside as void, useless, or obsolete, usually > in favor of something mentioned; make obsolete: They superseded the > old statute with a new one. > > No, that's not acceptable. New DVB devices as they come will make use > of the API and API changes might be applied. Honestly, I think we all should accept this proposal and just hope that the comment is going to be written objectively. Regards, Andreas -- 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] mm: cma: hack/workaround for some allocation issues
On Fri, 25 Nov 2011 17:43:07 +0100, Marek Szyprowski
wrote:
This is a quick and dirty patch and hack to solve some memory allocation
issues that appeared at CMA v17 after switching migration code from
hotplug to memory compaction. Especially the issue with watermark
adjustment need a real fix instead of disabling the code.
Signed-off-by: Marek Szyprowski
---
Hello,
This patch fixes the issues that have been reported recently. It should
be considered only as a temporary solution until a new version of CMA
patches is ready.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
---
mm/compaction.c |5 -
mm/page_alloc.c | 12 +---
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 3e07341..41976f8 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -79,8 +79,9 @@ isolate_freepages_range(struct zone *zone,
skip:
if (freelist)
goto next;
+failed:
for (; start < pfn; ++start)
- __free_page(pfn_to_page(pfn));
+ __free_page(pfn_to_page(start));
return 0;
}
Yeah, my mistake, sorry about that. ;)
@@ -91,6 +92,8 @@ skip:
struct page *p = page;
for (i = isolated; i; --i, ++p)
list_add(&p->lru, freelist);
+ } else if (!isolated) {
+ goto failed;
}
next:
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 714b1c1..b4a46c7 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1303,12 +1303,12 @@ int split_free_page(struct page *page)
zone = page_zone(page);
order = page_order(page);
-
+#if 0
/* Obey watermarks as if the page was being allocated */
watermark = low_wmark_pages(zone) + (1 << order);
if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
return 0;
-
+#endif
/* Remove page from free list */
list_del(&page->lru);
zone->free_area[order].nr_free--;
Come to think of it, this watermark check seem a little meaningless in case of
CMA. With CMA the pages that we are splitting here have migrate type ISOLATE
so they aren't “free” at all. Buddy will never use them for allocation. That
means that we don't really allocate any pages, we just want to split them into
order-0 pages.
Also, if we bail out now, it's a huge waste of time and efforts.
So, if the watermarks need to be checked, they should somewhere before we do
migration and stuff. This may be due to my ignorance, but I don't know whether
we really need the watermark check if we decide to use plain alloc_page() as
allocator for migrate_pages() rather then compaction_alloc().
@@ -5734,6 +5734,12 @@ static unsigned long pfn_align_to_maxpage_up(unsigned
long pfn)
return ALIGN(pfn, MAX_ORDER_NR_PAGES);
}
+static struct page *
+cma_migrate_alloc(struct page *page, unsigned long private, int **x)
+{
+ return alloc_page(GFP_HIGHUSER_MOVABLE);
+}
+
static int __alloc_contig_migrate_range(unsigned long start, unsigned long end)
{
/* This function is based on compact_zone() from compaction.c. */
@@ -5801,7 +5807,7 @@ static int __alloc_contig_migrate_range(unsigned long
start, unsigned long end)
}
/* Try to migrate. */
- ret = migrate_pages(&cc.migratepages, compaction_alloc,
+ ret = migrate_pages(&cc.migratepages, cma_migrate_alloc,
(unsigned long)&cc, false, cc.sync);
/* Migrated all of them? Great! */
Yep, that makes sense to me. compaction_alloc() takes only free pages (ie.
pages
from buddy system) from given zone. This means that no pages get discarded or
swapped to disk. This makes sense for compaction since it's opportunistic in
its
nature. We, however, want pages to be discarded/swapped if that's the only way
of
getting pages to migrate to.
Of course, with this change the “(unsigneg long)&cc” part can be safely replaced
with “NULL” and “cc.nr_freepages -= release_freepages(&cc.freepages);” at the
end
of the function (not visible in this patch) with the next line removed.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
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
Hauppauge HVR-900 HD
Hi All, I have a Hauppauge HVR-900 HD with ID 2040:b138. Is this device supported, and if so, which driver and firmware do I need? Regards, /Fredrik -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Nov 25 19:00:19 CET 2011 git hash:7e5219d18e93dd23e834a53b1ea73ead19cfeeb1 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: [patch] [media] saa7164: fix endian conversion in saa7164_bus_set()
Em 23-11-2011 05:09, Dan Carpenter escreveu:
> The msg->command field is 32 bits, and we should fill it with a call
> to cpu_to_le32(). The current code is broken on big endian systems,
> and on little endian systems it just truncates the 32 bit value to
> 16 bits.
>
> Signed-off-by: Dan Carpenter
> ---
> This is a static checker bug. I haven't tested it.
>
> diff --git a/drivers/media/video/saa7164/saa7164-bus.c
> b/drivers/media/video/saa7164/saa7164-bus.c
> index 466e1b0..8f853d1 100644
> --- a/drivers/media/video/saa7164/saa7164-bus.c
> +++ b/drivers/media/video/saa7164/saa7164-bus.c
> @@ -149,7 +149,7 @@ int saa7164_bus_set(struct saa7164_dev *dev, struct
> tmComResInfo* msg,
> saa7164_bus_verify(dev);
>
> msg->size = cpu_to_le16(msg->size);
> - msg->command = cpu_to_le16(msg->command);
> + msg->command = cpu_to_le32(msg->command);
> msg->controlselector = cpu_to_le16(msg->controlselector);
>
> if (msg->size > dev->bus.m_wMaxReqSize) {
Hmm... I don't have this hardware, but:
peekout:
msg->size = le16_to_cpu(msg->size);
msg->command = le16_to_cpu(msg->command);
msg->controlselector = le16_to_cpu(msg->controlselector);
ret = SAA_OK;
out:
mutex_unlock(&bus->lock);
saa7164_bus_verify(dev);
return ret;
}
le16_to_cpu() is used for command. If one place needs fix, so the other one also
requires it.
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
Re: [PATCH v1 2/2] vb2: add support for app_offset field of the v4l2_plane struct
Hi Hans,
Thanks for comments.
On Tue, Nov 22, 2011 at 02:38, Hans Verkuil wrote:
> Hi Pawel!
>
> Thanks for doing this work, but I have a few comments...
>
> On Tuesday, November 22, 2011 06:26:37 Pawel Osciak wrote:
>> The app_offset can only be set by userspace and will be passed by vb2 to
>> the driver.
(..,)
>
> I'd like to see this implemented in vivi and preferably one other driver.
>
Yes, I just wanted to show how the V4L2 API would change and make sure
people agreed before starting to implement in drivers. Looks like no
one is questioning it.
> What also needs to be clarified is how this affects queue_setup (should the
> sizes include the app_offset or not?) and e.g. vb2_plane_size (again, is the
> size with or without app_offset?).
>
> Should app_offset handling be enforced (i.e. should all vb2 drivers support
> it?) or should it be optional? If optional, then app_offset should be set to
> 0 somehow.
>
There are several design questions:
1. Enforcing handling of app_offset.
I would prefer enforcing it. If we don't, we'll need some kind of new
capability if forcing to 0 or would have to otherwise communicate it
(zero it out in kernel when setting the format maybe). I'd like to try
enforcing while hiding it in vb2 layer, so the drivers would not have
to be concerned about that. Note also that this applies only to
multiplanar drivers.
2. Allocation - additional memory must be allocated for mmap and one
problem is that the hardware will usually need buffer_addr +
app_offset to be page-aligned, so we'd be "wasting" up to a page per
buffer for this. Not a big deal probably though.
3. Handling in vb2
For mmap, vb2 (i.e. allocators) would have to allocate this memory in
addition to the required buffer size, provided by the driver. I hope
it could be made transparent to drivers by returning addresses to
buffers after app_offset to them only. So only the allocator would
need to be aware of both, but it's internal to vb2 as well.
4. queue_setup
I would like to make it oblivious to app_offset and keep and handle it
only in vb2 and allocators. Need to see how it works out by
implementing though.
5. And other things most probably. I will go ahead and start
implementing to see what less obvious subtleties I might be missing.
> This code in __qbuf_userptr should probably also be modified as this
> currently does not take app_offset into account.
>
> /* Check if the provided plane buffer is large enough */
> if (planes[plane].length < q->plane_sizes[plane]) {
> ret = -EINVAL;
> goto err;
> }
>
>
As for userptr, at first I thought that the correct behavior would be
to ignore that app memory entirely, i.e. make vb2 give pointers after
app_offset, but this won't fly with for more advanced allocators that
may need the app memory as well. Will rethink.
> I think there are some subtleties that we don't know about yet, so
> implementing
> this in a real driver would hopefully bring those subtleties out in the open.
>
Yes, I will implement it in vivi as a pilot now and add support in all
drivers once we have everything sorted out.
--
Best regards,
Pawel Osciak
--
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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab wrote: > Em 25-11-2011 14:03, Andreas Oberritter escreveu: >> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote: >>> Em 25-11-2011 12:41, Andreas Oberritter escreveu: On 25.11.2011 14:48, Mauro Carvalho Chehab wrote: > If your complain is about the removal of audio.h, video.h We're back on topic, thank you! > and osd.h, then my proposal is > to keep it there, writing a text that they are part of a deprecated API, That's exactly what I proposed. Well, you shouldn't write "deprecated", because it's not. Just explain - inside this text - when V4L2 should be preferred over DVB. >>> >>> It is deprecated, as the API is not growing to fulfill today's needs, and >>> no patches adding new stuff to it to it will be accepted anymore. >> >> Haha, nice one. "It doesn't grow because I don't allow it to." Great! > > No. It didn't grow because nobody cared with it for years: > > Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h. > > Excluding Hans changes for using it on a pure V4L device, and other trivial > patches not related to API changes, the last API change on audio.h and video.h > was this patch: > commit f05cce863fa399dd79c5aa3896d608b8b86d8030 > Author: Andreas Oberritter > Date: Mon Feb 27 00:09:00 2006 -0300 > > V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls > > (yet not used on any upstream driver) > > An then: > commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 > Author: Linus Torvalds > Date: Sat Apr 16 15:20:36 2005 -0700 > > Linux-2.6.12-rc2 > > No changes adding support for any in-kernel driver were ever added there. > > So, it didn't grow over the last 5 or 6 years because nobody submitted > driver patches requiring new things or _even_ using it. > >> > but keeping > the rest of the patches Which ones? >>> >>> V4L2, ivtv and DocBook patches. >> >> Fine. >> > and not accepting anymore any submission using them Why? First you complain about missing users and then don't want to allow any new ones. >>> >>> I didn't complain about missing users. What I've said is that, between a >>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze >>> the one-user API and mark it as deprecated. >> >> Your assumtion about only one user still isn't true. >> >>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev. >>> It is easier to add what's missing there for DVB than to work the other >>> way around, and deprecate V4L2/ALSA/MC/subdev. >> >> Yes. Please! Add it! But leave the DVB API alone! >> > , removing > the ioctl's that aren't used by av7110 from them. That's just stupid. I can easily provide a list of used and valuable ioctls, which need to remain present in order to not break userspace applications. >>> >>> Those ioctl's aren't used by any Kernel driver, and not even documented. >>> So, why to keep/maintain them? >> >> If you already deprecated it, why bother deleting random stuff from it >> that people are using? >> >> There's a difference in keeping and maintaining something. You don't >> need to maintain ioctls that haven't changed in years. Deleting >> something is more work than letting it there to be used by those who >> want to. > > Ok. Let's just keep the headers as is, just adding a comment that it is now > considered superseded. http://dictionary.reference.com/browse/superseded to set aside or cause to be set aside as void, useless, or obsolete, usually in favor of something mentioned; make obsolete: They superseded the old statute with a new one. No, that's not acceptable. New DVB devices as they come will make use of the API and API changes might be applied. -- 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] mm: cma: hack/workaround for some allocation issues
This is a quick and dirty patch and hack to solve some memory allocation
issues that appeared at CMA v17 after switching migration code from
hotplug to memory compaction. Especially the issue with watermark
adjustment need a real fix instead of disabling the code.
Signed-off-by: Marek Szyprowski
---
Hello,
This patch fixes the issues that have been reported recently. It should
be considered only as a temporary solution until a new version of CMA
patches is ready.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
---
mm/compaction.c |5 -
mm/page_alloc.c | 12 +---
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 3e07341..41976f8 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -79,8 +79,9 @@ isolate_freepages_range(struct zone *zone,
skip:
if (freelist)
goto next;
+failed:
for (; start < pfn; ++start)
- __free_page(pfn_to_page(pfn));
+ __free_page(pfn_to_page(start));
return 0;
}
@@ -91,6 +92,8 @@ skip:
struct page *p = page;
for (i = isolated; i; --i, ++p)
list_add(&p->lru, freelist);
+ } else if (!isolated) {
+ goto failed;
}
next:
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 714b1c1..b4a46c7 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1303,12 +1303,12 @@ int split_free_page(struct page *page)
zone = page_zone(page);
order = page_order(page);
-
+#if 0
/* Obey watermarks as if the page was being allocated */
watermark = low_wmark_pages(zone) + (1 << order);
if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
return 0;
-
+#endif
/* Remove page from free list */
list_del(&page->lru);
zone->free_area[order].nr_free--;
@@ -5734,6 +5734,12 @@ static unsigned long pfn_align_to_maxpage_up(unsigned
long pfn)
return ALIGN(pfn, MAX_ORDER_NR_PAGES);
}
+static struct page *
+cma_migrate_alloc(struct page *page, unsigned long private, int **x)
+{
+ return alloc_page(GFP_HIGHUSER_MOVABLE);
+}
+
static int __alloc_contig_migrate_range(unsigned long start, unsigned long end)
{
/* This function is based on compact_zone() from compaction.c. */
@@ -5801,7 +5807,7 @@ static int __alloc_contig_migrate_range(unsigned long
start, unsigned long end)
}
/* Try to migrate. */
- ret = migrate_pages(&cc.migratepages, compaction_alloc,
+ ret = migrate_pages(&cc.migratepages, cma_migrate_alloc,
(unsigned long)&cc, false, cc.sync);
/* Migrated all of them? Great! */
--
1.7.1.569.g6f426
--
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: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
I've rebuilt my PRIME interface on top of dmabuf to see how it would work, I've got primed gears running again on top, but I expect all my object lifetime and memory ownership rules need fixing up (i.e. leaks like a sieve). http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf has the i915/nouveau patches for the kernel to produce the prime interface. Dave. -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 25-11-2011 14:03, Andreas Oberritter escreveu: > On 25.11.2011 16:38, Mauro Carvalho Chehab wrote: >> Em 25-11-2011 12:41, Andreas Oberritter escreveu: >>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote: If your complain is about the removal of audio.h, video.h >>> >>> We're back on topic, thank you! >>> and osd.h, then my proposal is to keep it there, writing a text that they are part of a deprecated API, >>> >>> That's exactly what I proposed. Well, you shouldn't write "deprecated", >>> because it's not. Just explain - inside this text - when V4L2 should be >>> preferred over DVB. >> >> It is deprecated, as the API is not growing to fulfill today's needs, and >> no patches adding new stuff to it to it will be accepted anymore. > > Haha, nice one. "It doesn't grow because I don't allow it to." Great! No. It didn't grow because nobody cared with it for years: Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h. Excluding Hans changes for using it on a pure V4L device, and other trivial patches not related to API changes, the last API change on audio.h and video.h was this patch: commit f05cce863fa399dd79c5aa3896d608b8b86d8030 Author: Andreas Oberritter Date: Mon Feb 27 00:09:00 2006 -0300 V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls (yet not used on any upstream driver) An then: commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Author: Linus Torvalds Date: Sat Apr 16 15:20:36 2005 -0700 Linux-2.6.12-rc2 No changes adding support for any in-kernel driver were ever added there. So, it didn't grow over the last 5 or 6 years because nobody submitted driver patches requiring new things or _even_ using it. > but keeping the rest of the patches >>> >>> Which ones? >> >> V4L2, ivtv and DocBook patches. > > Fine. > and not accepting anymore any submission using them >>> >>> Why? First you complain about missing users and then don't want to allow >>> any new ones. >> >> I didn't complain about missing users. What I've said is that, between a >> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze >> the one-user API and mark it as deprecated. > > Your assumtion about only one user still isn't true. > >> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev. >> It is easier to add what's missing there for DVB than to work the other >> way around, and deprecate V4L2/ALSA/MC/subdev. > > Yes. Please! Add it! But leave the DVB API alone! > , removing the ioctl's that aren't used by av7110 from them. >>> >>> That's just stupid. I can easily provide a list of used and valuable >>> ioctls, which need to remain present in order to not break userspace >>> applications. >> >> Those ioctl's aren't used by any Kernel driver, and not even documented. >> So, why to keep/maintain them? > > If you already deprecated it, why bother deleting random stuff from it > that people are using? > > There's a difference in keeping and maintaining something. You don't > need to maintain ioctls that haven't changed in years. Deleting > something is more work than letting it there to be used by those who > want to. Ok. Let's just keep the headers as is, just adding a comment that it is now considered superseded. >>> Btw.: It's not easy to submit a driver for a SoC. Even if you are >>> legally allowed to do it, you have to first merge and maintain the board >>> support code before even thinking about multimedia. >> >> Yes, I know that there's a long road for SoC drivers addition. Fortunately, >> several vendors are now working to put their stuff upstream. >> >> I heard that there are some upcoming changes intended to simplify it a >> little bit, >> trying to make the architecture a little more generic, and put board-specific >> configuration on userspace. I dunno the details. > > Thanks for your help. > > Regards, > Andreas -- 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: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
> +struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> + struct device *dev)
> +{
> + struct dma_buf_attachment *attach;
> + int ret;
> +
> + BUG_ON(!dmabuf || !dev);
> +
> + mutex_lock(&dmabuf->lock);
> +
> + attach = kzalloc(sizeof(struct dma_buf_attachment), GFP_KERNEL);
> + if (attach == NULL)
> + goto err_alloc;
> +
> + attach->dev = dev;
> + if (dmabuf->ops->attach) {
> + ret = dmabuf->ops->attach(dmabuf, dev, attach);
> + if (!ret)
> + goto err_attach;
> + }
> + list_add(&attach->node, &dmabuf->attachments);
> +
I would assume at some point this needed at
attach->dmabuf = dmabuf;
added.
Dave.
--
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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Fri, Nov 25, 2011 at 9:33 PM, Mauro Carvalho Chehab wrote: > Em 25-11-2011 13:58, Manu Abraham escreveu: >> On Fri, Nov 25, 2011 at 8:52 PM, Hans Verkuil wrote: >>> On Friday, November 25, 2011 14:48:02 Mauro Carvalho Chehab wrote: Em 25-11-2011 10:00, Andreas Oberritter escreveu: > On 24.11.2011 19:47, Mauro Carvalho Chehab wrote: >> Em 24-11-2011 16:13, Manu Abraham escreveu: >>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab >>> wrote: Em 24-11-2011 16:01, Manu Abraham escreveu: > On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil > wrote: >> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >>> Don't break existing Userspace APIs for no reason! It's OK to add >>> the >>> new API, but - pretty please - don't just blindly remove audio.h and >>> video.h. They are in use since many years by av7110, out-of-tree >>> drivers >>> *and more importantly* by applications. Yes, I know, you'd like to >>> see >>> those out-of-tree drivers merged, but it isn't possible for many >>> reasons. And even if they were merged, you'd say "Port them and your >>> apps to V4L". No! That's not an option. >> >> I'm not breaking anything. All apps will still work. >> >> One option (and it depends on whether people like it or not) is to >> have >> audio.h, video.h and osd.h just include av7110.h and add a #warning >> that these headers need to be replaced by the new av7110.h. > > > That won't work with other non av7110 hardware. There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put a warning at the existing headers as-is, for now, putting them to be removed for a new kernel version, like 3.4. >>> >>> >>> No, that's not an option. The to-be merged saa716x driver depends on it. >> >> If the driver is not merged yet, it can be changed. >> >>> A DVB alone device need not depend V4L2 for it's operation. >> >> Why not? DVB drivers with IR should implement the input/event/IR API. >> DVB drivers with net >> should implement the Linux Network API. > > DVB doesn't specify IR. There's no such thing like a DVB IR device. > > IP over DVB is implemented transparently. No driver needs to do anything > but register its device's MAC address, therefore no driver implements > the Linux Network API. > >> There is nothing wrong on using the ALSA API for audio and the V4L2 API >> for video, >> as both API fits the needs for decoding audio and video streams, and new >> features >> could be added there when needed. > > Yes. There's nothing wrong with it and I'm not complaining. I don't care > about the implementation of the API in ivtv either. Just don't remove > the API from dvb-core, period. > >> Duplicated API's that become legacy are removed with time. Just to >> mention two >> notable cases, this happened with the old audio stack (OSS), with the >> old Wireless >> stack. > > I can still use iwconfig and linux/wireless.h is still available on my > system. Yes, but both iwconfig and the API changed. > ALSA still provides OSS emulation and the real OSS stack was marked > deprecated but still present for ages. OSS driver submission stopped years ago. I remember it clearly as they denied cx88-oss driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were dropped in 2007[1] in favor of the alsa drivers. The only hardware that are still there at OSS are the legacy ones that probably no alsa developer has anymore. [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread > In contrast, you want to remove a > stable API and introduce a new *completely untested* API between 3.3 and > 3.4. Please read the patches again. The API for the devices are still there: any binary compiled for older kernels will still work with av7110 and ivtv. With the patches applied, the only difference is that the header file has renamed, as they were moved to device-specific headers. It should be noticed that, while both av7110 and ivtv uses the same ioctl's, av7110 creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in practice, each driver has a different API. There are no plans to remove the API for av7110. As discussed on this thread, it seems that the agreed plans for the ivtv API is to put it into the standard kernel procedure to get rid of legacy API. That means that the API will be there for a few kernel versions. Hans proposal is to remove the ivtv API on 3
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 25-11-2011 13:58, Manu Abraham escreveu: > On Fri, Nov 25, 2011 at 8:52 PM, Hans Verkuil wrote: >> On Friday, November 25, 2011 14:48:02 Mauro Carvalho Chehab wrote: >>> Em 25-11-2011 10:00, Andreas Oberritter escreveu: On 24.11.2011 19:47, Mauro Carvalho Chehab wrote: > Em 24-11-2011 16:13, Manu Abraham escreveu: >> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab >> wrote: >>> Em 24-11-2011 16:01, Manu Abraham escreveu: On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil wrote: > On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >> Don't break existing Userspace APIs for no reason! It's OK to add the >> new API, but - pretty please - don't just blindly remove audio.h and >> video.h. They are in use since many years by av7110, out-of-tree >> drivers >> *and more importantly* by applications. Yes, I know, you'd like to >> see >> those out-of-tree drivers merged, but it isn't possible for many >> reasons. And even if they were merged, you'd say "Port them and your >> apps to V4L". No! That's not an option. > > I'm not breaking anything. All apps will still work. > > One option (and it depends on whether people like it or not) is to > have > audio.h, video.h and osd.h just include av7110.h and add a #warning > that these headers need to be replaced by the new av7110.h. That won't work with other non av7110 hardware. >>> >>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we >>> can put >>> a warning at the existing headers as-is, for now, putting them to be >>> removed >>> for a new kernel version, like 3.4. >> >> >> No, that's not an option. The to-be merged saa716x driver depends on it. > > If the driver is not merged yet, it can be changed. > >> A DVB alone device need not depend V4L2 for it's operation. > > Why not? DVB drivers with IR should implement the input/event/IR API. DVB > drivers with net > should implement the Linux Network API. DVB doesn't specify IR. There's no such thing like a DVB IR device. IP over DVB is implemented transparently. No driver needs to do anything but register its device's MAC address, therefore no driver implements the Linux Network API. > There is nothing wrong on using the ALSA API for audio and the V4L2 API > for video, > as both API fits the needs for decoding audio and video streams, and new > features > could be added there when needed. Yes. There's nothing wrong with it and I'm not complaining. I don't care about the implementation of the API in ivtv either. Just don't remove the API from dvb-core, period. > Duplicated API's that become legacy are removed with time. Just to > mention two > notable cases, this happened with the old audio stack (OSS), with the old > Wireless > stack. I can still use iwconfig and linux/wireless.h is still available on my system. >>> >>> Yes, but both iwconfig and the API changed. >>> ALSA still provides OSS emulation and the real OSS stack was marked deprecated but still present for ages. >>> >>> OSS driver submission stopped years ago. I remember it clearly as they >>> denied cx88-oss >>> driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were >>> dropped in 2007[1] >>> in favor of the alsa drivers. The only hardware that are still there at OSS >>> are the >>> legacy ones that probably no alsa developer has anymore. >>> >>> [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread >>> In contrast, you want to remove a stable API and introduce a new *completely untested* API between 3.3 and 3.4. >>> >>> Please read the patches again. The API for the devices are still there: >>> any binary compiled for older kernels will still work with av7110 and ivtv. >>> With the patches applied, the only difference is that the header file has >>> renamed, as they were moved to device-specific headers. >>> >>> It should be noticed that, while both av7110 and ivtv uses the same >>> ioctl's, av7110 >>> creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in >>> practice, >>> each driver has a different API. >>> >>> There are no plans to remove the API for av7110. >>> >>> As discussed on this thread, it seems that the agreed plans for the ivtv >>> API is to put >>> it into the standard kernel procedure to get rid of legacy API. That means >>> that the API >>> will be there for a few kernel versions. >>> >>> Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, >>> the first >>> API removal will happen in about 18 months from now (assuming about 2 >>> months per kernel >>> version). >>> > Do you have any issues
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On 25.11.2011 16:38, Mauro Carvalho Chehab wrote: > Em 25-11-2011 12:41, Andreas Oberritter escreveu: >> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote: >>> If your complain is about the removal of audio.h, video.h >> >> We're back on topic, thank you! >> >>> and osd.h, then my proposal is >>> to keep it there, writing a text that they are part of a deprecated API, >> >> That's exactly what I proposed. Well, you shouldn't write "deprecated", >> because it's not. Just explain - inside this text - when V4L2 should be >> preferred over DVB. > > It is deprecated, as the API is not growing to fulfill today's needs, and > no patches adding new stuff to it to it will be accepted anymore. Haha, nice one. "It doesn't grow because I don't allow it to." Great! >>> but keeping >>> the rest of the patches >> >> Which ones? > > V4L2, ivtv and DocBook patches. Fine. >>> and not accepting anymore any submission using them >> >> Why? First you complain about missing users and then don't want to allow >> any new ones. > > I didn't complain about missing users. What I've said is that, between a > one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze > the one-user API and mark it as deprecated. Your assumtion about only one user still isn't true. > Also, today's needs are properly already covered by V4L/ALSA/MC/subdev. > It is easier to add what's missing there for DVB than to work the other > way around, and deprecate V4L2/ALSA/MC/subdev. Yes. Please! Add it! But leave the DVB API alone! >>> , removing >>> the ioctl's that aren't used by av7110 from them. >> >> That's just stupid. I can easily provide a list of used and valuable >> ioctls, which need to remain present in order to not break userspace >> applications. > > Those ioctl's aren't used by any Kernel driver, and not even documented. > So, why to keep/maintain them? If you already deprecated it, why bother deleting random stuff from it that people are using? There's a difference in keeping and maintaining something. You don't need to maintain ioctls that haven't changed in years. Deleting something is more work than letting it there to be used by those who want to. >> Btw.: It's not easy to submit a driver for a SoC. Even if you are >> legally allowed to do it, you have to first merge and maintain the board >> support code before even thinking about multimedia. > > Yes, I know that there's a long road for SoC drivers addition. Fortunately, > several vendors are now working to put their stuff upstream. > > I heard that there are some upcoming changes intended to simplify it a little > bit, > trying to make the architecture a little more generic, and put board-specific > configuration on userspace. I dunno the details. Thanks for your help. Regards, Andreas -- 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: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Fri, Nov 25, 2011 at 02:13:22PM +, Dave Airlie wrote: > On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal wrote: > > This is the first step in defining a dma buffer sharing mechanism. > > > > A new buffer object dma_buf is added, with operations and API to allow easy > > sharing of this buffer object across devices. > > > > The framework allows: > > - a new buffer-object to be created with fixed size. > > - different devices to 'attach' themselves to this buffer, to facilitate > > backing storage negotiation, using dma_buf_attach() API. > > - association of a file pointer with each user-buffer and associated > > allocator-defined operations on that buffer. This operation is called the > > 'export' operation. > > - this exported buffer-object to be shared with the other entity by asking > > for > > its 'file-descriptor (fd)', and sharing the fd across. > > - a received fd to get the buffer object back, where it can be accessed > > using > > the associated exporter-defined operations. > > - the exporter and user to share the scatterlist using get_scatterlist and > > put_scatterlist operations. > > > > Atleast one 'attach()' call is required to be made prior to calling the > > get_scatterlist() operation. > > > > Couple of building blocks in get_scatterlist() are added to ease > > introduction > > of sync'ing across exporter and users, and late allocation by the exporter. > > > > mmap() file operation is provided for the associated 'fd', as wrapper over > > the > > optional allocator defined mmap(), to be used by devices that might need > > one. > > > > More details are there in the documentation patch. > > > > Some questions, I've started playing around with using this framework > to do buffer sharing between DRM devices, > > Why struct scatterlist and not struct sg_table? it seems like I really > want to use an sg_table, No reason at all besides that intel-gtt is using scatterlist internally (and only kludges the sg_table together in an ad-hoc fashion) and so I haven't noticed. sg_table for more consistency with the dma api sounds good. > I'm not convinced fd's are really useful over just some idr allocated > handle, so far I'm just returning the "fd" to userspace as a handle, > and passing it back in the other side, so I'm not really sure what an > fd wins us here, apart from the mmap thing which I think shouldn't be > here anyways. > (if fd's do win us more we should probably record that in the docs patch). Imo fds are nice because their known and there's already all the preexisting infrastructure for them around. And if we ever get fancy with e.g. sync objects we can easily add poll support (or some insane ioctls). But I agree that "we can mmap" is bust as a reason and should just die. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 25-11-2011 13:25, Hans Verkuil escreveu: > On Friday, November 25, 2011 16:18:52 Mauro Carvalho Chehab wrote: >> The V4L2 API complements the ALSA API. Audio streaming, audio format >> negotiation >> etc are via the ALSA API. >> >>> Can you control pass-through of digital audio to SPDIF for example? Can >>> you control which decoder should be the master when synchronizing AV? >> >> Patches for that are being proposed and should be merged soon. They are part >> of the set of patches under discussion with ALSA people, as part of the Media >> Controller API. > > Can you provide a link to those patches? I haven't seen anything cross-posted > to linux-media. That was my understanding when I was discussing with Sakari about the MC presentation for KS. I'll double check with him if he can provide us more details about the status of this subject. 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
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Fri, Nov 25, 2011 at 8:52 PM, Hans Verkuil wrote: > On Friday, November 25, 2011 14:48:02 Mauro Carvalho Chehab wrote: >> Em 25-11-2011 10:00, Andreas Oberritter escreveu: >> > On 24.11.2011 19:47, Mauro Carvalho Chehab wrote: >> >> Em 24-11-2011 16:13, Manu Abraham escreveu: >> >>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab >> >>> wrote: >> Em 24-11-2011 16:01, Manu Abraham escreveu: >> > On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil >> > wrote: >> >> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >> >>> Don't break existing Userspace APIs for no reason! It's OK to add the >> >>> new API, but - pretty please - don't just blindly remove audio.h and >> >>> video.h. They are in use since many years by av7110, out-of-tree >> >>> drivers >> >>> *and more importantly* by applications. Yes, I know, you'd like to >> >>> see >> >>> those out-of-tree drivers merged, but it isn't possible for many >> >>> reasons. And even if they were merged, you'd say "Port them and your >> >>> apps to V4L". No! That's not an option. >> >> >> >> I'm not breaking anything. All apps will still work. >> >> >> >> One option (and it depends on whether people like it or not) is to >> >> have >> >> audio.h, video.h and osd.h just include av7110.h and add a #warning >> >> that these headers need to be replaced by the new av7110.h. >> > >> > >> > That won't work with other non av7110 hardware. >> >> There isn't any non-av7110 driver using it at the Kernel. Anyway, we >> can put >> a warning at the existing headers as-is, for now, putting them to be >> removed >> for a new kernel version, like 3.4. >> >>> >> >>> >> >>> No, that's not an option. The to-be merged saa716x driver depends on it. >> >> >> >> If the driver is not merged yet, it can be changed. >> >> >> >>> A DVB alone device need not depend V4L2 for it's operation. >> >> >> >> Why not? DVB drivers with IR should implement the input/event/IR API. DVB >> >> drivers with net >> >> should implement the Linux Network API. >> > >> > DVB doesn't specify IR. There's no such thing like a DVB IR device. >> > >> > IP over DVB is implemented transparently. No driver needs to do anything >> > but register its device's MAC address, therefore no driver implements >> > the Linux Network API. >> > >> >> There is nothing wrong on using the ALSA API for audio and the V4L2 API >> >> for video, >> >> as both API fits the needs for decoding audio and video streams, and new >> >> features >> >> could be added there when needed. >> > >> > Yes. There's nothing wrong with it and I'm not complaining. I don't care >> > about the implementation of the API in ivtv either. Just don't remove >> > the API from dvb-core, period. >> > >> >> Duplicated API's that become legacy are removed with time. Just to >> >> mention two >> >> notable cases, this happened with the old audio stack (OSS), with the old >> >> Wireless >> >> stack. >> > >> > I can still use iwconfig and linux/wireless.h is still available on my >> > system. >> >> Yes, but both iwconfig and the API changed. >> >> > ALSA still provides OSS emulation and the real OSS stack was marked >> > deprecated but still present for ages. >> >> OSS driver submission stopped years ago. I remember it clearly as they >> denied cx88-oss >> driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were >> dropped in 2007[1] >> in favor of the alsa drivers. The only hardware that are still there at OSS >> are the >> legacy ones that probably no alsa developer has anymore. >> >> [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread >> >> > In contrast, you want to remove a >> > stable API and introduce a new *completely untested* API between 3.3 and >> > 3.4. >> >> Please read the patches again. The API for the devices are still there: >> any binary compiled for older kernels will still work with av7110 and ivtv. >> With the patches applied, the only difference is that the header file has >> renamed, as they were moved to device-specific headers. >> >> It should be noticed that, while both av7110 and ivtv uses the same ioctl's, >> av7110 >> creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in >> practice, >> each driver has a different API. >> >> There are no plans to remove the API for av7110. >> >> As discussed on this thread, it seems that the agreed plans for the ivtv API >> is to put >> it into the standard kernel procedure to get rid of legacy API. That means >> that the API >> will be there for a few kernel versions. >> >> Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, >> the first >> API removal will happen in about 18 months from now (assuming about 2 months >> per kernel >> version). >> >> >> Do you have any issues that needs to be addressed by the V4L2 API for it >> >> to fit >> >> on your needs? >>
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 25-11-2011 13:22, Hans Verkuil escreveu: > On Friday, November 25, 2011 14:48:02 Mauro Carvalho Chehab wrote: >> Em 25-11-2011 10:00, Andreas Oberritter escreveu: >>> On 24.11.2011 19:47, Mauro Carvalho Chehab wrote: Em 24-11-2011 16:13, Manu Abraham escreveu: > On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab > wrote: >> Em 24-11-2011 16:01, Manu Abraham escreveu: >>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil >>> wrote: On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: > Don't break existing Userspace APIs for no reason! It's OK to add the > new API, but - pretty please - don't just blindly remove audio.h and > video.h. They are in use since many years by av7110, out-of-tree > drivers > *and more importantly* by applications. Yes, I know, you'd like to see > those out-of-tree drivers merged, but it isn't possible for many > reasons. And even if they were merged, you'd say "Port them and your > apps to V4L". No! That's not an option. I'm not breaking anything. All apps will still work. One option (and it depends on whether people like it or not) is to have audio.h, video.h and osd.h just include av7110.h and add a #warning that these headers need to be replaced by the new av7110.h. >>> >>> >>> That won't work with other non av7110 hardware. >> >> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can >> put >> a warning at the existing headers as-is, for now, putting them to be >> removed >> for a new kernel version, like 3.4. > > > No, that's not an option. The to-be merged saa716x driver depends on it. If the driver is not merged yet, it can be changed. > A DVB alone device need not depend V4L2 for it's operation. Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net should implement the Linux Network API. >>> >>> DVB doesn't specify IR. There's no such thing like a DVB IR device. >>> >>> IP over DVB is implemented transparently. No driver needs to do anything >>> but register its device's MAC address, therefore no driver implements >>> the Linux Network API. >>> There is nothing wrong on using the ALSA API for audio and the V4L2 API for video, as both API fits the needs for decoding audio and video streams, and new features could be added there when needed. >>> >>> Yes. There's nothing wrong with it and I'm not complaining. I don't care >>> about the implementation of the API in ivtv either. Just don't remove >>> the API from dvb-core, period. >>> Duplicated API's that become legacy are removed with time. Just to mention two notable cases, this happened with the old audio stack (OSS), with the old Wireless stack. >>> >>> I can still use iwconfig and linux/wireless.h is still available on my >>> system. >> >> Yes, but both iwconfig and the API changed. >> >>> ALSA still provides OSS emulation and the real OSS stack was marked >>> deprecated but still present for ages. >> >> OSS driver submission stopped years ago. I remember it clearly as they >> denied cx88-oss >> driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were >> dropped in 2007[1] >> in favor of the alsa drivers. The only hardware that are still there at OSS >> are the >> legacy ones that probably no alsa developer has anymore. >> >> [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread >> >>> In contrast, you want to remove a >>> stable API and introduce a new *completely untested* API between 3.3 and >>> 3.4. >> >> Please read the patches again. The API for the devices are still there: >> any binary compiled for older kernels will still work with av7110 and ivtv. >> With the patches applied, the only difference is that the header file has >> renamed, as they were moved to device-specific headers. >> >> It should be noticed that, while both av7110 and ivtv uses the same ioctl's, >> av7110 >> creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in >> practice, >> each driver has a different API. >> >> There are no plans to remove the API for av7110. >> >> As discussed on this thread, it seems that the agreed plans for the ivtv API >> is to put >> it into the standard kernel procedure to get rid of legacy API. That means >> that the API >> will be there for a few kernel versions. >> >> Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, >> the first >> API removal will happen in about 18 months from now (assuming about 2 months >> per kernel >> version). >> Do you have any issues that needs to be addressed by the V4L2 API for it to fit on your needs? >>> >>> I don't want to be forced to use the V4L2 API for no reason and no gain. >> >> As already explai
Re: [RFCv2 PATCH 10/12] av7110: replace audio.h, video.h and osd.h by av7110.h.
On 24.11.2011 14:39, Hans Verkuil wrote: From: Hans Verkuil Create a new public header, av7110.h, that contains all the av7110 specific audio, video and osd APIs that used to be defined in dvb/audio.h, dvb/video.h and dvb/osd.h. These APIs are no longer part of DVBv5 but are now av7110-specific. This decision was taken during the 2011 Prague V4L-DVB workshop. Ideally av7110 would be converted to use the replacement V4L2 MPEG decoder API, but that's a huge job for such an old driver. Signed-off-by: Hans Verkuil This would break applications, especially VDR. I therefore strongly oppose this! You may introduce new APIs as you like, but don't break the existing ones that have worked for many years. Nacked-by: Klaus Schmidinger Klaus -- 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 v2 2/2] s5p-fimc: Add support for alpha component configuration
On Exynos SoCs the FIMC IP allows to configure globally the alpha
component of all pixels for V4L2_PIX_FMT_RGB32, V4L2_PIX_FMT_RGB555
and V4L2_PIX_FMT_RGB444 image formats. This patch adds a v4l2 control
in order to let the applications control the alpha component value.
The alpha value range depends on the pixel format, for RGB32 it's
0..255 (8-bits), for RGB555 - 0..1 (1-bit) and for RGB444 - 0..15
(4-bits). The v4l2 control range is always 0..255 and the alpha
component data width is determined by currently set format on the
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE buffer queue. The applications
need to match the alpha channel data width and the pixel format
since the driver will ignore the alpha component bits that are not
applicable to the configured pixel format.
A new entry is added in the variant description data structure
so an additional control is created only where really supported
by the hardware.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c |4 ++
drivers/media/video/s5p-fimc/fimc-core.c| 49 ++---
drivers/media/video/s5p-fimc/fimc-core.h| 13 ++-
drivers/media/video/s5p-fimc/fimc-reg.c | 53 +--
drivers/media/video/s5p-fimc/regs-fimc.h|5 +++
5 files changed, 105 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 82d9ab6..70176e5 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -63,6 +63,8 @@ static int fimc_init_capture(struct fimc_dev *fimc)
fimc_hw_set_effect(ctx, false);
fimc_hw_set_output_path(ctx);
fimc_hw_set_out_dma(ctx);
+ if (fimc->variant->has_alpha)
+ fimc_hw_set_rgb_alpha(ctx);
clear_bit(ST_CAPT_APPLY_CFG, &fimc->state);
}
spin_unlock_irqrestore(&fimc->slock, flags);
@@ -154,6 +156,8 @@ int fimc_capture_config_update(struct fimc_ctx *ctx)
fimc_hw_set_rotation(ctx);
fimc_prepare_dma_offset(ctx, &ctx->d_frame);
fimc_hw_set_out_dma(ctx);
+ if (fimc->variant->has_alpha)
+ fimc_hw_set_rgb_alpha(ctx);
clear_bit(ST_CAPT_APPLY_CFG, &fimc->state);
}
spin_unlock(&ctx->slock);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 567e9ea..5fe9aeb 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -52,13 +52,29 @@ static struct fimc_fmt fimc_formats[] = {
.colplanes = 1,
.flags = FMT_FLAGS_M2M,
}, {
- .name = "XRGB-8-8-8-8, 32 bpp",
+ .name = "ARGB, 32 bpp",
.fourcc = V4L2_PIX_FMT_RGB32,
.depth = { 32 },
.color = S5P_FIMC_RGB888,
.memplanes = 1,
.colplanes = 1,
- .flags = FMT_FLAGS_M2M,
+ .flags = FMT_FLAGS_M2M | FMT_HAS_ALPHA,
+ }, {
+ .name = "ARGB1555",
+ .fourcc = V4L2_PIX_FMT_RGB555,
+ .depth = { 16 },
+ .color = S5P_FIMC_RGB555,
+ .memplanes = 1,
+ .colplanes = 1,
+ .flags = FMT_FLAGS_M2M | FMT_HAS_ALPHA,
+ }, {
+ .name = "ARGB",
+ .fourcc = V4L2_PIX_FMT_RGB444,
+ .depth = { 16 },
+ .color = S5P_FIMC_RGB444,
+ .memplanes = 1,
+ .colplanes = 1,
+ .flags = FMT_FLAGS_M2M | FMT_HAS_ALPHA,
}, {
.name = "YUV 4:2:2 packed, YCbYCr",
.fourcc = V4L2_PIX_FMT_YUYV,
@@ -652,8 +668,11 @@ static void fimc_dma_run(void *priv)
if (ctx->state & (FIMC_DST_ADDR | FIMC_PARAMS))
fimc_hw_set_output_addr(fimc, &ctx->d_frame.paddr, -1);
- if (ctx->state & FIMC_PARAMS)
+ if (ctx->state & FIMC_PARAMS) {
fimc_hw_set_out_dma(ctx);
+ if (fimc->variant->has_alpha)
+ fimc_hw_set_rgb_alpha(ctx);
+ }
fimc_activate_capture(ctx);
@@ -790,6 +809,11 @@ static int fimc_s_ctrl(struct v4l2_ctrl *ctrl)
ctx->rotation = ctrl->val;
break;
+ case V4L2_CID_ALPHA_COMPONENT:
+ spin_lock_irqsave(&ctx->slock, flags);
+ ctx->d_frame.alpha = ctrl->val;
+ break;
+
default:
v4l2_err(fimc->v4l2_dev, "Invalid control: 0x%X\n", ctrl->id);
return -EINVAL;
@@ -806
[PATCH v2 1/2] v4l: Add new alpha component control
This control is intended for the video capture or memory-to-memory devices that are capable of setting up a per-pixel alpha component to some arbitrary value. The V4L2_CID_ALPHA_COMPONENT control allows to set the alpha component for all pixels to a value in range from 0 to 255. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Documentation/DocBook/media/v4l/compat.xml | 11 Documentation/DocBook/media/v4l/controls.xml | 25 +++ .../DocBook/media/v4l/pixfmt-packed-rgb.xml|7 - drivers/media/video/v4l2-ctrls.c |7 + include/linux/videodev2.h |6 ++-- 5 files changed, 45 insertions(+), 11 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index b68698f..0adda43 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2379,6 +2379,17 @@ that used it. It was originally scheduled for removal in 2.6.35. + + V4L2 in Linux 3.3 + + + Added V4L2_CID_ALPHA_COMPONENT control + to the User controls class. + + + + + Relation of V4L2 to other Linux multimedia APIs diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..4fd83c0 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -324,12 +324,6 @@ minimum value disables backlight compensation. (usually a microscope). - V4L2_CID_LASTP1 - - End of the predefined control IDs (currently -V4L2_CID_ILLUMINATORS_2 + 1). - - V4L2_CID_MIN_BUFFERS_FOR_CAPTURE integer This is a read-only control that can be read by the application @@ -345,6 +339,25 @@ and used as a hint to determine the number of OUTPUT buffers to pass to REQBUFS. The value is the minimum number of OUTPUT buffers that is necessary for hardware to work. + + V4L2_CID_ALPHA_COMPONENT + integer +Sets the alpha color component on the capture device or on + the capture buffer queue of a mem-to-mem device. When a mem-to-mem + device produces frame format that includes an alpha component + (e.g. packed RGB image formats) + and the alpha value is not defined by the mem-to-mem input data + this control lets you select the alpha component value of all + pixels. It is applicable to any pixel format that contains an alpha + component. + + + + V4L2_CID_LASTP1 + + End of the predefined control IDs (currently + V4L2_CID_ALPHA_COMPONENT + 1). + V4L2_CID_PRIVATE_BASE diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index 4db272b..c13278b 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml @@ -428,8 +428,11 @@ colorspace V4L2_COLORSPACE_SRGB. Bit 7 is the most significant bit. The value of a = alpha bits is undefined when reading from the driver, ignored when writing to the driver, except when alpha blending has been negotiated for a -Video Overlay or Video Output Overlay. +Video Overlay or +Video Output Overlay or when alpha component has been configured +for a Video Capture by means of V4L2_CID_ALPHA_COMPONENT + control. V4L2_PIX_FMT_BGR24 4 × 4 pixel diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c index 5552f81..882cc84 100644 --- a/drivers/media/video/v4l2-ctrls.c +++ b/drivers/media/video/v4l2-ctrls.c @@ -466,6 +466,7 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_ILLUMINATORS_2: return "Illuminator 2"; case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE: return "Minimum Number of Capture Buffers"; case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT: return "Minimum Number of Output Buffers"; + case V4L2_CID_ALPHA_COMPONENT: return "Alpha Component"; /* MPEG controls */ /* Keep the order of the 'case's the same as in videodev2.h! */ @@ -714,6 +715,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type, /* Max is calculated as RGB888 that is 2^24 */ *max = 0xFF; break; + case V4L2_CID_ALPHA_COMPONENT: + *type = V4L2_CTRL_TYPE_INTEGER; + *step = 1; + *min = 0; + *max = 0xff; + break; case V4L2_CID_FLASH_FAULT: *type = V4L2_CTRL_TYPE_BITMASK; break; diff --git
[PATCH/RFC v2] Add new V4L2_CID_ALPHA_COMPONENT control
Hello, This changeset adds new V4L2_CID_ALPHA_COMPONENT control that allows to configure an alpha component of all pixels on the video capture device or on capture queue of a mem-to-mem device. This is meant for devices that allow to set a per-pixel alpha at the pipeline output to a desired value and where the input alpha component doesn't influence the output alpha value. The second patch adds the control to s5p-fimc video capture and mem-to-mem driver. This changset also does a minor cleanup at the user controls DocBook chapter. Changes since v2: - rename V4L2_CID_COLOR_ALPHA to V4L2_CID_ALPHA_COMPONENT, - the documentation improvements. Sylwester Nawrocki (2): v4l: Add new alpha component control s5p-fimc: Add support for alpha component configuration Documentation/DocBook/media/v4l/compat.xml | 11 Documentation/DocBook/media/v4l/controls.xml | 25 +++-- .../DocBook/media/v4l/pixfmt-packed-rgb.xml|7 ++- drivers/media/video/s5p-fimc/fimc-capture.c|4 ++ drivers/media/video/s5p-fimc/fimc-core.c | 49 -- drivers/media/video/s5p-fimc/fimc-core.h | 13 - drivers/media/video/s5p-fimc/fimc-reg.c| 53 +++- drivers/media/video/s5p-fimc/regs-fimc.h |5 ++ drivers/media/video/v4l2-ctrls.c |7 +++ include/linux/videodev2.h |6 +- 10 files changed, 150 insertions(+), 30 deletions(-) -- Regards, Sylwester Nawrocki Samsung Poland R&D Center -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 25-11-2011 12:41, Andreas Oberritter escreveu: > On 25.11.2011 14:48, Mauro Carvalho Chehab wrote: >> If your complain is about the removal of audio.h, video.h > > We're back on topic, thank you! > >> and osd.h, then my proposal is >> to keep it there, writing a text that they are part of a deprecated API, > > That's exactly what I proposed. Well, you shouldn't write "deprecated", > because it's not. Just explain - inside this text - when V4L2 should be > preferred over DVB. It is deprecated, as the API is not growing to fulfill today's needs, and no patches adding new stuff to it to it will be accepted anymore. >> but keeping >> the rest of the patches > > Which ones? V4L2, ivtv and DocBook patches. >> and not accepting anymore any submission using them > > Why? First you complain about missing users and then don't want to allow > any new ones. I didn't complain about missing users. What I've said is that, between a one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze the one-user API and mark it as deprecated. Also, today's needs are properly already covered by V4L/ALSA/MC/subdev. It is easier to add what's missing there for DVB than to work the other way around, and deprecate V4L2/ALSA/MC/subdev. >> , removing >> the ioctl's that aren't used by av7110 from them. > > That's just stupid. I can easily provide a list of used and valuable > ioctls, which need to remain present in order to not break userspace > applications. Those ioctl's aren't used by any Kernel driver, and not even documented. So, why to keep/maintain them? > Btw.: It's not easy to submit a driver for a SoC. Even if you are > legally allowed to do it, you have to first merge and maintain the board > support code before even thinking about multimedia. Yes, I know that there's a long road for SoC drivers addition. Fortunately, several vendors are now working to put their stuff upstream. I heard that there are some upcoming changes intended to simplify it a little bit, trying to make the architecture a little more generic, and put board-specific configuration on userspace. I dunno the details. 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
Re: PROBLEM: EHCI disconnects DVB & HDD
On Fri, 25 Nov 2011, Johann Klammer wrote: > When using a DVB-T Dongle and an external HDD simultaneously, EHCI > almost always disconnects. > > When tuning, it works for some time, but after a while, probably > triggered by disk activity > the dmesg log fills up with disk errors and failed i2c writes. The > devices disconnect and the mountpoint gets lost. > Attempting a simple 'ls /mnt/rec' fails with 'input/ouput error'. The > kernel log sometimes reports > the khubd task hanging. As soon as the dvb software gets shut down(at > that point DVB doesn't work either), > the devices get rediscovered as low speed devices and work again after > umount/mount and restart of software. > But it's rather slow from there on. This is probably a low-level hardware error. Interference between the two ports of some kind. > usbdump.mon: On request. usbmon output for the whole host controller > during the event. I can mail this, but it's rather large and the mailing > list won't accept the message. Can you put the usbmon trace on a web server like pastebin.com? Alan Stern -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Friday, November 25, 2011 16:18:52 Mauro Carvalho Chehab wrote: > The V4L2 API complements the ALSA API. Audio streaming, audio format > negotiation > etc are via the ALSA API. > > > Can you control pass-through of digital audio to SPDIF for example? Can > > you control which decoder should be the master when synchronizing AV? > > Patches for that are being proposed and should be merged soon. They are part > of the set of patches under discussion with ALSA people, as part of the Media > Controller API. Can you provide a link to those patches? I haven't seen anything cross-posted to linux-media. 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Friday, November 25, 2011 14:48:02 Mauro Carvalho Chehab wrote: > Em 25-11-2011 10:00, Andreas Oberritter escreveu: > > On 24.11.2011 19:47, Mauro Carvalho Chehab wrote: > >> Em 24-11-2011 16:13, Manu Abraham escreveu: > >>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab > >>> wrote: > Em 24-11-2011 16:01, Manu Abraham escreveu: > > On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil > > wrote: > >> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: > >>> Don't break existing Userspace APIs for no reason! It's OK to add the > >>> new API, but - pretty please - don't just blindly remove audio.h and > >>> video.h. They are in use since many years by av7110, out-of-tree > >>> drivers > >>> *and more importantly* by applications. Yes, I know, you'd like to see > >>> those out-of-tree drivers merged, but it isn't possible for many > >>> reasons. And even if they were merged, you'd say "Port them and your > >>> apps to V4L". No! That's not an option. > >> > >> I'm not breaking anything. All apps will still work. > >> > >> One option (and it depends on whether people like it or not) is to have > >> audio.h, video.h and osd.h just include av7110.h and add a #warning > >> that these headers need to be replaced by the new av7110.h. > > > > > > That won't work with other non av7110 hardware. > > There isn't any non-av7110 driver using it at the Kernel. Anyway, we can > put > a warning at the existing headers as-is, for now, putting them to be > removed > for a new kernel version, like 3.4. > >>> > >>> > >>> No, that's not an option. The to-be merged saa716x driver depends on it. > >> > >> If the driver is not merged yet, it can be changed. > >> > >>> A DVB alone device need not depend V4L2 for it's operation. > >> > >> Why not? DVB drivers with IR should implement the input/event/IR API. DVB > >> drivers with net > >> should implement the Linux Network API. > > > > DVB doesn't specify IR. There's no such thing like a DVB IR device. > > > > IP over DVB is implemented transparently. No driver needs to do anything > > but register its device's MAC address, therefore no driver implements > > the Linux Network API. > > > >> There is nothing wrong on using the ALSA API for audio and the V4L2 API > >> for video, > >> as both API fits the needs for decoding audio and video streams, and new > >> features > >> could be added there when needed. > > > > Yes. There's nothing wrong with it and I'm not complaining. I don't care > > about the implementation of the API in ivtv either. Just don't remove > > the API from dvb-core, period. > > > >> Duplicated API's that become legacy are removed with time. Just to mention > >> two > >> notable cases, this happened with the old audio stack (OSS), with the old > >> Wireless > >> stack. > > > > I can still use iwconfig and linux/wireless.h is still available on my > > system. > > Yes, but both iwconfig and the API changed. > > > ALSA still provides OSS emulation and the real OSS stack was marked > > deprecated but still present for ages. > > OSS driver submission stopped years ago. I remember it clearly as they denied > cx88-oss > driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were > dropped in 2007[1] > in favor of the alsa drivers. The only hardware that are still there at OSS > are the > legacy ones that probably no alsa developer has anymore. > > [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread > > > In contrast, you want to remove a > > stable API and introduce a new *completely untested* API between 3.3 and > > 3.4. > > Please read the patches again. The API for the devices are still there: > any binary compiled for older kernels will still work with av7110 and ivtv. > With the patches applied, the only difference is that the header file has > renamed, as they were moved to device-specific headers. > > It should be noticed that, while both av7110 and ivtv uses the same ioctl's, > av7110 > creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in > practice, > each driver has a different API. > > There are no plans to remove the API for av7110. > > As discussed on this thread, it seems that the agreed plans for the ivtv API > is to put > it into the standard kernel procedure to get rid of legacy API. That means > that the API > will be there for a few kernel versions. > > Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, > the first > API removal will happen in about 18 months from now (assuming about 2 months > per kernel > version). > > >> Do you have any issues that needs to be addressed by the V4L2 API for it > >> to fit > >> on your needs? > > > > I don't want to be forced to use the V4L2 API for no reason and no gain. > > As already explained on the other email, there are gains on using it, like > the suppo
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 25-11-2011 10:55, Andreas Oberritter escreveu: > On 25.11.2011 03:44, Mauro Carvalho Chehab wrote: >> Em 24-11-2011 23:09, Andreas Oberritter escreveu: >>> On 24.11.2011 19:25, Mauro Carvalho Chehab wrote: Em 24-11-2011 16:07, Andreas Oberritter escreveu: > On 24.11.2011 18:58, Mauro Carvalho Chehab wrote: >> Em 24-11-2011 15:51, Andreas Oberritter escreveu: >>> >>> You're encouraging people to do their own stuff instead of using and >>> contributing to a common API? >> >> Not at all, but this is what happens when drivers are out-of-tree. >> The only way to avoid it to happen is to merge the drivers upstream. > > Well, you're right. But only because you artificially made it the only > way to contribute to the API. > >>> Anyway, you're talking about the DVB API as a whole, which of course >>> diverges a little bit from upstream in every implementation, because >>> patches to enhance the API are generally rejected if no in-kernel driver >>> uses the new function/flag/whatever at the time of its introduction. I >>> would have submitted many more API enhancements in the past, if you >>> wouldn't force that strict policy. Instead I usually have to wait until >>> another developer does the same job and then merge our work. >> >> There are no restrictions for you to merge your API enhancements with your >> drivers. > > I guess you're misunderstanding. I don't need to merge *my* enhancements > with *my* drivers. I need to merge upstream API changes with my local > API changes, whenever they are done, i.e. when a device appears which > has a new feature for which I already have created an API extension. See > DVB-T2 as an example: I had the API definition ready and tested about a > year before the first public driver appeared. But I couldn't merge it > upstream without submitting a driver. The result of course is that > everybody else who wanted to develop a DVB-T2 driver during that period > of time needed to create his own API, which IMO is worse than having a > new API (well, two or three #defines or additions to enums) without > in-kernel users. You're free to submit API enhancements patches to the ML. I will only be merged after having some kernel driver using it. The thing with kernel API's is that they should be there for a long period (well, an API that nobody uses inside the kernel can be changed anytime, but still people complain about changing that). An API without a public implementation can't prove its value for the reviewers. >>> On the other hand, S2API was merged upstream with many unused "DTV_xxx" >>> commands and unused structs in the public header, being incomplete at >>> the same time (e.g. missing DiSEqC support and signal quality >>> measurements functions). >> >> Yes, this was a big mistake. It should never happen again. On that time, >> I trusted that the developer that proposed S2API would provide us both API >> documentation and the missing features, as promised, with unfortunately >> didn't happen. >> >> This is one more reason for me to not accept anymore patches that adds >> incomplete >> stuff at the Kernel API's: a new API patch series now needs to provide: >>- API bits; >>- Documentation; >>- driver using it. >> >> This is the only way to be sure that everything is all set, and to warrant >> that >> other drivers using the API will behave like the first one that added it. > > It does not warrant anything, because both drivers and APIs do contain > bugs and oversights, and first implementations are usually worst. You > can't foresee the future, so APIs will eventually evolve, no matter > whether submitted together with a driver or without. Reviewers work better when they can actually look on an implementation for the API. So, keeping the in-kernel unused ioctl's don't bring any real benefit, as vendors can still do their forks, and applications designed to work with those hardware need to support the vendor's stack. >>> >>> Can you please list all unused ioctls? As you know, av7110 uses some of >>> them and Manu is currently developing another open source driver using >>> the audio and video APIs. Please don't pretend that all ioctls are >>> unused to justify a removal of the whole API. >> >> a make htmldocs will list what API calls aren't documented: >> >> Error: no ID for constraint linkend: AUDIO_GET_PTS. >> Error: no ID for constraint linkend: AUDIO_BILINGUAL_CHANNEL_SELECT. >> Error: no ID for constraint linkend: CA_RESET. >> Error: no ID for constraint linkend: CA_GET_CAP. >> Error: no ID for constraint linkend: CA_GET_SLOT_INFO. >> Error: no ID for constraint linkend: CA_GET_DESCR_INFO. >> Error: no ID for constraint linkend: CA_GET_MSG. >> Error: no ID for constraint linkend: CA_SEND_MSG. >> Error: no ID for constraint linkend: CA_SET_DESCR. >> Error: no ID for constraint linkend: CA_SET_PID. >> Error: no ID for constraint linkend: DMX_GET_PES_PIDS. >> Error: no ID for constraint linkend: DMX_GET_CAPS.
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On 25.11.2011 14:48, Mauro Carvalho Chehab wrote: > If your complain is about the removal of audio.h, video.h We're back on topic, thank you! > and osd.h, then my proposal is > to keep it there, writing a text that they are part of a deprecated API, That's exactly what I proposed. Well, you shouldn't write "deprecated", because it's not. Just explain - inside this text - when V4L2 should be preferred over DVB. > but keeping > the rest of the patches Which ones? > and not accepting anymore any submission using them Why? First you complain about missing users and then don't want to allow any new ones. >, removing > the ioctl's that aren't used by av7110 from them. That's just stupid. I can easily provide a list of used and valuable ioctls, which need to remain present in order to not break userspace applications. Btw.: It's not easy to submit a driver for a SoC. Even if you are legally allowed to do it, you have to first merge and maintain the board support code before even thinking about multimedia. Regards, Andreas -- 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: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal wrote: > This is the first step in defining a dma buffer sharing mechanism. > > A new buffer object dma_buf is added, with operations and API to allow easy > sharing of this buffer object across devices. > > The framework allows: > - a new buffer-object to be created with fixed size. > - different devices to 'attach' themselves to this buffer, to facilitate > backing storage negotiation, using dma_buf_attach() API. > - association of a file pointer with each user-buffer and associated > allocator-defined operations on that buffer. This operation is called the > 'export' operation. > - this exported buffer-object to be shared with the other entity by asking for > its 'file-descriptor (fd)', and sharing the fd across. > - a received fd to get the buffer object back, where it can be accessed using > the associated exporter-defined operations. > - the exporter and user to share the scatterlist using get_scatterlist and > put_scatterlist operations. > > Atleast one 'attach()' call is required to be made prior to calling the > get_scatterlist() operation. > > Couple of building blocks in get_scatterlist() are added to ease introduction > of sync'ing across exporter and users, and late allocation by the exporter. > > mmap() file operation is provided for the associated 'fd', as wrapper over the > optional allocator defined mmap(), to be used by devices that might need one. > > More details are there in the documentation patch. > Some questions, I've started playing around with using this framework to do buffer sharing between DRM devices, Why struct scatterlist and not struct sg_table? it seems like I really want to use an sg_table, I'm not convinced fd's are really useful over just some idr allocated handle, so far I'm just returning the "fd" to userspace as a handle, and passing it back in the other side, so I'm not really sure what an fd wins us here, apart from the mmap thing which I think shouldn't be here anyways. (if fd's do win us more we should probably record that in the docs patch). Dave. -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Fri, Nov 25, 2011 at 7:18 PM, Mauro Carvalho Chehab wrote: > Em 25-11-2011 10:00, Andreas Oberritter escreveu: >> On 24.11.2011 19:47, Mauro Carvalho Chehab wrote: >>> Em 24-11-2011 16:13, Manu Abraham escreveu: On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab wrote: > Em 24-11-2011 16:01, Manu Abraham escreveu: >> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil >> wrote: >>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: Don't break existing Userspace APIs for no reason! It's OK to add the new API, but - pretty please - don't just blindly remove audio.h and video.h. They are in use since many years by av7110, out-of-tree drivers *and more importantly* by applications. Yes, I know, you'd like to see those out-of-tree drivers merged, but it isn't possible for many reasons. And even if they were merged, you'd say "Port them and your apps to V4L". No! That's not an option. >>> >>> I'm not breaking anything. All apps will still work. >>> >>> One option (and it depends on whether people like it or not) is to have >>> audio.h, video.h and osd.h just include av7110.h and add a #warning >>> that these headers need to be replaced by the new av7110.h. >> >> >> That won't work with other non av7110 hardware. > > There isn't any non-av7110 driver using it at the Kernel. Anyway, we can > put > a warning at the existing headers as-is, for now, putting them to be > removed > for a new kernel version, like 3.4. No, that's not an option. The to-be merged saa716x driver depends on it. >>> >>> If the driver is not merged yet, it can be changed. >>> A DVB alone device need not depend V4L2 for it's operation. >>> >>> Why not? DVB drivers with IR should implement the input/event/IR API. DVB >>> drivers with net >>> should implement the Linux Network API. >> >> DVB doesn't specify IR. There's no such thing like a DVB IR device. >> >> IP over DVB is implemented transparently. No driver needs to do anything >> but register its device's MAC address, therefore no driver implements >> the Linux Network API. >> >>> There is nothing wrong on using the ALSA API for audio and the V4L2 API for >>> video, >>> as both API fits the needs for decoding audio and video streams, and new >>> features >>> could be added there when needed. >> >> Yes. There's nothing wrong with it and I'm not complaining. I don't care >> about the implementation of the API in ivtv either. Just don't remove >> the API from dvb-core, period. >> >>> Duplicated API's that become legacy are removed with time. Just to mention >>> two >>> notable cases, this happened with the old audio stack (OSS), with the old >>> Wireless >>> stack. >> >> I can still use iwconfig and linux/wireless.h is still available on my >> system. > > Yes, but both iwconfig and the API changed. > >> ALSA still provides OSS emulation and the real OSS stack was marked >> deprecated but still present for ages. > > OSS driver submission stopped years ago. I remember it clearly as they denied > cx88-oss > driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were > dropped in 2007[1] > in favor of the alsa drivers. The only hardware that are still there at OSS > are the > legacy ones that probably no alsa developer has anymore. > > [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread > >> In contrast, you want to remove a >> stable API and introduce a new *completely untested* API between 3.3 and >> 3.4. > > Please read the patches again. The API for the devices are still there: > any binary compiled for older kernels will still work with av7110 and ivtv. > With the patches applied, the only difference is that the header file has > renamed, as they were moved to device-specific headers. > > It should be noticed that, while both av7110 and ivtv uses the same ioctl's, > av7110 > creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in > practice, > each driver has a different API. > > There are no plans to remove the API for av7110. > > As discussed on this thread, it seems that the agreed plans for the ivtv API > is to put > it into the standard kernel procedure to get rid of legacy API. That means > that the API > will be there for a few kernel versions. > > Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, > the first > API removal will happen in about 18 months from now (assuming about 2 months > per kernel > version). > >>> Do you have any issues that needs to be addressed by the V4L2 API for it to >>> fit >>> on your needs? >> >> I don't want to be forced to use the V4L2 API for no reason and no gain. > > As already explained on the other email, there are gains on using it, like > the support > for other types of encoding, the pipeline setup, sub-device control, shared > buffer interface > with
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 25-11-2011 10:00, Andreas Oberritter escreveu: > On 24.11.2011 19:47, Mauro Carvalho Chehab wrote: >> Em 24-11-2011 16:13, Manu Abraham escreveu: >>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab >>> wrote: Em 24-11-2011 16:01, Manu Abraham escreveu: > On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil wrote: >> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >>> Don't break existing Userspace APIs for no reason! It's OK to add the >>> new API, but - pretty please - don't just blindly remove audio.h and >>> video.h. They are in use since many years by av7110, out-of-tree drivers >>> *and more importantly* by applications. Yes, I know, you'd like to see >>> those out-of-tree drivers merged, but it isn't possible for many >>> reasons. And even if they were merged, you'd say "Port them and your >>> apps to V4L". No! That's not an option. >> >> I'm not breaking anything. All apps will still work. >> >> One option (and it depends on whether people like it or not) is to have >> audio.h, video.h and osd.h just include av7110.h and add a #warning >> that these headers need to be replaced by the new av7110.h. > > > That won't work with other non av7110 hardware. There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put a warning at the existing headers as-is, for now, putting them to be removed for a new kernel version, like 3.4. >>> >>> >>> No, that's not an option. The to-be merged saa716x driver depends on it. >> >> If the driver is not merged yet, it can be changed. >> >>> A DVB alone device need not depend V4L2 for it's operation. >> >> Why not? DVB drivers with IR should implement the input/event/IR API. DVB >> drivers with net >> should implement the Linux Network API. > > DVB doesn't specify IR. There's no such thing like a DVB IR device. > > IP over DVB is implemented transparently. No driver needs to do anything > but register its device's MAC address, therefore no driver implements > the Linux Network API. > >> There is nothing wrong on using the ALSA API for audio and the V4L2 API for >> video, >> as both API fits the needs for decoding audio and video streams, and new >> features >> could be added there when needed. > > Yes. There's nothing wrong with it and I'm not complaining. I don't care > about the implementation of the API in ivtv either. Just don't remove > the API from dvb-core, period. > >> Duplicated API's that become legacy are removed with time. Just to mention >> two >> notable cases, this happened with the old audio stack (OSS), with the old >> Wireless >> stack. > > I can still use iwconfig and linux/wireless.h is still available on my > system. Yes, but both iwconfig and the API changed. > ALSA still provides OSS emulation and the real OSS stack was marked > deprecated but still present for ages. OSS driver submission stopped years ago. I remember it clearly as they denied cx88-oss driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were dropped in 2007[1] in favor of the alsa drivers. The only hardware that are still there at OSS are the legacy ones that probably no alsa developer has anymore. [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread > In contrast, you want to remove a > stable API and introduce a new *completely untested* API between 3.3 and > 3.4. Please read the patches again. The API for the devices are still there: any binary compiled for older kernels will still work with av7110 and ivtv. With the patches applied, the only difference is that the header file has renamed, as they were moved to device-specific headers. It should be noticed that, while both av7110 and ivtv uses the same ioctl's, av7110 creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in practice, each driver has a different API. There are no plans to remove the API for av7110. As discussed on this thread, it seems that the agreed plans for the ivtv API is to put it into the standard kernel procedure to get rid of legacy API. That means that the API will be there for a few kernel versions. Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, the first API removal will happen in about 18 months from now (assuming about 2 months per kernel version). >> Do you have any issues that needs to be addressed by the V4L2 API for it to >> fit >> on your needs? > > I don't want to be forced to use the V4L2 API for no reason and no gain. As already explained on the other email, there are gains on using it, like the support for other types of encoding, the pipeline setup, sub-device control, shared buffer interface with GPU, proper support for SoC, etc. Also, currently, just one device uses it (av7110). I don't think that the chipset is still manufactured. At least Google didn't help finding anything: http://www.google.com/search
Re: gnutv should not ignore SIGPIPE
On 11-11-25 08:34 AM, Rémi Denis-Courmont wrote: > > Anyway, the problem is not so mucgh ignoring SIGPIPE as ignoring EPIPE write > errors. Yes, that is the other way to skin that cat I suppose. What's the best/proper way to go about getting this fixed? Cheers, b. signature.asc Description: OpenPGP digital signature
Re: gnutv should not ignore SIGPIPE
Le vendredi 25 novembre 2011 15:05:44 Brian J. Murrell, vous avez écrit : > Is there a good reason I am not seeing why gnutv should be ignoring > SIGPIPE? In general, ignoring SIGPIPE is the easiest way to protect against denial of service when a peer connection socket is hung up remotely. MSG_NOSIGNAL is a more modern alternative. Anyway, the problem is not so mucgh ignoring SIGPIPE as ignoring EPIPE write errors. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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/RFC 1/2] v4l: Add a global color alpha control
Hi Sylwester, On Friday 25 November 2011 14:24:47 Sylwester Nawrocki wrote: > On 11/25/2011 01:57 PM, Laurent Pinchart wrote: > > On Thursday 24 November 2011 16:53:12 Sylwester Nawrocki wrote: > >> On 11/24/2011 03:00 PM, Laurent Pinchart wrote: > >>> On Thursday 24 November 2011 13:22:10 Hans Verkuil wrote: > On Thursday, November 24, 2011 13:06:09 Laurent Pinchart wrote: > > On Thursday 24 November 2011 12:49:00 Hans Verkuil wrote: > >> On Thursday, November 24, 2011 12:39:54 Sylwester Nawrocki wrote: > >>> On 11/24/2011 12:09 PM, Laurent Pinchart wrote: > On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: > > On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: > Well, if that's the case, then we already have an API for that > (http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-window, field > global_alpha). > > It was my understanding that this is used with a mem2mem device where > you just want to fill in the alpha channel to the desired value. It's > not used inside the device at all (that happens later in the > pipeline). > >>> > >>> OK, now I understand. Maybe the documentation should describe this a > >>> bit more explicitly ? > >> > >> I've modified the control description so now it is: > >> > >> V4L2_CID_ALPHA_COMPONENT > >> integer > > > > What about clarifying it further with something like > > > > "When a mem-to-mem device produces a frame format that includes an alpha > > component (e.g. _packed RGB image_ formats), the alpha value is not > > defined by the mem-to-mem input data. This control lets you select the > > alpha component value of all pixels in such a case. It is applicable to > > any pixel format that contains an alpha component." > > Thanks for the help. Since there are also mem-to-mem devices that account > an input alpha when producing an output frame (e.g. S5P SoC G2D IP block > supports alpha blending), I would change that to: > > > "When a mem-to-mem device produces a frame format that includes an alpha > component (e.g. _packed RGB image_ formats) and the alpha value is not > defined by the mem-to-mem input data this control lets you select the > alpha component value of all pixels. It is applicable to any pixel format > that contains an alpha component." That sounds good to me. > > OR > > "When data format of a frame produced by a mem-to-mem device includes an > alpha component (e.g. _packed RGB image_ formats) and the alpha value is > not defined by the mem-to-mem input data this control lets you select the > alpha component value of all pixels. The control is applicable to any > pixel format that contains an alpha component." > > How do you think ? > > >> And the part below Table 2.6 > >> > >> Bit 7 is the most significant bit. The value of a = alpha bits is > >> undefined when reading from the driver, ignored when writing to the > >> driver, except when alpha blending has been negotiated for a Video > >> Overlay or Video Output Overlay or when alpha component has been > >> configured for a Video Capture by means of V4L2_CID_ALPHA_COMPONENT > >> control. -- 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: [PATCH/RFC 1/2] v4l: Add a global color alpha control
Hi Laurent, On 11/25/2011 01:57 PM, Laurent Pinchart wrote: > On Thursday 24 November 2011 16:53:12 Sylwester Nawrocki wrote: >> On 11/24/2011 03:00 PM, Laurent Pinchart wrote: >>> On Thursday 24 November 2011 13:22:10 Hans Verkuil wrote: On Thursday, November 24, 2011 13:06:09 Laurent Pinchart wrote: > On Thursday 24 November 2011 12:49:00 Hans Verkuil wrote: >> On Thursday, November 24, 2011 12:39:54 Sylwester Nawrocki wrote: >>> On 11/24/2011 12:09 PM, Laurent Pinchart wrote: On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: > On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: Well, if that's the case, then we already have an API for that (http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-window, field global_alpha). It was my understanding that this is used with a mem2mem device where you just want to fill in the alpha channel to the desired value. It's not used inside the device at all (that happens later in the pipeline). >>> >>> OK, now I understand. Maybe the documentation should describe this a bit >>> more explicitly ? >> >> I've modified the control description so now it is: >> >> V4L2_CID_ALPHA_COMPONENT >> integer >> > > What about clarifying it further with something like > > "When a mem-to-mem device produces a frame format that includes an alpha > component (e.g. _packed RGB image_ formats), the alpha value is not defined > by > the mem-to-mem input data. This control lets you select the alpha component > value of all pixels in such a case. It is applicable to any pixel format that > contains an alpha component." Thanks for the help. Since there are also mem-to-mem devices that account an input alpha when producing an output frame (e.g. S5P SoC G2D IP block supports alpha blending), I would change that to: "When a mem-to-mem device produces a frame format that includes an alpha component (e.g. _packed RGB image_ formats) and the alpha value is not defined by the mem-to-mem input data this control lets you select the alpha component value of all pixels. It is applicable to any pixel format that contains an alpha component." OR "When data format of a frame produced by a mem-to-mem device includes an alpha component (e.g. _packed RGB image_ formats) and the alpha value is not defined by the mem-to-mem input data this control lets you select the alpha component value of all pixels. The control is applicable to any pixel format that contains an alpha component." How do you think ? > >> And the part below Table 2.6 >> >> Bit 7 is the most significant bit. The value of a = alpha bits is undefined >> when reading from the driver, ignored when writing to the driver, except >> when alpha blending has been negotiated for a Video Overlay or Video >> Output Overlay or when alpha component has been configured for a Video >> Capture by means of V4L2_CID_ALPHA_COMPONENT control. -- Thanks, 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
gnutv should not ignore SIGPIPE
Currently, (at least in rev. 1355) gnutv is ignoring SIGPIPE: signal(SIGPIPE, SIG_IGN); This means though that if it is used as such: gnutv -out stdout -channels /home/mythtv/channels.conf.found 91-472 | mplayer - It will not terminate as it should when/if it's consumer (mplayer in the above example) is killed. Is there a good reason I am not seeing why gnutv should be ignoring SIGPIPE? Cheers, b. signature.asc Description: OpenPGP digital signature
Re: [RFC/PATCH 1/3] v4l: Introduce integer menu controls
Hi Sakari,
On Friday 25 November 2011 13:56:50 Sakari Ailus wrote:
> On Fri, Nov 25, 2011 at 01:43:12PM +0100, Laurent Pinchart wrote:
> > On Friday 25 November 2011 13:02:02 Sakari Ailus wrote:
> > > On Fri, Nov 25, 2011 at 11:28:46AM +0100, Laurent Pinchart wrote:
> > > > On Thursday 24 November 2011 17:12:50 Sakari Ailus wrote:
> > > ...
> > >
> > > > > @@ -1440,12 +1458,13 @@ struct v4l2_ctrl
> > > > > *v4l2_ctrl_new_std_menu(struct v4l2_ctrl_handler *hdl, u32 flags;
> > > > >
> > > > > v4l2_ctrl_fill(id, &name, &type, &min, &max, &step, &def,
> > > > > &flags);
> > > > >
> > > > > - if (type != V4L2_CTRL_TYPE_MENU) {
> > > > > + if (type != V4L2_CTRL_TYPE_MENU
> > > > > + && type != V4L2_CTRL_TYPE_INTEGER_MENU) {
> > > > >
> > > > > handler_set_err(hdl, -EINVAL);
> > > > > return NULL;
> > > > >
> > > > > }
> > > > > return v4l2_ctrl_new(hdl, ops, id, name, type,
> > > > >
> > > > > - 0, max, mask, def, flags, qmenu,
> > > > > NULL);
> > > > > + 0, max, mask, def, flags, qmenu, NULL,
> > > > > NULL);
> > > >
> > > > You pass NULL to the v4l2_ctrl_new() qmenu_int argument, which will
> > > > make the function fail for integer menu controls. Do you expect
> > > > standard integer menu controls to share a list of values ? If not,
> > > > what about modifying v4l2_ctrl_new_std_menu() to take a list of
> > > > values (or alternatively forbidding the function from being used for
> > > > integer menu controls) ?
> > >
> > > We currently have no integer menu controls, let alone one which would
> > > have a set of standard values. We need same functionality as in
> > > v4l2_ctrl_get_menu() for integer menus when we add the first
> > > standardised integer menu control. I think it could be added at that
> > > time, or I could implement a v4l2_ctrl_get_integer_menu() which would
> > > do nothing.
> > >
> > > What do you think?
> >
> > I was just wondering if we will ever have a standard menu control with
> > standard integer items. If that never happens, v4l2_ctrl_new_std_menu()
> > needs to either take a qmenu_int array, or reject integer menu controls
> > completely. I would thus delay adding the V4L2_CTRL_TYPE_INTEGER_MENU
> > check to the function as it wouldn't work anyway (or, alternatively, we
> > would add the qmenu_int argument now).
>
> Either one, yes. I think I'll add a separate patch adding standard integer
> menus and remove the check from this one.
>
> There'll definitely be a need for them. For example, there are bit rate
> menus in the standard menu type controls that ideally should be integers.
Sure, but I doubt that the bit rates themselves will be standard.
> We won't change them but there will be others. Or I'd be very surprised if
> there were not!
--
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: [PATCH/RFC 1/2] v4l: Add a global color alpha control
Hi Sylwester, On Thursday 24 November 2011 16:53:12 Sylwester Nawrocki wrote: > On 11/24/2011 03:00 PM, Laurent Pinchart wrote: > > On Thursday 24 November 2011 13:22:10 Hans Verkuil wrote: > >> On Thursday, November 24, 2011 13:06:09 Laurent Pinchart wrote: > >>> On Thursday 24 November 2011 12:49:00 Hans Verkuil wrote: > On Thursday, November 24, 2011 12:39:54 Sylwester Nawrocki wrote: > > On 11/24/2011 12:09 PM, Laurent Pinchart wrote: > >> On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: > >>> On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: > >> Well, if that's the case, then we already have an API for that > >> (http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-window, field > >> global_alpha). > >> > >> It was my understanding that this is used with a mem2mem device where > >> you just want to fill in the alpha channel to the desired value. It's > >> not used inside the device at all (that happens later in the pipeline). > > > > OK, now I understand. Maybe the documentation should describe this a bit > > more explicitly ? > > I've modified the control description so now it is: > > V4L2_CID_ALPHA_COMPONENT > integer > What about clarifying it further with something like "When a mem-to-mem device produces a frame format that includes an alpha component (e.g. _packed RGB image_ formats), the alpha value is not defined by the mem-to-mem input data. This control lets you select the alpha component value of all pixels in such a case. It is applicable to any pixel format that contains an alpha component." > And the part below Table 2.6 > > Bit 7 is the most significant bit. The value of a = alpha bits is undefined > when reading from the driver, ignored when writing to the driver, except > when alpha blending has been negotiated for a Video Overlay or Video > Output Overlay or when alpha component has been configured for a Video > Capture by means of V4L2_CID_ALPHA_COMPONENT control. -- 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 1/3] v4l: Introduce integer menu controls
On Fri, Nov 25, 2011 at 01:43:12PM +0100, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Friday 25 November 2011 13:02:02 Sakari Ailus wrote:
> > On Fri, Nov 25, 2011 at 11:28:46AM +0100, Laurent Pinchart wrote:
> > > On Thursday 24 November 2011 17:12:50 Sakari Ailus wrote:
> > ...
> >
> > > > @@ -1440,12 +1458,13 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct
> > > > v4l2_ctrl_handler *hdl, u32 flags;
> > > >
> > > > v4l2_ctrl_fill(id, &name, &type, &min, &max, &step, &def,
> > > > &flags);
> > > >
> > > > - if (type != V4L2_CTRL_TYPE_MENU) {
> > > > + if (type != V4L2_CTRL_TYPE_MENU
> > > > + && type != V4L2_CTRL_TYPE_INTEGER_MENU) {
> > > >
> > > > handler_set_err(hdl, -EINVAL);
> > > > return NULL;
> > > >
> > > > }
> > > > return v4l2_ctrl_new(hdl, ops, id, name, type,
> > > >
> > > > - 0, max, mask, def, flags, qmenu,
> > > > NULL);
> > > > +0, max, mask, def, flags, qmenu, NULL,
> > > > NULL);
> > >
> > > You pass NULL to the v4l2_ctrl_new() qmenu_int argument, which will make
> > > the function fail for integer menu controls. Do you expect standard
> > > integer menu controls to share a list of values ? If not, what about
> > > modifying v4l2_ctrl_new_std_menu() to take a list of values (or
> > > alternatively forbidding the function from being used for integer menu
> > > controls) ?
> >
> > We currently have no integer menu controls, let alone one which would have
> > a set of standard values. We need same functionality as in
> > v4l2_ctrl_get_menu() for integer menus when we add the first standardised
> > integer menu control. I think it could be added at that time, or I could
> > implement a v4l2_ctrl_get_integer_menu() which would do nothing.
> >
> > What do you think?
>
> I was just wondering if we will ever have a standard menu control with
> standard integer items. If that never happens, v4l2_ctrl_new_std_menu() needs
> to either take a qmenu_int array, or reject integer menu controls completely.
> I would thus delay adding the V4L2_CTRL_TYPE_INTEGER_MENU check to the
> function as it wouldn't work anyway (or, alternatively, we would add the
> qmenu_int argument now).
Either one, yes. I think I'll add a separate patch adding standard integer
menus and remove the check from this one.
There'll definitely be a need for them. For example, there are bit rate
menus in the standard menu type controls that ideally should be integers. We
won't change them but there will be others. Or I'd be very surprised if
there were not!
Cheers,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On 25.11.2011 03:44, Mauro Carvalho Chehab wrote: > Em 24-11-2011 23:09, Andreas Oberritter escreveu: >> On 24.11.2011 19:25, Mauro Carvalho Chehab wrote: >>> Em 24-11-2011 16:07, Andreas Oberritter escreveu: On 24.11.2011 18:58, Mauro Carvalho Chehab wrote: > Em 24-11-2011 15:51, Andreas Oberritter escreveu: >> >> You're encouraging people to do their own stuff instead of using and >> contributing to a common API? > > Not at all, but this is what happens when drivers are out-of-tree. > The only way to avoid it to happen is to merge the drivers upstream. Well, you're right. But only because you artificially made it the only way to contribute to the API. >> Anyway, you're talking about the DVB API as a whole, which of course >> diverges a little bit from upstream in every implementation, because >> patches to enhance the API are generally rejected if no in-kernel driver >> uses the new function/flag/whatever at the time of its introduction. I >> would have submitted many more API enhancements in the past, if you >> wouldn't force that strict policy. Instead I usually have to wait until >> another developer does the same job and then merge our work. > > There are no restrictions for you to merge your API enhancements with your > drivers. I guess you're misunderstanding. I don't need to merge *my* enhancements with *my* drivers. I need to merge upstream API changes with my local API changes, whenever they are done, i.e. when a device appears which has a new feature for which I already have created an API extension. See DVB-T2 as an example: I had the API definition ready and tested about a year before the first public driver appeared. But I couldn't merge it upstream without submitting a driver. The result of course is that everybody else who wanted to develop a DVB-T2 driver during that period of time needed to create his own API, which IMO is worse than having a new API (well, two or three #defines or additions to enums) without in-kernel users. >> On the other hand, S2API was merged upstream with many unused "DTV_xxx" >> commands and unused structs in the public header, being incomplete at >> the same time (e.g. missing DiSEqC support and signal quality >> measurements functions). > > Yes, this was a big mistake. It should never happen again. On that time, > I trusted that the developer that proposed S2API would provide us both API > documentation and the missing features, as promised, with unfortunately > didn't happen. > > This is one more reason for me to not accept anymore patches that adds > incomplete > stuff at the Kernel API's: a new API patch series now needs to provide: >- API bits; >- Documentation; >- driver using it. > > This is the only way to be sure that everything is all set, and to warrant > that > other drivers using the API will behave like the first one that added it. It does not warrant anything, because both drivers and APIs do contain bugs and oversights, and first implementations are usually worst. You can't foresee the future, so APIs will eventually evolve, no matter whether submitted together with a driver or without. >>> So, keeping the in-kernel unused ioctl's don't bring any real benefit, as >>> vendors >>> can still do their forks, and applications designed to work with those >>> hardware >>> need to support the vendor's stack. >> >> Can you please list all unused ioctls? As you know, av7110 uses some of >> them and Manu is currently developing another open source driver using >> the audio and video APIs. Please don't pretend that all ioctls are >> unused to justify a removal of the whole API. > > a make htmldocs will list what API calls aren't documented: > > Error: no ID for constraint linkend: AUDIO_GET_PTS. > Error: no ID for constraint linkend: AUDIO_BILINGUAL_CHANNEL_SELECT. > Error: no ID for constraint linkend: CA_RESET. > Error: no ID for constraint linkend: CA_GET_CAP. > Error: no ID for constraint linkend: CA_GET_SLOT_INFO. > Error: no ID for constraint linkend: CA_GET_DESCR_INFO. > Error: no ID for constraint linkend: CA_GET_MSG. > Error: no ID for constraint linkend: CA_SEND_MSG. > Error: no ID for constraint linkend: CA_SET_DESCR. > Error: no ID for constraint linkend: CA_SET_PID. > Error: no ID for constraint linkend: DMX_GET_PES_PIDS. > Error: no ID for constraint linkend: DMX_GET_CAPS. > Error: no ID for constraint linkend: DMX_SET_SOURCE. > Error: no ID for constraint linkend: DMX_ADD_PID. > Error: no ID for constraint linkend: DMX_REMOVE_PID. > Error: no ID for constraint linkend: DTV-ENUM-DELSYS. > Error: no ID for constraint linkend: NET_ADD_IF. > Error: no ID for constraint linkend: NET_REMOVE_IF. > Error: no ID for constraint linkend: NET_GET_IF. > Error: no ID for constraint linkend: VIDEO_GET_SIZE. > Error: no ID for constraint linkend: VIDEO_GET_FRAME_RATE. > Error: no ID for constraint linkend: VIDEO_GET_PTS. > Error: no ID for constraint linkend: VIDEO_GET_FRAME_COUNT. > Error: no ID for constraint linkend:
Re: [RFC/PATCH 1/3] v4l: Introduce integer menu controls
Hi Sakari,
On Friday 25 November 2011 13:02:02 Sakari Ailus wrote:
> On Fri, Nov 25, 2011 at 11:28:46AM +0100, Laurent Pinchart wrote:
> > On Thursday 24 November 2011 17:12:50 Sakari Ailus wrote:
> ...
>
> > > @@ -1440,12 +1458,13 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct
> > > v4l2_ctrl_handler *hdl, u32 flags;
> > >
> > > v4l2_ctrl_fill(id, &name, &type, &min, &max, &step, &def, &flags);
> > >
> > > - if (type != V4L2_CTRL_TYPE_MENU) {
> > > + if (type != V4L2_CTRL_TYPE_MENU
> > > + && type != V4L2_CTRL_TYPE_INTEGER_MENU) {
> > >
> > > handler_set_err(hdl, -EINVAL);
> > > return NULL;
> > >
> > > }
> > > return v4l2_ctrl_new(hdl, ops, id, name, type,
> > >
> > > - 0, max, mask, def, flags, qmenu, NULL);
> > > + 0, max, mask, def, flags, qmenu, NULL, NULL);
> >
> > You pass NULL to the v4l2_ctrl_new() qmenu_int argument, which will make
> > the function fail for integer menu controls. Do you expect standard
> > integer menu controls to share a list of values ? If not, what about
> > modifying v4l2_ctrl_new_std_menu() to take a list of values (or
> > alternatively forbidding the function from being used for integer menu
> > controls) ?
>
> We currently have no integer menu controls, let alone one which would have
> a set of standard values. We need same functionality as in
> v4l2_ctrl_get_menu() for integer menus when we add the first standardised
> integer menu control. I think it could be added at that time, or I could
> implement a v4l2_ctrl_get_integer_menu() which would do nothing.
>
> What do you think?
I was just wondering if we will ever have a standard menu control with
standard integer items. If that never happens, v4l2_ctrl_new_std_menu() needs
to either take a qmenu_int array, or reject integer menu controls completely.
I would thus delay adding the V4L2_CTRL_TYPE_INTEGER_MENU check to the
function as it wouldn't work anyway (or, alternatively, we would add the
qmenu_int argument now).
--
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 2/3] v4l: Document integer menu controls
On Fri, Nov 25, 2011 at 11:30:32AM +0100, Laurent Pinchart wrote: > Hi Sakari, > > Thanks for the patch. Hi Laurent, Thanks for the comments! > On Thursday 24 November 2011 17:12:51 Sakari Ailus wrote: ... > > @@ -292,6 +313,20 @@ the menu items can be enumerated with the > > VIDIOC_QUERYMENU ioctl. > > > > > > + V4L2_CTRL_TYPE_INTEGER_MENU > > + ≥ 0 > > + 1 > > + N-1 > > + > > + The control has a menu of N choices. The names of the > > + menu items can be enumerated with the > > + VIDIOC_QUERYMENU ioctl. This is > > + similar to V4L2_CTRL_TYPE_MENU > > + except that instead of integers, the menu items are > > Do you mean "instead of strings" ? Yes, I do. Will fix this. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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 1/3] v4l: Introduce integer menu controls
On Fri, Nov 25, 2011 at 11:28:46AM +0100, Laurent Pinchart wrote:
> Hi Sakari,
>
> Thanks for the patch.
Hi Laurent,
Thanks for the comments!
> On Thursday 24 November 2011 17:12:50 Sakari Ailus wrote:
...
> > @@ -1440,12 +1458,13 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct
> > v4l2_ctrl_handler *hdl, u32 flags;
> >
> > v4l2_ctrl_fill(id, &name, &type, &min, &max, &step, &def, &flags);
> > - if (type != V4L2_CTRL_TYPE_MENU) {
> > + if (type != V4L2_CTRL_TYPE_MENU
> > + && type != V4L2_CTRL_TYPE_INTEGER_MENU) {
> > handler_set_err(hdl, -EINVAL);
> > return NULL;
> > }
> > return v4l2_ctrl_new(hdl, ops, id, name, type,
> > - 0, max, mask, def, flags, qmenu, NULL);
> > +0, max, mask, def, flags, qmenu, NULL, NULL);
>
> You pass NULL to the v4l2_ctrl_new() qmenu_int argument, which will make the
> function fail for integer menu controls. Do you expect standard integer menu
> controls to share a list of values ? If not, what about modifying
> v4l2_ctrl_new_std_menu() to take a list of values (or alternatively
> forbidding
> the function from being used for integer menu controls) ?
We currently have no integer menu controls, let alone one which would have a
set of standard values. We need same functionality as in
v4l2_ctrl_get_menu() for integer menus when we add the first standardised
integer menu control. I think it could be added at that time, or I could
implement a v4l2_ctrl_get_integer_menu() which would do nothing.
What do you think?
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On 24.11.2011 19:47, Mauro Carvalho Chehab wrote: > Em 24-11-2011 16:13, Manu Abraham escreveu: >> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab >> wrote: >>> Em 24-11-2011 16:01, Manu Abraham escreveu: On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil wrote: > On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >> Don't break existing Userspace APIs for no reason! It's OK to add the >> new API, but - pretty please - don't just blindly remove audio.h and >> video.h. They are in use since many years by av7110, out-of-tree drivers >> *and more importantly* by applications. Yes, I know, you'd like to see >> those out-of-tree drivers merged, but it isn't possible for many >> reasons. And even if they were merged, you'd say "Port them and your >> apps to V4L". No! That's not an option. > > I'm not breaking anything. All apps will still work. > > One option (and it depends on whether people like it or not) is to have > audio.h, video.h and osd.h just include av7110.h and add a #warning > that these headers need to be replaced by the new av7110.h. That won't work with other non av7110 hardware. >>> >>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put >>> a warning at the existing headers as-is, for now, putting them to be removed >>> for a new kernel version, like 3.4. >> >> >> No, that's not an option. The to-be merged saa716x driver depends on it. > > If the driver is not merged yet, it can be changed. > >> A DVB alone device need not depend V4L2 for it's operation. > > Why not? DVB drivers with IR should implement the input/event/IR API. DVB > drivers with net > should implement the Linux Network API. DVB doesn't specify IR. There's no such thing like a DVB IR device. IP over DVB is implemented transparently. No driver needs to do anything but register its device's MAC address, therefore no driver implements the Linux Network API. > There is nothing wrong on using the ALSA API for audio and the V4L2 API for > video, > as both API fits the needs for decoding audio and video streams, and new > features > could be added there when needed. Yes. There's nothing wrong with it and I'm not complaining. I don't care about the implementation of the API in ivtv either. Just don't remove the API from dvb-core, period. > Duplicated API's that become legacy are removed with time. Just to mention two > notable cases, this happened with the old audio stack (OSS), with the old > Wireless > stack. I can still use iwconfig and linux/wireless.h is still available on my system. ALSA still provides OSS emulation and the real OSS stack was marked deprecated but still present for ages. In contrast, you want to remove a stable API and introduce a new *completely untested* API between 3.3 and 3.4. > Do you have any issues that needs to be addressed by the V4L2 API for it to > fit > on your needs? I don't want to be forced to use the V4L2 API for no reason and no gain. >> Also, it doesn't >> make any sense to have device specific headers to be used by an application, >> when drivers share more than one commonality. > > The only in-kernel driver using audio/video/osd is av7110. Once again: Manu is going to submit a new driver soon. You're trying to remove an API that you've never used. The people who use the API want it to stay. Regards, Andreas -- 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 3/3] ivtv: setup per-device caps.
Em 25-11-2011 09:29, Hans Verkuil escreveu:
> On Friday, November 25, 2011 12:00:31 Mauro Carvalho Chehab wrote:
>> Em 22-11-2011 08:05, Hans Verkuil escreveu:
>>> From: Hans Verkuil
>>>
>>> Signed-off-by: Hans Verkuil
>>> ---
>>> drivers/media/video/ivtv/ivtv-driver.h |1 +
>>> drivers/media/video/ivtv/ivtv-ioctl.c |7 +--
>>> drivers/media/video/ivtv/ivtv-streams.c | 14 ++
>>> 3 files changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/media/video/ivtv/ivtv-driver.h
>>> b/drivers/media/video/ivtv/ivtv-driver.h
>>> index 8f9cc17..06b9efd 100644
>>> --- a/drivers/media/video/ivtv/ivtv-driver.h
>>> +++ b/drivers/media/video/ivtv/ivtv-driver.h
>>> @@ -331,6 +331,7 @@ struct ivtv_stream {
>>> struct ivtv *itv; /* for ease of use */
>>> const char *name; /* name of the stream */
>>> int type; /* stream type */
>>> + u32 caps; /* V4L2 capabilities */
>>>
>>> u32 id;
>>> spinlock_t qlock; /* locks access to the queues */
>>> diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c
>>> b/drivers/media/video/ivtv/ivtv-ioctl.c
>>> index ecafa69..6be63e9 100644
>>> --- a/drivers/media/video/ivtv/ivtv-ioctl.c
>>> +++ b/drivers/media/video/ivtv/ivtv-ioctl.c
>>> @@ -752,12 +752,15 @@ static int ivtv_s_register(struct file *file, void
>>> *fh, struct v4l2_dbg_register
>>>
>>> static int ivtv_querycap(struct file *file, void *fh, struct
>>> v4l2_capability *vcap)
>>> {
>>> - struct ivtv *itv = fh2id(fh)->itv;
>>> + struct ivtv_open_id *id = fh2id(file->private_data);
>>> + struct ivtv *itv = id->itv;
>>> + struct ivtv_stream *s = &itv->streams[id->type];
>>>
>>> strlcpy(vcap->driver, IVTV_DRIVER_NAME, sizeof(vcap->driver));
>>> strlcpy(vcap->card, itv->card_name, sizeof(vcap->card));
>>> snprintf(vcap->bus_info, sizeof(vcap->bus_info), "PCI:%s",
>>> pci_name(itv->pdev));
>>> - vcap->capabilities = itv->v4l2_cap; /* capabilities */
>>> + vcap->capabilities = itv->v4l2_cap | V4L2_CAP_DEVICE_CAPS;
>>
>> IMO, the right thing to do here would be:
>>
>> vcap->capabilities = V4L2_CAP_DEVICE_CAPS;
>> for (i = 0; i < ARRAY_SIZE(ivtv_stream_info); i++)
>> vcap->capabilities |= ivtv_stream_info[v4l2_caps];
>
> This won't work actually. Which devices are available depends on more things
> than just that array.
Yes, I suspect so. Yet, a loop like that would still work:
for (i = 0; i < ARRAY_SIZE(ivtv_stream_info); i++)
if (check_if_device_applies(ivtv_stream_info[i]))
vcap->capabilities |= ivtv_stream_info[v4l2_caps];
> It's not something I think needs to change.
I still think that something like the above is better than two separate magic
sets.
OK, it is perhaps an overkill for ivtv, as there aren't any new
features/boards/etc added
there for some time.
>
>> This avoids the risk of future patches adding new device_caps at the
>> devices, but
>> forgetting to update the physical device capabilities.
>>
>> Also, as the initial patches will be used as implementation reference by
>> others,
>> such implementation will be more effective than a "magic" set of features
>> that
>> may or may not match the union of all device capabilities.
>
> I wouldn't use ivtv as a reference implementation (other than for cx18). vivi
> however
> is a very nice reference implementation these days.
Yes, but vivi creates just one device per "physical device". So, the
implementation there is trivial.
>
> As soon as this patch is in I'll also update v4l2-compliance.
>
> Regards,
>
> Hans
>
>>
>>> + vcap->device_caps = s->caps;
>>> return 0;
>>> }
>>>
>>> diff --git a/drivers/media/video/ivtv/ivtv-streams.c
>>> b/drivers/media/video/ivtv/ivtv-streams.c
>>> index e7794dc..4d4ae6e 100644
>>> --- a/drivers/media/video/ivtv/ivtv-streams.c
>>> +++ b/drivers/media/video/ivtv/ivtv-streams.c
>>> @@ -78,60 +78,73 @@ static struct {
>>> int num_offset;
>>> int dma, pio;
>>> enum v4l2_buf_type buf_type;
>>> + u32 v4l2_caps;
>>> const struct v4l2_file_operations *fops;
>>> } ivtv_stream_info[] = {
>>> { /* IVTV_ENC_STREAM_TYPE_MPG */
>>> "encoder MPG",
>>> VFL_TYPE_GRABBER, 0,
>>> PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_VIDEO_CAPTURE,
>>> + V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_TUNER |
>>> + V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
>>> &ivtv_v4l2_enc_fops
>>> },
>>> { /* IVTV_ENC_STREAM_TYPE_YUV */
>>> "encoder YUV",
>>> VFL_TYPE_GRABBER, IVTV_V4L2_ENC_YUV_OFFSET,
>>> PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_VIDEO_CAPTURE,
>>> + V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_TUNER |
>>> + V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
>>> &ivtv_v4l2_enc_fops
>>> },
>>> { /* IVTV_ENC_STREAM_TYPE_VBI */
Re: Using MT9P031 digital sensor
On 2011-11-24 04:28, Laurent Pinchart wrote: Hi Gary, On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: On 2011-11-11 07:26, Laurent Pinchart wrote: On Wednesday 09 November 2011 17:24:26 Gary Thomas wrote: On 2011-11-09 09:18, Laurent Pinchart wrote: On Wednesday 09 November 2011 12:01:34 Gary Thomas wrote: On 2011-11-08 17:54, Laurent Pinchart wrote: On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote: On 2011-11-08 06:06, Laurent Pinchart wrote: On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote: On 2011-11-08 05:30, Javier Martinez Canillas wrote: On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote: On 2011-11-04 04:37, Laurent Pinchart wrote: On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote: I'm trying to use the MT9P031 digital sensor with the Media Controller Framework. media-ctl tells me that the sensor is set to capture using SGRBG12 2592x1944 Questions: * What pixel format in ffmpeg does this correspond to? I don't know if ffmpeg supports Bayer formats. The corresponding fourcc in V4L2 is BA12. ffmpeg doesn't seem to support these formats If your sensor is hooked up to the OMAP3 ISP, you can then configure the pipeline to include the preview engine and the resizer, and capture YUV data at the resizer output. I am using the OMAP3 ISP, but it's a bit unclear to me how to set up the pipeline Hi Gary, I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can help you. using media-ctl (I looked for documentation on this tool, but came up dry - is there any?) Do you have an example of how to configure this using the OMAP3 ISP? This is how I configure the pipeline to connect the CCDC with the Previewer and Resizer: ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' ./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' ./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]' ./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9v032 3-005c":0[SGRBG10 752x480]' ./media-ctl -f '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]' ./media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]' ./media-ctl -f '"OMAP3 ISP preview":0 [SGRBG10 752x479]' ./media-ctl -f '"OMAP3 ISP resizer":0 [YUYV 734x471]' ./media-ctl -f '"OMAP3 ISP resizer":1 [YUYV 640x480]' Hope it helps, Thanks, I'll give this a try. I assume that your sensor is probably larger than 752x480 (the mt9p031 is 2592x1944 raw) and that setting the smaller frame size enables some scaling and/or cropping in the driver? The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You should modify the resolutions in the above commands according to your sensor. Note that the CCDC crops online line when outputting data to the preview engine, and that the preview engine crops 18 columsn and 8 lines. You can then scale the image by modifying the resizer output size. Thanks. After much trial and error (and some kernel printks to understand what parameters were failing), I came up with this sequence: media-ctl -r media-ctl -l '"mt9p031 3-005d":0->"OMAP3 ISP CCDC":0[1]' media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]' media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' media-ctl -f '"mt9p031 3-005d":0[SGRBG12 2592x1944]' media-ctl -f '"OMAP3 ISP CCDC":0 [SGRBG12 2592x1944]' media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG12 2592x1944]' media-ctl -f '"OMAP3 ISP preview":0 [SGRBG12 2592x1943]' media-ctl -f '"OMAP3 ISP resizer":0 [YUYV 2574x1935]' media-ctl -f '"OMAP3 ISP resizer":1 [YUYV 642x483]' When I tried to grab though, I got this: # yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6 Device /dev/video6 opened. Device `OMAP3 ISP resizer output' on `media' is a video capture device. Video format set: YUYV (56595559) 642x483 buffer size 633696 Video format: YUYV (56595559) 642x483 buffer size 633696 8 buffers requested. length: 633696 offset: 0 Buffer 0 mapped at address 0x4028c000. length: 633696 offset: 634880 Buffer 1 mapped at address 0x403d. length: 633696 offset: 1269760 Buffer 2 mapped at address 0x404b3000. length: 633696 offset: 1904640 Buffer 3 mapped at address 0x4062b000. length: 633696 offset: 2539520 Buffer 4 mapped at address 0x406d6000. length: 633696 offset: 3174400 Buffer 5 mapped at address 0x40821000. length: 633696 offset: 3809280 Buffer 6 mapped at address 0x4097c000. length: 633696 offset: 160 Buffer 7 mapped at address 0x40adf000. Unable to handle kernel NULL pointer dereference at virtual address 0018 Ouch :-( Could you please verify that arch/arm/mach-omap2/board-overo.c includes the following code, and that CONFIG_OMAP_MUX is enabled ? I'm not using an Overo board - rather one of our own internal designs. M
Re: More missing module.h includes
On Friday, November 25, 2011 12:37:58 Hans Verkuil wrote: > While compiling the very latest for_v3.3 branch with the very latest > media_build > on a 3.1 kernel I got more compile errors for a missing module.h header. I spoke too soon, I was actually using a different source tree than I expected. I need to do some more digging in order to understand why I get these compile errors... Regards, Hans > > Add these includes. > > Signed-off-by: Hans Verkuil > > Regards, > > Hans > > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c > index 6edc9ba..b826867 100644 > --- a/drivers/media/media-device.c > +++ b/drivers/media/media-device.c > @@ -21,6 +21,7 @@ > */ > > #include > +#include > #include > #include > #include > diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c > b/drivers/media/video/hdpvr/hdpvr-i2c.c > index 82e819f..48cf133 100644 > --- a/drivers/media/video/hdpvr/hdpvr-i2c.c > +++ b/drivers/media/video/hdpvr/hdpvr-i2c.c > @@ -15,6 +15,7 @@ > > #if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE) > > +#include > #include > #include > #include > diff --git a/drivers/media/video/v4l2-subdev.c > b/drivers/media/video/v4l2-subdev.c > index 65ade5f..5c3abc5 100644 > --- a/drivers/media/video/v4l2-subdev.c > +++ b/drivers/media/video/v4l2-subdev.c > @@ -20,6 +20,7 @@ > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > */ > > +#include > #include > #include > #include > -- > 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
More missing module.h includes
While compiling the very latest for_v3.3 branch with the very latest media_build on a 3.1 kernel I got more compile errors for a missing module.h header. Add these includes. Signed-off-by: Hans Verkuil Regards, Hans diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index 6edc9ba..b826867 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -21,6 +21,7 @@ */ #include +#include #include #include #include diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c b/drivers/media/video/hdpvr/hdpvr-i2c.c index 82e819f..48cf133 100644 --- a/drivers/media/video/hdpvr/hdpvr-i2c.c +++ b/drivers/media/video/hdpvr/hdpvr-i2c.c @@ -15,6 +15,7 @@ #if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE) +#include #include #include #include diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index 65ade5f..5c3abc5 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -20,6 +20,7 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include #include #include #include -- 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 3/3] ivtv: setup per-device caps.
On Friday, November 25, 2011 12:00:31 Mauro Carvalho Chehab wrote:
> Em 22-11-2011 08:05, Hans Verkuil escreveu:
> > From: Hans Verkuil
> >
> > Signed-off-by: Hans Verkuil
> > ---
> > drivers/media/video/ivtv/ivtv-driver.h |1 +
> > drivers/media/video/ivtv/ivtv-ioctl.c |7 +--
> > drivers/media/video/ivtv/ivtv-streams.c | 14 ++
> > 3 files changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/video/ivtv/ivtv-driver.h
> > b/drivers/media/video/ivtv/ivtv-driver.h
> > index 8f9cc17..06b9efd 100644
> > --- a/drivers/media/video/ivtv/ivtv-driver.h
> > +++ b/drivers/media/video/ivtv/ivtv-driver.h
> > @@ -331,6 +331,7 @@ struct ivtv_stream {
> > struct ivtv *itv; /* for ease of use */
> > const char *name; /* name of the stream */
> > int type; /* stream type */
> > + u32 caps; /* V4L2 capabilities */
> >
> > u32 id;
> > spinlock_t qlock; /* locks access to the queues */
> > diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c
> > b/drivers/media/video/ivtv/ivtv-ioctl.c
> > index ecafa69..6be63e9 100644
> > --- a/drivers/media/video/ivtv/ivtv-ioctl.c
> > +++ b/drivers/media/video/ivtv/ivtv-ioctl.c
> > @@ -752,12 +752,15 @@ static int ivtv_s_register(struct file *file, void
> > *fh, struct v4l2_dbg_register
> >
> > static int ivtv_querycap(struct file *file, void *fh, struct
> > v4l2_capability *vcap)
> > {
> > - struct ivtv *itv = fh2id(fh)->itv;
> > + struct ivtv_open_id *id = fh2id(file->private_data);
> > + struct ivtv *itv = id->itv;
> > + struct ivtv_stream *s = &itv->streams[id->type];
> >
> > strlcpy(vcap->driver, IVTV_DRIVER_NAME, sizeof(vcap->driver));
> > strlcpy(vcap->card, itv->card_name, sizeof(vcap->card));
> > snprintf(vcap->bus_info, sizeof(vcap->bus_info), "PCI:%s",
> > pci_name(itv->pdev));
> > - vcap->capabilities = itv->v4l2_cap; /* capabilities */
> > + vcap->capabilities = itv->v4l2_cap | V4L2_CAP_DEVICE_CAPS;
>
> IMO, the right thing to do here would be:
>
> vcap->capabilities = V4L2_CAP_DEVICE_CAPS;
> for (i = 0; i < ARRAY_SIZE(ivtv_stream_info); i++)
> vcap->capabilities |= ivtv_stream_info[v4l2_caps];
This won't work actually. Which devices are available depends on more things
than just that array. It's not something I think needs to change.
> This avoids the risk of future patches adding new device_caps at the devices,
> but
> forgetting to update the physical device capabilities.
>
> Also, as the initial patches will be used as implementation reference by
> others,
> such implementation will be more effective than a "magic" set of features that
> may or may not match the union of all device capabilities.
I wouldn't use ivtv as a reference implementation (other than for cx18). vivi
however
is a very nice reference implementation these days.
As soon as this patch is in I'll also update v4l2-compliance.
Regards,
Hans
>
> > + vcap->device_caps = s->caps;
> > return 0;
> > }
> >
> > diff --git a/drivers/media/video/ivtv/ivtv-streams.c
> > b/drivers/media/video/ivtv/ivtv-streams.c
> > index e7794dc..4d4ae6e 100644
> > --- a/drivers/media/video/ivtv/ivtv-streams.c
> > +++ b/drivers/media/video/ivtv/ivtv-streams.c
> > @@ -78,60 +78,73 @@ static struct {
> > int num_offset;
> > int dma, pio;
> > enum v4l2_buf_type buf_type;
> > + u32 v4l2_caps;
> > const struct v4l2_file_operations *fops;
> > } ivtv_stream_info[] = {
> > { /* IVTV_ENC_STREAM_TYPE_MPG */
> > "encoder MPG",
> > VFL_TYPE_GRABBER, 0,
> > PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_VIDEO_CAPTURE,
> > + V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_TUNER |
> > + V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
> > &ivtv_v4l2_enc_fops
> > },
> > { /* IVTV_ENC_STREAM_TYPE_YUV */
> > "encoder YUV",
> > VFL_TYPE_GRABBER, IVTV_V4L2_ENC_YUV_OFFSET,
> > PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_VIDEO_CAPTURE,
> > + V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_TUNER |
> > + V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
> > &ivtv_v4l2_enc_fops
> > },
> > { /* IVTV_ENC_STREAM_TYPE_VBI */
> > "encoder VBI",
> > VFL_TYPE_VBI, 0,
> > PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_VBI_CAPTURE,
> > + V4L2_CAP_VBI_CAPTURE | V4L2_CAP_SLICED_VBI_CAPTURE |
> > V4L2_CAP_TUNER |
> > + V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
> > &ivtv_v4l2_enc_fops
> > },
> > { /* IVTV_ENC_STREAM_TYPE_PCM */
> > "encoder PCM",
> > VFL_TYPE_GRABBER, IVTV_V4L2_ENC_PCM_OFFSET,
> > PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_PRIVATE,
> > + V4L2_CAP_TUNER | V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
> > &ivtv_v4l2_enc_fops
> > },
> > {
Re: [PATCH 2/3] vivi: set device_caps.
On Friday, November 25, 2011 11:53:52 Mauro Carvalho Chehab wrote: > Em 22-11-2011 08:05, Hans Verkuil escreveu: > > From: Hans Verkuil > > > > Signed-off-by: Hans Verkuil > > --- > > drivers/media/video/vivi.c |5 +++-- > > 1 files changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c > > index 7d754fb..84ea88d 100644 > > --- a/drivers/media/video/vivi.c > > +++ b/drivers/media/video/vivi.c > > @@ -819,8 +819,9 @@ static int vidioc_querycap(struct file *file, void > > *priv, > > strcpy(cap->driver, "vivi"); > > strcpy(cap->card, "vivi"); > > strlcpy(cap->bus_info, dev->v4l2_dev.name, sizeof(cap->bus_info)); > > - cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | \ > > - V4L2_CAP_READWRITE; > > + cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | > > + V4L2_CAP_READWRITE | V4L2_CAP_DEVICE_CAPS; > > + cap->device_caps = cap->capabilities; > > Hmm... should V4L2_CAP_DEVICE_CAPS be present at both device_caps and > capabilities? Good question. It doesn't feel right to me to add it to device_caps: it really doesn't mean anything there. The whole point is to have device_caps only show the capabilities of that device node. V4L2_CAP_DEVICE_CAPS is a capability of the whole physical device, so I don't believe it should be set in device_caps. > > IMHO, the better would be to do: > > cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | > V4L2_CAP_READWRITE | V4L2_CAP_DEVICE_CAPS; > cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS; > > Btw, this ambiguity should also be solved at the V4L2 spec. I will update the docs, once we agree 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: [PATCH 1/3] V4L2: Add per-device-node capabilities
On Friday, November 25, 2011 11:51:20 Mauro Carvalho Chehab wrote:
> Hi Hans,
>
> I have a few notes about the wording. See bellow.
>
> Em 22-11-2011 08:05, Hans Verkuil escreveu:
> > From: Hans Verkuil
> >
> > If V4L2_CAP_DEVICE_CAPS is set, then the new device_caps field is filled
> > with
> > the capabilities of the opened device node.
> >
> > The capabilities field traditionally contains the capabilities of the whole
> > device.
>
> Confusing. /dev/video is a "whole device", from kernel POV.
> It should be, instead, "physical device".
>
> Maybe it could be written as:
>
> "The capabilities field traditionally contains the capabilities of the
> physical
>device, being a superset of all capabilities available at the several
> device nodes."
Nice. I'll use your phrasing.
>
> > E.g., if you open video0, then if it contains VBI caps then that means
> > that there is a corresponding vbi node as well. And the capabilities field
> > of
> > both the video and vbi node should contain identical caps.
> >
> > However, it would be very useful to also have a capabilities field that
> > contains
> > just the caps for the currently open device, hence the new CAP bit and
> > field.
> >
> > Signed-off-by: Hans Verkuil
> > ---
> > Documentation/DocBook/media/v4l/compat.xml |9 ++
> > Documentation/DocBook/media/v4l/v4l2.xml |9 +-
> > .../DocBook/media/v4l/vidioc-querycap.xml | 29
> > +--
> > drivers/media/video/cx231xx/cx231xx-417.c |1 -
> > drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 -
> > drivers/media/video/v4l2-ioctl.c |6 +++-
> > include/linux/videodev2.h | 29
> > +--
> > 7 files changed, 67 insertions(+), 17 deletions(-)
> >
> > diff --git a/Documentation/DocBook/media/v4l/compat.xml
> > b/Documentation/DocBook/media/v4l/compat.xml
> > index b68698f..88ea4fc 100644
> > --- a/Documentation/DocBook/media/v4l/compat.xml
> > +++ b/Documentation/DocBook/media/v4l/compat.xml
> > @@ -2378,6 +2378,15 @@ that used it. It was originally scheduled for
> > removal in 2.6.35.
> >
> >
> >
> > +
> > + V4L2 in Linux 3.3
> > +
> > +
> > + Added the device_caps field to struct v4l2_capabilities and
> > added the new
> > + V4L2_CAP_DEVICE_CAPS capability.
> > +
> > +
> > +
> >
> >
> >Relation of V4L2 to other Linux multimedia APIs
> > diff --git a/Documentation/DocBook/media/v4l/v4l2.xml
> > b/Documentation/DocBook/media/v4l/v4l2.xml
> > index 2ab365c..6b6e584 100644
> > --- a/Documentation/DocBook/media/v4l/v4l2.xml
> > +++ b/Documentation/DocBook/media/v4l/v4l2.xml
> > @@ -128,6 +128,13 @@ structs, ioctls) must be noted in more detail in the
> > history chapter
> > applications. -->
> >
> >
> > + 3.3
> > + 2011-11-22
> > + hv
> > + Added device_caps field to struct
> > v4l2_capabilities.
> > +
> > +
> > +
> > 3.2
> > 2011-08-26
> > hv
> > @@ -417,7 +424,7 @@ and discussions on the V4L mailing list.
> >
> >
> > Video for Linux Two API Specification
> > - Revision 3.2
> > + Revision 3.3
> >
> >
> > &sub-common;
> > diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
> > b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
> > index e3664d6..632ad13 100644
> > --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
> > +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
> > @@ -124,12 +124,29 @@ printf ("Version: %u.%u.%u\n",
> >
> > __u32
> > capabilities
> > - Device capabilities, see > - linkend="device-capabilities" />.
> > + Device capabilities of the physical device as a whole, see
> > > + linkend="device-capabilities" />. The same physical device can
> > export
> > + multiple devices in /dev (e.g. /dev/videoX, /dev/vbiY and
> > /dev/radioZ).
> > + For all those devices the capabilities field returns the same
> > set of
> > + capabilities. This allows applications to open just the video
> > device
> > + and discover whether vbi or radio is also supported.
>
> I would write it as:
>
> Available capabilities of the physical device as a whole,
> seelinkend="device-capabilities" />. The same physical device can
> export
> multiple devices in /dev (e.g. /dev/videoX, /dev/vbiY and
> /dev/radioZ).
> The capabilities field should contain an union of all
> capabilities available
> around the several V4L2 devices exported to userspace.
> For all those devices the capabilities field returns the same
> set of
> capabilities. This allows applications to open just one of the
> devices
> (typically the video device) and discover whether video, vbi
> and/or r
Re: [PATCH 3/3] ivtv: setup per-device caps.
Em 22-11-2011 08:05, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/video/ivtv/ivtv-driver.h |1 +
> drivers/media/video/ivtv/ivtv-ioctl.c |7 +--
> drivers/media/video/ivtv/ivtv-streams.c | 14 ++
> 3 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/video/ivtv/ivtv-driver.h
> b/drivers/media/video/ivtv/ivtv-driver.h
> index 8f9cc17..06b9efd 100644
> --- a/drivers/media/video/ivtv/ivtv-driver.h
> +++ b/drivers/media/video/ivtv/ivtv-driver.h
> @@ -331,6 +331,7 @@ struct ivtv_stream {
> struct ivtv *itv; /* for ease of use */
> const char *name; /* name of the stream */
> int type; /* stream type */
> + u32 caps; /* V4L2 capabilities */
>
> u32 id;
> spinlock_t qlock; /* locks access to the queues */
> diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c
> b/drivers/media/video/ivtv/ivtv-ioctl.c
> index ecafa69..6be63e9 100644
> --- a/drivers/media/video/ivtv/ivtv-ioctl.c
> +++ b/drivers/media/video/ivtv/ivtv-ioctl.c
> @@ -752,12 +752,15 @@ static int ivtv_s_register(struct file *file, void *fh,
> struct v4l2_dbg_register
>
> static int ivtv_querycap(struct file *file, void *fh, struct v4l2_capability
> *vcap)
> {
> - struct ivtv *itv = fh2id(fh)->itv;
> + struct ivtv_open_id *id = fh2id(file->private_data);
> + struct ivtv *itv = id->itv;
> + struct ivtv_stream *s = &itv->streams[id->type];
>
> strlcpy(vcap->driver, IVTV_DRIVER_NAME, sizeof(vcap->driver));
> strlcpy(vcap->card, itv->card_name, sizeof(vcap->card));
> snprintf(vcap->bus_info, sizeof(vcap->bus_info), "PCI:%s",
> pci_name(itv->pdev));
> - vcap->capabilities = itv->v4l2_cap; /* capabilities */
> + vcap->capabilities = itv->v4l2_cap | V4L2_CAP_DEVICE_CAPS;
IMO, the right thing to do here would be:
vcap->capabilities = V4L2_CAP_DEVICE_CAPS;
for (i = 0; i < ARRAY_SIZE(ivtv_stream_info); i++)
vcap->capabilities |= ivtv_stream_info[v4l2_caps];
This avoids the risk of future patches adding new device_caps at the devices,
but
forgetting to update the physical device capabilities.
Also, as the initial patches will be used as implementation reference by others,
such implementation will be more effective than a "magic" set of features that
may or may not match the union of all device capabilities.
> + vcap->device_caps = s->caps;
> return 0;
> }
>
> diff --git a/drivers/media/video/ivtv/ivtv-streams.c
> b/drivers/media/video/ivtv/ivtv-streams.c
> index e7794dc..4d4ae6e 100644
> --- a/drivers/media/video/ivtv/ivtv-streams.c
> +++ b/drivers/media/video/ivtv/ivtv-streams.c
> @@ -78,60 +78,73 @@ static struct {
> int num_offset;
> int dma, pio;
> enum v4l2_buf_type buf_type;
> + u32 v4l2_caps;
> const struct v4l2_file_operations *fops;
> } ivtv_stream_info[] = {
> { /* IVTV_ENC_STREAM_TYPE_MPG */
> "encoder MPG",
> VFL_TYPE_GRABBER, 0,
> PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_VIDEO_CAPTURE,
> + V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_TUNER |
> + V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
> &ivtv_v4l2_enc_fops
> },
> { /* IVTV_ENC_STREAM_TYPE_YUV */
> "encoder YUV",
> VFL_TYPE_GRABBER, IVTV_V4L2_ENC_YUV_OFFSET,
> PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_VIDEO_CAPTURE,
> + V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_TUNER |
> + V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
> &ivtv_v4l2_enc_fops
> },
> { /* IVTV_ENC_STREAM_TYPE_VBI */
> "encoder VBI",
> VFL_TYPE_VBI, 0,
> PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_VBI_CAPTURE,
> + V4L2_CAP_VBI_CAPTURE | V4L2_CAP_SLICED_VBI_CAPTURE |
> V4L2_CAP_TUNER |
> + V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
> &ivtv_v4l2_enc_fops
> },
> { /* IVTV_ENC_STREAM_TYPE_PCM */
> "encoder PCM",
> VFL_TYPE_GRABBER, IVTV_V4L2_ENC_PCM_OFFSET,
> PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_PRIVATE,
> + V4L2_CAP_TUNER | V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
> &ivtv_v4l2_enc_fops
> },
> { /* IVTV_ENC_STREAM_TYPE_RAD */
> "encoder radio",
> VFL_TYPE_RADIO, 0,
> PCI_DMA_NONE, 1, V4L2_BUF_TYPE_PRIVATE,
> + V4L2_CAP_RADIO | V4L2_CAP_TUNER,
> &ivtv_v4l2_enc_fops
> },
> { /* IVTV_DEC_STREAM_TYPE_MPG */
> "decoder MPG",
> VFL_TYPE_GRABBER, IVTV_V4L2_DEC_MPG_OFFSET,
> PCI_DMA_TODEVICE, 0, V4L2_BUF_TYPE_VIDEO_OUTPUT,
> + V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
>
Re: [PATCH 2/3] vivi: set device_caps.
Em 22-11-2011 08:05, Hans Verkuil escreveu: > From: Hans Verkuil > > Signed-off-by: Hans Verkuil > --- > drivers/media/video/vivi.c |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c > index 7d754fb..84ea88d 100644 > --- a/drivers/media/video/vivi.c > +++ b/drivers/media/video/vivi.c > @@ -819,8 +819,9 @@ static int vidioc_querycap(struct file *file, void *priv, > strcpy(cap->driver, "vivi"); > strcpy(cap->card, "vivi"); > strlcpy(cap->bus_info, dev->v4l2_dev.name, sizeof(cap->bus_info)); > - cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | \ > - V4L2_CAP_READWRITE; > + cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | > + V4L2_CAP_READWRITE | V4L2_CAP_DEVICE_CAPS; > + cap->device_caps = cap->capabilities; Hmm... should V4L2_CAP_DEVICE_CAPS be present at both device_caps and capabilities? IMHO, the better would be to do: cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | V4L2_CAP_READWRITE | V4L2_CAP_DEVICE_CAPS; cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS; Btw, this ambiguity should also be solved at the V4L2 spec. 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
Re: [PATCH 1/3] V4L2: Add per-device-node capabilities
Hi Hans,
I have a few notes about the wording. See bellow.
Em 22-11-2011 08:05, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> If V4L2_CAP_DEVICE_CAPS is set, then the new device_caps field is filled with
> the capabilities of the opened device node.
>
> The capabilities field traditionally contains the capabilities of the whole
> device.
Confusing. /dev/video is a "whole device", from kernel POV.
It should be, instead, "physical device".
Maybe it could be written as:
"The capabilities field traditionally contains the capabilities of the
physical
device, being a superset of all capabilities available at the several
device nodes."
> E.g., if you open video0, then if it contains VBI caps then that means
> that there is a corresponding vbi node as well. And the capabilities field of
> both the video and vbi node should contain identical caps.
>
> However, it would be very useful to also have a capabilities field that
> contains
> just the caps for the currently open device, hence the new CAP bit and field.
>
> Signed-off-by: Hans Verkuil
> ---
> Documentation/DocBook/media/v4l/compat.xml |9 ++
> Documentation/DocBook/media/v4l/v4l2.xml |9 +-
> .../DocBook/media/v4l/vidioc-querycap.xml | 29 +--
> drivers/media/video/cx231xx/cx231xx-417.c |1 -
> drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 -
> drivers/media/video/v4l2-ioctl.c |6 +++-
> include/linux/videodev2.h | 29 +--
> 7 files changed, 67 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/DocBook/media/v4l/compat.xml
> b/Documentation/DocBook/media/v4l/compat.xml
> index b68698f..88ea4fc 100644
> --- a/Documentation/DocBook/media/v4l/compat.xml
> +++ b/Documentation/DocBook/media/v4l/compat.xml
> @@ -2378,6 +2378,15 @@ that used it. It was originally scheduled for removal
> in 2.6.35.
>
>
>
> +
> + V4L2 in Linux 3.3
> +
> +
> + Added the device_caps field to struct v4l2_capabilities and
> added the new
> + V4L2_CAP_DEVICE_CAPS capability.
> +
> +
> +
>
>
>Relation of V4L2 to other Linux multimedia APIs
> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml
> b/Documentation/DocBook/media/v4l/v4l2.xml
> index 2ab365c..6b6e584 100644
> --- a/Documentation/DocBook/media/v4l/v4l2.xml
> +++ b/Documentation/DocBook/media/v4l/v4l2.xml
> @@ -128,6 +128,13 @@ structs, ioctls) must be noted in more detail in the
> history chapter
> applications. -->
>
>
> + 3.3
> + 2011-11-22
> + hv
> + Added device_caps field to struct
> v4l2_capabilities.
> +
> +
> +
> 3.2
> 2011-08-26
> hv
> @@ -417,7 +424,7 @@ and discussions on the V4L mailing list.
>
>
> Video for Linux Two API Specification
> - Revision 3.2
> + Revision 3.3
>
>
> &sub-common;
> diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
> b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
> index e3664d6..632ad13 100644
> --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
> +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
> @@ -124,12 +124,29 @@ printf ("Version: %u.%u.%u\n",
>
> __u32
> capabilities
> - Device capabilities, see - linkend="device-capabilities" />.
> + Device capabilities of the physical device as a whole, see
> + linkend="device-capabilities" />. The same physical device can
> export
> + multiple devices in /dev (e.g. /dev/videoX, /dev/vbiY and
> /dev/radioZ).
> + For all those devices the capabilities field returns the same
> set of
> + capabilities. This allows applications to open just the video
> device
> + and discover whether vbi or radio is also supported.
I would write it as:
Available capabilities of the physical device as a whole,
see . The same physical device can
export
multiple devices in /dev (e.g. /dev/videoX, /dev/vbiY and
/dev/radioZ).
The capabilities field should contain an union of all
capabilities available
around the several V4L2 devices exported to userspace.
For all those devices the capabilities field returns the same
set of
capabilities. This allows applications to open just one of the
devices
(typically the video device) and discover whether video, vbi
and/or radio are
also supported.
> +
>
>
> __u32
> - reserved[4]
> + device_caps
> + Device capabilities of the open device, see + linkend="device-capabilities" />. This is the set of
> capabilities
> + of just the open device. So
> device_caps
> + of a radio device will
Re: [RFC/PATCH 2/3] v4l: Document integer menu controls
Hi Sakari, Thanks for the patch. On Thursday 24 November 2011 17:12:51 Sakari Ailus wrote: > Signed-off-by: Sakari Ailus > --- > Documentation/DocBook/media/v4l/compat.xml | 10 + > Documentation/DocBook/media/v4l/v4l2.xml |7 > .../DocBook/media/v4l/vidioc-queryctrl.xml | 39 > +++- 3 files changed, 54 insertions(+), 2 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/compat.xml > b/Documentation/DocBook/media/v4l/compat.xml index b68698f..569efd1 100644 > --- a/Documentation/DocBook/media/v4l/compat.xml > +++ b/Documentation/DocBook/media/v4l/compat.xml > @@ -2379,6 +2379,16 @@ that used it. It was originally scheduled for > removal in 2.6.35. > > > + > + V4L2 in Linux 3.3 > + > + > + Added integer menus, the new type will be > + V4L2_CTRL_TYPE_INTEGER_MENU. > + > + > + > + > >Relation of V4L2 to other Linux multimedia APIs > > diff --git a/Documentation/DocBook/media/v4l/v4l2.xml > b/Documentation/DocBook/media/v4l/v4l2.xml index 2ab365c..affe1ba 100644 > --- a/Documentation/DocBook/media/v4l/v4l2.xml > +++ b/Documentation/DocBook/media/v4l/v4l2.xml > @@ -128,6 +128,13 @@ structs, ioctls) must be noted in more detail in the > history chapter applications. --> > > > + 3.3 > + 2011-11-24 > + sa > + Added V4L2_CTRL_TYPE_INTEGER_MENU. > + > + > + > 3.2 > 2011-08-26 > hv > diff --git a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml > b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml index > 0ac0057..049cd46 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml > @@ -215,11 +215,12 @@ the array to zero. > > >struct v4l2_querymenu > - > + > &cs-str; > > > __u32 > + > id > Identifies the control, set by the application > from the respective &v4l2-queryctrl; > @@ -227,18 +228,38 @@ from the respective &v4l2-queryctrl; > > > __u32 > + > index > Index of the menu item, starting at zero, set by > the application. > > > + union > + > + > + > + > + > + > __u8 > name[32] > Name of the menu item, a NUL-terminated ASCII > -string. This information is intended for the user. > +string. This information is intended for the user. This field is valid > +for V4L2_CTRL_FLAG_MENU type controls. > + > + > + > + __s64 > + value > + > + Value of the integer menu item. This field is valid for > + V4L2_CTRL_FLAG_INTEGER_MENU type > + controls. > + > > > __u32 > + > reserved > Reserved for future extensions. Drivers must set > the array to zero. > @@ -292,6 +313,20 @@ the menu items can be enumerated with the > VIDIOC_QUERYMENU ioctl. > > > + V4L2_CTRL_TYPE_INTEGER_MENU > + ≥ 0 > + 1 > + N-1 > + > + The control has a menu of N choices. The names of the > + menu items can be enumerated with the > + VIDIOC_QUERYMENU ioctl. This is > + similar to V4L2_CTRL_TYPE_MENU > + except that instead of integers, the menu items are Do you mean "instead of strings" ? > + signed 64-bit integers. > + > + > + > V4L2_CTRL_TYPE_BITMASK > 0 > n/a -- 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 1/3] v4l: Introduce integer menu controls
Hi Sakari,
Thanks for the patch.
On Thursday 24 November 2011 17:12:50 Sakari Ailus wrote:
> Create a new control type called V4L2_CTRL_TYPE_INTEGER_MENU. Integer menu
> controls are just like menu controls but the menu items are 64-bit integers
> rather than strings.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/video/v4l2-ctrls.c | 63
> +++-- include/linux/videodev2.h|
> 6 +++-
> include/media/v4l2-ctrls.h |6 +++-
> 3 files changed, 56 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-ctrls.c
> b/drivers/media/video/v4l2-ctrls.c index 0f415da..609eb31 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c
> @@ -804,7 +804,8 @@ static void fill_event(struct v4l2_event *ev, struct
> v4l2_ctrl *ctrl, u32 change ev->u.ctrl.value64 = ctrl->cur.val64;
> ev->u.ctrl.minimum = ctrl->minimum;
> ev->u.ctrl.maximum = ctrl->maximum;
> - if (ctrl->type == V4L2_CTRL_TYPE_MENU)
> + if (ctrl->type == V4L2_CTRL_TYPE_MENU
> + || ctrl->type == V4L2_CTRL_TYPE_INTEGER_MENU)
> ev->u.ctrl.step = 1;
> else
> ev->u.ctrl.step = ctrl->step;
> @@ -1035,10 +1036,13 @@ static int validate_new_int(const struct v4l2_ctrl
> *ctrl, s32 *pval) return 0;
>
> case V4L2_CTRL_TYPE_MENU:
> + case V4L2_CTRL_TYPE_INTEGER_MENU:
> if (val < ctrl->minimum || val > ctrl->maximum)
> return -ERANGE;
> - if (ctrl->qmenu[val][0] == '\0' ||
> - (ctrl->menu_skip_mask & (1 << val)))
> + if (ctrl->menu_skip_mask & (1 << val))
> + return -EINVAL;
> + if (ctrl->type == V4L2_CTRL_TYPE_MENU &&
> + ctrl->qmenu[val][0] == '\0')
> return -EINVAL;
> return 0;
>
> @@ -1295,7 +1299,8 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl, const struct v4l2_ctrl_ops *ops,
> u32 id, const char *name, enum v4l2_ctrl_type type,
> s32 min, s32 max, u32 step, s32 def,
> - u32 flags, const char * const *qmenu, void *priv)
> + u32 flags, const char * const *qmenu,
> + const s64 *qmenu_int, void *priv)
> {
> struct v4l2_ctrl *ctrl;
> unsigned sz_extra = 0;
> @@ -1308,6 +1313,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl, (type == V4L2_CTRL_TYPE_INTEGER && step == 0) ||
> (type == V4L2_CTRL_TYPE_BITMASK && max == 0) ||
> (type == V4L2_CTRL_TYPE_MENU && qmenu == NULL) ||
> + (type == V4L2_CTRL_TYPE_INTEGER_MENU && qmenu_int == NULL) ||
> (type == V4L2_CTRL_TYPE_STRING && max == 0)) {
> handler_set_err(hdl, -ERANGE);
> return NULL;
> @@ -1318,6 +1324,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl, }
> if ((type == V4L2_CTRL_TYPE_INTEGER ||
>type == V4L2_CTRL_TYPE_MENU ||
> + type == V4L2_CTRL_TYPE_INTEGER_MENU ||
>type == V4L2_CTRL_TYPE_BOOLEAN) &&
> (def < min || def > max)) {
> handler_set_err(hdl, -ERANGE);
> @@ -1352,7 +1359,10 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl, ctrl->minimum = min;
> ctrl->maximum = max;
> ctrl->step = step;
> - ctrl->qmenu = qmenu;
> + if (type == V4L2_CTRL_TYPE_MENU)
> + ctrl->qmenu = qmenu;
> + else if (type == V4L2_CTRL_TYPE_INTEGER_MENU)
> + ctrl->qmenu_int = qmenu_int;
> ctrl->priv = priv;
> ctrl->cur.val = ctrl->val = ctrl->default_value = def;
>
> @@ -1379,6 +1389,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
> v4l2_ctrl_handler *hdl, struct v4l2_ctrl *ctrl;
> const char *name = cfg->name;
> const char * const *qmenu = cfg->qmenu;
> + const s64 *qmenu_int = cfg->qmenu_int;
> enum v4l2_ctrl_type type = cfg->type;
> u32 flags = cfg->flags;
> s32 min = cfg->min;
> @@ -1390,18 +1401,24 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
> v4l2_ctrl_handler *hdl, v4l2_ctrl_fill(cfg->id, &name, &type, &min, &max,
> &step,
> &def, &flags);
>
> - is_menu = (cfg->type == V4L2_CTRL_TYPE_MENU);
> + is_menu = (cfg->type == V4L2_CTRL_TYPE_MENU ||
> +cfg->type == V4L2_CTRL_TYPE_INTEGER_MENU);
> if (is_menu)
> WARN_ON(step);
> else
> WARN_ON(cfg->menu_skip_mask);
> - if (is_menu && qmenu == NULL)
> + if (cfg->type == V4L2_CTRL_TYPE_MENU && qmenu == NULL)
> qmenu = v4l2_ctrl_get_menu(cfg->id);
> + else if (cfg->type == V4L2_CTRL_TYPE_INTEGER_MENU &&
> + qmenu_int == NULL) {
> + handler_set_err(hdl, -EINVAL);
> + return NULL;
> + }
>
> ctrl = v4l2_ctrl_new(hdl, c
