[PATCH] v4l: soc_camera: fix bound checking of mbus_fmt[] index
When code <= V4L2_MBUS_FMT_FIXED soc_mbus_get_fmtdesc returns a pointer to
mbus_fmt[x], where x < 0. Fix this.
Signed-off-by: Baruch Siach
---
drivers/media/video/soc_mediabus.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/soc_mediabus.c
b/drivers/media/video/soc_mediabus.c
index f8d5c87..a2808e2 100644
--- a/drivers/media/video/soc_mediabus.c
+++ b/drivers/media/video/soc_mediabus.c
@@ -136,6 +136,8 @@ const struct soc_mbus_pixelfmt *soc_mbus_get_fmtdesc(
{
if ((unsigned int)(code - V4L2_MBUS_FMT_FIXED) > ARRAY_SIZE(mbus_fmt))
return NULL;
+ if ((unsigned int)code <= V4L2_MBUS_FMT_FIXED)
+ return NULL;
return mbus_fmt + code - V4L2_MBUS_FMT_FIXED - 1;
}
EXPORT_SYMBOL(soc_mbus_get_fmtdesc);
--
1.6.6.1
--
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 0/4] DocBook additions for V4L new formats
On 02/17/10 09:06, Mauro Carvalho Chehab wrote: > Adds DocBook items for Bayer and two proprietary formats used on gspca. > > In the past, a few targets were generated at the Mercurial development > tree. However, at the beginning of this year, we moved to use -git as > the primary resource. So, the Makefile logic to autogenerate those > targets needs to be moved to git as well. > > While here, I noticed that DocBook is too verbose to generate the > htmldocs target. So, make it less verbose, if V=0. > > Guennadi Liakhovetski (1): > V4L/DVB: v4l: document new Bayer and monochrome pixel formats > > Mauro Carvalho Chehab (3): > DocBook/Makefile: Make it less verbose > DocBook: Add rules to auto-generate some media docbooks > DocBook/v4l/pixfmt.xml: Add missing formats for gspca cpia1 and > sn9c2028 drivers Hi Mauro, Patches 1 & 3 are OK. I'm having problems with patch 2/4 when I use O=DOCDIR on the make command (which I always do). videodev2.h.xml is not being generated, and after that it goes downhill. I will let you know more when I have more info, or you or Guennadi can send a fixup patch for that. > Documentation/DocBook/Makefile | 493 +++- > Documentation/DocBook/dvb/frontend.h.xml | 415 -- > Documentation/DocBook/media-entities.tmpl| 383 -- > Documentation/DocBook/media-indices.tmpl | 89 -- > Documentation/DocBook/v4l/pixfmt-srggb10.xml | 90 ++ > Documentation/DocBook/v4l/pixfmt-srggb8.xml | 67 + > Documentation/DocBook/v4l/pixfmt-y10.xml | 79 ++ > Documentation/DocBook/v4l/pixfmt.xml | 18 +- > Documentation/DocBook/v4l/videodev2.h.xml| 1757 > -- > 9 files changed, 738 insertions(+), 2653 deletions(-) > delete mode 100644 Documentation/DocBook/dvb/frontend.h.xml > delete mode 100644 Documentation/DocBook/media-entities.tmpl > delete mode 100644 Documentation/DocBook/media-indices.tmpl > create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb10.xml > create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb8.xml > create mode 100644 Documentation/DocBook/v4l/pixfmt-y10.xml > delete mode 100644 Documentation/DocBook/v4l/videodev2.h.xml > -- ~Randy -- 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] V4L/DVB: lgs8gxx: remove firmware for lgs8g75
On Tue, 2010-02-02 at 13:40 -0200, Mauro Carvalho Chehab wrote: > Mauro Carvalho Chehab wrote: > > Ben Hutchings wrote: > >> The recently added support for lgs8g75 included some 8051 machine code > >> without accompanying source code. Replace this with use of the > >> firmware loader. > >> > >> Compile-tested only. > >> > >> Signed-off-by: Ben Hutchings > >> --- > >> This firmware can be added to linux-firmware.git instead, and I will be > >> requesting that very shortly. > > > > Had you submitted a patch for it already? Could you please test the patch > > before we commit it at the tree? > > Ping. I'm still trying to get some response from David Woodhouse to my previous pull request. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Re: [PATCH] DTV2000 H Plus issues
On Wed, Feb 17, 2010 at 7:08 PM, Mauro Carvalho Chehab wrote: > OK. Then, I need your SOB for the 95% of the code, and his SOB for the > remaining ;) Yeah, my plan at this point was to submit a PULL request once I felt the driver is stable (and I had already offered to apply his incremental patches onto my tree before said pull request). 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] DTV2000 H Plus issues
Devin Heitmueller wrote: > On Wed, Feb 17, 2010 at 6:51 PM, Mauro Carvalho Chehab > wrote: >> Hi Istvan, >> >> istva...@mailbox.hu wrote: >>> The attached new patches contain all the previous changes merged, and >>> are against the latest v4l-dvb revision. >> Please provide your Signed-off-by. This is a basic requirement for your >> driver to be accepted. Please read: >>http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches >> >> for instructions on how to submit a patch. > > Hi Mauro, > > I would hate to come across as a jerk here, but he cannot provide his > SOB for this patch, as I wrote about 95% of the code here. It's > derived from a tree I have been working on for the PCTV 340e: > > http://kernellabs.com/hg/~dheitmueller/pctv-340e-2/ > > I know that istvan wants to see the support merged, but he is going to > have to wait a bit longer since he is not the author or maintainer of > the driver in question. OK. Then, I need your SOB for the 95% of the code, and his SOB for the remaining ;) -- Cheers, 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: image capture with ov9655 camera and intel pxa270C5C520
Hello everyone,
i've worked recently on my source code for the image capturing duties.
With the Hint of Mr. Herbrechtsmeier to use YUV everything worked quite
well and now i get no failure message anymore and even the image.txt
file gets filled with values separated by tabulators and a newline after
each "picture" line.
This numerical values should represent the colour values of each pixel.
Now the main proble is, that every value is zero...
Hint: the initialisation of mmap with NULL let's the system choose an
empty area in the stack where the values from the camera memory can be
mapped to.
Now my question is. Has anyone an idea why there are only zeros?
Is it an failure in the program flow?
Is there something missing?
Do i need an loop or delays for the image capturing process?
I hope that someone can give me a hint or a solution for my problem.
Regards,
Kai Tiwisina
Stefan Herbrechtsmeier schrieb:
Hi,
Kai Tiwisina schrieb:
Hello everyone,
here is a little update to my question and to the source code.
After i implemented an function with the VIDIOC_ENUM_FMT ioctl i
recognized, that only two formats are support by the driver by now.
(Thanks to Mr. Liakhovetski by the way ;) )
The output.txt shows the output of this function and mentions the two
different types.
One is definately the V4L2_PIX_FMT_YUYV format but i don't know the
other one exactly...
I changed my set_format function after i got this information and
unfortunately nothing has changed...
Perhaps there are some further possibilities to solve this Problem.
Maybe there have some other v4l2 structures to be initialized, befor
the VIDIOC_S_FMT ioctl runs?
You have to set fmt.fmt.pix.field toV4L2_FIELD_ANY and only YUV is
supported at the moment.
Regards,
Stefan
Guennadi Liakhovetski wrote:
Hi Kai
On Mon, 23 Nov 2009, Kai Tiwisina wrote:
Hello,
my name is Kai Tiwisina and i'm a student in germany and i'm trying
to communicate with a Omnivision ov9655 camera which is atteched
with my embedded linux system via the v4l commands.
I've written a small testprogram which should grow step by step
while i'm trying one ioctl after another.
Everything worked fine until i tried to use the VIDIOC_S_FMT ioctl.
It's always giving me an "invalid argument" failure and i don't
know why.
Since you don't seem to have the source of the driver at hand, I'd
suggest to use the VIDIOC_ENUM_FMT
http://v4l2spec.bytesex.org/spec/r8367.htm ioctl to enumerate all
pixel formats supported be the driver. If the driver you're using is
the same, that Stefan (cc'ed) has submitted to the list, then indeed
it does not support the V4L2_PIX_FMT_RGB555 format, that you're
requesting, only various YUV (and a Bayer?) formats.
Perhaps someone of you is able to help me with this ioctl and give
an advice for a simple flow chart for a single frame image capture.
Which ioctl steps are neccessary and where do i need loops and for
what, because the capture-example.c from bytesex.org is way too
general for my purpose.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
/*
Name: stream_test.c
Author : Kai Tiwisina
Version :
Copyright :
Description : Output of camera stream in text file
*/
#include
#include
#include
#include // open() is in here
#include // close() is in here
#include // used for desolving error
numbers
#include // ioctl() is in here
#include
#include // jpeg_markers are defined in here
#include // for videodev2.h
#include // VIDIOC_QUERYCAP & struct v4ls_capability are
defined in here
#define CLEAR(x) memset(&(x), 0, sizeof(x))
#define v4l2_fourcc(a,b,c,d)
(((__u32)(a)<<0)|((__u32)(b)<<8)|((__u32)(c)<<16)|((__u32)(d)<<24))
#define NUMEL 2 // the BeBot cam doesn't
support more formats!
void print_errno(char *s); //returns errno argument as value and expression
void open_device(); //opens a v4l device returning new file descriptor and
gives error info if necessary
void query_cap();
void request_buffer();
void stream_on();
void query_buffer();
void memory_mapping();
void stream_off();
void get_format();
void set_format();
void enum_format();
static struct v4l2_requestbuffers buffer;
static struct v4l2_buffer q_buffer;
static struct v4l2_format f_type;
static int fd; // fd
is the file descriptor
int main(void)
{
open_device();
printf("\n\n*New file descriptor: %i*\n\n",fd);
query_cap();
request_buffer();
enum_format();
set_format();
get_format();
s
Re: [PATCH] DTV2000 H Plus issues
On Wed, Feb 17, 2010 at 6:51 PM, Mauro Carvalho Chehab wrote: > Hi Istvan, > > istva...@mailbox.hu wrote: >> The attached new patches contain all the previous changes merged, and >> are against the latest v4l-dvb revision. > > Please provide your Signed-off-by. This is a basic requirement for your > driver to be accepted. Please read: > http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches > > for instructions on how to submit a patch. Hi Mauro, I would hate to come across as a jerk here, but he cannot provide his SOB for this patch, as I wrote about 95% of the code here. It's derived from a tree I have been working on for the PCTV 340e: http://kernellabs.com/hg/~dheitmueller/pctv-340e-2/ I know that istvan wants to see the support merged, but he is going to have to wait a bit longer since he is not the author or maintainer of the driver in question. 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] DTV2000 H Plus issues
Hi Istvan, istva...@mailbox.hu wrote: > The attached new patches contain all the previous changes merged, and > are against the latest v4l-dvb revision. Please provide your Signed-off-by. This is a basic requirement for your driver to be accepted. Please read: http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches for instructions on how to submit a patch. Cheers, Mauro. > > By the way, someone on a forum reported having a DTV1800 H card with > a PCI ID of 107d:6f38. This seems to differ from the already supported > DTV1800 H version (107d:6654) by having an XC4000 tuner instead of > XC3028. From the Windows INF files it seems this card is very similar > to the DTV2000 H Plus, but there is no GPIO for selecting antenna/cable > input. > > On 02/11/2010 08:16 PM, istva...@mailbox.hu wrote: > >> Update: the following patch, which should be applied after the previous >> ones, makes a few additional changes to the XC4000 driver: >> - adds support for DTV7 >> - implements power management >> - adds a mutex and locking for tuner operations >> - some unused or unneeded code has been removed >> >> On 02/09/2010 06:35 PM, istva...@mailbox.hu wrote: >> >>> There are two separate patches for v4l-dvb revision 28f5eca12bb0: the >>> first one adds the XC4000 driver, while the second one adds support for >>> the Leadtek WinFast DTV2000H Plus card in the CX88 driver. >>> >>> http://www.sharemation.com/IstvanV/v4l/xc4000-28f5eca12bb0.patch >>> http://www.sharemation.com/IstvanV/v4l/cx88-dtv2000h+-28f5eca12bb0.patch >>> >>> These new firmware files are more complete than the previous ones, but >>> are not compatible with the original driver. Both version 1.2 and 1.4 >>> are available: >>> >>> http://www.sharemation.com/IstvanV/v4l/xc4000-1.2.fw >>> http://www.sharemation.com/IstvanV/v4l/xc4000-1.4.fw >>> >>> The following simple utility was used for creating the firmware files. >>> >>> http://www.sharemation.com/IstvanV/v4l/xc4000fw.c -- Cheers, 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: alevt-dvb 1.7.0: new version, should be free from bugs now
--- On Sat, 2/13/10, Chicken Shack wrote: > From: Chicken Shack > Subject: Re: alevt-dvb 1.7.0: new version, should be free from bugs now > To: "Francesco Lavra" > Cc: "Linux media" > Date: Saturday, February 13, 2010, 6:11 AM > Am Samstag, den 13.02.2010, 10:56 > +0100 schrieb Francesco Lavra: > > On Thu, 2010-02-11 at 22:26 +0100, Chicken Shack > wrote: > > > Hi, > > > > > > my way to say "Thank you". > > > Just enjoy this tiny little program with the > latest kernel. > > > Debian files for producing a Debian binary > included. > > > This version needs libzvbi as dependency to run. > > > Thanks to Tom Zoerne for the implemention patch > that I found by > > > accident. > > > > > > > > > Cheers > > > CS > > > > > > P. S.: There are two issues in the TODO list. > > > Please drop me a note if you can fix those issues > mentioned there. > > > > > > ENJOY! Does this version work with recent kernels without reverting dvb-demux? > > > > What about adding this program to v4l-dvb (under > v4l2-apps/util/)? > > AFAIK, alevt currently doesn't have a proper site > where development > > could take place. > > I think it would enjoy a better maintenance if it was > hosted in vl4-dvb, > > and it could be an additional testing tool useful for > drivers > > development. > > And it is GPL-licensed. > > > > Francesco > > Hi Francesco, > > I wish your point of view were right. But it isn't at all. > > There are a couple of reasons for that: > > 1. As long as there is not at least one person doing the > necessary DVB > maintenance sponsored by some industry there will never be > a significant > change at all. > The roots of the DVB project were a company called > Convergence media in > Cologne, Germany. When this company broke down, the > relevant persons > vanished one by one leaving behind their heritage. > For details ask the administrator of linuxtv.org, Johannes > Stezenbach. > > 2. Right now the personnel of the DVB development appears > and vanishes > whenever they want to. It's completely absurd to build up a > kernel > branch nearly only on volunteers, but that's the way it > is. > Even Linus Torvalds does not see that there should be a > change: > Do everything to win skilled ans sponsored people for the > work to be > done. > > 3. I do not trust in the capabilities of the man who is > maintaining the > actual dvb-apps. His mouth is too big, his thoughts are > malicious very > often, his experience level is rather low, and his > capabilities aren't > even mediocre. > And worst of all: exaggerated egoism instead of real > partnership work, > real team work, same problem as with Mauro Carvalho > Chehab. > > Applying for a job these people wouldn't even pass at least > one > so-called assessment test (which is checking out the human > skills). > But there seem to be places in the world where this kind of > tests aren't > mandatory at all. > > > Basic rule: Centralization itself does not resolve any > problem at all. > You need qualified people and, as a minimum adequate > demand, at least > one sponsored person if the job is not only a "fun bringer" > but at least > in significant parts a rather "unthankful" one. > > DVB development at linuxtv.org has been a stepchild for > more than 5 > years now. > All the former significant people have vanished. > > As long as this continues we're on our own: It's us picking > up the > issues, it's us to investigate etc. > We cannot continue to delegate issues in the traditional > paternalistic > spirit - at least not with these people. > > > To get back to the program: > > I still do not comprehend why alevt-dvb hangs when the > transponder is > changed. > I've found out that if you start it without any commandline > parameters > it does the following: > > a. read and parse the PAT > b. read and parse the SDT > c. read and parse the PMT > > It will always start reading the videotext of the program > with the first > found (i. e. the lowest) PMT. > > 2 effects out of its standard behaviour: > > 1. When you change the channel within the current > transponder the > program takes a short break and then comes back continuing > to read the > same PMT. It will not follow the external player doing the > tuning to the > new channel. > > 2. When you change the channel AND change the transponder > the program > will hang and will only get finished by _killall_. Or you can tune back to the original transponder or a transponder with the same provider, then alevt works again. So there is may be a check for the provider name. > > The task is to change that behaviour. alevt-dvb should > follow the new > channel. In mtt (by Gerd Hoffmann @ bytesex.org - xawtv-4.0 > pre) a > module called dvb-monitor does that job. > > Cheers > > CS Thanks for your this version. Emil -- 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-in
[PATCH 2/2] V4L/DVB: az6027: az6027_read_mac_addr is currently unused
drivers/media/dvb/dvb-usb/az6027.c:759: warning: ‘az6027_read_mac_addr’ defined
but not used
While there's some code that uses it, it is currently commented. So, comment
also
the function itself.
CC: Manu Abraham
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb/dvb-usb/az6027.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/az6027.c
b/drivers/media/dvb/dvb-usb/az6027.c
index e8d5d05..919ca94 100644
--- a/drivers/media/dvb/dvb-usb/az6027.c
+++ b/drivers/media/dvb/dvb-usb/az6027.c
@@ -754,13 +754,13 @@ static int az6027_ci_init(struct dvb_usb_adapter *a)
return 0;
}
-
+#if 0
static int az6027_read_mac_addr(struct dvb_usb_device *d, u8 mac[6])
{
az6027_usb_in_op(d, 0xb7, 6, 0, &mac[0], 6);
return 0;
}
-
+#endif
static int az6027_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t
voltage)
{
--
1.6.6.1
--
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 1/2] V4L/DVB: az6027: IR RC keys are using the old struct with 3 parameters, instead of 2
drivers/media/dvb/dvb-usb/az6027.c:390: warning: excess elements in struct
initializer
drivers/media/dvb/dvb-usb/az6027.c:390: warning: (near initialization for
‘az6027_rc_keys[0]’)
drivers/media/dvb/dvb-usb/az6027.c:391: warning: excess elements in struct
initializer
drivers/media/dvb/dvb-usb/az6027.c:391: warning: (near initialization for
‘az6027_rc_keys[1]’)
CC: Manu Abraham
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb/dvb-usb/az6027.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/az6027.c
b/drivers/media/dvb/dvb-usb/az6027.c
index 30fd046..e8d5d05 100644
--- a/drivers/media/dvb/dvb-usb/az6027.c
+++ b/drivers/media/dvb/dvb-usb/az6027.c
@@ -387,8 +387,8 @@ static int az6027_streaming_ctrl(struct dvb_usb_adapter
*adap, int onoff)
/* keys for the enclosed remote control */
static struct dvb_usb_rc_key az6027_rc_keys[] = {
- { 0x00, 0x01, KEY_1 },
- { 0x00, 0x02, KEY_2 },
+ { 0x0001, KEY_1 },
+ { 0x0002, KEY_2 },
};
/* remote control stuff (does not work with my box) */
--
1.6.6.1
--
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 4/4] V4L/DVB: v4l: document new Bayer and monochrome pixel formats
On Wed, 17 Feb 2010, Mauro Carvalho Chehab wrote: > Guennadi, > > Your original patch were against the out-of-tree "media-specs/Makefile", > present > only at the -hg tree. > > The way my conversion scripts work is that they'll convert the patches into a > patch that can be applied directly into -git. Among other things, all > changes on files outside the kernel tree are simply discarded by them. > > Also, before patch 2/4, such addition won't be possible. > > So, what happened here is that, after importing from your hg tree, I noticed > -git compilation breakage. So, I ported the autobuild bits for media-entities > & co, > manually added the missing pixfmt xml's and removed the duplicate symbol for > one > of the bayer standards. > > That's said, I don't really have any preference about the order where the > files appear > at the Makefile. I have no objection if you prefer to add them on any other > random order. > > In a matter of fact, IMO, the better is to later write a patch that discards > this static list of files, auto-generating it dynamically. > > So, if you really prefer a different order, please re-submit another version > for this patch. No, no problem with me, it doesn't bother me _that_ much;) Thanks for fixing stuff! Thanks Guennadi --- Guennadi Liakhovetski -- 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 4/4] V4L/DVB: v4l: document new Bayer and monochrome pixel formats
Guennadi Liakhovetski wrote: > On Wed, 17 Feb 2010, Mauro Carvalho Chehab wrote: > >> Document all four 10-bit Bayer formats, 10-bit monochrome and a missing >> 8-bit Bayer formats. >> >> [mche...@redhat.com: remove duplicated symbol for V4L2-PIX-FMT-SGRBG10] >> Signed-off-by: Guennadi Liakhovetski >> Signed-off-by: Mauro Carvalho Chehab >> --- >> Documentation/DocBook/Makefile |3 + >> Documentation/DocBook/v4l/pixfmt-srggb10.xml | 90 >> ++ >> Documentation/DocBook/v4l/pixfmt-srggb8.xml | 67 +++ >> Documentation/DocBook/v4l/pixfmt-y10.xml | 79 ++ >> Documentation/DocBook/v4l/pixfmt.xml |8 +-- >> 5 files changed, 242 insertions(+), 5 deletions(-) >> create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb10.xml >> create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb8.xml >> create mode 100644 Documentation/DocBook/v4l/pixfmt-y10.xml >> >> diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile >> index 65deaba..1c796fc 100644 >> --- a/Documentation/DocBook/Makefile >> +++ b/Documentation/DocBook/Makefile >> @@ -309,6 +309,9 @@ V4L_SGMLS = \ >> v4l/pixfmt-yuv422p.xml \ >> v4l/pixfmt-yuyv.xml \ >> v4l/pixfmt-yvyu.xml \ >> +v4l/pixfmt-srggb10.xml \ >> +v4l/pixfmt-srggb8.xml \ >> +v4l/pixfmt-y10.xml \ > > Mauro, why didn't you put them next to similar formats, as in my original > patch? Guennadi, Your original patch were against the out-of-tree "media-specs/Makefile", present only at the -hg tree. The way my conversion scripts work is that they'll convert the patches into a patch that can be applied directly into -git. Among other things, all changes on files outside the kernel tree are simply discarded by them. Also, before patch 2/4, such addition won't be possible. So, what happened here is that, after importing from your hg tree, I noticed -git compilation breakage. So, I ported the autobuild bits for media-entities & co, manually added the missing pixfmt xml's and removed the duplicate symbol for one of the bayer standards. That's said, I don't really have any preference about the order where the files appear at the Makefile. I have no objection if you prefer to add them on any other random order. In a matter of fact, IMO, the better is to later write a patch that discards this static list of files, auto-generating it dynamically. So, if you really prefer a different order, please re-submit another version for this patch. Cheers, 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 4/4] V4L/DVB: v4l: document new Bayer and monochrome pixel formats
On Wed, 17 Feb 2010, Mauro Carvalho Chehab wrote: > Document all four 10-bit Bayer formats, 10-bit monochrome and a missing > 8-bit Bayer formats. > > [mche...@redhat.com: remove duplicated symbol for V4L2-PIX-FMT-SGRBG10] > Signed-off-by: Guennadi Liakhovetski > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/DocBook/Makefile |3 + > Documentation/DocBook/v4l/pixfmt-srggb10.xml | 90 > ++ > Documentation/DocBook/v4l/pixfmt-srggb8.xml | 67 +++ > Documentation/DocBook/v4l/pixfmt-y10.xml | 79 ++ > Documentation/DocBook/v4l/pixfmt.xml |8 +-- > 5 files changed, 242 insertions(+), 5 deletions(-) > create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb10.xml > create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb8.xml > create mode 100644 Documentation/DocBook/v4l/pixfmt-y10.xml > > diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile > index 65deaba..1c796fc 100644 > --- a/Documentation/DocBook/Makefile > +++ b/Documentation/DocBook/Makefile > @@ -309,6 +309,9 @@ V4L_SGMLS = \ > v4l/pixfmt-yuv422p.xml \ > v4l/pixfmt-yuyv.xml \ > v4l/pixfmt-yvyu.xml \ > + v4l/pixfmt-srggb10.xml \ > + v4l/pixfmt-srggb8.xml \ > + v4l/pixfmt-y10.xml \ Mauro, why didn't you put them next to similar formats, as in my original patch? > v4l/pixfmt.xml \ > v4l/vidioc-cropcap.xml \ > v4l/vidioc-dbg-g-register.xml \ Thanks Guennadi --- Guennadi Liakhovetski -- 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 4/4] V4L/DVB: v4l: document new Bayer and monochrome pixel formats
Randy,
Mauro Carvalho Chehab wrote:
> Document all four 10-bit Bayer formats, 10-bit monochrome and a missing
> 8-bit Bayer formats.
>
> [mche...@redhat.com: remove duplicated symbol for V4L2-PIX-FMT-SGRBG10]
> Signed-off-by: Guennadi Liakhovetski
> Signed-off-by: Mauro Carvalho Chehab
Although patch 0/4 has the correct authorship:
Guennadi Liakhovetski (1):
V4L/DVB: v4l: document new Bayer and monochrome pixel formats
Unfortunately git format-patch didn't preserve the authorship on this patch
(or my emailer removed the additional From:)
Please fix it before applying:
From: Guennadi Liakhovetski
If you prefer, I can apply this series on my tree after your ack.
Cheers,
Mauro.
> ---
> Documentation/DocBook/Makefile |3 +
> Documentation/DocBook/v4l/pixfmt-srggb10.xml | 90
> ++
> Documentation/DocBook/v4l/pixfmt-srggb8.xml | 67 +++
> Documentation/DocBook/v4l/pixfmt-y10.xml | 79 ++
> Documentation/DocBook/v4l/pixfmt.xml |8 +--
> 5 files changed, 242 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb10.xml
> create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb8.xml
> create mode 100644 Documentation/DocBook/v4l/pixfmt-y10.xml
>
> diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
> index 65deaba..1c796fc 100644
> --- a/Documentation/DocBook/Makefile
> +++ b/Documentation/DocBook/Makefile
> @@ -309,6 +309,9 @@ V4L_SGMLS = \
> v4l/pixfmt-yuv422p.xml \
> v4l/pixfmt-yuyv.xml \
> v4l/pixfmt-yvyu.xml \
> + v4l/pixfmt-srggb10.xml \
> + v4l/pixfmt-srggb8.xml \
> + v4l/pixfmt-y10.xml \
> v4l/pixfmt.xml \
> v4l/vidioc-cropcap.xml \
> v4l/vidioc-dbg-g-register.xml \
> diff --git a/Documentation/DocBook/v4l/pixfmt-srggb10.xml
> b/Documentation/DocBook/v4l/pixfmt-srggb10.xml
> new file mode 100644
> index 000..7b27409
> --- /dev/null
> +++ b/Documentation/DocBook/v4l/pixfmt-srggb10.xml
> @@ -0,0 +1,90 @@
> +
> +
> + V4L2_PIX_FMT_SRGGB10 ('RG10'),
> + V4L2_PIX_FMT_SGRBG10 ('BA10'),
> + V4L2_PIX_FMT_SGBRG10 ('GB10'),
> + V4L2_PIX_FMT_SBGGR10 ('BG10'),
> +
> + &manvol;
> +
> +
> + id="V4L2-PIX-FMT-SRGGB10">V4L2_PIX_FMT_SRGGB10
> + id="V4L2-PIX-FMT-SGRBG10">V4L2_PIX_FMT_SGRBG10
> + id="V4L2-PIX-FMT-SGBRG10">V4L2_PIX_FMT_SGBRG10
> + id="V4L2-PIX-FMT-SBGGR10">V4L2_PIX_FMT_SBGGR10
> + 10-bit Bayer formats expanded to 16 bits
> +
> +
> + Description
> +
> + The following four pixel formats are raw sRGB / Bayer formats with
> +10 bits per colour. Each colour component is stored in a 16-bit word, with 6
> +unused high bits filled with zeros. Each n-pixel row contains n/2 green
> samples
> +and n/2 blue or red samples, with alternating red and blue rows. Bytes are
> +stored in memory in little endian order. They are conventionally described
> +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
> +formats
> +
> +
> + V4L2_PIX_FMT_SBGGR10 4 × 4
> +pixel image
> +
> +
> + Byte Order.
> + Each cell is one byte, high 6 bits in high bytes are 0.
> +
> +
> +
> +
> +
> + start + 0:
> + B00low
> + B00high
> + G01low
> + G01high
> + B02low
> + B02high
> + G03low
> + G03high
> +
> +
> + start + 8:
> + G10low
> + G10high
> + R11low
> + R11high
> + G12low
> + G12high
> + R13low
> + R13high
> +
> +
> + start + 16:
> + B20low
> + B20high
> + G21low
> + G21high
> + B22low
> + B22high
> + G23low
> + G23high
> +
> +
> + start + 24:
> + G30low
> + G30high
> + R31low
> + R31high
> + G32low
> + G32high
> + R33low
> + R33high
> +
> +
> +
> +
> +
> +
> +
> +
> +
> diff --git a/Documentation/DocBook/v4l/pixfmt-srggb8.xml
> b/Documentation/DocBook/v4l/pixfmt-srggb8.xml
> new file mode 100644
> index 000..2570e3b
> --- /dev/null
> +++ b/Documentation/DocBook/v4l/pixfmt-srggb8.xml
> @@ -0,0 +1,67 @@
> +
> +
> + V4L2_PIX_FMT_SRGGB8 ('RGGB')
> + &manvol;
> +
> +
> + V4L2_PIX_FMT_SRGGB8
> + Bayer RGB format
> +
> +
> + Description
> +
> + This is commonly the native format of digital cameras,
> +reflecting the arrangement of sensors on
V4L on Blackfin, non-MMU issues
Apologies for any ignorance here, I have been out of kernel/V4l
development for some time, and non-MMU kernel development is
relatively new to me. I am awaiting approval for the uclinux
mailing list, so haven't CCed there. I cover a lot of ground in
this post, so bear with me.
I'm trying to stream video from a Blackfin board - either
via USB initially, or a PPI connected camera. c.f.:
http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:usb_video_device_class
http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:ffmpeg
I am using trunk uclinux sources. It should be obvious from the above that this
once worked.
The camera I actually want to use is an OV7725, however for hardware reasons I
needn't go into here, that isn't immediately possible. So, I switched to a USB
Logitech Quickcam chat, which has an unusual pixel format, that seems to be only
supported by vlc, and not ffmpeg.
The camera I have now is a Chicony chipset using the uvcvideo driver. which
behaves as expected under x86 Linux with ffmpeg streaming, etc.
For blackfin/nommu, there seem to be some unresolved problems with uvcvideo:
http://www.mail-archive.com/linux-uvc-de...@lists.berlios.de/msg03530.html
That is, attempts to mmap the uvcvideo device fail. With the above message
in mind, I put in a get_unmapped function into uvc_v4l.c, with code similar
to that in the mmap call. This seemed to do the right thing, although
the problem now was that I ran into:
http://lists.berlios.de/pipermail/linux-uvc-devel/2008-December/004346.html
In particular, the "uvcvideo: Failed to submit URB 0 (-90)"
As best I can tell, comprehensive highspeed patches for musb have been submitted
a few times, but rejected for various reasons, although there's some
partial support. Please correct me if I'm wrong.
As for the get_unmapped function, the only other v4l driver that has this
function seems to blackfin_cam.c, so it looks like an idea that was
taken up, then later forgotten about.
And so, with little else to try, I took a look at the vivi driver:
ffmpeg -v 0 -f video4linux2 -r 10 -s 320x240 -i /dev/video0 -an -qscale
...
[video4linux2 @ 0x1112010]mmap: No such device
/dev/video0: I/O error occurred
Which I think is the same get_unmapped thing above. I have no yet
tried a function here for this.
And then:
ffmpeg -v 0 -f video4linux -r 10 -s 320x240 -i /dev/video0 -an -qscale 2
...
INFO: task ffmpeg:459 blocked for more than 120 seconds.
...
frame 1 : <0x004433fc> { _schedule + 0x28c }
frame 2 : <0x00444272> { ___down_write_nested + 0x66 }
address : <0x0023f26e> { _vmalloc_user + 0x2a }
address : <0x00442e48> { _printk + 0x10 }
address : <0x00392a04> { ___videobuf_iolock + 0x84 }
address : <0x00393962> { _buffer_prepare + 0xc2 }
address : <0x0039223e> { ___videobuf_read_start + 0x7a }
address : <0x0039253c> { _videobuf_read_stream + 0x16c }
address : <0x00394190> { _vivi_read + 0x38 }
address : <0x0023eb9c> { _do_mmap_private + 0x10c }
address : <0x0023ee44> { _do_mmap_pgoff + 0x134 }
address : <0x0023c230> { _sys_mmap_pgoff + 0x4c }
address : <0xffa0089e> { _system_call + 0x6a }
address : <0x02743202> /* kernel dynamic memory */
address : <0xffa00fb8> { _evt_system_call + 0x64 }
So, can anyone shed any light on any of these?
--
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: Fourcc for multiplanar formats
Hi Pawel, Any progress on the RFC for allowing user applications to specify separate user ptr for each plane of a multi-planar format? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com >-Original Message- >From: Hans Verkuil [mailto:hverk...@xs4all.nl] >Sent: Wednesday, February 17, 2010 1:42 PM >To: Karicheri, Muralidharan >Cc: Pawel Osciak; linux-media@vger.kernel.org; Sylwester Nawrocki; 'Kamil >Debski' >Subject: Re: Fourcc for multiplanar formats > >On Wednesday 17 February 2010 19:32:06 Karicheri, Muralidharan wrote: >> Hi, >> >> I think all of the planar pix format defined in videodev2.h are >contiguous in memory. So I would suggest adding some suffix to indicate >this so that it is obvious to application users. >> >> >What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.? >> >> Not sure what Hans mean by the 2P or 3P extensions since NV16 has 2 >planes. Why do we want to re-define NV12 and NV12_2P since it can cause >backward compatibility issues. Why don't we keep existing naming convention >for >> contiguous formats and add a suffix for indicating the planes are not >> contiguous. >> >> For example >> >> V4L2_PIX_FMT_NV16 vs V4L2_PIX_FMT_NV16_NC where NC - Non Contiguous > >That's better than my suggestion. What I meant with 2P and 3P was that is >has >2 (or 3 or whatever) non-contiguous planes. But that's confusing. > >Regards, > > Hans > >> >> Just my thoughts... >> >> Murali Karicheri >> Software Design Engineer >> Texas Instruments Inc. >> Germantown, MD 20874 >> email: m-kariche...@ti.com >> >> >-Original Message- >> >From: linux-media-ow...@vger.kernel.org [mailto:linux-media- >> >ow...@vger.kernel.org] On Behalf Of Hans Verkuil >> >Sent: Wednesday, February 17, 2010 1:22 PM >> >To: Pawel Osciak >> >Cc: linux-media@vger.kernel.org; Sylwester Nawrocki; 'Kamil Debski' >> >Subject: Re: Fourcc for multiplanar formats >> > >> >On Monday 15 February 2010 17:27:46 Pawel Osciak wrote: >> >> Hello, >> >> >> >> we would like to ask for suggestions for new fourcc formats for >> >multiplanar buffers. >> >> >> >> There are planar formats in V4L2 API, but for all of them, each plane >X >> >"immediately >> >> follows Y plane in memory". We are in the process of testing formats >and >> >V4L2 extensions >> >> that relax those requirements and allow each plane to reside in a >> >separate area of >> >> memory. >> >> >> >> I am not sure how we should name those formats though. In our example, >we >> >are focusing >> >> on the following formats at the moment: >> >> - YCbCr 422 2-planar (multiplanar version of V4L2_PIX_FMT_NV16) >> >> - YCbCr 422 3-planar (multiplanar version of V4L2_PIX_FMT_YUV422P) >> >> - YCbCr 420 2-planar (multiplanar version of V4L2_PIX_FMT_NV12) >> >> - YCbCr 420 3-planar (multiplanar version of V4L2_PIX_FMT_YUV420) >> >> >> >> >> >> Could anyone give any suggestions how we should name such formats and >> >what to pass to >> >> the v4l2_fourcc() macro? >> > >> >What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.? >> > >> >What we pass to the fourcc macro is not very important IMHO. As long as >it >> >is unique. >> > >> >Regards, >> > >> >Hans >> > >> >> >> >> >> >> Best regards >> >> -- >> >> Pawel Osciak >> >> 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 >> >> >> >> >> > >> >-- >> >Hans Verkuil - video4linux developer - sponsored by TANDBERG >> >-- >> >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 >> >> > >-- >Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Fourcc for multiplanar formats
On Wednesday 17 February 2010 19:32:06 Karicheri, Muralidharan wrote: > Hi, > > I think all of the planar pix format defined in videodev2.h are contiguous in > memory. So I would suggest adding some suffix to indicate this so that it is > obvious to application users. > > >What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.? > > Not sure what Hans mean by the 2P or 3P extensions since NV16 has 2 planes. > Why do we want to re-define NV12 and NV12_2P since it can cause backward > compatibility issues. Why don't we keep existing naming convention for > contiguous formats and add a suffix for indicating the planes are not > contiguous. > > For example > > V4L2_PIX_FMT_NV16 vs V4L2_PIX_FMT_NV16_NC where NC - Non Contiguous That's better than my suggestion. What I meant with 2P and 3P was that is has 2 (or 3 or whatever) non-contiguous planes. But that's confusing. Regards, Hans > > Just my thoughts... > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > email: m-kariche...@ti.com > > >-Original Message- > >From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > >ow...@vger.kernel.org] On Behalf Of Hans Verkuil > >Sent: Wednesday, February 17, 2010 1:22 PM > >To: Pawel Osciak > >Cc: linux-media@vger.kernel.org; Sylwester Nawrocki; 'Kamil Debski' > >Subject: Re: Fourcc for multiplanar formats > > > >On Monday 15 February 2010 17:27:46 Pawel Osciak wrote: > >> Hello, > >> > >> we would like to ask for suggestions for new fourcc formats for > >multiplanar buffers. > >> > >> There are planar formats in V4L2 API, but for all of them, each plane X > >"immediately > >> follows Y plane in memory". We are in the process of testing formats and > >V4L2 extensions > >> that relax those requirements and allow each plane to reside in a > >separate area of > >> memory. > >> > >> I am not sure how we should name those formats though. In our example, we > >are focusing > >> on the following formats at the moment: > >> - YCbCr 422 2-planar (multiplanar version of V4L2_PIX_FMT_NV16) > >> - YCbCr 422 3-planar (multiplanar version of V4L2_PIX_FMT_YUV422P) > >> - YCbCr 420 2-planar (multiplanar version of V4L2_PIX_FMT_NV12) > >> - YCbCr 420 3-planar (multiplanar version of V4L2_PIX_FMT_YUV420) > >> > >> > >> Could anyone give any suggestions how we should name such formats and > >what to pass to > >> the v4l2_fourcc() macro? > > > >What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.? > > > >What we pass to the fourcc macro is not very important IMHO. As long as it > >is unique. > > > >Regards, > > > > Hans > > > >> > >> > >> Best regards > >> -- > >> Pawel Osciak > >> 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 > >> > >> > > > >-- > >Hans Verkuil - video4linux developer - sponsored by TANDBERG > >-- > >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 > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Fourcc for multiplanar formats
Hi, I think all of the planar pix format defined in videodev2.h are contiguous in memory. So I would suggest adding some suffix to indicate this so that it is obvious to application users. >What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.? Not sure what Hans mean by the 2P or 3P extensions since NV16 has 2 planes. Why do we want to re-define NV12 and NV12_2P since it can cause backward compatibility issues. Why don't we keep existing naming convention for contiguous formats and add a suffix for indicating the planes are not contiguous. For example V4L2_PIX_FMT_NV16 vs V4L2_PIX_FMT_NV16_NC where NC - Non Contiguous Just my thoughts... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com >-Original Message- >From: linux-media-ow...@vger.kernel.org [mailto:linux-media- >ow...@vger.kernel.org] On Behalf Of Hans Verkuil >Sent: Wednesday, February 17, 2010 1:22 PM >To: Pawel Osciak >Cc: linux-media@vger.kernel.org; Sylwester Nawrocki; 'Kamil Debski' >Subject: Re: Fourcc for multiplanar formats > >On Monday 15 February 2010 17:27:46 Pawel Osciak wrote: >> Hello, >> >> we would like to ask for suggestions for new fourcc formats for >multiplanar buffers. >> >> There are planar formats in V4L2 API, but for all of them, each plane X >"immediately >> follows Y plane in memory". We are in the process of testing formats and >V4L2 extensions >> that relax those requirements and allow each plane to reside in a >separate area of >> memory. >> >> I am not sure how we should name those formats though. In our example, we >are focusing >> on the following formats at the moment: >> - YCbCr 422 2-planar (multiplanar version of V4L2_PIX_FMT_NV16) >> - YCbCr 422 3-planar (multiplanar version of V4L2_PIX_FMT_YUV422P) >> - YCbCr 420 2-planar (multiplanar version of V4L2_PIX_FMT_NV12) >> - YCbCr 420 3-planar (multiplanar version of V4L2_PIX_FMT_YUV420) >> >> >> Could anyone give any suggestions how we should name such formats and >what to pass to >> the v4l2_fourcc() macro? > >What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.? > >What we pass to the fourcc macro is not very important IMHO. As long as it >is unique. > >Regards, > > Hans > >> >> >> Best regards >> -- >> Pawel Osciak >> 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 >> >> > >-- >Hans Verkuil - video4linux developer - sponsored by TANDBERG >-- >To unsubscribe from this list: send the line "unsubscribe linux-media" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal for a V4L2 Media Controller mini-summit
On Friday 12 February 2010 15:50:08 Hans Verkuil wrote: > Hi all, > > During the Linux Plumbers Conference in September 2009 I organized a V4L-DVB > mini-summit. The focus of that summit was on discussing a framework through > which we could support all the functionality that the video hardware of modern > embedded devices provides. > > It was a very successful summit and a lot of work has been done since that > time. See this posting for to get an idea of what was discussed for those > who were not present: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg10136.html > > Since that time we have added a new API to support HDTV formats, a new > event API is almost ready, a lot of work is being done on the media > controller API with omap3 as guinea pig and Samsung has done work on the > memory handling of V4L2. > > From April 12th to 14th the CELF Embedded Linux Conference is held in > San Francisco, and it is co-located with the Linux Foundation Collaboration > Summit (April 14th-16th). Links to these conferences are here: > > http://www.embeddedlinuxconference.com/elc_2010/index.html > http://events.linuxfoundation.org/events/collaboration-summit > > I will be doing a presentation on the new framework during the ELC. > > Since this conference is about 6 months after the mini-summit I consider this > a good time to organize a new V4L2 Media Controller mini-summit to discuss > progress and future work in this area. I think that particular attention > should be given to how we are going to do memory handling. The proposals > from Samsung have received very little attention and we should discuss those > in more detail. > > I do not know on which dates exactly such a summit can take place. There > are three possibilities: > > April 10-11/12 > April 12-14 > April 14/15-16 > > I think that registering for the ELC gives to free access to the Collaboration > Summit, but I'm waiting for a confirmation on that. > > I'm not keen on the center option (12-14 April) since that often means that > you don't see a lot of the conference itself. And the ELC is generally quite > interesting. > > There is another alternative and that is that I organize a mini-summit in May > in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I think > that it is more fun to do this during/before/after a conference. If only > because there are a lot of linux kernel experts on hand during such a > conference that you can ask for help if needed. > > Please let me know asap if you are interested in attending such a mini-summit > and what dates are possible for you: > > a: April 10-11 (or 12) > b: April 12-14 > c: April 14 (or 15)-16 > d: Somewhere in May (suggestions for dates are welcome) I would appreciate it if people/companies who are interested in attending would let me know as soon as possible. Options A and B are a no go, so it is either April 14-16, or it will be in May. It doesn't have to be definitive, but I would like to have an idea of what to expect. The V4L2 API work that is in progress is crucially important for embedded hardware, so getting involved now will ensure that your devices will work fine on linux in the future. And we get to see more of the complex use cases that we must cater to in the API. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Fourcc for multiplanar formats
On Monday 15 February 2010 17:27:46 Pawel Osciak wrote: > Hello, > > we would like to ask for suggestions for new fourcc formats for multiplanar > buffers. > > There are planar formats in V4L2 API, but for all of them, each plane X > "immediately > follows Y plane in memory". We are in the process of testing formats and V4L2 > extensions > that relax those requirements and allow each plane to reside in a separate > area of > memory. > > I am not sure how we should name those formats though. In our example, we are > focusing > on the following formats at the moment: > - YCbCr 422 2-planar (multiplanar version of V4L2_PIX_FMT_NV16) > - YCbCr 422 3-planar (multiplanar version of V4L2_PIX_FMT_YUV422P) > - YCbCr 420 2-planar (multiplanar version of V4L2_PIX_FMT_NV12) > - YCbCr 420 3-planar (multiplanar version of V4L2_PIX_FMT_YUV420) > > > Could anyone give any suggestions how we should name such formats and what to > pass to > the v4l2_fourcc() macro? What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.? What we pass to the fourcc macro is not very important IMHO. As long as it is unique. Regards, Hans > > > Best regards > -- > Pawel Osciak > 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 > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 4/4] V4L/DVB: v4l: document new Bayer and monochrome pixel formats
Document all four 10-bit Bayer formats, 10-bit monochrome and a missing
8-bit Bayer formats.
[mche...@redhat.com: remove duplicated symbol for V4L2-PIX-FMT-SGRBG10]
Signed-off-by: Guennadi Liakhovetski
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/DocBook/Makefile |3 +
Documentation/DocBook/v4l/pixfmt-srggb10.xml | 90 ++
Documentation/DocBook/v4l/pixfmt-srggb8.xml | 67 +++
Documentation/DocBook/v4l/pixfmt-y10.xml | 79 ++
Documentation/DocBook/v4l/pixfmt.xml |8 +--
5 files changed, 242 insertions(+), 5 deletions(-)
create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb10.xml
create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb8.xml
create mode 100644 Documentation/DocBook/v4l/pixfmt-y10.xml
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 65deaba..1c796fc 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -309,6 +309,9 @@ V4L_SGMLS = \
v4l/pixfmt-yuv422p.xml \
v4l/pixfmt-yuyv.xml \
v4l/pixfmt-yvyu.xml \
+ v4l/pixfmt-srggb10.xml \
+ v4l/pixfmt-srggb8.xml \
+ v4l/pixfmt-y10.xml \
v4l/pixfmt.xml \
v4l/vidioc-cropcap.xml \
v4l/vidioc-dbg-g-register.xml \
diff --git a/Documentation/DocBook/v4l/pixfmt-srggb10.xml
b/Documentation/DocBook/v4l/pixfmt-srggb10.xml
new file mode 100644
index 000..7b27409
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-srggb10.xml
@@ -0,0 +1,90 @@
+
+
+ V4L2_PIX_FMT_SRGGB10 ('RG10'),
+V4L2_PIX_FMT_SGRBG10 ('BA10'),
+V4L2_PIX_FMT_SGBRG10 ('GB10'),
+V4L2_PIX_FMT_SBGGR10 ('BG10'),
+
+ &manvol;
+
+
+ V4L2_PIX_FMT_SRGGB10
+ V4L2_PIX_FMT_SGRBG10
+ V4L2_PIX_FMT_SGBRG10
+ V4L2_PIX_FMT_SBGGR10
+ 10-bit Bayer formats expanded to 16 bits
+
+
+ Description
+
+ The following four pixel formats are raw sRGB / Bayer formats with
+10 bits per colour. Each colour component is stored in a 16-bit word, with 6
+unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
+and n/2 blue or red samples, with alternating red and blue rows. Bytes are
+stored in memory in little endian order. They are conventionally described
+as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
+formats
+
+
+ V4L2_PIX_FMT_SBGGR10 4 × 4
+pixel image
+
+
+ Byte Order.
+ Each cell is one byte, high 6 bits in high bytes are 0.
+
+
+
+
+
+ start + 0:
+ B00low
+ B00high
+ G01low
+ G01high
+ B02low
+ B02high
+ G03low
+ G03high
+
+
+ start + 8:
+ G10low
+ G10high
+ R11low
+ R11high
+ G12low
+ G12high
+ R13low
+ R13high
+
+
+ start + 16:
+ B20low
+ B20high
+ G21low
+ G21high
+ B22low
+ B22high
+ G23low
+ G23high
+
+
+ start + 24:
+ G30low
+ G30high
+ R31low
+ R31high
+ G32low
+ G32high
+ R33low
+ R33high
+
+
+
+
+
+
+
+
+
diff --git a/Documentation/DocBook/v4l/pixfmt-srggb8.xml
b/Documentation/DocBook/v4l/pixfmt-srggb8.xml
new file mode 100644
index 000..2570e3b
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-srggb8.xml
@@ -0,0 +1,67 @@
+
+
+ V4L2_PIX_FMT_SRGGB8 ('RGGB')
+ &manvol;
+
+
+ V4L2_PIX_FMT_SRGGB8
+ Bayer RGB format
+
+
+ Description
+
+ This is commonly the native format of digital cameras,
+reflecting the arrangement of sensors on the CCD device. Only one red,
+green or blue value is given for each pixel. Missing components must
+be interpolated from neighbouring pixels. From left to right the first
+row consists of a red and green value, the second row of a green and
+blue value. This scheme repeats to the right and down for every two
+columns and rows.
+
+
+ V4L2_PIX_FMT_SRGGB8 4 × 4
+pixel image
+
+
+ Byte Order.
+ Each cell is one byte.
+
+
+
+
+
+ start + 0:
+ R00
+ G01
+ R02
+ G03
+
[PATCH 3/4] DocBook/v4l/pixfmt.xml: Add missing formats for gspca cpia1 and sn9c2028 drivers
The CPIA and SONX fourcc codes weren't at the specs. Detected it thanks to the autogenerated targets added to Makefile. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/pixfmt.xml | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index 885968d..6e38f50 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml @@ -685,6 +685,11 @@ http://www.ivtvdriver.org/The format is documented in the kernel sources in the file Documentation/video4linux/cx2341x/README.hm12 + + V4L2_PIX_FMT_CPIA1 + 'CPIA' + YUV format used by the gspca cpia1 driver. + V4L2_PIX_FMT_SPCA501 'S501' @@ -770,6 +775,11 @@ kernel sources in the file Documentation/video4linux/cx2341x/README.hm 'S920' YUV 4:2:0 format of the gspca sn9c20x driver. + + V4L2_PIX_FMT_SN9C2028 + 'SONX' + Compressed GBRG bayer format of the gspca sn9c2028 driver. + V4L2_PIX_FMT_STV0680 'S680' -- 1.6.6.1 -- 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 1/4] DocBook/Makefile: Make it less verbose
Don't show build commands for html main file and media dir creation, if V=0. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/Makefile |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 325cfd1..7c590ef 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -46,8 +46,9 @@ pdfdocs: $(PDF) HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS))) htmldocs: $(HTML) - $(call build_main_index) - $(call build_images) + @$($(quiet)cmd_build_main_index) + @$($(call build_main_index)) + @($(call build_images)) MAN := $(patsubst %.xml, %.9, $(BOOKS)) mandocs: $(MAN) @@ -145,6 +146,8 @@ quiet_cmd_db2pdf = PDF $@ %.pdf : %.xml $(call cmd,db2pdf) + cmd_build_main_index = : +quiet_cmd_build_main_index = echo ' BUILD $@' index = index.html main_idx = Documentation/DocBook/$(index) -- 1.6.6.1 -- 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 0/4] DocBook additions for V4L new formats
Adds DocBook items for Bayer and two proprietary formats used on gspca. In the past, a few targets were generated at the Mercurial development tree. However, at the beginning of this year, we moved to use -git as the primary resource. So, the Makefile logic to autogenerate those targets needs to be moved to git as well. While here, I noticed that DocBook is too verbose to generate the htmldocs target. So, make it less verbose, if V=0. Guennadi Liakhovetski (1): V4L/DVB: v4l: document new Bayer and monochrome pixel formats Mauro Carvalho Chehab (3): DocBook/Makefile: Make it less verbose DocBook: Add rules to auto-generate some media docbooks DocBook/v4l/pixfmt.xml: Add missing formats for gspca cpia1 and sn9c2028 drivers Documentation/DocBook/Makefile | 493 +++- Documentation/DocBook/dvb/frontend.h.xml | 415 -- Documentation/DocBook/media-entities.tmpl| 383 -- Documentation/DocBook/media-indices.tmpl | 89 -- Documentation/DocBook/v4l/pixfmt-srggb10.xml | 90 ++ Documentation/DocBook/v4l/pixfmt-srggb8.xml | 67 + Documentation/DocBook/v4l/pixfmt-y10.xml | 79 ++ Documentation/DocBook/v4l/pixfmt.xml | 18 +- Documentation/DocBook/v4l/videodev2.h.xml| 1757 -- 9 files changed, 738 insertions(+), 2653 deletions(-) delete mode 100644 Documentation/DocBook/dvb/frontend.h.xml delete mode 100644 Documentation/DocBook/media-entities.tmpl delete mode 100644 Documentation/DocBook/media-indices.tmpl create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb10.xml create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb8.xml create mode 100644 Documentation/DocBook/v4l/pixfmt-y10.xml delete mode 100644 Documentation/DocBook/v4l/videodev2.h.xml -- 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: tw68: Congratulations :-) and possible vsync problem :-(
This driver has not yet been submitted for review by members of the linux-media list (although it most certainly will be in the future). I greatly appreciate this report (and would also welcome any others), but I don't want to spend much time here responding to it. Reports sent to me by direct email are also welcome. The problem is basically caused by an overload of your CPU - it doesn't have enough power to handle the processing of the video stream the application has asked for. I'm able to run all of your examples on my development machine (an Intel i7a with 4gb) with no problems at all. That said, it is also true that the driver should do a better job of assuring the buffer stream being sent to the application is correct and consistent. I can reproduce the problem on relatively slow systems (an AMD Duron and a Pentium4, each with 256mb), and will try to improve the driver's behaviour. Thanks for the report! Bill TW68 developer Michael wrote: > Sorry for spamming this :-) > > The problem is not solved. Now that I tested all possible normid > settings, > it became clear that it only occurs if I have the correct cropping. > > With the PAL and SECAM settings, I get correct cropping, but the vsync > problem in case of high cpu load. With NTSC settings I get wrong > cropping > (missing bottom lines), but no vsync problems. > > If I switch my video cam from PAL to NTSC output, I also get vsync > problems > with NTSC normids. > > It seems that the driver misses the vsync somehow if it went down > correctly > till the last horizontal line and if there is high CPU load. > > Michael > > Michael wrote: > >> Wow things are really moving fast here. >> >> This morning there was a commit in git, which actually eliminates >> the >> below mentioned problem. >> >> It, however, introduced another small problem. The pictures is >> wrongly >> cropped. There is the lower part missing (roughly 150-200 lines). >> >> With the last version, I had the same problem, but was able to get >> the >> full picture with the option "normid=3". This is no longer working. >> >> Otherwise, great work! >> >> Michael >> >> >> Michael wrote: >> >>> Hello >>> >>> I have tested a TW6805 based mini-pci card with the new tw68-v2 >>> driver >>> from git (22 January 2010). >>> >>> First of all: Congratulations! It is really working great. >>> >>> However, I noticed some frame errors here and then. It is not easy >>> to >>> identify what the reason is. It looks a bit like a buffer problem >>> as it >>> happens more often, if there is some load on the system. >>> >>> Here is a simple way how I can reproduce the frame errors: >>> >>> mplayer -framedrop -fs -vo x11 tv:// -tv >>> device=/dev/video0:width=640:height=480:normid=3 >>> >>> With this command, cpu load goes to 100% on my low powered geode >>> system. >>> The frame errors are very obvious. It looks like a vsync problem as >>> the >>> wrong frames always start somewhere in the middle. There is no >>> horizontal >>> shift visible. >>> >>> Reducing the image size: >>> >>> mplayer -framedrop -fs -vo x11 tv:// -tv >>> device=/dev/video0:width=320:height=240:normid=3 >>> >>> gives a drop in CPU load to 13%. No more frame errors. >>> >>> Also using hardware accelerated video playback (xv) reduces CPU >>> load to >>> some 20% and removes the frame errors: >>> >>> mplayer -framedrop -fs -vo xv tv:// -tv >>> device=/dev/video0:width=640:height=480:normid=3 >>> >>> Still, even here, occasionally there are some frame errors, >>> depending on >>> what happens on the system. These can be induced as follows. Using >>> this >>> program: >>> >>> mkfifo /tmp/mp >>> mplayer -framedrop -fs -vf screenshot -vo xv tv:// -tv >>> device=/dev/video0:normid=3 -slave -input file=/tmp/mp >> >/dev/null >>> >>> When this test prog runs, you can issue commands to mplayer, e.g. >>> >>> echo pause > /tmp/mp >>> >>> This pauses mplayer. A second >>> >>> echo pause > /tmp/mp >>> >>> starts mplayer again. Here the first frame shows the error. >>> >>> The same happens if you issue: >>> >>> echo screenshot 0 > /tmp/mp >>> >>> This captures a screenshot and saves it into the current pwd. >>> Again, when >>> mplayer takes the shot, there comes one error frame (probably also >>> wrong >>> vsync). >>> >>> >>> Btw. using instead a bttv based card all these tests run without >>> frame >>> errors. >>> >>> Does this information help to identify and remove the bug? >>> >>> Best regards >>> >>> Michael > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pac207: problem with Trust USB webcam
On Wednesday 17 February 2010 09:57:48 Hans de Goede wrote: > On 02/17/2010 01:04 AM, Adam Baker wrote: > > On Tuesday 16 Feb 2010, Hans de Goede wrote: > >> You need to use libv4l and have your apps patched > >> to use libv4l or use the LD_PRELOAD wrapper. > >> > >> Here is the latest libv4l: > >> http://people.fedoraproject.org/~jwrdegoede/libv4l-0.6.5-test.tar.gz > >> > >> And here are install instructions: > >> http://hansdegoede.livejournal.com/7622.html > > > > libv4l is already packaged by lenny but doing > > > > LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so xawtv > > > > results in either a plain green screen or a mostly green screen with > > some picture visible behind it. IIRC this is due to a bug in older > > versions of xawtv. I didn't try vlc as it wanted to install too many > > dependencies but I did try cheese which also wouldn't work. Thanks a lot to you both for the pointers! I've gotten vlc to work using v4l1compat.so. The image is recognizable, but the color etc is way off. Haven't found a way to correct that yet. But the main thing for me ATM is that it's working now. > > which suggests that the packaged libv4l is fine and it is just the apps > > that are an issue. > > Anyways I don't know how old the libv4l is in Lenny, but you will want at > least version 0.6.0, as that has some fixes for the pac207 compression, > and prefarably 0.6.1 as that some desirable bug fixes. The releases past > 0.6.2 mainly add support for other webcam compressions. I used the 0.6.3 version from the Lenny Backports repository. Thanks again, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
http://linuxtv.org/wiki/index.php/FreeBSD_violates_GPL
http://linuxtv.org/wiki/index.php/FreeBSD_violates_GPL -- 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
terratec grabby sound problem
Bonjour, I've bought a terratec grabby device but I've experimented some audio problems with it I run an ubuntu karmic (9.10) distri and use mplayer/mencoder to see and capture vhs pal stuff. But, If video works with mplayer/mencoder, sound doesn't So I run alsamixer -c1 to access grabby capture volume, then when I change volume slider a little bit I get an ugly sound very jerky Then I go to sound préférences of pulsaudio and swith the grabby device to off (éteint in french) andb after to analog input and then I get a good sound. I's very strange because with my old pinnacle dvc100 sound works immediatly (but this device seems to have problem because sound move time to time to an affect like a flanger and then come normal again ; I suspect a hardware problem of the device but I cannot be sure because I have no microsoft computer to test it). I've bought this low-cost terratec grabby to do the job but, finally, I experiment another problemI'm trying to grab my vhs since several months and I have still no success ! I cannot try to grab my vhs because,even doing things I've mentionned, I'm never sure that it works because mencoder encodes but don't show any video or sound during it works. I've seached but found nothing...so I post here.if someone has an idea. cordialement, -- 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: pac207: problem with Trust USB webcam
Hi, On 02/17/2010 01:04 AM, Adam Baker wrote: On Tuesday 16 Feb 2010, Hans de Goede wrote: Hi, You need to use libv4l and have your apps patched to use libv4l or use the LD_PRELOAD wrapper. Here is the latest libv4l: http://people.fedoraproject.org/~jwrdegoede/libv4l-0.6.5-test.tar.gz And here are install instructions: http://hansdegoede.livejournal.com/7622.html Hi, libv4l is already packaged by lenny but doing LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so xawtv results in either a plain green screen or a mostly green screen with some picture visible behind it. IIRC this is due to a bug in older versions of xawtv. I didn't try vlc as it wanted to install too many dependencies but I did try cheese which also wouldn't work. I did find I could capture single frames with LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so vgrabbj -d /dev/video0>grab.jpg or LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so fswebcam --save grab2.jpg which suggests that the packaged libv4l is fine and it is just the apps that are an issue. Yes that is very likely I'm the author and maintainer of both libv4l and the pac207 kernel driver and I have 5 different pac207 based cams to test with and all work well on a variety of computers. xawtv indeed is known to be buggy, and cheese too has had some bad releases. Anyways I don't know how old the libv4l is in Lenny, but you will want at least version 0.6.0, as that has some fixes for the pac207 compression, and prefarably 0.6.1 as that some desirable bug fixes. The releases past 0.6.2 mainly add support for other webcam compressions. 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
