New Tuner: Hauppauge Aero-M
Hello, all: I've recently purchased a Hauppauge Aero-M. It is an ATSC USB receiver that decodes both regular ATSC and the upcoming ATSC-MH standard. I am mainly concerned with the ATSC half of it as it has the latest LG chip, meaning it is likely one of the best tuners available at present. This tuner scans in as 2040:c61b and does not seem to work in Linux at present, though it is detected in dmesg. I spoke with a friend who works for a broadcaster and he said: "I did some more checking and see that the MXL5007 does have a Linux driver. That's the tuner that's used in the MXF111 so it shouldn't need a lot of rewrite. The only thing that needs all new code is the USB interface portion of the MXF111." This gave me hope that maybe at least the ATSC side could be made to work with Linux without much trouble. I am not a programmer and know basically nothing beyond web coding, but I was wondering if someone could perhaps put some time into getting this up and running. I am glad to provide any output that is required and perform any testing that is requested. Thanks, all. =) - Trip -- 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
[GIT PATCH FOR v3.1] uvcvideo: Set alternate setting 0 on resume if the bus has been reset
Hi Mauro, The following changes since commit 46540f7ac646ada7f22912ea7ea9b761ff5c4718: [media] ir-mce_kbd-decoder: include module.h for its facilities (2011-07-29 12:52:23 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-stable Ming Lei (1): uvcvideo: Set alternate setting 0 on resume if the bus has been reset drivers/media/video/uvc/uvc_driver.c |2 +- drivers/media/video/uvc/uvc_video.c | 10 +- drivers/media/video/uvc/uvcvideo.h |2 +- 3 files changed, 11 insertions(+), 3 deletions(-) -- 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
[PATCH][Resend] viacam: Don't explode if pci_find_bus() returns NULL
In the unlikely case that pci_find_bus() should return NULL viacam_serial_is_enabled() is going to dereference a NULL pointer and blow up. Better safe than sorry, so be defensive and check the pointer. Signed-off-by: Jesper Juhl Acked-by: Jonathan Corbet --- drivers/media/video/via-camera.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/via-camera.c b/drivers/media/video/via-camera.c index 85d3048..bb7f17f 100644 --- a/drivers/media/video/via-camera.c +++ b/drivers/media/video/via-camera.c @@ -1332,6 +1332,8 @@ static __devinit bool viacam_serial_is_enabled(void) struct pci_bus *pbus = pci_find_bus(0, 0); u8 cbyte; + if (!pbus) + return false; pci_bus_read_config_byte(pbus, VIACAM_SERIAL_DEVFN, VIACAM_SERIAL_CREG, &cbyte); if ((cbyte & VIACAM_SERIAL_BIT) == 0) -- 1.7.6 -- Jesper Juhlhttp://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. -- 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][Resend] Remove unneeded version.h includes from include/
It was pointed out by 'make versioncheck' that some includes of linux/version.h are not needed in include/. This patch removes them. When I last posted the patch, the ceph bit was ACK'ed by Sage Weil, so I've added that below. The pwc-ioctl change generated quite a bit of discussion about V4L version numbers in general, but as far as I can tell, no concensus was reached on what the long term solution should be, so in the mean time I think we could start by just removing the unneeded include, which is why I'm resending the patch with that hunk still included. Signed-off-by: Jesper Juhl Acked-by: Sage Weil --- include/linux/ceph/messenger.h |1 - include/media/pwc-ioctl.h |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/include/linux/ceph/messenger.h b/include/linux/ceph/messenger.h index d7adf15..ca768ae 100644 --- a/include/linux/ceph/messenger.h +++ b/include/linux/ceph/messenger.h @@ -6,7 +6,6 @@ #include #include #include -#include #include #include "types.h" diff --git a/include/media/pwc-ioctl.h b/include/media/pwc-ioctl.h index 0f19779..1ed1e61 100644 --- a/include/media/pwc-ioctl.h +++ b/include/media/pwc-ioctl.h @@ -53,7 +53,6 @@ */ #include -#include /* Enumeration of image sizes */ #define PSZ_SQCIF 0x00 -- 1.7.6 -- Jesper Juhlhttp://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. -- 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] [resend] usbvision: disable scaling for Nogatech MicroCam
Em 01-08-2011 15:50, Ondrej Zary escreveu: > On Wednesday 27 July 2011 17:03:06 Mauro Carvalho Chehab wrote: >> Em 22-07-2011 18:44, Ondrej Zary escreveu: >>> On Friday 22 July 2011 23:31:46 Devin Heitmueller wrote: On Fri, Jul 22, 2011 at 5:22 PM, Ondrej Zary wrote: > Seems that this bug is widespread - the same problem appears also in > guvcview > and adobe flash. I think that the driver is broken too - it should return > corrected resolution in TRY_FMT. Well, if the driver does not return the resolution it is actually capturing in, then that indeed is a driver bug. That's a different issue though than what your patch proposed. You should make the TRY_FMT call specifying an invalid resolution and see if it returns the real resolution the device will capture at. If it doesn't, then fix *that* bug. >>> >>> It does not, there's no code that would do that. I actually fixed that only >>> to find out that the scaling is unusable at least with the MicroCam because >>> of black horizontal lines that appear in the image (amount of the lines >>> depend on the scaling factor). So I just disabled the scaling completely for >>> MicroCam. >>> >>> I also don't know if the multiple-of-64 width limit is valid for all >>> usbvision devices - that's why I haven't posted patch to fix this. >>> The application needs to know the capturing resolution, so it's possible that it does properly handle the driver passing back the real resolution and the driver is at fault, in which case no change is needed to the app at all. >> >> Well, for sure you don't need to touch at s_fmt, as it calls try_fmt. Also, >> if the problem is that the scaler requrires that the vertical resolution to >> be >> multiple of some limit, a patch like the one bellow would do a better job: >> >> diff --git a/drivers/media/video/usbvision/usbvision-video.c >> b/drivers/media/video/usbvision/usbvision-video.c >> index 5a74f5e..6907eff 100644 >> --- a/drivers/media/video/usbvision/usbvision-video.c >> +++ b/drivers/media/video/usbvision/usbvision-video.c >> @@ -922,6 +922,9 @@ static int vidioc_try_fmt_vid_cap(struct file *file, >> void *priv, >> RESTRICT_TO_RANGE(vf->fmt.pix.width, MIN_FRAME_WIDTH, MAX_FRAME_WIDTH); >> RESTRICT_TO_RANGE(vf->fmt.pix.height, MIN_FRAME_HEIGHT, >> MAX_FRAME_HEIGHT); >> >> +/* FIXME: please correct the minimum resolution here */ >> +vf->fmt.pix.width &= ~0x01; >> + >> vf->fmt.pix.bytesperline = vf->fmt.pix.width* >> usbvision->palette.bytes_per_pixel; >> vf->fmt.pix.sizeimage = vf->fmt.pix.bytesperline*vf->fmt.pix.height; >> >> Some scalers require an even vertical resolution. So, you'll need to adjust >> the >> above, according with the restrictions you may have on the scaler your webcam >> has. >> >> Btw, V4L2 core defines a macro for such type of adjustments. For example, >> em28xx uses it as: >> >> /* width must even because of the YUYV format >> height must be even because of interlacing */ >> v4l_bound_align_image(&width, 48, maxw, 1, &height, 32, maxh, >>1, 0); >> >> ( >> >> So, a better fix would be to remove the RESTRICT_TO_RANGE() calls, and use >> the v4l_bound_align_image() macro instead, filled with the needed >> restrictions, >> like: >> v4l_bound_align_image(&width, MIN_FRAME_WIDTH, MAX_FRAME_WIDTH, 1, >>&height, MIN_FRAME_HEIGHT, MAX_FRAME_HEIGHT, 0); >> >> >> - >> >> [usbvision] Fix width/height scaling limits >> >> It assumes that both just width is required to be even number. > > Width on the Nogatech MicroCam is limited to multiples of 64 (e.g. if you set > the width to 160, you get 128 instead). But the scaled output is useless > because of black horizontal lines that scaling produces with compression > (which is enabled by default). Ok. This seems to be either a sensor or a bridge problem. So, it is not specific to Nogatech. > Probably nobody wants to disable the > compression as the framerate is very low without it. Yet, it may make sense for some applications, like surveillance cameras or telescopes. If the driver already supports compression to be disabled, maybe the right thing to do would be to allow scaling only if compression is disabled, for the devices that have the same bridge and sensor. > > I don't know about other usbvision devices. We shouldn't change the code for > all of them without testing. > > >> NOT TESTED. >> >> Signed-of-by: Mauro Carvalho Chehab >> >> diff --git a/drivers/media/video/usbvision/usbvision-video.c >> b/drivers/media/video/usbvision/usbvision-video.c >> index 5a74f5e..41d3b47 100644 >> --- a/drivers/media/video/usbvision/usbvision-video.c >> +++ b/drivers/media/video/usbvision/usbvision-video.c >> @@ -919,8 +919,11 @@ static int vidioc_try_fmt_vid_cap(struct file *file, >> void *priv, >> /* robustness */ >>
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Aug 1 19:00:34 CEST 2011 git hash:46540f7ac646ada7f22912ea7ea9b761ff5c4718 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: 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: ERRORS 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-2.6.31.12-x86_64: ERRORS 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 spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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] [resend] usbvision: disable scaling for Nogatech MicroCam
On Wednesday 27 July 2011 17:03:06 Mauro Carvalho Chehab wrote: > Em 22-07-2011 18:44, Ondrej Zary escreveu: > > On Friday 22 July 2011 23:31:46 Devin Heitmueller wrote: > >> On Fri, Jul 22, 2011 at 5:22 PM, Ondrej Zary > >> wrote: > >>> Seems that this bug is widespread - the same problem appears also in > >>> guvcview > >>> and adobe flash. I think that the driver is broken too - it should return > >>> corrected resolution in TRY_FMT. > >> > >> Well, if the driver does not return the resolution it is actually > >> capturing in, then that indeed is a driver bug. That's a different > >> issue though than what your patch proposed. > >> > >> You should make the TRY_FMT call specifying an invalid resolution and > >> see if it returns the real resolution the device will capture at. If > >> it doesn't, then fix *that* bug. > > > > It does not, there's no code that would do that. I actually fixed that only > > to find out that the scaling is unusable at least with the MicroCam because > > of black horizontal lines that appear in the image (amount of the lines > > depend on the scaling factor). So I just disabled the scaling completely for > > MicroCam. > > > > I also don't know if the multiple-of-64 width limit is valid for all > > usbvision devices - that's why I haven't posted patch to fix this. > > > >> The application needs to know the capturing resolution, so it's > >> possible that it does properly handle the driver passing back the real > >> resolution and the driver is at fault, in which case no change is > >> needed to the app at all. > > Well, for sure you don't need to touch at s_fmt, as it calls try_fmt. Also, > if the problem is that the scaler requrires that the vertical resolution to be > multiple of some limit, a patch like the one bellow would do a better job: > > diff --git a/drivers/media/video/usbvision/usbvision-video.c > b/drivers/media/video/usbvision/usbvision-video.c > index 5a74f5e..6907eff 100644 > --- a/drivers/media/video/usbvision/usbvision-video.c > +++ b/drivers/media/video/usbvision/usbvision-video.c > @@ -922,6 +922,9 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void > *priv, > RESTRICT_TO_RANGE(vf->fmt.pix.width, MIN_FRAME_WIDTH, MAX_FRAME_WIDTH); > RESTRICT_TO_RANGE(vf->fmt.pix.height, MIN_FRAME_HEIGHT, > MAX_FRAME_HEIGHT); > > + /* FIXME: please correct the minimum resolution here */ > + vf->fmt.pix.width &= ~0x01; > + > vf->fmt.pix.bytesperline = vf->fmt.pix.width* > usbvision->palette.bytes_per_pixel; > vf->fmt.pix.sizeimage = vf->fmt.pix.bytesperline*vf->fmt.pix.height; > > Some scalers require an even vertical resolution. So, you'll need to adjust > the > above, according with the restrictions you may have on the scaler your webcam > has. > > Btw, V4L2 core defines a macro for such type of adjustments. For example, > em28xx uses it as: > > /* width must even because of the YUYV format > height must be even because of interlacing */ > v4l_bound_align_image(&width, 48, maxw, 1, &height, 32, maxh, > 1, 0); > > ( > > So, a better fix would be to remove the RESTRICT_TO_RANGE() calls, and use > the v4l_bound_align_image() macro instead, filled with the needed > restrictions, > like: > v4l_bound_align_image(&width, MIN_FRAME_WIDTH, MAX_FRAME_WIDTH, 1, > &height, MIN_FRAME_HEIGHT, MAX_FRAME_HEIGHT, 0); > > > - > > [usbvision] Fix width/height scaling limits > > It assumes that both just width is required to be even number. Width on the Nogatech MicroCam is limited to multiples of 64 (e.g. if you set the width to 160, you get 128 instead). But the scaled output is useless because of black horizontal lines that scaling produces with compression (which is enabled by default). Probably nobody wants to disable the compression as the framerate is very low without it. I don't know about other usbvision devices. We shouldn't change the code for all of them without testing. > NOT TESTED. > > Signed-of-by: Mauro Carvalho Chehab > > diff --git a/drivers/media/video/usbvision/usbvision-video.c > b/drivers/media/video/usbvision/usbvision-video.c > index 5a74f5e..41d3b47 100644 > --- a/drivers/media/video/usbvision/usbvision-video.c > +++ b/drivers/media/video/usbvision/usbvision-video.c > @@ -919,8 +919,11 @@ static int vidioc_try_fmt_vid_cap(struct file *file, > void *priv, > /* robustness */ > if (format_idx == USBVISION_SUPPORTED_PALETTES) > return -EINVAL; > - RESTRICT_TO_RANGE(vf->fmt.pix.width, MIN_FRAME_WIDTH, MAX_FRAME_WIDTH); > - RESTRICT_TO_RANGE(vf->fmt.pix.height, MIN_FRAME_HEIGHT, > MAX_FRAME_HEIGHT); > + > + v4l_bound_align_image(&vf->fmt.pix.width, > + MIN_FRAME_WIDTH, MAX_FRAME_WIDTH, 1, > + &vf->fmt.pix.height, > + MIN_FRAME_HEIGHT, MAX_FRAME_HEIGHT, 0, 0);
Re: [PATCH] uvcvideo: add SetInterface(0) in .reset_resume handler
Em 01-08-2011 08:26, Laurent Pinchart escreveu: > Hi Ming, > > On Monday 01 August 2011 02:56:59 Ming Lei wrote: >> On Sun, Jul 31, 2011 at 11:38 PM, Laurent Pinchart wrote: >>> Hi Ming, >>> >>> Thanks for the patch. I've queued it for v3.2 with a small modification >>> (the usb_set_interface() call has been moved to uvc_video.c). >> >> Thanks for queuing it. >> >> Considered it is a fix patch, could you queue it for 3.1 -rcX as fix patch? >> But anyway, it is up to you, :-) > > It's not completely up to me :-) This patch falls in the "features that never > worked" category. I've heard that Linus didn't want such non-regression fixes > during the 3.0-rc phase. Mauro, is it still true for v3.1-rc ? Can I push > this > patch for 3.1, or does it need to wait until 3.2 ? Theoretically, we're still with the open window. Well, send it to me. It is a fix. I'll likely queue it to 3.1 and send on a next pull request, together with a few other fixes probably on the next weekend. Thanks, 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
Support for Elgato Eyetv Hybrid?
Hello all, I would really much like to know if somebody is working yet on adding support to the kernel for the Elgato Eyetv Hybrid DVB/Analogue USB TV tuner stick (Vendor 0fd9 Product 0018). lsusb currently only shows there is a device with ID 0df9:0018 >From what i found on the internet, the device's specs are: Model: EU 2008 USB Controller: Empia EM2884 Stereo A/V Decoder: Micronas AVF 49x08 Hybrid Channel Decoder: Micronas DRX-K DRX3926K:A1 0.9.0 I spoke to a few people on the IRC linuxtv channel @freenode and someone told this was the best place to ask for it. Regards, Eddie. -- 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] v4l2: Fix documentation of the codec device controls
On Mon, 01 Aug 2011 16:51:39 +0200 Kamil Debski wrote: > Fixed missing ids of the codec controls description in the controls.xml file. > > Signed-off-by: Kamil Debski > Signed-off-by: Kyungmin Park > Reported-by: Randy Dunlap > --- > Hi, > > This patch fixes the problem with codec controls documentation reported by > Randy > in the following email: > http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/36288 > > Thanks for reporting those errors. > > Best wishes, > Kamil Hi, This patch eliminates some (3) of the reported errors, but not all of them. The fixed ones are: Error: no ID for constraint linkend: v4l2-mpeg-video-h264-level. Error: no ID for constraint linkend: v4l2-mpeg-video-h264-vui-sar-idc. Error: no ID for constraint linkend: v4l2-mpeg-video-mpeg4-level. but I still see these: Error: no ID for constraint linkend: v4l2-mpeg-video-header-mode. Error: no ID for constraint linkend: v4l2-mpeg-video-multi-slice-mode. Error: no ID for constraint linkend: v4l2-mpeg-video-h264-entropy-mode. Error: no ID for constraint linkend: v4l2-mpeg-video-h264-loop-filter-mode. Error: no ID for constraint linkend: v4l2-mpeg-video-h264-profile. Error: no ID for constraint linkend: v4l2-mpeg-video-mpeg4-profile. Error: no ID for constraint linkend: v4l2-mpeg-mfc51-video-frame-skip-mode. Error: no ID for constraint linkend: v4l2-mpeg-mfc51-video-force-frame-type. > --- > Documentation/DocBook/media/v4l/controls.xml | 24 > 1 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > b/Documentation/DocBook/media/v4l/controls.xml > index 8516401..09d6872 100644 > --- a/Documentation/DocBook/media/v4l/controls.xml > +++ b/Documentation/DocBook/media/v4l/controls.xml > @@ -1455,7 +1455,7 @@ Applicable to the H264 encoder. > > > > - > + >spanname="id">V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC > enum v4l2_mpeg_video_h264_vui_sar_idc > > @@ -1561,7 +1561,7 @@ Applicable to the H264 encoder. > > > > - > + >spanname="id">V4L2_CID_MPEG_VIDEO_H264_LEVEL > enum v4l2_mpeg_video_h264_level > > @@ -1641,7 +1641,7 @@ Possible values are: > > > > - > + >spanname="id">V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL > enum v4l2_mpeg_video_mpeg4_level > > @@ -1689,7 +1689,7 @@ Possible values are: > > > > - > + >spanname="id">V4L2_CID_MPEG_VIDEO_H264_PROFILE > enum v4l2_mpeg_h264_profile > > @@ -1774,7 +1774,7 @@ Possible values are: > > > > - > + >spanname="id">V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE > enum v4l2_mpeg_mpeg4_profile > > @@ -1820,7 +1820,7 @@ Applicable to the encoder. > > > > - > + >spanname="id">V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE > enum v4l2_mpeg_multi_slice_mode > > @@ -1868,7 +1868,7 @@ Applicable to the encoder. > > > > - > + >spanname="id">V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_MODE > enum v4l2_mpeg_h264_loop_filter_mode > > @@ -1913,9 +1913,9 @@ Applicable to the H264 encoder. > > > > - > + >spanname="id">V4L2_CID_MPEG_VIDEO_H264_ENTROPY_MODE > - enum v4l2_mpeg_h264_symbol_mode > + enum v4l2_mpeg_h264_entropy_mode > > Entropy coding mode for H264 - > CABAC/CAVALC. > Applicable to the H264 encoder. > @@ -2140,7 +2140,7 @@ previous frames. Applicable to the H264 encoder. > > > > - > + >spanname="id">V4L2_CID_MPEG_VIDEO_HEADER_MODE > enum v4l2_mpeg_header_mode > > @@ -2320,7 +2320,7 @@ Valid only when H.264 and macroblock level RC is > enabled (V4L2_CID_MPE > Applicable to the H264 encoder. > > > - > + >spanname="id">V4L2_CID_MPEG_MFC51_VIDEO_FRAME_SKIP_MODE > enum v4l2_mpeg_mfc51_frame_skip_mode > > @@ -2361,7 +2361,7 @@ the stream will meet tight bandwidth contraints. > Applicable to encoders. > > > > - > + >spanname="id">V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE > enum v4l2_mpeg_mfc51_force_frame_type > > -- --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a
Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management
On Mon, 1 Aug 2011, Sakari Ailus wrote: > Guennadi Liakhovetski wrote: > > On Tue, 26 Jul 2011, Hans Verkuil wrote: > > > >> On Tuesday, July 26, 2011 13:44:28 Sakari Ailus wrote: > >>> Hi Hans and Guennadi, > >> > >> > >> > I realized that it is not clear from the documentation whether it is > possible to call > VIDIOC_REQBUFS and make additional calls to VIDIOC_CREATE_BUFS > afterwards. > >>> > >>> That's actually a must if one wants to release buffers. Currently no other > >>> method than requesting 0 buffers using REQBUFS is provided (apart from > >>> closing the file handle). > >> > >> I was referring to the non-0 use-case :-) > >> > I can't remember whether the code allows it or not, but it should be > clearly documented. > >>> > >>> I would guess no user application would have to call REQBUFS with other > >>> than > >>> zero buffers when using CREATE_BUFS. This must be an exception if mixing > >>> REQBUFS and CREATE_BUFS is not allowed in general. That said, I don't see > >>> a > >>> reason to prohibit either, but perhaps Guennadi has more informed opinion > >>> on this. > >> > >> > >> > >>> Future functionality which would be nice: > >>> > >>> - Format counters. Every format set by S_FMT (or gotten by G_FMT) > >>> should > >>> come with a counter value so that the user would know the format of > >>> dequeued buffers when setting the format on-the-fly. Currently > >>> there are > >>> only bytesperline and length, but the format can't be explicitly > >>> determined from those. > > Actually, the index field will give you that information. When you > create the > buffers you know that range [index, index + count - 1] is associated > with that > specific format. > >>> > >>> Some hardware is able to change the format while streaming is ongoing (for > >>> example: OMAP 3). The problem is that the user should be able to know > >>> which > >>> frame has the new format. > > > > How exactly does this work or should it work? You mean, you just configure > > your hardware with new frame size parameters without stopping the current > > streaming, and the ISP will change frame sizes, beginning with some future > > frame? How does the driver then get to know, which frame already has the > > That's correct. > > > new sizes? You actually want to know this in advance to already queue a > > suitably sized buffer to the hardware? > > The driver knows that since it has configured the hardware to produce > that frame size. > > The assumption is that all the buffers have suitable size for all the > formats. This must be checked by the driver, something which also must > be taken into account. Hm, but do you then at all need different buffers? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] tuner_xc2028: Allow selection of the frequency adjustment code for XC3028
Hey, thanks Mauro, thanks Alina, my DVB-T Card started to work again, too. Jean -- 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] V4L: add two new ioctl()s for multi-size videobuffer management
Guennadi Liakhovetski wrote: > On Tue, 26 Jul 2011, Hans Verkuil wrote: > >> On Tuesday, July 26, 2011 13:44:28 Sakari Ailus wrote: >>> Hi Hans and Guennadi, >> >> >> I realized that it is not clear from the documentation whether it is possible to call VIDIOC_REQBUFS and make additional calls to VIDIOC_CREATE_BUFS afterwards. >>> >>> That's actually a must if one wants to release buffers. Currently no other >>> method than requesting 0 buffers using REQBUFS is provided (apart from >>> closing the file handle). >> >> I was referring to the non-0 use-case :-) >> I can't remember whether the code allows it or not, but it should be clearly documented. >>> >>> I would guess no user application would have to call REQBUFS with other than >>> zero buffers when using CREATE_BUFS. This must be an exception if mixing >>> REQBUFS and CREATE_BUFS is not allowed in general. That said, I don't see a >>> reason to prohibit either, but perhaps Guennadi has more informed opinion >>> on this. >> >> >> >>> Future functionality which would be nice: >>> >>> - Format counters. Every format set by S_FMT (or gotten by G_FMT) should >>> come with a counter value so that the user would know the format of >>> dequeued buffers when setting the format on-the-fly. Currently there >>> are >>> only bytesperline and length, but the format can't be explicitly >>> determined from those. Actually, the index field will give you that information. When you create the buffers you know that range [index, index + count - 1] is associated with that specific format. >>> >>> Some hardware is able to change the format while streaming is ongoing (for >>> example: OMAP 3). The problem is that the user should be able to know which >>> frame has the new format. > > How exactly does this work or should it work? You mean, you just configure > your hardware with new frame size parameters without stopping the current > streaming, and the ISP will change frame sizes, beginning with some future > frame? How does the driver then get to know, which frame already has the That's correct. > new sizes? You actually want to know this in advance to already queue a > suitably sized buffer to the hardware? The driver knows that since it has configured the hardware to produce that frame size. The assumption is that all the buffers have suitable size for all the formats. This must be checked by the driver, something which also must be taken into account. -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l2: Fix documentation of the codec device controls
Fixed missing ids of the codec controls description in the controls.xml file. Signed-off-by: Kamil Debski Signed-off-by: Kyungmin Park Reported-by: Randy Dunlap --- Hi, This patch fixes the problem with codec controls documentation reported by Randy in the following email: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/36288 Thanks for reporting those errors. Best wishes, Kamil --- Documentation/DocBook/media/v4l/controls.xml | 24 1 files changed, 12 insertions(+), 12 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 8516401..09d6872 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -1455,7 +1455,7 @@ Applicable to the H264 encoder. - + V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC enum v4l2_mpeg_video_h264_vui_sar_idc @@ -1561,7 +1561,7 @@ Applicable to the H264 encoder. - + V4L2_CID_MPEG_VIDEO_H264_LEVEL enum v4l2_mpeg_video_h264_level @@ -1641,7 +1641,7 @@ Possible values are: - + V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL enum v4l2_mpeg_video_mpeg4_level @@ -1689,7 +1689,7 @@ Possible values are: - + V4L2_CID_MPEG_VIDEO_H264_PROFILE enum v4l2_mpeg_h264_profile @@ -1774,7 +1774,7 @@ Possible values are: - + V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE enum v4l2_mpeg_mpeg4_profile @@ -1820,7 +1820,7 @@ Applicable to the encoder. - + V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE enum v4l2_mpeg_multi_slice_mode @@ -1868,7 +1868,7 @@ Applicable to the encoder. - + V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_MODE enum v4l2_mpeg_h264_loop_filter_mode @@ -1913,9 +1913,9 @@ Applicable to the H264 encoder. - + V4L2_CID_MPEG_VIDEO_H264_ENTROPY_MODE - enum v4l2_mpeg_h264_symbol_mode + enum v4l2_mpeg_h264_entropy_mode Entropy coding mode for H264 - CABAC/CAVALC. Applicable to the H264 encoder. @@ -2140,7 +2140,7 @@ previous frames. Applicable to the H264 encoder. - + V4L2_CID_MPEG_VIDEO_HEADER_MODE enum v4l2_mpeg_header_mode @@ -2320,7 +2320,7 @@ Valid only when H.264 and macroblock level RC is enabled (V4L2_CID_MPE Applicable to the H264 encoder. - + V4L2_CID_MPEG_MFC51_VIDEO_FRAME_SKIP_MODE enum v4l2_mpeg_mfc51_frame_skip_mode @@ -2361,7 +2361,7 @@ the stream will meet tight bandwidth contraints. Applicable to encoders. - + V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE enum v4l2_mpeg_mfc51_force_frame_type -- 1.6.3.3 -- 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] fbdev: Add FOURCC-based format configuration API
Hi Florian, On Monday 01 August 2011 01:58:27 Florian Tobias Schandinat wrote: > On 07/31/2011 11:28 PM, Laurent Pinchart wrote: > > On Monday 01 August 2011 00:54:48 Florian Tobias Schandinat wrote: > >> On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote: > >>> On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart wrote: > > As for struct fb_var_screeninfo fields to support switching to a > > FOURCC mode, I also prefer an explicit dedicated flag to specify > > switching to it. Even though using FOURCC doesn't fit under the > > notion of a videomode, using one of .vmode bits is too tempting, so, > > I would actually take the plunge and use FB_VMODE_FOURCC. > > Another option would be to consider any grayscale> 1 value as a > FOURCC. I've briefly checked the in-tree drivers: they only assign > grayscale with 0 or 1, and check whether grayscale is 0 or different > than 0. If a userspace application only sets grayscale> 1 when > talking to a driver that supports the FOURCC-based API, we could get > rid of the flag. > > What can't be easily found out is whether existing applications set > grayscale to a> 1 value. They would break when used with > FOURCC-aware drivers if we consider any grayscale> 1 value as a > FOURCC. Is that a risk we can take ? > >>> > >>> I think we can. I'd expect applications to use either 1 or -1 (i.e. > >>> all ones), both are > >>> invalid FOURCC values. > >>> > >>> Still, I prefer the nonstd way. > >>> And limiting traditional nonstd values to the lowest 24 bits (there > >>> are no in-tree > >>> drivers using the highest 8 bits, right?). > >> > >> Okay, it would be okay for me to > >> - write raw FOURCC values in nonstd, enable FOURCC mode if upper byte != > >> 0 - not having an explicit flag to enable FOURCC > >> - in FOURCC mode drivers must set visual to FB_VISUAL_FOURCC > >> - making support of FOURCC visible to userspace by capabilites |= > >> FB_CAP_FOURCC > >> > >> The capabilities is not strictly necessary but I think it's very useful > >> as - it allows applications to make sure the extension is supported > >> (for example to adjust the UI) > >> - it allows applications to distinguish whether a particular format is > >> not supported or FOURCC at all > >> - it allows signaling further extensions of the API > >> - it does not hurt, one line per driver and still some bytes in fixinfo > >> free > > > > Without a FOURCC capability applications will need to try FOURCCs > > blindly. Drivers that are not FOURCC aware would then risk interpreting > > the FOURCC as something else. As you mention below applications will > > need that check that visual == FB_VISUAL_FOURCC, so it's less of an > > issue than I initially thought, but it doesn't become a non-issue. The > > display might still show glitches. > > True. > > >> So using it would look like this: > >> - the driver must have capabilities |= FB_CAP_FOURCC > >> - the application may check capabilities to know whether FOURCC is > >> supported - the application may write a raw FOURCC value in nonstd to > >> request changing to FOURCC mode with this format > >> - when the driver switches to a FOURCC mode it must have visual = > >> FB_VISUAL_FOURCC and the current FOURCC format in nonstd > >> - the application should check visual and nonstd to make sure it gets > >> what it wanted > >> > >> > >> So if there are no strong objections against this I think we should > >> implement it. I do not really care whether we use a union or not but I > >> think if we decide to have one it should cover all fields that are > >> undefined/unused in FOURCC mode. > >> > >> > >> Hope we can find anything that everyone considers acceptable, > > > > This sounds good to me, except that I would use the grayscale field > > instead of the nonstd field. nonstd has pretty weird usecases, while > > grayscale is better defined. nonstd might also make sense combined with > > FOURCC-based modes, while grayscale would be completely redundant. > > > > What's your opinion on that ? > > I do not really care, either one would be okay for me. > You're right that nonstd is used for a lot of things and perhaps some of > those should still be possible in FOURCC mode. On the other hand I think > applications are more likely to pass random values to grayscale as its > meaning seems globally accepted (in contrast to nonstd where the > application needs to know the driver to get any use of it). > Perhaps you should also say that in FOURCC mode all unused pixel format > fields should be set to 0 by the application and other values of those may > get a meaning in later extensions or individual drivers. Good point. I'll add that to the documentation. -- 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: media Documentation Errors
Hi, > From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] > > Hi Randy, > > Em 30-07-2011 20:51, Randy Dunlap escreveu: > > Hi, > > > > What do I need to do to eliminate these errors? > > (from 3.0-git12) > > Thanks for reporting it. > > > Error: no ID for constraint linkend: v4l2-mpeg-video-header-mode. > > Error: no ID for constraint linkend: v4l2-mpeg-video-multi-slice-mode. > > Error: no ID for constraint linkend: v4l2-mpeg-video-h264-entropy-mode. > > Error: no ID for constraint linkend: v4l2-mpeg-video-h264-level. > > Error: no ID for constraint linkend: v4l2-mpeg-video-h264-loop-filter-mode. > > Error: no ID for constraint linkend: v4l2-mpeg-video-h264-profile. > > Error: no ID for constraint linkend: v4l2-mpeg-video-h264-vui-sar-idc. > > Error: no ID for constraint linkend: v4l2-mpeg-video-mpeg4-level. > > Error: no ID for constraint linkend: v4l2-mpeg-video-mpeg4-profile. > > Error: no ID for constraint linkend: v4l2-mpeg-mfc51-video-frame-skip-mode. > > Error: no ID for constraint linkend: v4l2-mpeg-mfc51-video-force-frame- > type. > > Error: no ID for constraint linkend: v4l2-mpeg-video-header-mode. > > Error: no ID for constraint linkend: v4l2-mpeg-video-multi-slice-mode. > > Error: no ID for constraint linkend: v4l2-mpeg-video-h264-entropy-mode. > > Error: no ID for constraint linkend: v4l2-mpeg-video-h264-level. > > Error: no ID for constraint linkend: v4l2-mpeg-video-h264-loop-filter-mode. > > Error: no ID for constraint linkend: v4l2-mpeg-video-h264-profile. > > Error: no ID for constraint linkend: v4l2-mpeg-video-h264-vui-sar-idc. > > Error: no ID for constraint linkend: v4l2-mpeg-video-mpeg4-level. > > Error: no ID for constraint linkend: v4l2-mpeg-video-mpeg4-profile. > > Error: no ID for constraint linkend: v4l2-mpeg-mfc51-video-frame-skip-mode. > > Error: no ID for constraint linkend: v4l2-mpeg-mfc51-video-force-frame- > type. > > This probably means that Samsung guys didn't properly documented those new > stuff > into the DocBook, e. g. they're defined at include/linux/videodev2.h, but > either there's no documentation for them, or the links inside the docbook > don't match. > > Kamil? Yes, I can confirm this and I am working on a fix. It is strange that I did not get those errors when I did "make htmldocs". Best wishes, -- Kamil Debski Linux Platform Group 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: [GIT PULL for v3.0] media updates for v3.1
Hi, On 08/01/2011 09:45 AM, Hans Verkuil wrote: Hi, On 07/31/2011 12:38 PM, Mauro Carvalho Chehab wrote: Em 31-07-2011 04:57, Hans de Goede escreveu: Hi, I notice that Hans Verkuil's patches to make poll report what is being polled to drivers, and my corresponding patches for adding event support to pwc are not included, what is the plan with these? The changes for the vfs code need vfs maintainer's ack, or to go via their tree. So, we need to wait for them to merge/send it upstream, before being able to merge the patches that depend on it. Hmm, has anyone had any direct communications with the vfs maintainer about this? If not I think we should have some direct communications on this, otherwise we may end up waiting a long long time. He was CC-ed on this from the very beginning... He probably is CC-ed on a gazillion mails. May I suggest sending him a direct personal mail (no lists in the CC etc.) 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] uvcvideo: add SetInterface(0) in .reset_resume handler
Hi Ming, On Monday 01 August 2011 02:56:59 Ming Lei wrote: > On Sun, Jul 31, 2011 at 11:38 PM, Laurent Pinchart wrote: > > Hi Ming, > > > > Thanks for the patch. I've queued it for v3.2 with a small modification > > (the usb_set_interface() call has been moved to uvc_video.c). > > Thanks for queuing it. > > Considered it is a fix patch, could you queue it for 3.1 -rcX as fix patch? > But anyway, it is up to you, :-) It's not completely up to me :-) This patch falls in the "features that never worked" category. I've heard that Linus didn't want such non-regression fixes during the 3.0-rc phase. Mauro, is it still true for v3.1-rc ? Can I push this patch for 3.1, or does it need to wait until 3.2 ? -- 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: [PATCHv4 05/11] omap3isp: Use *_dec_not_zero instead of *_add_unless
Hi Sven, On Monday 01 August 2011 12:07:15 Sven Eckelmann wrote: > On Sunday 31 July 2011 17:00:43 Laurent Pinchart wrote: > > On Wednesday 27 July 2011 11:47:44 Sven Eckelmann wrote: > > > atomic_dec_not_zero is defined for each architecture through > > > to provide the functionality of > > > atomic_add_unless(x, -1, 0). > > > > > > Signed-off-by: Sven Eckelmann > > > Cc: Laurent Pinchart > > > > Acked-by: Laurent Pinchart > > > > I'll queue this to my tree for v3.2. Please let me know if you would > > rather push the patch through another tree. > > The problem is that until now no one from linux-arch has applied the patch > 01/11 in his tree (which is needed before this patch can be applied) and > you tree have to be based on the "yet to be chosen linux-arch tree". > Otherwise your tree will just break and not be acceptable for a pull > request. > > Maybe it is easier when one person applies 01-11 after 02-11 was Acked-by > the responsible maintainers. > > 02 is more or less automatically Acked-by us :) > 04, 09 and 10 are also Acked. > ... and the rest is waiting for actions. OK. I'm fine with 05/11 being pushed through any tree with my ack. Please let me know if/when you want me to apply it to my tree. -- 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 v3] V4L: add two new ioctl()s for multi-size videobuffer management
On Sat, 30 Jul 2011, Hans Verkuil wrote: [snip] > No. We do not have a mechanism (yet) to tie a pipeline configuration to > a queued buffer (to be discussed in next week in Cambourne). > > It is my understanding that you change the current streaming format, and > then queue the large (prepared) buffer and switch back afterwards. As far as I understand, currently we have 2 unclarified points with this patch: 1. size of the reserved field. Sakari proposed 19 32-bit words for possible per-plane extensions with a max of 8 planes. That would make up to 2 32-bit words per plane plus 3 words for the common part. So, although reserving 76 bytes "just in case" seems like a huge overkill to me, I kinda can see the reasoning... We could also do with 10 reserved words - 1 word per plane + 2 common. What do others think? 2. as in the above quote - we do not know yet, how to tell the user, when the format changes. AFAIU, the problem is the following: (a) we prepare buffers of two sizes, say - small for preview and large for snapshot (b) S_FMT(preview) (c) QBUF(preview)... (d) STREAMON (e) capture for some time... (f) S_FMT(snapshot) (g) now, we do not yet necessarily want to queue our big buffers, because the hardware will not switch immediately (h) when the hardware has switch we QBUF(snapshor) ... Currently, there's no way to find out when the hardware switched to the new frame format. Maybe an event is needed? Besides, the TRY_FMT idea is nice, but it doesn't give us an ultimate solution either. What if a TRY_FMT now returns different plane sizes, than when we actually perform S_FMT? E.g., if the user also issues an S_CROP between those and that also changes the output format because of driver limitations? So, my question is: shall I prepare a new version of this RFC now, also providing examples for vb2 and a hardware driver, or we're waiting for the brainstorming and following ML discussion results on the above? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 00/59] Convert soc-camera to .[gs]_mbus_config() subdev operations
Dnia piątek, 29 lipca 2011 o 12:56:00 Guennadi Liakhovetski napisał(a):
> This patch-series converts all soc-camera client and host drivers and
> the core from soc-camera specific .{query,set}_bus_param()
> operations to the new .[gs]_mbus_config() subdev operations. In
> order to prevent bisect breakage we first have to only add new
> methods to client drivers, then convert all host drivers, taking
> care to preserve platform compatibility, and only then soc-camera
> methods can be removed. These patches are also available as a git
> branch:
>
> git://linuxtv.org/gliakhovetski/v4l-dvb.git mbus-config
>
> Tested on i.MX31, PXA270, SuperH, mach-shmobile. Compile-tested on
> many others. Reviews and tests welcome!:-)
Tested on Amstrad Delta - omap1_camera + ov6650.
Thanks,
Janusz
--
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: Re: [PATCHv4 05/11] omap3isp: Use *_dec_not_zero instead of *_add_unless
On Sunday 31 July 2011 17:00:43 Laurent Pinchart wrote: > Hi Sven, > > Thanks for the patch. > > On Wednesday 27 July 2011 11:47:44 Sven Eckelmann wrote: > > atomic_dec_not_zero is defined for each architecture through > > to provide the functionality of > > atomic_add_unless(x, -1, 0). > > > > Signed-off-by: Sven Eckelmann > > Cc: Laurent Pinchart > > Acked-by: Laurent Pinchart > > I'll queue this to my tree for v3.2. Please let me know if you would rather > push the patch through another tree. The problem is that until now no one from linux-arch has applied the patch 01/11 in his tree (which is needed before this patch can be applied) and you tree have to be based on the "yet to be chosen linux-arch tree". Otherwise your tree will just break and not be acceptable for a pull request. Maybe it is easier when one person applies 01-11 after 02-11 was Acked-by the responsible maintainers. 02 is more or less automatically Acked-by us :) 04, 09 and 10 are also Acked. ... and the rest is waiting for actions. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
On Mon, Aug 1, 2011 at 00:54, Florian Tobias Schandinat
wrote:
> On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote:
>> On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart
>> wrote:
As for struct fb_var_screeninfo fields to support switching to a FOURCC
mode, I also prefer an explicit dedicated flag to specify switching to
it.
Even though using FOURCC doesn't fit under the notion of a videomode,
using
one of .vmode bits is too tempting, so, I would actually take the plunge
and
use FB_VMODE_FOURCC.
>>>
>>> Another option would be to consider any grayscale> 1 value as a FOURCC.
>>> I've
>>> briefly checked the in-tree drivers: they only assign grayscale with 0 or
>>> 1,
>>> and check whether grayscale is 0 or different than 0. If a userspace
>>> application only sets grayscale> 1 when talking to a driver that
>>> supports the
>>> FOURCC-based API, we could get rid of the flag.
>>>
>>> What can't be easily found out is whether existing applications set
>>> grayscale
>>> to a> 1 value. They would break when used with FOURCC-aware drivers if
>>> we
>>> consider any grayscale> 1 value as a FOURCC. Is that a risk we can take
>>> ?
>>
>> I think we can. I'd expect applications to use either 1 or -1 (i.e.
>> all ones), both are
>> invalid FOURCC values.
>>
>> Still, I prefer the nonstd way.
>> And limiting traditional nonstd values to the lowest 24 bits (there
>> are no in-tree
>> drivers using the highest 8 bits, right?).
>
> Okay, it would be okay for me to
> - write raw FOURCC values in nonstd, enable FOURCC mode if upper byte != 0
> - not having an explicit flag to enable FOURCC
> - in FOURCC mode drivers must set visual to FB_VISUAL_FOURCC
> - making support of FOURCC visible to userspace by capabilites |=
> FB_CAP_FOURCC
>
> The capabilities is not strictly necessary but I think it's very useful as
> - it allows applications to make sure the extension is supported (for
> example to adjust the UI)
> - it allows applications to distinguish whether a particular format is not
> supported or FOURCC at all
> - it allows signaling further extensions of the API
> - it does not hurt, one line per driver and still some bytes in fixinfo free
>
>
> So using it would look like this:
> - the driver must have capabilities |= FB_CAP_FOURCC
> - the application may check capabilities to know whether FOURCC is supported
> - the application may write a raw FOURCC value in nonstd to request changing
> to FOURCC mode with this format
> - when the driver switches to a FOURCC mode it must have visual =
> FB_VISUAL_FOURCC and the current FOURCC format in nonstd
> - the application should check visual and nonstd to make sure it gets what
> it wanted
As several of the FOURCC formats duplicate formats you can already
specify in some
other way (e.g. the RGB and greyscale formats), and as FOURCC makes life easier
for the application writer, I'm wondering whether it makes sense to add FOURCC
support in the generic layer for drivers that don't support it? I.e.
the generic layer would
fill in fb_var_screeninfo depending on the requested FOURCC mode, if possible.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] V4L: add two new ioctl()s for multi-size videobuffer management
On Tue, 26 Jul 2011, Hans Verkuil wrote: > On Tuesday, July 26, 2011 13:44:28 Sakari Ailus wrote: > > Hi Hans and Guennadi, > > > > > > I realized that it is not clear from the documentation whether it is > > > possible to call > > > VIDIOC_REQBUFS and make additional calls to VIDIOC_CREATE_BUFS afterwards. > > > > That's actually a must if one wants to release buffers. Currently no other > > method than requesting 0 buffers using REQBUFS is provided (apart from > > closing the file handle). > > I was referring to the non-0 use-case :-) > > > > I can't remember whether the code allows it or not, but it should be > > > clearly documented. > > > > I would guess no user application would have to call REQBUFS with other than > > zero buffers when using CREATE_BUFS. This must be an exception if mixing > > REQBUFS and CREATE_BUFS is not allowed in general. That said, I don't see a > > reason to prohibit either, but perhaps Guennadi has more informed opinion > > on this. > > > > > > > > > Future functionality which would be nice: > > > > > > > > > > > > - Format counters. Every format set by S_FMT (or gotten by G_FMT) > > > > > > should > > > > > > come with a counter value so that the user would know the format > > > > > > of > > > > > > dequeued buffers when setting the format on-the-fly. Currently > > > > > > there are > > > > > > only bytesperline and length, but the format can't be explicitly > > > > > > determined from those. > > > > > > Actually, the index field will give you that information. When you create > > > the > > > buffers you know that range [index, index + count - 1] is associated with > > > that > > > specific format. > > > > Some hardware is able to change the format while streaming is ongoing (for > > example: OMAP 3). The problem is that the user should be able to know which > > frame has the new format. How exactly does this work or should it work? You mean, you just configure your hardware with new frame size parameters without stopping the current streaming, and the ISP will change frame sizes, beginning with some future frame? How does the driver then get to know, which frame already has the new sizes? You actually want to know this in advance to already queue a suitably sized buffer to the hardware? Thanks Guennadi > Ah, of course. > > > Of course one could stop streaming but this would mean lost frames. > > > > A flag has been proposed to this previously. That's one option but forces > > the user to keep track of the changes since only one change is allowed until > > it has taken effect. > > Something to discuss next week, I think. > > Regards, > > Hans > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [GIT PULL for v3.0] media updates for v3.1
> Hi, > > On 07/31/2011 12:38 PM, Mauro Carvalho Chehab wrote: >> Em 31-07-2011 04:57, Hans de Goede escreveu: >>> Hi, >>> >>> I notice that Hans Verkuil's patches to make poll >>> report what is being polled to drivers, and my corresponding >>> patches for adding event support to pwc are not included, >>> what is the plan with these? >> >> The changes for the vfs code need vfs maintainer's ack, or to go >> via their tree. So, we need to wait for them to merge/send it >> upstream, before being able to merge the patches that depend on it. > > Hmm, has anyone had any direct communications with the vfs maintainer > about this? If not I think we should have some direct communications > on this, otherwise we may end up waiting a long long time. He was CC-ed on this from the very beginning... Regards, Hans > > 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: [GIT PULL for v3.0] media updates for v3.1
Hi, On 07/31/2011 12:38 PM, Mauro Carvalho Chehab wrote: Em 31-07-2011 04:57, Hans de Goede escreveu: Hi, I notice that Hans Verkuil's patches to make poll report what is being polled to drivers, and my corresponding patches for adding event support to pwc are not included, what is the plan with these? The changes for the vfs code need vfs maintainer's ack, or to go via their tree. So, we need to wait for them to merge/send it upstream, before being able to merge the patches that depend on it. Hmm, has anyone had any direct communications with the vfs maintainer about this? If not I think we should have some direct communications on this, otherwise we may end up waiting a long long time. 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
