Re: MR97310A and other image formats
kilg...@banach.math.auburn.edu wrote: On Fri, 20 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: On Thu, 19 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: Yes, what you quote is the SOF marker for all of these cameras. The total header length, including the SOF marker ought to be 12 bytes. On all of the mr97310 cameras that I have dealt with, the last 5 bytes are obviously related somehow to the image (contrast, color balance, gamma, whatever). I have no idea how to interpret those values, but we can hope that someone will figure out how. Two of them are luminance values (middle and edge) for the PAC207. Which two, and how do those numbers translate into anything relevant? Looks like I had some off list (private) email conversation about the frame header of PAC207 with Michel Xhaard. I just paste the whole thing in here: michel Xhaard wrote: Le Samedi 18 Fe'vrier 2006 12:16, vous avez e'crit : michel Xhaard wrote: Le Samedi 18 Fe'vrier 2006 10:10, vous avez e'crit : Hello Michel michel Xhaard wrote: Le Mercredi 15 Fe'vrier 2006 12:43, vous avez e'crit : Just relook the snoop, the header is always 16 bytes long starting with: ff ff 00 ff 96 64 follow xx 00 xx xx xx xx 64 xx 00 00 let try to play poker with the asumption the R mean G0 mean B mean G1 mean is encoded here. Not sure about the 64 can you look at your snoop? I never thought about that. So, you see I have not experience with webcams. Anyway, here are my observations about the header: In the snoop, it looks a bit different then yours FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 1. xx: looks like random value 2. xx: changed from 0x03 to 0x0b 3. xx: changed from 0x06 to 0x49 4. xx: changed from 0x07 to 0x55 5. xx: static 0x96 6. xx: static 0x80 7. xx: static 0xa0 And I did play in Linux and could identify some fields :-) . In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 1. xx: don't know but value is changing between 0x00 to 0x07 2. xx: this is the actual pixel clock 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Regards, Thomas Thomas, Cool good works :) so 3 and 4 are good candidate . To get good picture result there are 2 windows where the chips measure the ligth condition. Generally one is set to the center of the image the other are set to get the background light. At the moment my autobrightness setting used simple code and only one windows of measurement (the center one) . Some more info, 3 is the center one. :) Did you want i try to implement these feature ? or maybe you can have a try :) the only problem i see is between interrupt() context and process context. I have set up a spinlock for that look at the code how to use it ( spca5xx_move_data() ) Yes, please. Because I have no idea how to do this :-( I am good in investigating :-) I know, but can be very good in code to, as you know the hardware :) now let try to look at 1 ^^ What does this mean? is there the black luma level ? I don't get it. What is the black luma level? Regards, Thomas -- http://www.kaiser-linux.li By any chance, you do not have a JL2005B or JL2005C or JL2005D camera among them, do you? AFAICT they all use the same compression algorithm (in stillcam mode), and it appears to me to be a really nasty one. Any help I could get with that algorithm is welcome indeed. I have to check. Please send me the USB ID. 0x0979 is the Vendor ID from Jeilin. 0x0227 is the Product ID of the JL2005B/C/D cameras (yes, all three of them have the same ID) Thomas Thanks for the information. But this is an old letter. What is happening with Michel Xhaard these days? Do you know? I miss him. Yes, I know it is an old letter, but these info are still valid for the PAC207 chipset! I don't know what happened to Michel. I didn't exchange mails with him for a long time. PS: Now we have the 5. season in Liechtenstein, Fasnacht (means carnival). So, you can guess what I am doing the next couple of days :-) I don't know. Eat too much Wienerschnitzel? Temporarily transform into ein Bierfass? Um Verzeihung. Ich hole sofort den Hut... ... party . Thomas -- 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: Questions about VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP
On Thursday 19 February 2009 15:02:31 Hans Verkuil wrote: Hi, The VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP v4l2 ioctls seem not to be used by many drivers / applications. They should! Unfortunately, these ioctls are completely undocumented. Which might be the reason why they aren't used :-) In some ms-win traces, there are automatic and dynamic adjustments of the JPEG quality according to... who knows? Also, most webcams do not include the quantization tables in the images. Then, (in gspca), these tables are added by the subdrivers with a quality defined by the testers and according to their taste. As I understand, the JPEGCOMP ioctls permit to set the JPEG quality and to define the content of the JPEG frames. If I implement these controls in gspca: - by default, I could not add the quantization and Huffman tables in the image frames, - the quality could be set dynamically, this value being used to load the quantization tables in the webcam and also to convert the images. The questions are: 1) May the driver refuse to set some values on VIDIOC_S_JPEGCOMP? For example, if it cannot add the Huffman table in the frames. You will have to check what the existing practice is. How to other drivers handle this? 2) Will the VIDIOC_G_JPEGCOMP ioctl be used by the v4l library (for conversion purpose)? 3) Does anybody know a command line or X application which may get/set these JPEG parameters? Support for these ioctls should be added to v4l2-ctl.cpp. It's the right place for that. But more important is to document these ioctls in the v4l2 spec. As far as I can tell these ioctls came from the zoran driver where basically a private ioctl was elevated to a public ioctl, but with little or no review. Do you know enough about these ioctls to update the v4l2 spec? That would be a great help. Regards, Hans I'm working on the zoran driver anyway, so I'll document this and add support to v4l2-ctl. I now understand what this is about. The COM and APP markers are either obsolete or are meant as a read-only property. And while it is possible theoretically to set multiple APP segments, it is impossible with the current API to ever read more than one back. Sigh. 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: Minimum kernel version supported by v4l-dvb
Am Freitag, den 20.02.2009, 10:49 +0100 schrieb Jean Delvare: On Fri, 20 Feb 2009 07:53:16 +0100, Hans Verkuil wrote: On Friday 20 February 2009 04:57:11 hermann pitton wrote: Hans decided deliberately to extend backward compat even down to 2.6.16, now seeing the bill. I didn't extend it, instead I reduced the backward compat to 2.6.16 at the time. It supported older kernels as well back then, however since nobody ever compiled for those older kernels quite a few drivers were broken. Creating the daily build system at least ensures that we know v4l-dvb can compile for those kernels we support officially. In the past this was more based on hope and a prayer :-) That's better than before, but just because it builds doesn't mean it works... Given the restricted testing (!) capabilities in both directions, I don't even know how many and different devices we support currently and that it works is not always guaranteed on a released kernel either :) Does Linus know it better ;) Cheers, Hermann -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l-dvb: work around an autoconf.h include in mmdebug.h - v4l2-spec: document V4L2_CID_COLORFX. - v4l2: add colorfx support to v4l2-common.c, and add to 'Changes' in spec. - v4l2: add V4L2_CTRL_FLAG_WRITE_ONLY flag. - v4l2-common/v4l2-spec: support/document write-only and button controls - v4l2-ctl: add get/set-jpeg-comp support. - v4l2-apps: clean up the output for g_jpegcomp a bit. - vivi: fix compile warning. Thanks, Hans diffstat: linux/drivers/media/video/v4l2-common.c | 43 - linux/drivers/media/video/vivi.c|2 linux/include/linux/videodev2.h |1 v4l/scripts/make_config_compat.pl |7 + v4l2-apps/util/v4l2-ctl.cpp | 143 v4l2-spec/compat.sgml | 11 ++ v4l2-spec/controls.sgml | 33 --- v4l2-spec/vidioc-queryctrl.sgml | 15 +++ 8 files changed, 220 insertions(+), 35 deletions(-) -- 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: Questions about VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP
On Fri, 20 Feb 2009 09:29:36 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Support for these ioctls should be added to v4l2-ctl.cpp. It's the right place for that. But more important is to document these ioctls in the v4l2 spec. As far as I can tell these ioctls came from the zoran driver where basically a private ioctl was elevated to a public ioctl, but with little or no review. Do you know enough about these ioctls to update the v4l2 spec? That would be a great help. I'm working on the zoran driver anyway, so I'll document this and add support to v4l2-ctl. I now understand what this is about. The COM and APP markers are either obsolete or are meant as a read-only property. And while it is possible theoretically to set multiple APP segments, it is impossible with the current API to ever read more than one back. Sigh. Hi Hans, I see three parts in these ioctls: - quality, - definition of the APP and COM markers, - presence / absence of some JPEG fields (quantization, Huffman..) Looking at the video tree, the quality is treated by 5 drivers: - in cpia2, the quality is not settable and defaults to 80 (%), - in zc0301, the quality may be only set to 0, - in et61x251 and sn9c102, the quality may be set to 0 or 1, - in zoran, the quality may be set from 5% to 100%, but it is used only to compute the max size of the images! I don't see the usage of APP or COM markers. Such fields may be added by the applications. Actually, only the zoran and cpia2 drivers treat them. About the presence / absence of the JPEG fields, it is simpler to have all the required fields in the JPEG image. If some field is lacking, it should be added at conversion time by the v4l library or added by the driver if video output. The fact the ioctl permits the control of these fields obliges the drivers (input) or the applications (output) to know how to add (or remove) the fields. It seems a complex treatment for a small benefit: reduce the size of images by 100 or 200 bytes. Actually, only the zoran and cpia2 drivers treat these controls. So, I propose to remove these ioctls, and to add two controls: one to set the JPEG quality (range 15..95 %) and the other to set a webcam quality which might be a boolean or any value depending on some associated webcam parameter. What do you think of it? Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [linux-dvb] HVR2250 Status - Where am I?
John Drescher wrote: On Thu, Feb 19, 2009 at 11:57 PM, Steven Toth st...@linuxtv.org wrote: It's best to explain it here: http://steventoth.net/blog/hvr-2250 Any way to get a running total on your blog? I'll try to figure something out. - Steve -- 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: vbox cat's eye 3560 usb device
Lastly, are there any other IC components on the back or front of the PCB ? Can you provide pics (upload them to the wiki article)) ? The back only has a couple components, probably for electrical, no ICs. The front only has the cypress (100 pin pkg) chip and the NIM, with a couple small components, that I can't read what they are. The PCB is stamped osc by one of them and usbid on the other, so I'm guessing one is an oscillator and the other the PROM where the cold USB id is stored. I opened up the NIM (hey, they're $30 at my local computer store right now, so even if I kill it, I have an extra), and I saw my old friend the BCM3510 (I have a 1rst gen air2pc pci card that works pretty well for me) and a smaller chip marked tua6030 (or could be 6080, the writing is faint, but infineon doesn't look like they make an 6080). I have photos but need to upload them. have a look at the cxusb, its likely closer to what you want: http://linuxtv.org/hg/v4l-dvb/file/tip/linux/drivers/media/dvb/dvb-usb/ OK, I'll take a look there. Thank you. -- 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 2/2 v2] soc-camera: configure drivers with a default format on open
Currently soc-camera doesn't set up any image format without an explicit S_FMT.
It seems this should be supported, since, for example, capture-example.c from
v4l2-apps by default doesn't issue an S_FMT. This patch configures a default
image format on open().
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
On Fri, 20 Feb 2009, morimoto.kunin...@renesas.com wrote:
Morimoto-san, please, have a look how far these two patches take you, I
lost the track of the problems a bit:-) Does capture-example work for you
now without the -f?
Oooops. sorry ov772x and tw9910 doesn't works...
The reason is videobuf-core.c :: videobuf_next_field.
BUG_ON(V4L2_FIELD_ANY == filed);
sh_mobile_ceu use V4L2_FIELD_ANY now.
and ov772x and tw9910 change field in try_fmt.
But try_fmt isn't called...
Ok, you're right. I do call it now. How about this version?
drivers/media/video/soc_camera.c | 100 ++
1 files changed, 68 insertions(+), 32 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 9939b04..fcd6b2c 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -30,6 +30,10 @@
#include media/videobuf-core.h
#include media/soc_camera.h
+/* Default to VGA resolution */
+#define DEFAULT_WIDTH 640
+#define DEFAULT_HEIGHT 480
+
static LIST_HEAD(hosts);
static LIST_HEAD(devices);
static DEFINE_MUTEX(list_lock);
@@ -256,6 +260,44 @@ static void soc_camera_free_user_formats(struct
soc_camera_device *icd)
vfree(icd-user_formats);
}
+/* Called with .vb_lock held */
+static int soc_camera_set_fmt(struct soc_camera_file *icf,
+ struct v4l2_format *f)
+{
+ struct soc_camera_device *icd = icf-icd;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+ struct v4l2_pix_format *pix = f-fmt.pix;
+ int ret;
+
+ /* We always call try_fmt() before set_fmt() or set_crop() */
+ ret = ici-ops-try_fmt(icd, f);
+ if (ret 0)
+ return ret;
+
+ ret = ici-ops-set_fmt(icd, f);
+ if (ret 0) {
+ return ret;
+ } else if (!icd-current_fmt ||
+ icd-current_fmt-fourcc != pix-pixelformat) {
+ dev_err(ici-dev,
+ Host driver hasn't set up current format
correctly!\n);
+ return -EINVAL;
+ }
+
+ icd-width = pix-width;
+ icd-height = pix-height;
+ icf-vb_vidq.field = pix-field;
+ if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ dev_warn(icd-dev, Attention! Wrong buf-type %d\n,
+f-type);
+
+ dev_dbg(icd-dev, set width: %d height: %d\n,
+ icd-width, icd-height);
+
+ /* set physical bus parameters */
+ return ici-ops-set_bus_param(icd, pix-pixelformat);
+}
+
static int soc_camera_open(struct file *file)
{
struct video_device *vdev;
@@ -297,6 +339,15 @@ static int soc_camera_open(struct file *file)
/* Now we really have to activate the camera */
if (icd-use_count == 1) {
+ struct v4l2_format f = {
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .fmt.pix = {
+ .width = DEFAULT_WIDTH,
+ .height = DEFAULT_HEIGHT,
+ .field = V4L2_FIELD_ANY,
+ },
+ };
+
ret = soc_camera_init_user_formats(icd);
if (ret 0)
goto eiufmt;
@@ -305,6 +356,14 @@ static int soc_camera_open(struct file *file)
dev_err(icd-dev, Couldn't activate the camera:
%d\n, ret);
goto eiciadd;
}
+
+ f.fmt.pix.pixelformat = icd-current_fmt-fourcc;
+ f.fmt.pix.colorspace= icd-current_fmt-colorspace;
+
+ /* Try to configure with default parameters */
+ ret = soc_camera_set_fmt(icf, f);
+ if (ret 0)
+ goto esfmt;
}
mutex_unlock(icd-video_lock);
@@ -316,7 +375,12 @@ static int soc_camera_open(struct file *file)
return 0;
- /* First two errors are entered with the .video_lock held */
+ /*
+* First three errors are entered with the .video_lock held
+* and use_count == 1
+*/
+esfmt:
+ ici-ops-remove(icd);
eiciadd:
soc_camera_free_user_formats(icd);
eiufmt:
@@ -415,16 +479,10 @@ static int soc_camera_s_fmt_vid_cap(struct file *file,
void *priv,
{
struct soc_camera_file *icf = file-private_data;
struct soc_camera_device *icd = icf-icd;
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
- struct v4l2_pix_format *pix = f-fmt.pix;
int ret;
WARN_ON(priv !=
Re: [linux-dvb] Klear?
On Fri, 2009-02-20 at 15:57 +0200, Juhana Sadeharju wrote: I will pick up Kaffeine, but Ubuntu is missing the package. I try compile it. You must be kidding, right ? http://packages.ubuntu.com/search?suite=defaultsection=allarch=anysearchon=nameskeywords=kaffeine Nico -- 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: MR97310A and other image formats
On Fri, 20 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: On Fri, 20 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: On Thu, 19 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: Yes, what you quote is the SOF marker for all of these cameras. The total header length, including the SOF marker ought to be 12 bytes. On all of the mr97310 cameras that I have dealt with, the last 5 bytes are obviously related somehow to the image (contrast, color balance, gamma, whatever). I have no idea how to interpret those values, but we can hope that someone will figure out how. Two of them are luminance values (middle and edge) for the PAC207. Which two, and how do those numbers translate into anything relevant? Looks like I had some off list (private) email conversation about the frame header of PAC207 with Michel Xhaard. I just paste the whole thing in here: michel Xhaard wrote: Le Samedi 18 Fe'vrier 2006 12:16, vous avez e'crit : michel Xhaard wrote: Le Samedi 18 Fe'vrier 2006 10:10, vous avez e'crit : Hello Michel michel Xhaard wrote: Le Mercredi 15 Fe'vrier 2006 12:43, vous avez e'crit : Just relook the snoop, the header is always 16 bytes long starting with: ff ff 00 ff 96 64 follow xx 00 xx xx xx xx 64 xx 00 00 let try to play poker with the asumption the R mean G0 mean B mean G1 mean is encoded here. Not sure about the 64 can you look at your snoop? I never thought about that. So, you see I have not experience with webcams. Anyway, here are my observations about the header: In the snoop, it looks a bit different then yours FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 1. xx: looks like random value 2. xx: changed from 0x03 to 0x0b 3. xx: changed from 0x06 to 0x49 4. xx: changed from 0x07 to 0x55 5. xx: static 0x96 6. xx: static 0x80 7. xx: static 0xa0 And I did play in Linux and could identify some fields :-) . In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 1. xx: don't know but value is changing between 0x00 to 0x07 2. xx: this is the actual pixel clock 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Regards, Thomas Thomas, Cool good works :) so 3 and 4 are good candidate . To get good picture result there are 2 windows where the chips measure the ligth condition. Generally one is set to the center of the image the other are set to get the background light. At the moment my autobrightness setting used simple code and only one windows of measurement (the center one) . Some more info, 3 is the center one. :) Did you want i try to implement these feature ? or maybe you can have a try :) the only problem i see is between interrupt() context and process context. I have set up a spinlock for that look at the code how to use it ( spca5xx_move_data() ) Yes, please. Because I have no idea how to do this :-( I am good in investigating :-) I know, but can be very good in code to, as you know the hardware :) now let try to look at 1 ^^ What does this mean? is there the black luma level ? I don't get it. What is the black luma level? Regards, Thomas -- http://www.kaiser-linux.li By any chance, you do not have a JL2005B or JL2005C or JL2005D camera among them, do you? AFAICT they all use the same compression algorithm (in stillcam mode), and it appears to me to be a really nasty one. Any help I could get with that algorithm is welcome indeed. I have to check. Please send me the USB ID. 0x0979 is the Vendor ID from Jeilin. 0x0227 is the Product ID of the JL2005B/C/D cameras (yes, all three of them have the same ID) Thomas Thanks for the information. But this is an old letter. What is happening with Michel Xhaard these days? Do you know? I miss him. Yes, I know it is an old letter, but these info are still valid for the PAC207 chipset! I don't know what happened to Michel. I didn't exchange mails with him for a long time. I believe you that the information is valid. The comment about the age of the letter related to the fact that I have not heard from Michel for approximately that long, myself. As to the information, though, what I would really like to see is a collection started which lists the known compression algorithms for the PAC family and, at least, their code bytes. So far, we have 0x00 (no compression) and 0x20, 0x50, 0xd0, and what else? For example, what is the next byte after the FF FF 00 FF 96 for the PAC207? That would probably be good to know, but if anyone has recorded that information I have missed it. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
Re: Questions about VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP
On Friday 20 February 2009 12:04:00 Jean-Francois Moine wrote: On Fri, 20 Feb 2009 09:29:36 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Support for these ioctls should be added to v4l2-ctl.cpp. It's the right place for that. But more important is to document these ioctls in the v4l2 spec. As far as I can tell these ioctls came from the zoran driver where basically a private ioctl was elevated to a public ioctl, but with little or no review. Do you know enough about these ioctls to update the v4l2 spec? That would be a great help. I'm working on the zoran driver anyway, so I'll document this and add support to v4l2-ctl. I now understand what this is about. The COM and APP markers are either obsolete or are meant as a read-only property. And while it is possible theoretically to set multiple APP segments, it is impossible with the current API to ever read more than one back. Sigh. Hi Hans, I see three parts in these ioctls: - quality, - definition of the APP and COM markers, - presence / absence of some JPEG fields (quantization, Huffman..) Looking at the video tree, the quality is treated by 5 drivers: - in cpia2, the quality is not settable and defaults to 80 (%), - in zc0301, the quality may be only set to 0, - in et61x251 and sn9c102, the quality may be set to 0 or 1, - in zoran, the quality may be set from 5% to 100%, but it is used only to compute the max size of the images! I don't see the usage of APP or COM markers. Such fields may be added by the applications. Actually, only the zoran and cpia2 drivers treat them. About the presence / absence of the JPEG fields, it is simpler to have all the required fields in the JPEG image. If some field is lacking, it should be added at conversion time by the v4l library or added by the driver if video output. The fact the ioctl permits the control of these fields obliges the drivers (input) or the applications (output) to know how to add (or remove) the fields. It seems a complex treatment for a small benefit: reduce the size of images by 100 or 200 bytes. Actually, only the zoran and cpia2 drivers treat these controls. So, I propose to remove these ioctls, and to add two controls: one to set the JPEG quality (range 15..95 %) and the other to set a webcam quality which might be a boolean or any value depending on some associated webcam parameter. What do you think of it? I have my doubts about actually removing these ioctls. I was thinking more along the lines of refining them. The quality field is currently utterly useless, so my idea was to make it a value in the range of 0-100, which the driver will convert to whatever it supports. And yes, I know 0 and 100 are impossible values, but since drivers currently support values in that range I think we should keep that. The jpeg_markers field should probably be obsoleted: i.e. drivers return 0 and ignore and set values. I agree that there is little point in that field. The APP and COM part, however, probably cannot be removed. I see no reason why we should burden apps with hacking the MJPEG stream to add these fields. And if the driver doesn't reserve space for them, then that's pretty much impossible. Especially the COM part might be useful. It would be nice to have the driver report whether APPn and COM is supported: we might be able to use field_markers for that by creating new capability bits for this. Adding a webcam quality control is fine by me, provided it is mutually exclusive with the VIDIOC_S_JPEGCOMP. Otherwise it gets really confusing (or more that it already is). 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: HVR-950q analog support - testers wanted
On Fri, Feb 20, 2009 at 1:12 PM, Robert Vincent Krakora rob.krak...@messagenetsystems.com wrote: I tried one HVR950Q device on one my mediaports and I got a lock up once and then a lockup with a kernel oops a few minutes later. It seems to load the firmware and tune correctly but has trouble playing video and audio. Ok, let's try a couple of things: Can you get an full stack trace of the oops, using perhaps a serial console? Can you identify how reproducible the issue is? Does it happen every time? Does it occur when the device is plugged in, or when you start your application? What application were you using when the problem occurred? It looks like the device was connected when the system was booted. Could you please boot up the system without the device connected and see if the issue still occurs? Thanks, -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: MR97310A and other image formats
kilg...@banach.math.auburn.edu wrote: On Fri, 20 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: On Fri, 20 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: On Thu, 19 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: Yes, what you quote is the SOF marker for all of these cameras. The total header length, including the SOF marker ought to be 12 bytes. On all of the mr97310 cameras that I have dealt with, the last 5 bytes are obviously related somehow to the image (contrast, color balance, gamma, whatever). I have no idea how to interpret those values, but we can hope that someone will figure out how. Two of them are luminance values (middle and edge) for the PAC207. Which two, and how do those numbers translate into anything relevant? Looks like I had some off list (private) email conversation about the frame header of PAC207 with Michel Xhaard. I just paste the whole thing in here: michel Xhaard wrote: Le Samedi 18 Fe'vrier 2006 12:16, vous avez e'crit : michel Xhaard wrote: Le Samedi 18 Fe'vrier 2006 10:10, vous avez e'crit : Hello Michel michel Xhaard wrote: Le Mercredi 15 Fe'vrier 2006 12:43, vous avez e'crit : Just relook the snoop, the header is always 16 bytes long starting with: ff ff 00 ff 96 64 follow xx 00 xx xx xx xx 64 xx 00 00 let try to play poker with the asumption the R mean G0 mean B mean G1 mean is encoded here. Not sure about the 64 can you look at your snoop? I never thought about that. So, you see I have not experience with webcams. Anyway, here are my observations about the header: In the snoop, it looks a bit different then yours FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 1. xx: looks like random value 2. xx: changed from 0x03 to 0x0b 3. xx: changed from 0x06 to 0x49 4. xx: changed from 0x07 to 0x55 5. xx: static 0x96 6. xx: static 0x80 7. xx: static 0xa0 And I did play in Linux and could identify some fields :-) . In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 1. xx: don't know but value is changing between 0x00 to 0x07 2. xx: this is the actual pixel clock 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Regards, Thomas Thomas, Cool good works :) so 3 and 4 are good candidate . To get good picture result there are 2 windows where the chips measure the ligth condition. Generally one is set to the center of the image the other are set to get the background light. At the moment my autobrightness setting used simple code and only one windows of measurement (the center one) . Some more info, 3 is the center one. :) Did you want i try to implement these feature ? or maybe you can have a try :) the only problem i see is between interrupt() context and process context. I have set up a spinlock for that look at the code how to use it ( spca5xx_move_data() ) Yes, please. Because I have no idea how to do this :-( I am good in investigating :-) I know, but can be very good in code to, as you know the hardware :) now let try to look at 1 ^^ What does this mean? is there the black luma level ? I don't get it. What is the black luma level? Regards, Thomas -- http://www.kaiser-linux.li By any chance, you do not have a JL2005B or JL2005C or JL2005D camera among them, do you? AFAICT they all use the same compression algorithm (in stillcam mode), and it appears to me to be a really nasty one. Any help I could get with that algorithm is welcome indeed. I have to check. Please send me the USB ID. 0x0979 is the Vendor ID from Jeilin. 0x0227 is the Product ID of the JL2005B/C/D cameras (yes, all three of them have the same ID) Thomas Thanks for the information. But this is an old letter. What is happening with Michel Xhaard these days? Do you know? I miss him. Yes, I know it is an old letter, but these info are still valid for the PAC207 chipset! I don't know what happened to Michel. I didn't exchange mails with him for a long time. I believe you that the information is valid. The comment about the age of the letter related to the fact that I have not heard from Michel for approximately that long, myself. As to the information, though, what I would really like to see is a collection started which lists the known compression algorithms for the PAC family and, at least, their code bytes. So far, we have 0x00 (no compression) and 0x20, 0x50, 0xd0, and what else? For example, what is the next byte after the FF FF 00 FF 96 for the PAC207? That would probably be good to know, but if anyone has recorded that information I have missed it. Theodore Kilgore Hello Theodore At this time I wrote this letter, I had a lot of
[cron job] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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:Fri Feb 20 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10653:359d95e1d541 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc5-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc5-armv5-omap2: OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc5-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc5-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc5-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc5-powerpc64: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-rc5-x86_64: WARNINGS fw/apps: OK spec: ERRORS sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc5): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.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 1/2] Pad configuration for OMAP3EVM Multi-Media Daughter Card Support
* Hiremath, Vaibhav hvaib...@ti.com [090210 04:11]:
Thanks,
Vaibhav Hiremath
-Original Message-
From: Hiremath, Vaibhav
Sent: Friday, January 30, 2009 12:52 AM
To: linux-o...@vger.kernel.org
Cc: linux-media@vger.kernel.org; Hiremath, Vaibhav; Jadav, Brijesh
R; Shah, Hardik
Subject: [PATCH 1/2] Pad configuration for OMAP3EVM Multi-Media
Daughter Card Support
From: Vaibhav Hiremath hvaib...@ti.com
On OMAP3EVM Mass Market Daugher Card following GPIO pins are being
used -
GPIO134 -- Enable/Disable TVP5146 interface
GPIO54 -- Enable/Disable Expansion Camera interface
GPIO136 -- Enable/Disable Camera (Sensor) interface
Added entry for the above GPIO's in mux.c and mux.h file
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/mux.c |6 ++
arch/arm/plat-omap/include/mach/mux.h |5 -
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 1556688..d226d81 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -471,6 +471,12 @@ MUX_CFG_34XX(AF5_34XX_GPIO142, 0x170,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
MUX_CFG_34XX(AE5_34XX_GPIO143, 0x172,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX(AG4_34XX_GPIO134, 0x160,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX(U8_34XX_GPIO54, 0x0b4,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX(AE4_34XX_GPIO136, 0x164,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
};
diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-
omap/include/mach/mux.h
index 67fddec..ace037f 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -795,7 +795,10 @@ enum omap34xx_index {
AF6_34XX_GPIO140_UP,
AE6_34XX_GPIO141,
AF5_34XX_GPIO142,
- AE5_34XX_GPIO143
+ AE5_34XX_GPIO143,
+ AG4_34XX_GPIO134,
+ U8_34XX_GPIO54,
+ AE4_34XX_GPIO136,
};
[Hiremath, Vaibhav] If there are no review comments on this then probably
this patch should go through, since this is independent and being used with
Multi-Media Daughter card support.
Added to omap-upstream queue and pushing to linux-omap.
Tony
--
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: MR97310A and other image formats
On Fri, 20 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: On Fri, 20 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: On Fri, 20 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: On Thu, 19 Feb 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: Yes, what you quote is the SOF marker for all of these cameras. The total header length, including the SOF marker ought to be 12 bytes. On all of the mr97310 cameras that I have dealt with, the last 5 bytes are obviously related somehow to the image (contrast, color balance, gamma, whatever). I have no idea how to interpret those values, but we can hope that someone will figure out how. Two of them are luminance values (middle and edge) for the PAC207. Which two, and how do those numbers translate into anything relevant? Looks like I had some off list (private) email conversation about the frame header of PAC207 with Michel Xhaard. I just paste the whole thing in here: michel Xhaard wrote: Le Samedi 18 Fe'vrier 2006 12:16, vous avez e'crit : michel Xhaard wrote: Le Samedi 18 Fe'vrier 2006 10:10, vous avez e'crit : Hello Michel michel Xhaard wrote: Le Mercredi 15 Fe'vrier 2006 12:43, vous avez e'crit : Just relook the snoop, the header is always 16 bytes long starting with: ff ff 00 ff 96 64 follow xx 00 xx xx xx xx 64 xx 00 00 let try to play poker with the asumption the R mean G0 mean B mean G1 mean is encoded here. Not sure about the 64 can you look at your snoop? I never thought about that. So, you see I have not experience with webcams. Anyway, here are my observations about the header: In the snoop, it looks a bit different then yours FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 1. xx: looks like random value 2. xx: changed from 0x03 to 0x0b 3. xx: changed from 0x06 to 0x49 4. xx: changed from 0x07 to 0x55 5. xx: static 0x96 6. xx: static 0x80 7. xx: static 0xa0 And I did play in Linux and could identify some fields :-) . In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 1. xx: don't know but value is changing between 0x00 to 0x07 2. xx: this is the actual pixel clock 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Regards, Thomas Thomas, Cool good works :) so 3 and 4 are good candidate . To get good picture result there are 2 windows where the chips measure the ligth condition. Generally one is set to the center of the image the other are set to get the background light. At the moment my autobrightness setting used simple code and only one windows of measurement (the center one) . Some more info, 3 is the center one. :) Did you want i try to implement these feature ? or maybe you can have a try :) the only problem i see is between interrupt() context and process context. I have set up a spinlock for that look at the code how to use it ( spca5xx_move_data() ) Yes, please. Because I have no idea how to do this :-( I am good in investigating :-) I know, but can be very good in code to, as you know the hardware :) now let try to look at 1 ^^ What does this mean? is there the black luma level ? I don't get it. What is the black luma level? Regards, Thomas -- http://www.kaiser-linux.li By any chance, you do not have a JL2005B or JL2005C or JL2005D camera among them, do you? AFAICT they all use the same compression algorithm (in stillcam mode), and it appears to me to be a really nasty one. Any help I could get with that algorithm is welcome indeed. I have to check. Please send me the USB ID. 0x0979 is the Vendor ID from Jeilin. 0x0227 is the Product ID of the JL2005B/C/D cameras (yes, all three of them have the same ID) Thomas Thanks for the information. But this is an old letter. What is happening with Michel Xhaard these days? Do you know? I miss him. Yes, I know it is an old letter, but these info are still valid for the PAC207 chipset! I don't know what happened to Michel. I didn't exchange mails with him for a long time. I believe you that the information is valid. The comment about the age of the letter related to the fact that I have not heard from Michel for approximately that long, myself. As to the information, though, what I would really like to see is a collection started which lists the known compression algorithms for the PAC family and, at least, their code bytes. So far, we have 0x00 (no compression) and 0x20, 0x50, 0xd0, and what else? For example, what is the next byte after the FF FF 00 FF 96 for the PAC207? That would probably be good to know, but if anyone has recorded that information I have missed it. Theodore Kilgore Hello Theodore At this
mantis build error on vanilla kernel 2.6.28.6 [Re: Terratec Cinergy C HD (PCI, DVB-C): how to make it work?]
Ok, I was told at #linuxtv on freenode to use a vanilla kernel, so I did: $ wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.6.tar.bz2 $ tar xjf linux-2.6.28.6.tar.bz2 $ cd linux-2.6.28.6/ $ make menuconfig $ sudo make modules_install install (reboot) $ wget -c http://jusst.de/hg/mantis/archive/tip.tar.bz2 $ tar xjf tip.tar.bz2 $ cd mantis-5292a47772ad/ $ make ... /home/gronslet/Download/mantis-5292a47772ad/v4l/saa7134-alsa.c: In function 'snd_card_saa7134_hw_params': /home/gronslet/Download/mantis-5292a47772ad/v4l/saa7134-alsa.c:496: error: implicit declaration of function 'snd_assert' /home/gronslet/Download/mantis-5292a47772ad/v4l/saa7134-alsa.c:497: error: expected expression before 'return' /home/gronslet/Download/mantis-5292a47772ad/v4l/saa7134-alsa.c:498: error: expected expression before 'return' /home/gronslet/Download/mantis-5292a47772ad/v4l/saa7134-alsa.c:499: error: expected expression before 'return' /home/gronslet/Download/mantis-5292a47772ad/v4l/saa7134-alsa.c: In function 'snd_card_saa7134_new_mixer': /home/gronslet/Download/mantis-5292a47772ad/v4l/saa7134-alsa.c:950: error: expected expression before 'return' make[3]: *** [/home/gronslet/Download/mantis-5292a47772ad/v4l/saa7134-alsa.o] Error 1 make[2]: *** [_module_/home/gronslet/Download/mantis-5292a47772ad/v4l] Error 2 make[2]: Leaving directory `/mythmedia/buffer/linux-2.6.28.6' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/gronslet/Download/mantis-5292a47772ad/v4l' make: *** [all] Error 2 What did I miss here? -MartinG -- 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: Questions about VIDIOC_G_JPEGCOMP / VIDIOC_S_JPEGCOMP
On Fri, 20 Feb 2009, Jean-Francois Moine wrote: So, I propose to remove these ioctls, and to add two controls: one to set the JPEG quality (range 15..95 %) and the other to set a webcam quality which might be a boolean or any value depending on some associated webcam parameter. A control can have any min, max and step size the driver wants to give it. So their could easily be a quality control that's 15 to 95 on one driver and 0 to 1 on another. For zoran, I wonder if it would a good idea to support the existing V4L2_CID_MPEG_VIDEO_BITRATE_MODE and V4L2_CID_MPEG_VIDEO_BITRATE controls. Yeah, zoran is MJPEG and not MPEG, but what does one letter in the control name matter? IIRC, the zr36060 chip supports both VBR and CBR. The hardware is programmed with a bit rate in CBR mode. The quality setting is just an artificial construct created by the driver for user convenience. A generic quality control would still be useful for hardware that doesn't support bitrate setting and just as some nebulous quality setting. -- 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: [linux-dvb] Terratec Cinergy T USB XXS: remote does not work with 1.20 firmware
On Fri, Feb 20, 2009 at 4:43 PM, Nicolas George nicolas.geo...@normalesup.org wrote: Hi. I am trying to get the remote controller with a Terratec Cinergy T USB XXS. With the firmware dvb-usb-dib0700-1.10.fw, the remote sends codes (not perfectly, but I can see where I am going). On the other hand, with dvb-usb-dib0700-1.20.fw, the remote does not detect anything. After some tracking, I found that in dib0700_rc_query_v1_20 (from dib0700_devices.c), the status from usb_bulk_msg is always -110 (-ETIMEDOUT). Is there some way I can help fixing things? I do not mind using the old firmware, but I would like to help improving things. That's code I wrote, based on information provided by Patrick over at Dibcom. I would have to look at the code, but if I recall, the code is designed to return -ETIMEDOUT during normal operation when no key press is detected. That said, seeing that return condition should not be perceived as a problem. Are there any cases where it returns something *other* than -ETIMEDOUT? Because if so, then the keypress is probably being received but not processed properly. I would recommend you add a line of code to printk() any return condition other than -ETIMEDOUT, and see if something shows up in the log when you try to use the remote control. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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 Cinergy T USB XXS: remote does not work with 1.20 firmware
[This is a repost of a message sent to the obsolete linux-...@linuxtv.org list.] Hi. I am trying to get the remote controller with a Terratec Cinergy T USB XXS. With the firmware dvb-usb-dib0700-1.10.fw, the remote sends codes (not perfectly, but I can see where I am going). On the other hand, with dvb-usb-dib0700-1.20.fw, the remote does not detect anything. After some tracking, I found that in dib0700_rc_query_v1_20 (from dib0700_devices.c), the status from usb_bulk_msg is always -110 (-ETIMEDOUT). Is there some way I can help fixing things? I do not mind using the old firmware, but I would like to help improving things. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: Terratec Cinergy T USB XXS: remote does not work with 1.20 firmware
On Fri, Feb 20, 2009 at 5:50 PM, Nicolas George nicolas.geo...@normalesup.org wrote: [This is a repost of a message sent to the obsolete linux-...@linuxtv.org list.] Hi. I am trying to get the remote controller with a Terratec Cinergy T USB XXS. With the firmware dvb-usb-dib0700-1.10.fw, the remote sends codes (not perfectly, but I can see where I am going). On the other hand, with dvb-usb-dib0700-1.20.fw, the remote does not detect anything. After some tracking, I found that in dib0700_rc_query_v1_20 (from dib0700_devices.c), the status from usb_bulk_msg is always -110 (-ETIMEDOUT). Is there some way I can help fixing things? I do not mind using the old firmware, but I would like to help improving things. Regards, -- Nicolas George That's code I wrote, based on information provided by Patrick over at Dibcom. I would have to look at the code, but if I recall, the code is designed to return -ETIMEDOUT during normal operation when no key press is detected. That said, seeing that return condition should not be perceived as a problem. Are there any cases where it returns something *other* than -ETIMEDOUT? Because if so, then the keypress is probably being received but not processed properly. I would recommend you add a line of code to printk() any return condition other than -ETIMEDOUT, and see if something shows up in the log when you try to use the remote control. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: mantis build error on vanilla kernel 2.6.28.6 [Re: Terratec Cinergy C HD (PCI, DVB-C): how to make it work?]
On Sat, Feb 21, 2009 at 12:22 AM, hermann pitton
hermann-pit...@arcor.de wrote:
you can see changes on saa7134-alsa here.
http://linuxtv.org/hg/v4l-dvb/log/359d95e1d541/linux/drivers/media/video/saa7134/saa7134-alsa.c
Likely this kernel backport is missing.
http://linuxtv.org/hg/v4l-dvb/rev/b4d664a2592a
Thank you for your reply!
I think I got it working, thanks to you. This is what I did (on the
vanilla 2.6.28.6 kernel):
$ cd mantis-5292a47772ad/
$ make distclean clean
$ cp v4l/saa7134-alsa.c v4l/saa7134-alsa.c.orig
$ emacs -nw v4l/saa7134-alsa.c
Patch according to:
http://linuxtv.org/hg/v4l-dvb/diff/b4d664a2592a/linux/drivers/media/video/saa7134/saa7134-alsa.c
$ make -j2
(works)
# make install
remove all other (dvb) modules
# modprobe mantis
This gave me at least
/dev/dvb/adapter0/{demux0,dvr0,frontend0,net0}
But then the computer froze when I did:
# scandvb dvb-apps/util/scan/dvb-c/no-Oslo-Get
scanning dvb-apps/util/scan/dvb-c/no-Oslo-Get
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 24100 690 0 5
initial transponder 27200 690 0 5
initial transponder 28000 690 0 5
initial transponder 29000 690 0 5
initial transponder 29800 690 0 5
initial transponder 30600 690 0 5
initial transponder 31400 690 0 5
initial transponder 32200 690 0 5
initial transponder 33000 690 0 5
initial transponder 33800 690 0 5
initial transponder 34600 690 0 5
initial transponder 35400 690 0 5
initial transponder 36200 690 0 5
initial transponder 37000 690 0 5
initial transponder 37800 690 0 5
initial transponder 38600 690 0 5
initial transponder 39400 690 0 5
initial transponder 41000 690 0 5
initial transponder 44200 6952000 0 5
initial transponder 48200 690 0 5
initial transponder 49800 690 0 5
tune to: 24100:INVERSION_AUTO:690:FEC_NONE:QAM_256
(total freeze here, not even ssh access to the box)
I think I had the scandvb tool from a binary install, maybe I'll try
to compile from sources.
And I'll try to read some more docs.
Thank you for helping me out on this!
-MartinG
--
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: Minimum kernel version supported by v4l-dvb
On Wed, 18 Feb 2009 14:01:05 +0100 Jean Delvare kh...@linux-fr.org wrote: Hi Mauro, On Wed, 18 Feb 2009 07:10:41 -0300, Mauro Carvalho Chehab wrote: On Wed, 18 Feb 2009 09:55:53 +0100 (CET) Hans Verkuil hverk...@xs4all.nl wrote: Not at all. I work with embedded systems and what happens is that you effectively take a kernel snapshot for your device and stick to that. You're not using v4l-dvb, but you might backport important fixes on occasion. Again, it's not our job. The linux model is to get your drivers into the kernel, then let distros take care of the rest, which includes backporting if needed to older kernels. We are doing the work that distros should be doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the express purpose to be finally free of keeping it backwards compatible with older kernels. Now I find myself doing the same AGAIN. And you are talking about that mythical user that needs it. I've yet to SEE that user here and telling me that it is essential to their product. PROVE to me that it is really necessary and really our job, and esp. my job, since *I'm* the one keeping the backwards compatibility for i2c modules alive. All I hear is 'there might be', 'I know some company', 'I heard'. Right now there is crappy code in the kernel whose only purpose is to facilitate support for old kernels. That's actually against the kernel policy. One alternative is it create a separate repository just before the compat code is removed, and merge important fixes for drivers in there. That should tide us over until RHEL 6 is released. Which also raises the other question: what criterium is there anyway to decide what is the oldest kernel to support? RHEL 5 will no doubt be used for 1-2 years after RHEL 6 is release, do we still keep support for that? Old kernels will be used for a long time in embedded systems, do we still keep support for that too? Hans, I'm doing backport since 2005. So, you are not the only one that are doing backports. On V4L, this started ever since. In the case of DVB, we started backport on 2006. Before that, they use to support only the latest kernel version. If you get a snapshot of our tree of about 6 months to one year ago, we had even support for linux-2.4 I2C (and yes, this works - I have a tree here for vivi and bttv drivers based on that i2c support, working with 2.4). Not necessarily something to be proud about. This only shows how slowly v4l has evolved in the past few years. Big changes that should have happen have been constantly postponed in the name of compatibility. No change I'm aware of were postponed due to previous kernel compatibility. In the past, our criteria were simply to support all 2.6 versions and the latest 2.4 versions. Sometime after having the last 2.4 distro moving their stable repo to 2.6, we decided to drop 2.4, because we got no complains to keep 2.4 on that time. Maybe the current solution for i2c backport is not the better one, and we need to use another approach. If the current i2c backport is interfering on the development, then maybe we need to re-think about the backport implementation. The backport shouldn't affect the upstream. It were never affected until the recent i2c backport. Even the 2.4 i2c backport didn't interfere upstream, even having a completely different implementation on 2.4. Actually, 2.6 kernels up to 2.6.13 had an i2c API very similar to what 2.4 had. The binding model changes we are undergoing now are way more intrusive than the migration from 2.4 to early 2.6. This is true for the drivers that are using the newer model. However, there are still several drivers that use the old model (bttv, em28xx, cx88 - maybe others). I think that maybe we'll need some legacy-like support for bttv and cx88, since there are some boards that relies on the old i2c method to work. On those boards (like cx88 Pixelview), the same board model (and PCB revision) may or may not have a separate audio decoder. On those devices that have an audio decoder, the widely used solution is to load tvaudio module and let it bind at the i2c bus, on such cases. The only reasonable criterium I see is technical: when you start to introduce cruft into the kernel just to support older kernels, then it is time to cut off support to those kernels. The criteria for backport is not technical. That technical isn't the only criteria, I agree with. But claiming that technical isn't a criteria at all is plain wrong. This is equivalent to claiming that development time doesn't cost anything. Well, what's the technical criteria? I don't see much #if's inside the i2c part of the drivers. (...) It is all about offering a version that testers with standard distros can use it, without needing to use the latest
Re: Minimum kernel version supported by v4l-dvb
On Saturday 21 February 2009 01:23:27 Mauro Carvalho Chehab wrote: On Wed, 18 Feb 2009 14:01:05 +0100 Jean Delvare kh...@linux-fr.org wrote: Hi Mauro, On Wed, 18 Feb 2009 07:10:41 -0300, Mauro Carvalho Chehab wrote: On Wed, 18 Feb 2009 09:55:53 +0100 (CET) Hans Verkuil hverk...@xs4all.nl wrote: Not at all. I work with embedded systems and what happens is that you effectively take a kernel snapshot for your device and stick to that. You're not using v4l-dvb, but you might backport important fixes on occasion. Again, it's not our job. The linux model is to get your drivers into the kernel, then let distros take care of the rest, which includes backporting if needed to older kernels. We are doing the work that distros should be doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the express purpose to be finally free of keeping it backwards compatible with older kernels. Now I find myself doing the same AGAIN. And you are talking about that mythical user that needs it. I've yet to SEE that user here and telling me that it is essential to their product. PROVE to me that it is really necessary and really our job, and esp. my job, since *I'm* the one keeping the backwards compatibility for i2c modules alive. All I hear is 'there might be', 'I know some company', 'I heard'. Right now there is crappy code in the kernel whose only purpose is to facilitate support for old kernels. That's actually against the kernel policy. One alternative is it create a separate repository just before the compat code is removed, and merge important fixes for drivers in there. That should tide us over until RHEL 6 is released. Which also raises the other question: what criterium is there anyway to decide what is the oldest kernel to support? RHEL 5 will no doubt be used for 1-2 years after RHEL 6 is release, do we still keep support for that? Old kernels will be used for a long time in embedded systems, do we still keep support for that too? Hans, I'm doing backport since 2005. So, you are not the only one that are doing backports. On V4L, this started ever since. In the case of DVB, we started backport on 2006. Before that, they use to support only the latest kernel version. If you get a snapshot of our tree of about 6 months to one year ago, we had even support for linux-2.4 I2C (and yes, this works - I have a tree here for vivi and bttv drivers based on that i2c support, working with 2.4). Not necessarily something to be proud about. This only shows how slowly v4l has evolved in the past few years. Big changes that should have happen have been constantly postponed in the name of compatibility. No change I'm aware of were postponed due to previous kernel compatibility. In the past, our criteria were simply to support all 2.6 versions and the latest 2.4 versions. Sometime after having the last 2.4 distro moving their stable repo to 2.6, we decided to drop 2.4, because we got no complains to keep 2.4 on that time. Maybe the current solution for i2c backport is not the better one, and we need to use another approach. If the current i2c backport is interfering on the development, then maybe we need to re-think about the backport implementation. The backport shouldn't affect the upstream. It were never affected until the recent i2c backport. Even the 2.4 i2c backport didn't interfere upstream, even having a completely different implementation on 2.4. Actually, 2.6 kernels up to 2.6.13 had an i2c API very similar to what 2.4 had. The binding model changes we are undergoing now are way more intrusive than the migration from 2.4 to early 2.6. This is true for the drivers that are using the newer model. However, there are still several drivers that use the old model (bttv, em28xx, cx88 - maybe others). I think that maybe we'll need some legacy-like support for bttv and cx88, since there are some boards that relies on the old i2c method to work. On those boards (like cx88 Pixelview), the same board model (and PCB revision) may or may not have a separate audio decoder. On those devices that have an audio decoder, the widely used solution is to load tvaudio module and let it bind at the i2c bus, on such cases. That's what the i2c_new_probed_device() call is for (called through v4l2_i2c_new_probed_subdev). You pass a list of i2c addresses that the i2c core will probe for you: but this comes from the adapter driver, not from the i2c module. And that makes all the difference. So bttv, cx88, etc. are all on my list to be converted. The drivers pvrusb2, cx18 and em28xx are already being converted by Mike Isely, Andy Walls and Douglas Landgraf. I'm doing usbvision and w9968cf. I have already done zoran, vino and cafe_ccic which are waiting for test results. That leaves bttv,
Re: Minimum kernel version supported by v4l-dvb
On Fri, 20 Feb 2009, Mauro Carvalho Chehab wrote: On Wed, 18 Feb 2009 14:01:05 +0100 Jean Delvare kh...@linux-fr.org wrote: Hi Mauro, On Wed, 18 Feb 2009 07:10:41 -0300, Mauro Carvalho Chehab wrote: On Wed, 18 Feb 2009 09:55:53 +0100 (CET) Hans Verkuil hverk...@xs4all.nl wrote: Not at all. I work with embedded systems and what happens is that you effectively take a kernel snapshot for your device and stick to that. You're not using v4l-dvb, but you might backport important fixes on occasion. Again, it's not our job. The linux model is to get your drivers into the kernel, then let distros take care of the rest, which includes backporting if needed to older kernels. We are doing the work that distros should be doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the express purpose to be finally free of keeping it backwards compatible with older kernels. Now I find myself doing the same AGAIN. And you are talking about that mythical user that needs it. I've yet to SEE that user here and telling me that it is essential to their product. PROVE to me that it is really necessary and really our job, and esp. my job, since *I'm* the one keeping the backwards compatibility for i2c modules alive. All I hear is 'there might be', 'I know some company', 'I heard'. Right now there is crappy code in the kernel whose only purpose is to facilitate support for old kernels. That's actually against the kernel policy. One alternative is it create a separate repository just before the compat code is removed, and merge important fixes for drivers in there. That should tide us over until RHEL 6 is released. Which also raises the other question: what criterium is there anyway to decide what is the oldest kernel to support? RHEL 5 will no doubt be used for 1-2 years after RHEL 6 is release, do we still keep support for that? Old kernels will be used for a long time in embedded systems, do we still keep support for that too? Hans, I'm doing backport since 2005. So, you are not the only one that are doing backports. On V4L, this started ever since. In the case of DVB, we started backport on 2006. Before that, they use to support only the latest kernel version. If you get a snapshot of our tree of about 6 months to one year ago, we had even support for linux-2.4 I2C (and yes, this works - I have a tree here for vivi and bttv drivers based on that i2c support, working with 2.4). Not necessarily something to be proud about. This only shows how slowly v4l has evolved in the past few years. Big changes that should have happen have been constantly postponed in the name of compatibility. No change I'm aware of were postponed due to previous kernel compatibility. In the past, our criteria were simply to support all 2.6 versions and the latest 2.4 versions. Sometime after having the last 2.4 distro moving their stable repo to 2.6, we decided to drop 2.4, because we got no complains to keep 2.4 on that time. Maybe the current solution for i2c backport is not the better one, and we need to use another approach. If the current i2c backport is interfering on the development, then maybe we need to re-think about the backport implementation. The backport shouldn't affect the upstream. It were never affected until the recent i2c backport. Even the 2.4 i2c backport didn't interfere upstream, even having a completely different implementation on 2.4. Actually, 2.6 kernels up to 2.6.13 had an i2c API very similar to what 2.4 had. The binding model changes we are undergoing now are way more intrusive than the migration from 2.4 to early 2.6. This is true for the drivers that are using the newer model. However, there are still several drivers that use the old model (bttv, em28xx, cx88 - maybe others). I think that maybe we'll need some legacy-like support for bttv and cx88, since there are some boards that relies on the old i2c method to work. On those boards (like cx88 Pixelview), the same board model (and PCB revision) may or may not have a separate audio decoder. On those devices that have an audio decoder, the widely used solution is to load tvaudio module and let it bind at the i2c bus, on such cases. The only reasonable criterium I see is technical: when you start to introduce cruft into the kernel just to support older kernels, then it is time to cut off support to those kernels. The criteria for backport is not technical. That technical isn't the only criteria, I agree with. But claiming that technical isn't a criteria at all is plain wrong. This is equivalent to claiming that development time doesn't cost anything. Well, what's the technical criteria? I don't see much #if's inside the i2c part of the drivers. (...) It is all about offering a version that testers with standard distros can use it, without needing to use the latest -rc kernel. I'm fine to drop support to unused kernels, but the hole idea to have backport is to allow an easy usage of the
Re: [linux-dvb] Can I use AVerTV Volar Black HD (A850) with Linux ?
Hi,
I bought an AverMedia Volar Black HD too.
I opened it, i can confirm the device contains a AF9015N1 chip and a
MXL5003S tuner.
I think there was something missing your diff Antti :
@@ -1404,7 +1405,7 @@
.i2c_algo = af9015_i2c_algo,
- .num_device_descs = 7,
+ .num_device_descs = 8,
.devices = {
{
.name = Xtensions XD-380,
After patching af9015.c file, when i plug it, modules are loading but it
seems that the tuner did not work :
Module Size Used by
mxl5005s 32388 1
af9013 18756 1
dvb_usb_af9015 27184 0
dvb_usb19916 1 dvb_usb_af9015
dvb_core 88676 1 dvb_usb
$ dmesg
usb 4-1: configuration #1 chosen from 1 choice
dvb-usb: found a 'AVerMedia A850' in cold state, will try to load a firmware
firmware: requesting dvb-usb-af9015.fw
dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw'
dvb-usb: found a 'AVerMedia A850' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software
demuxer.
DVB: registering new adapter (AVerMedia A850)
af9013: firmware version:4.95.0
DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)...
MXL5005S: Attached at address 0xc6
dvb-usb: will pass the complete MPEG2 transport stream to the software
demuxer.
DVB: registering new adapter (AVerMedia A850)
af9015: command failed:2
af9015: firmware copy to 2nd frontend failed, will disable it
dvb-usb: no frontend was attached by 'AVerMedia A850'
dvb-usb: AVerMedia A850 successfully initialized and connected.
usbcore: registered new interface driver dvb_usb_af9015
$ dvbscan /usr/share/dvb/dvb-t/fr-Lyon-Fourviere
Unable to query frontend status
$ dmesg
af9015: recv bulk message failed:-110
af9013: I2C read failed reg:d417
Anything else we can try Antti ?
Thanks
signature.asc
Description: OpenPGP digital signature
Re: mantis build error on vanilla kernel 2.6.28.6 [Re: Terratec Cinergy C HD (PCI, DVB-C): how to make it work?]
Am Samstag, den 21.02.2009, 01:06 +0100 schrieb MartinG:
On Sat, Feb 21, 2009 at 12:22 AM, hermann pitton
hermann-pit...@arcor.de wrote:
you can see changes on saa7134-alsa here.
http://linuxtv.org/hg/v4l-dvb/log/359d95e1d541/linux/drivers/media/video/saa7134/saa7134-alsa.c
Likely this kernel backport is missing.
http://linuxtv.org/hg/v4l-dvb/rev/b4d664a2592a
Thank you for your reply!
I think I got it working, thanks to you. This is what I did (on the
vanilla 2.6.28.6 kernel):
$ cd mantis-5292a47772ad/
$ make distclean clean
$ cp v4l/saa7134-alsa.c v4l/saa7134-alsa.c.orig
$ emacs -nw v4l/saa7134-alsa.c
Patch according to:
http://linuxtv.org/hg/v4l-dvb/diff/b4d664a2592a/linux/drivers/media/video/saa7134/saa7134-alsa.c
$ make -j2
(works)
# make install
remove all other (dvb) modules
# modprobe mantis
This gave me at least
/dev/dvb/adapter0/{demux0,dvr0,frontend0,net0}
But then the computer froze when I did:
# scandvb dvb-apps/util/scan/dvb-c/no-Oslo-Get
scanning dvb-apps/util/scan/dvb-c/no-Oslo-Get
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 24100 690 0 5
initial transponder 27200 690 0 5
initial transponder 28000 690 0 5
initial transponder 29000 690 0 5
initial transponder 29800 690 0 5
initial transponder 30600 690 0 5
initial transponder 31400 690 0 5
initial transponder 32200 690 0 5
initial transponder 33000 690 0 5
initial transponder 33800 690 0 5
initial transponder 34600 690 0 5
initial transponder 35400 690 0 5
initial transponder 36200 690 0 5
initial transponder 37000 690 0 5
initial transponder 37800 690 0 5
initial transponder 38600 690 0 5
initial transponder 39400 690 0 5
initial transponder 41000 690 0 5
initial transponder 44200 6952000 0 5
initial transponder 48200 690 0 5
initial transponder 49800 690 0 5
tune to: 24100:INVERSION_AUTO:690:FEC_NONE:QAM_256
(total freeze here, not even ssh access to the box)
I think I had the scandvb tool from a binary install, maybe I'll try
to compile from sources.
And I'll try to read some more docs.
Thank you for helping me out on this!
-MartinG
I am sorry for that.
To give an example.
If we are seated in a chair looking to the wall in front of us or better
to the horizon in the height of our eyes, without moving our eyes we can
see something like 180 degrees horizontally.
If we move our eyes we can see already a lot in our backs, if we move
our heads we can see already almost all in our backs, to move the body
is a further step only taken if really needed.
Now, from the first just sitting there, the vertical reception is a
little different, at least for me. Without moving the eyes we can see
our feet, not that sharp, but enough to be aware of.
In the upper direction it seems to be a little bit different, only the
half of what is present on the bottom is visible without moving ...
This seems to be a part of the conditio humanum we share with others :)
It is the same with out of kernel drivers.
Await Manu's instructions what to use for testing and if a 2.6.28 is
safe.
Cheers,
Hermann
--
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: Minimum kernel version supported by v4l-dvb
On Sat, 21 Feb 2009 02:12:53 +0100 Hans Verkuil hverk...@xs4all.nl wrote: I think that maybe we'll need some legacy-like support for bttv and cx88, since there are some boards that relies on the old i2c method to work. On those boards (like cx88 Pixelview), the same board model (and PCB revision) may or may not have a separate audio decoder. On those devices that have an audio decoder, the widely used solution is to load tvaudio module and let it bind at the i2c bus, on such cases. That's what the i2c_new_probed_device() call is for (called through v4l2_i2c_new_probed_subdev). You pass a list of i2c addresses that the i2c core will probe for you: but this comes from the adapter driver, not from the i2c module. This is a problem. The current procedure used by end users will stop working. It is a little worse: as the adapter driver has no means to know that some device could need tvaudio or other similar devices, we would need some hacking to allow the user to pass a parameter to the driver in order to test/load such drivers, since there's no documentation of when such things are needed. And that makes all the difference. So bttv, cx88, etc. are all on my list to be converted. The drivers pvrusb2, cx18 and em28xx are already being converted by Mike Isely, Andy Walls and Douglas Landgraf. I'm doing usbvision and w9968cf. I have already done zoran, vino and cafe_ccic which are waiting for test results. That leaves bttv, cx88 and cx23885 which still need a volunteer. The worse one will be bttv. For sure there are several cases where users need to load the i2c modules by hand. On cx88, the only case I know is with Pixelview Ultra Pro devices. Yet, I dunno how to properly solve it. The manufacturer chipped a dozen of different boards, all of them without eeproms - so using the generic address - and most using the same PCB revision. I've seen models of PV ultra with Philips 1236 tuners, with Tena tuners, with TI-based tuners, with tvaudio and without tvaudio chips, with tea5767, without tea5767... There's no external indication about what's inside the device. All of them are branded with the same name and the same model number. The only reasonable criterium I see is technical: when you start to introduce cruft into the kernel just to support older kernels, then it is time to cut off support to those kernels. The criteria for backport is not technical. That technical isn't the only criteria, I agree with. But claiming that technical isn't a criteria at all is plain wrong. This is equivalent to claiming that development time doesn't cost anything. Well, what's the technical criteria? I don't see much #if's inside the i2c part of the drivers. Look in include/media/v4l2-i2c-drv*.h and v4l2-common.c. That's why I created these headers: to keep the #if's to a minimum in the actual i2c modules. The -legacy variant is really bad, but when I'm done with the conversion it can actually disappear, so in all fairness we can ignore that header. But v4l2-i2c-drv.h is bad enough, and even worse is what it looks like in the kernel when the compat code has been stripped from it: it's turned into a completely pointless header. And all the v4l2 i2c modules look peculiar as well due to that header include. IMO, we should first focus on removing the legacy code. Even on v4l2-common.c, we have some tricks due to legacy support. After removing the legacy code, I suspect that the code will be simpler to understand the code and to find other ways to preserve compatibility if needed. I suspect that just removing 2.6.22 or lower support is not enough to remove v4l2-i2c-drv.h. Maybe we should have some sort of scripts to auto-generate tarballs with backport patches inside (alsa has a model like this). They are now using -git for development, and stopped using -hg. The issue here is that we should take some time to think on how this will work, and design a set of scripts to generate the backport tree. As long as we intend to provide some sort of backwards compatibility we will hit the same problem: for how long will you keep supporting kernels? And the reason why the i2c part is so hard is that it isn't a case of changed data structures or some data that's been move from one place to another, but it is a complete change in the i2c model. And the solutions to that end up affecting the code as it appears in the kernel, and that's really bad. Eventually, things could be easier if we found better model. For example, a configure script could seek for a particular string on a kernel header. If not found, it may apply a patch, or run a parser to replace one code into another. This way, the development code won't have any #if's or compat code. I'm afraid that just using patches may also bring another range of troubles of needing to periodically maintain the backports. On the other hand, a syntax/semantic parser would be
