Re: [ADMIN] linuxtv.org is moving
Thank you for your hard work! Me and my co-workers appreciate you. Cheers, Nate On Thu, Mar 26, 2009 at 1:25 AM, Johannes Stezenbach j...@linuxtv.org wrote: Hi, linuxtv.org will move to a new server machine tomorrow. Expect some downtime during the move and please be patient. Everything on the old machine will be rsynced to the new machine right before the switch so nothing should get lost. Cheers, Johannes -- 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 -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
how about adding FOCUS mode?
Hello, Hans everyone.
I'm trying to adapt the various FOCUS MODE int the NEC ISP driver.
NEC ISP supports 4 focus mode, AUTO/MACRO/MANUAL/FULL or NORMAL.
but, i think that it's a little insufficient to use V4L2 FOCUS Feature.
so, suggest that,
- change V4L2_CID_FOCUS_AUTO's type from boolean to interger, and add
the following enumerations for CID values.
enum v4l2_focus_mode {
V4L2_FOCUS_AUTO = 0,
V4L2_FOCUS_MACRO = 1,
V4L2_FOCUS_MANUAL = 2,
V4L2_FOCUS_NORMAL = 3,
V4L2_FOCUS_LASTP = 3,
};
how about this usage? i wanna get some advice about FOCUS MODE.
Thanks,
Riverful
--
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: how about adding FOCUS mode?
On Friday 27 March 2009 07:20:51 Kim, Heung Jun wrote:
Hello, Hans everyone.
I'm trying to adapt the various FOCUS MODE int the NEC ISP driver.
NEC ISP supports 4 focus mode, AUTO/MACRO/MANUAL/FULL or NORMAL.
but, i think that it's a little insufficient to use V4L2 FOCUS Feature.
so, suggest that,
- change V4L2_CID_FOCUS_AUTO's type from boolean to interger, and add
the following enumerations for CID values.
enum v4l2_focus_mode {
V4L2_FOCUS_AUTO = 0,
V4L2_FOCUS_MACRO = 1,
V4L2_FOCUS_MANUAL = 2,
V4L2_FOCUS_NORMAL = 3,
V4L2_FOCUS_LASTP = 3,
};
how about this usage? i wanna get some advice about FOCUS MODE.
This seems more logical to me:
enum v4l2_focus_mode {
V4L2_FOCUS_MANUAL = 0,
V4L2_FOCUS_AUTO_NORMAL = 1,
V4L2_FOCUS_AUTO_MACRO = 2,
};
At least this maps the current boolean values correctly. I'm not sure from
your decription what the fourth auto focus mode is supposed to be.
But I think it might be better to have a separate control that allows you to
set the auto-focus mode. I can imagine that different devices might have
different auto-focus modes.
I've CC-ed Laurent since this is more his field than mine.
Regards,
Hans
Thanks,
Riverful
--
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: [v4l-dvb-maintainer] [PATCH] Allow the user to restrict the RC5 address
On Thursday 26 March 2009 19:45:53 Udo A. Steinberg wrote: On Thu, 26 Mar 2009 12:45:18 -0400 Steven Toth (ST) wrote: ST I too tend to have multiple remotes, I don't think it's that unusual for ST long standing Hauppauge customers to have many boards with many types of ST remotes. ST ST It might be better to have an option to explicitly allow old Hauppauge ST remotes that send 0x00. ST ST I could live with this. It relegates older remotes but those remotes ST are no longer made. This feels like a good compromise. How about changing the parameter such that it is a filter mask? The default value of 0x0 would accept all remotes. For non-zero values, each bit set in the parameter would filter the device address corresponding to that bit, e.g. 0x1 would filter address 0x0, 0x8000 would filter address 0x1f, etc. Seems way to complicated to me. Remember that end users have no idea about the device addresses, so it should be a simple to understand module option. So I'd just go with Steve's preference. Regards, Hans Cheers, - Udo -- 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: [PATCH v3] ov772x: add edge contrl support
Hello Morimoto-san
On Wed, 25 Mar 2009, morimoto.kunin...@renesas.com wrote:
Whatever this edge does, isn't it so, that threshold, upper, and
lower parameters configure it and strength actually enforces the
changes? Say, if strength == 0, edge control is off, and as soon as you
switch it to != 0, it is on with all the configured parameters? If my
guess is right, wouldn't it make sense to first configure parameters and
then set strength? If you agree, I'll just swap them when committing, so,
you don't have to resend. Just please either confirm that you agree, or
explain why I am wrong.
I don't know detail of these register's order.
Because my datasheet doesn't have detail explain.
For example, does strength actually enforce
all of configured parameters change ?
So, I tried to test whether these register setting
order were important.
It seems to be independent apparently respectively.
For example, I can change only upper register and
the setting was effective.
So, you _do_ know what that parameter does - if you can verify what effect
it produces on the camera? So, that's just what I was asking - what do
these settings do? What changes do you observe when you manipulate them?
And this your observation actually suffices to me to preserve your
original order of register writes. If documentation says nothing about it,
and as long as it works - we can keep it.
So, I will ask to maker about these register's behavior.
Because it seems to relate to other register.
So, please ignore this patch until I get answer. sorry.
Well, I don't think we have to wait for an answer for too long. If they
don't reply within 1-2 days, let's just take the patch as is (with the
single minor correction I proposed).
+#define OV772X_EDGECTRL(s, t, u, l)\
+{ \
+ .strength = (s 0x1F), \
+ .threshold = (t 0x0F), \
+ .upper = (u 0xFF), \
+ .lower = (l 0xFF), \
+}
I will fix this in next =)
That's up to you. This is a minor formatting correction, which I can do
myself when merging. But if you like, you can send an update, sure.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
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/5] CSI camera interface driver for MX1
Sparse is another tool which can be used while building the kernel to increase the build time checking, but it can be quite noisy, so please only look at stuff which pops up for your specific area. To get rid of some of the warnings, you can analyze only the parts of the source that you're working on. You just need sparse in your PATH and issue: $ make SUBDIRS=arch/arm/mach-mx2 C=2 Unfortunately, the arm tree is a bit different to mainline linux, because $ make SUBDIRS=arch/arm C=2 arch/arm/Makefile:31: *** Recursive variable `KBUILD_CFLAGS' references itself (eventually). Stop. make: *** [_module_arch/arm] Error 2 breaks, with and without sparse: -- 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
DMB-TH patches
Hi all, Anyone would like to take care of my patch related to DMB-TH? at least putting them into some development branch? The unified lgs8gxx code is much complete compare to the reverse engineered lgs8gl5, and It is tested by lgs8gl5 original author Timothy Lee. The patches are: http://patchwork.kernel.org/patch/12633/ http://patchwork.kernel.org/patch/12634/ http://patchwork.kernel.org/patch/12636/ http://www.spinics.net/lists/linux-media/msg03655.html David -- 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/5] CSI camera interface driver for MX1
On Fri, Mar 27, 2009 at 08:33:27AM +0100, Holger Schurig wrote: Sparse is another tool which can be used while building the kernel to increase the build time checking, but it can be quite noisy, so please only look at stuff which pops up for your specific area. To get rid of some of the warnings, you can analyze only the parts of the source that you're working on. You just need sparse in your PATH and issue: $ make SUBDIRS=arch/arm/mach-mx2 C=2 Unfortunately, the arm tree is a bit different to mainline linux, because $ make SUBDIRS=arch/arm C=2 arch/arm/Makefile:31: *** Recursive variable `KBUILD_CFLAGS' references itself (eventually). Stop. make: *** [_module_arch/arm] Error 2 Line 31 is the KBUILD_CFLAGS line of: ifeq ($(CONFIG_FRAME_POINTER),y) KBUILD_CFLAGS +=-fno-omit-frame-pointer -mapcs -mno-sched-prolog endif which is _not_ a recursive definition. Either your make is broken or you have local changes to that line. -- 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: how about adding FOCUS mode?
Hello Hans, and Laurent
On Fri, Mar 27, 2009 at 4:24 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On Friday 27 March 2009 07:20:51 Kim, Heung Jun wrote:
Hello, Hans everyone.
I'm trying to adapt the various FOCUS MODE int the NEC ISP driver.
NEC ISP supports 4 focus mode, AUTO/MACRO/MANUAL/FULL or NORMAL.
but, i think that it's a little insufficient to use V4L2 FOCUS Feature.
so, suggest that,
- change V4L2_CID_FOCUS_AUTO's type from boolean to interger, and add
the following enumerations for CID values.
enum v4l2_focus_mode {
V4L2_FOCUS_AUTO = 0,
V4L2_FOCUS_MACRO = 1,
V4L2_FOCUS_MANUAL = 2,
V4L2_FOCUS_NORMAL = 3,
V4L2_FOCUS_LASTP = 3,
};
how about this usage? i wanna get some advice about FOCUS MODE.
This seems more logical to me:
enum v4l2_focus_mode {
V4L2_FOCUS_MANUAL = 0,
V4L2_FOCUS_AUTO_NORMAL = 1,
V4L2_FOCUS_AUTO_MACRO = 2,
};
I think it could be more than that. Because some ISP devices support
much more presets like AF-S and AF-C.
I mean AF Static? or something for AF-S and AF continuous for AF-C...
At least this maps the current boolean values correctly. I'm not sure from
your decription what the fourth auto focus mode is supposed to be.
But I think it might be better to have a separate control that allows you to
set the auto-focus mode. I can imagine that different devices might have
different auto-focus modes.
You are right. But on the other hand, it seems to be not bad using API
in same way as EXPOSURE CID (V4L2_CID_EXPOSURE_AUTO) to avoid
confusion.
Cheers,
Nate
I've CC-ed Laurent since this is more his field than mine.
Regards,
Hans
Thanks,
Riverful
--
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
[PATCH]: gspca: use usb interface as parent
Hi all, As discussed in the: v4l parent for usb device interface or device? thread, here is a patch for gspca to make it use the usb interface as its parent device, instead of the usb device. Regards, Hans p.s. I'll also push a patch to my libv4l repo, with matching libv4l changes so that libv4l's upside down cam detections stays working with this change. Note: this libv4l patch also fixes libv4l upside down detection for the new device numbering style. diff -r c28651a2c2c3 linux/drivers/media/video/gspca/gspca.c --- a/linux/drivers/media/video/gspca/gspca.c Thu Mar 26 09:44:15 2009 +0100 +++ b/linux/drivers/media/video/gspca/gspca.c Fri Mar 27 10:32:24 2009 +0100 @@ -1958,7 +1958,7 @@ /* init video stuff */ memcpy(gspca_dev-vdev, gspca_template, sizeof gspca_template); - gspca_dev-vdev.parent = dev-dev; + gspca_dev-vdev.parent = intf-dev; gspca_dev-module = module; gspca_dev-present = 1; ret = video_register_device(gspca_dev-vdev,
Re: [PATCH 1/5] CSI camera interface driver for MX1
Mauro Carvalho Chehab wrote: Hi Darius, Please always base your patches against the last v4l-dvb tree or linux-next. This is specially important those days, where v4l core is suffering several changes. Hi, could you please advice which v4l-dvb Git repository I should pull from? Because git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/devel.git does not have any new stuff now. git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git is marked as unstable for testing purposes. What is better to base my patches on? Darius. -- 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: libv4l, yuv420 and gspca-stv06xx conversion
2009/3/25 Hans de Goede hdego...@redhat.com: On 03/23/2009 08:40 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Hans, I'm trying to get gstreamer and the yuv420 format conversion in libv4l to play nice with the gspca-stv06xx driver. Currently this is not working. The resolution of the vv6410 sensor is 356*292 pixels and the native format of the camera is V4L2_PIX_FMT_SGRBG8. This produces a total image size of 103952 bytes which gets page aligned to 106496. When requesting to conversion to yuv420 in gstreamer I launch gst-launch with the following parameters: gst-launch-0.10 -v v4l2src queue-size=4 ! ffmpegcolorspace ! xvimageink gstreamer then proceeds with complaining that it received a frame of size 155928 bytes but it expected a frame of size 156512 bytes. The delivered 155928 size seems sane as 155928 / 356 gives 438 and 155928 / 292 gives 534. Furthermore, the difference between the received size and the expected size is 584 bytes which is 2x the height. Anyhow, I hacked libv4l2.c and padded the frame with 584 in order to acheive the requested 156512 bytes. This worked and yielded the attached image. I'm currently at loss what's the root cause of this. Could the page align interfer somehow with the frame size? What's the correct image size? The converted image is clearly correct. I think that something in the gstreamer stack expect the U and V planes of the YUV planar data, to have each line start 32 bit word aligned. So they expect us to add 2 bytes of padding after each line of U and V data. That would give us 2 x (292 / 2) extra bytes for the U and for the V plane, so 2 x (2 x (292 / 2)) = 584 bytes of additional data, and would also explain the color banding in the image you've attached. Now the question is, is gstreamer right in assuming this padding? You're right in that gstreamer expects: outsize = GST_ROUND_UP_4 (*w) * GST_ROUND_UP_2 (*h); outsize += 2 * ((GST_ROUND_UP_8 (*w) / 2) * (GST_ROUND_UP_2 (*h) / 2)); I tried to hack around this by changing the 8 to a 4 which produces the same image as when I added the 584 offset. My take is that the alignment is also used somewhere else in the gstreamer stack. I'll try to post on their devel list and see if I can get any tips on how to resolve this problem. Best regards, Erik The v4l2 standard is pretty clear on this: http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/c2030.htm#V4L2-PIX-FORMAT And then the bytesperline description, clearly says the what gstreamer expects is wrong. But what is normal for other YUV420 planar data producing sources? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] [ADMIN] linuxtv.org is moving
On Fri, Mar 27, 2009 at 10:44:33AM +1000, Torgeir Veimo wrote: So how do I unsubscribe from linux-dvb? It seems that I still gets some mails from this list, but information on how to unsubscribe is lost from the website. Every mail from the list contains the link for the Mailman web interface. Johannes -- 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] CXUSB D680 DMB using unified lgs8gxx driver
On Tue, 17 Mar 2009 23:56:57 +0800 David Wong davidtlw...@gmail.com wrote: This patch replace the use of lgs8gl5 driver by unified lgs8gxx driver, for CXUSB D680 DMB (MagicPro ProHDTV) David T.L. Wong Patch is ok. However, as it depends on the previous one, I'll mark it as RFC. When you submit back the previous patch (plus the API patch), re-submit the other patches on this series. Also, since those patches are dependent, please number they at the subject, as: [PATCH 01/05] ... [PATCH 05/05] This allows us to be sure about the proper patch order to apply. 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] Remove stream pipe draining code for CXUSB D680 DMB
On Wed, 18 Mar 2009 00:00:10 +0800 David Wong davidtlw...@gmail.com wrote: CXUSB D680 DMB pipe draining code found to be problematic for new kernels (eg. kernel 2.6.27 @ Ubuntu 8.10) Could you please provide a clearer description? Why is it problematic? Also, please don't test against a distro-patched kernel, but against vanilla kernel. Since the patch will appear after 2.6.29, you should test using 2.6.29. 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] radio-mr800.c: Missing mutex include
On Wed, 18 Mar 2009 00:42:08 +0300 Alexey Klimov klimov.li...@gmail.com wrote: On Tue, 2009-03-17 at 22:00 +0100, Alessio Igor Bogani wrote: radio-mr800.c uses struct mutex, so while linux/mutex.h seems to be pulled in indirectly by one of the headers it already includes, the right thing is to include it directly. Hello, Alessio Patch looks okay for my eyes. If it useful it should be applied. Thank you! Mauro, if patch is okay please apply it. If you need my ack - here it is: Acked-by: Alexey Klimov klimov.li...@gmail.com If the mutex.h were already included by another kernel header, I don't see why to include it again. If a later patch remove the mutex.h from the header, then the patch author should take care of this change anyway. 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
VDR User wrote: On Thu, Mar 19, 2009 at 11:55 PM, Manu Abraham abraham.m...@gmail.com wrote: * At the peak, you will get the maximum quality * falling down the slope to the left and right you will get falling signal strengths * Still rolling down, you will get increasing ERROR's, with still UNCORRECTABLES being steady. * Still falling down at the thresholds where you are about to loose frontend LOCK, you will see UNCORRECTABLE's getting incremented. Couple this logic into a program, with a feedback to the ROTOR and you get an automated satellite positioner, with a good fine tuned position. This would make for a very very useful tool to have. I can't count the number of times I've seen people inquire about tools to help them aim their dish and this sounds like the perfect solution to that long standing problem. Especially if it returned the network id once it's achieve a lock so the user can see if he's pointed to the correct satellite. If you have a motor and you are able to automatically peak satellites, the only thing missing is a program to find all the signals automatically, including the ones which are turned on and off in a matter of minutes. Just google for *blindscan* (and maybe my name) to find a utility I wrote years ago and abandoned after failing to get the corresponding mt312-autosymbolrate kernel patch integrated. Next step, automatically upload found signals on some site, maybe including a frame from the received video stream and let users comment/moderate interesting ones on a sort of forum. :-) H, feeds... Best regards. -- Roberto Ragusamail at robertoragusa.it -- 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/5] CSI camera interface driver for MX1
On Fri, 27 Mar 2009 11:37:23 +0200 Darius Augulis augulis.dar...@gmail.com wrote: Mauro Carvalho Chehab wrote: Hi Darius, Please always base your patches against the last v4l-dvb tree or linux-next. This is specially important those days, where v4l core is suffering several changes. Hi, could you please advice which v4l-dvb Git repository I should pull from? Because git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/devel.git does not have any new stuff now. During the merge window, all patches that are ready for submission are moved to: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git is marked as unstable for testing purposes. What is better to base my patches on? Darius. 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] gspca: add missing .type field check in VIDIOC_G_PARM
On Thu, 19 Mar 2009 17:47:13 -0700 (PDT) Trent Piepho xy...@speakeasy.org wrote: On Thu, 19 Mar 2009, [UTF-8] Németh Márton wrote: The gspca webcam driver does not check the .type field of struct v4l2_streamparm. This field is an input parameter for the driver according to V4L2 API specification, revision 0.24 [1]. Add the missing check. I think this check could go in the v4l2 core too. It already does a similar check for QUERYBUF, QBUF, DQBUF, etc. If the driver doesn't provide a method for -vidioc_try_fmt_foo() then the v4l2 core will reject a call with .type == V4L2_BUF_TYPE_foo. It seems like it should be ok to do this for S_PARM and G_PARM too. I agree. Could you provide such 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] Support for Legend Silicon LGS8913/LGS8GL5/LGS8GXX China DMB-TH digital demodulator
On Tue, 17 Mar 2009 23:55:05 +0800
David Wong davidtlw...@gmail.com wrote:
+#undef USE_FAKE_SIGNAL_STRENGTH
Hmm... why do you need this upstream? Is the signal strength working? If so,
just remove this test code.
+
+static void lgs8gxx_auto_lock(struct lgs8gxx_state *priv);
I don't see why do you need to prototype this function.
+
+static int debug = 0;
Don't initialize static vars to zero. Kernel already does this, and static
initialization requires eats some space.
+static int lgs8gxx_set_fe(struct dvb_frontend *fe,
+ struct dvb_frontend_parameters *fe_params)
+{
+ struct lgs8gxx_state *priv = fe-demodulator_priv;
+
+ dprintk(%s\n, __func__);
+
+ /* set frequency */
+ if (fe-ops.tuner_ops.set_params) {
+ fe-ops.tuner_ops.set_params(fe, fe_params);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 0);
+ }
+
+ /* Hardcoded to use auto as much as possible */
+ fe_params-u.ofdm.code_rate_HP = FEC_AUTO;
+ fe_params-u.ofdm.guard_interval = GUARD_INTERVAL_AUTO;
+ fe_params-u.ofdm.transmission_mode = TRANSMISSION_MODE_AUTO;
Hmm... this is weird.
That's said, maybe you may need some DVBS2 API additions for DMB. You should
propose some API additions and provide a patch for it.
+ /* FEC. No exact match for DMB-TH, pick approx. value */
+ switch(t LGS_FEC_MASK) {
+ case LGS_FEC_0_4: /* FEC 0.4 */
+ translated_fec = FEC_1_2;
+ break;
+ case LGS_FEC_0_6: /* FEC 0.6 */
+ translated_fec = FEC_2_3;
+ break;
+ case LGS_FEC_0_8: /* FEC 0.8 */
+ translated_fec = FEC_5_6;
+ break;
+ default:
+ translated_fec = FEC_1_2;
+ }
Same here: if there's no exact match, we should first patch the core files to
improve the API, and then use the correct values.
+ fe_params-u.ofdm.code_rate_HP =
+ fe_params-u.ofdm.code_rate_LP = translated_fec;
The above seems weird. It would be better to do:
+ fe_params-u.ofdm.code_rate_HP = translated_fec;
+ fe_params-u.ofdm.code_rate_LP = translated_fec;
The gcc optimizer will produce the same code, but this way would be cleaner for
those who are reading the source code.
+static
+int lgs8gxx_get_tune_settings(struct dvb_frontend *fe,
+ struct dvb_frontend_tune_settings *fesettings)
+{
+ /* FIXME: copy from tda1004x.c */
It would be nice if you fix those FIXME's.
+ fesettings-min_delay_ms = 800;
+ /* Drift compensation makes no sense for DVB-T */
DVB-T???
+static int lgs8gxx_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+ struct lgs8gxx_state *priv = fe-demodulator_priv;
+ u8 t;
+ *snr = 0;
+
+ lgs8gxx_read_reg(priv, 0x95, t);
+ dprintk(AVG Noise=0x%02X\n, t);
+ *snr = 256 - t;
+ *snr = 8;
+ dprintk(snr=0x%x\n, *snr);
+
+ return 0;
+}
I dunno if you are following all those discussions about SNR. We're trying to
standardize the meaning for all those status reads (SNR, signal strength, etc.
Nothing were decided yet, but while we don't take a decision, the better is if
you provide some comments at the source code specifying what's the unit for
each of those status (dB? 0.1 dB steps? dB * 256 ?).
+static struct dvb_frontend_ops lgs8gxx_ops = {
+ .info = {
+ .name = Legend Silicon LGS8913/LGS8GXX DMB-TH,
+ .type = FE_OFDM,
+ .frequency_min = 47400,
+ .frequency_max = 85800,
+ .frequency_stepsize = 1,
+ .caps =
+ FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
+ FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
+ FE_CAN_QPSK |
+ FE_CAN_QAM_16 | FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
+ FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_GUARD_INTERVAL_AUTO
+ },
Also here we should reflect the proper DMB parameters, after the API additions.
---
Before submitting patches, please check they with checkpatch.pl ( see
http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches for the submission
procedures).
Please fix the CodingStyle errors detected by the tool:
ERROR: do not initialise statics to 0 or NULL
#91: FILE: linux/drivers/media/dvb/frontends/lgs8gxx.c:43:
+static int debug = 0;
WARNING: printk() should include KERN_ facility level
#145: FILE: linux/drivers/media/dvb/frontends/lgs8gxx.c:97:
+ printk(%s: reg=0x%02X, data=0x%02X\n, __func__, reg, b1[0]);
ERROR: do not use C99 // comments
#164: FILE: linux/drivers/media/dvb/frontends/lgs8gxx.c:116:
+ if_conf = 0x10; // AGC output on;
ERROR: spaces required around that ':' (ctx:VxV)
#167: FILE: linux/drivers/media/dvb/frontends/lgs8gxx.c:119:
+ ((config-ext_adc) ? 0x80:0x00) |
^
ERROR: spaces required around
Re: [RFC] Another OV7670 Soc-camera driver
On Tue, 24 Mar 2009 09:36:35 +0200 Darius augulis.dar...@gmail.com wrote: Hi All, seems everybody has their own OV7670 driver... I have one written from scratch too. It is written using Omnivision user manual, application note, and register reference settings. Omnivision provides settings arrays for every resolution (VGA, QVGA, QQVGA, CIF, QCIF). This driver has lot of harcoded magic numbers. Of course OV7670 has lot of undocumented mystery and strange bugs. Maybe my work could be useful merging all available OV7670 drivers into single one. This driver is tested with MXLADS v2.0 board. So there it is: Well, now, we have 3 drivers for the same device... We should really try to merge those three into one. AFAIK, Jonathan driver were also written using the Omnivision docs. 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 1/5] CSI camera interface driver for MX1
On Fri, 27 Mar 2009 11:37:23 +0200 Darius Augulis augulis.dar...@gmail.com wrote: Mauro Carvalho Chehab wrote: Hi Darius, Please always base your patches against the last v4l-dvb tree or linux-next. This is specially important those days, where v4l core is suffering several changes. Btw, you shouldn't be c/c a list that requires subscription. Every time I send something, I got such errors: From: linux-arm-kernel-boun...@lists.arm.linux.org.uk To: mche...@infradead.org Subject: Your message to Linux-arm-kernel awaits moderator approval Date: Fri, 27 Mar 2009 10:34:51 + Sender: linux-arm-kernel-boun...@lists.arm.linux.org.uk Your mail to 'Linux-arm-kernel' with the subject Re: [PATCH 1/5] CSI camera interface driver for MX1 Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.arm.linux.org.uk/mailman/confirm/linux-arm-kernel/f04eda1d528be13a0d486acf4663a17ca96b05bd 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] Support for Legend Silicon LGS8913/LGS8GL5/LGS8GXX China DMB-TH digital demodulator
On Fri, Mar 27, 2009 at 5:57 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
On Tue, 17 Mar 2009 23:55:05 +0800
David Wong davidtlw...@gmail.com wrote:
+#undef USE_FAKE_SIGNAL_STRENGTH
Hmm... why do you need this upstream? Is the signal strength working? If so,
just remove this test code.
I don't know if I should remove the that signal strength code.
LGS8913 codes already use a very slow loop get get signal strength.
It loops from 1 to 915 (for 915 guard intervals), set a register and then read.
Such loop is very slow, that's why I add a fake signal strength.
for LGS8GL5 and newer chips, it reads two register to roughly get the
AGC output value.
seems LGS8913 can use the new method too. Perhaps we can remove the
fake signal strength code.
+
+static void lgs8gxx_auto_lock(struct lgs8gxx_state *priv);
I don't see why do you need to prototype this function.
No problem, to be removed.
+
+static int debug = 0;
Don't initialize static vars to zero. Kernel already does this, and static
initialization requires eats some space.
No problem.
+static int lgs8gxx_set_fe(struct dvb_frontend *fe,
+ struct dvb_frontend_parameters *fe_params)
+{
+ struct lgs8gxx_state *priv = fe-demodulator_priv;
+
+ dprintk(%s\n, __func__);
+
+ /* set frequency */
+ if (fe-ops.tuner_ops.set_params) {
+ fe-ops.tuner_ops.set_params(fe, fe_params);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 0);
+ }
+
+ /* Hardcoded to use auto as much as possible */
+ fe_params-u.ofdm.code_rate_HP = FEC_AUTO;
+ fe_params-u.ofdm.guard_interval = GUARD_INTERVAL_AUTO;
+ fe_params-u.ofdm.transmission_mode = TRANSMISSION_MODE_AUTO;
Hmm... this is weird.
That's said, maybe you may need some DVBS2 API additions for DMB. You should
propose some API additions and provide a patch for it.
That's the code copied from another frontend when I start the work.
But currently I would like to make it AUTO only.
Yes, I think there is a need for DMB-TH API.
FYI, DMB-TH is union of two modes, single carrier and multi-carrier.
The multi carrier mode is very DVB-T 8MHz alike.
The single carrier mode, I guess, is ATSC like.
I am not very familiar with RF and DTV technology and there is no
single carrier mode broadcast in Hong Kong.
It is very welcome to open a new thread to discuss proposal for DMB-TH API
+ fe_params-u.ofdm.code_rate_HP = translated_fec;
+ fe_params-u.ofdm.code_rate_LP = translated_fec;
The gcc optimizer will produce the same code, but this way would be cleaner
for
those who are reading the source code.
OK.
+static
+int lgs8gxx_get_tune_settings(struct dvb_frontend *fe,
+ struct dvb_frontend_tune_settings *fesettings)
+{
+ /* FIXME: copy from tda1004x.c */
It would be nice if you fix those FIXME's.
+ fesettings-min_delay_ms = 800;
+ /* Drift compensation makes no sense for DVB-T */
DVB-T???
That's the code copy from tda1004x. What is that delay for?
+static int lgs8gxx_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+ struct lgs8gxx_state *priv = fe-demodulator_priv;
+ u8 t;
+ *snr = 0;
+
+ lgs8gxx_read_reg(priv, 0x95, t);
+ dprintk(AVG Noise=0x%02X\n, t);
+ *snr = 256 - t;
+ *snr = 8;
+ dprintk(snr=0x%x\n, *snr);
+
+ return 0;
+}
I dunno if you are following all those discussions about SNR. We're trying to
standardize the meaning for all those status reads (SNR, signal strength, etc.
Nothing were decided yet, but while we don't take a decision, the better is if
you provide some comments at the source code specifying what's the unit for
each of those status (dB? 0.1 dB steps? dB * 256 ?).
Yes, I read your SNR discussion.
The register read is called average noise magnitude, but I don't know the unit.
There is no description from vendor.
+static struct dvb_frontend_ops lgs8gxx_ops = {
+ .info = {
+ .name = Legend Silicon LGS8913/LGS8GXX DMB-TH,
+ .type = FE_OFDM,
+ .frequency_min = 47400,
+ .frequency_max = 85800,
+ .frequency_stepsize = 1,
+ .caps =
+ FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
+ FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
+ FE_CAN_QPSK |
+ FE_CAN_QAM_16 | FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
+ FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_GUARD_INTERVAL_AUTO
+ },
Also here we should reflect the proper DMB parameters, after the API
additions.
---
Before submitting patches, please check they with checkpatch.pl ( see
http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches for the submission
procedures).
Please fix the CodingStyle errors detected by the tool:
No problem.
Regards,
David
--
To unsubscribe from this list: send the line unsubscribe
Re: [PATCH] Remove stream pipe draining code for CXUSB D680 DMB
On Fri, Mar 27, 2009 at 6:07 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: On Wed, 18 Mar 2009 00:00:10 +0800 David Wong davidtlw...@gmail.com wrote: CXUSB D680 DMB pipe draining code found to be problematic for new kernels (eg. kernel 2.6.27 @ Ubuntu 8.10) Could you please provide a clearer description? Why is it problematic? Also, please don't test against a distro-patched kernel, but against vanilla kernel. Since the patch will appear after 2.6.29, you should test using 2.6.29. Cheers, Mauro With that pipe draining code, the USB controller response is weird, i2c doesn't work. But Timothy Lee said he need that to drain the pipe after hibernate. Seems some TS data remains in the pipe that troubles mplayer. Regards, David -- 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/5] CSI camera interface driver for MX1
Mauro Carvalho Chehab wrote: On Fri, 27 Mar 2009 11:37:23 +0200 Darius Augulis augulis.dar...@gmail.com wrote: Mauro Carvalho Chehab wrote: Hi Darius, Please always base your patches against the last v4l-dvb tree or linux-next. This is specially important those days, where v4l core is suffering several changes. Btw, you shouldn't be c/c a list that requires subscription. Every time I send something, I got such errors: I sent it to ARM Linux ML, because it has lot of ARM stuff and there are people who maintain ARM/MXC. You probably could remove some CC from your reply message? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add zero fill for VIDIOC_ENUM_FMT
On Wednesday 25 March 2009 07:59:30 Németh Márton wrote:
From: Márton Németh nm...@freemail.hu
When enumerating formats with VIDIOC_ENUM_FMT the uvcvideo driver does not
fill the reserved fields of the struct v4l2_fmtdesc with zeros as required
by V4L2 API revision 0.24 [1]. Add the missing initializations.
The patch was tested with v4l-test 0.10 [2] with CNF7129 webcam found on
EeePC 901.
References:
[1] V4L2 API specification, revision 0.24
http://v4l2spec.bytesex.org/spec/r8367.htm
[2] v4l-test: Test environment for Video For Linux Two API
http://v4l-test.sourceforge.net/
Signed-off-by: Márton Németh nm...@freemail.hu
Applied, thanks.
---
--- linux-2.6.29/drivers/media/video/uvc/uvc_v4l2.c.orig 2009-03-24
00:12:14.0 +0100 +++
linux-2.6.29/drivers/media/video/uvc/uvc_v4l2.c 2009-03-25
07:24:42.0 +0100 @@ -673,11 +673,19 @@ static long
uvc_v4l2_do_ioctl(struct fil
{
struct v4l2_fmtdesc *fmt = arg;
struct uvc_format *format;
+ __u32 index;
+ enum v4l2_buf_type type;
if (fmt-type != video-streaming-type ||
fmt-index = video-streaming-nformats)
return -EINVAL;
+ index = fmt-index;
+ type = fmt-type;
+ memset(fmt, 0, sizeof(*fmt));
+ fmt-index = index;
+ fmt-type = type;
+
format = video-streaming-format[fmt-index];
fmt-flags = 0;
if (format-flags UVC_FMT_FLAG_COMPRESSED)
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ADMIN] linuxtv.org is moving
On Fri, Mar 27, 2009 at 02:20:58AM +0200, Antti Palosaari wrote: [cr...@localhost v4l-dvb]$ hg push ssh://ant...@linuxtv.org/hg/~anttip/af9015 pushing to ssh://ant...@linuxtv.org/hg/~anttip/af9015 searching for changes remote: abort: No space left on device [cr...@localhost v4l-dvb]$ host linuxtv.org linuxtv.org has address 217.160.6.122 I removed 5-6 my old devel trees, still no space :o This issue should be resolved now, /tmp had insufficient space. BTW: it is faster and uses less disk space to use hg-menu to clone the v4l-dvb tree on the server (hg then uses hardlinks), and push your changes on top of it. ssh -t ant...@linuxtv.org hg-menu Johannes -- 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/5] CSI camera interface driver for MX1
Hi Guennadi,
+/*
+ * Videobuf operations
+ */
+static int imx_videobuf_setup(struct videobuf_queue *vq, unsigned int *count,
+ unsigned int *size)
+{
+ struct soc_camera_device *icd = vq-priv_data;
+
+ *size = icd-width * icd-height *
+ ((icd-current_fmt-depth + 7) 3);
+
+ if (0 == *count)
+ *count = 32;
Doesn't look like a good idea to me. You don't restrict picture sizes in
your try_fmt / set_fmt and here you default to 32 buffers...
I'm not sure about this one. Should I leave this unchanged?
+ struct imx_camera_dev *pcdev = ici-priv;
+ struct imx_buffer *buf = container_of(vb, struct imx_buffer, vb);
+ unsigned long flags;
+
+ dev_dbg(icd-dev, %s (vb=0x%p) 0x%08lx %d\n, __func__,
+ vb, vb-baddr, vb-bsize);
+ spin_lock_irqsave(pcdev-lock, flags);
You use an FIQ for SoF, and spin_lock_irqsave() to protect. Don't they
only disable IRQs and not FIQs? But it seems your FIQ cannot cause any
trouble, so, it should be fine. Do you really need an FIQ?
yes, FIQ is necessary. Because IRQ is to slow. When SoF is detected, DMA must
be activated immediately, but not to early.
Whe tried to use IRQ, and many starts of frames were missed.
May I remove these spin_lock_irqsave's?
+
+ list_add_tail(vb-queue, pcdev-capture);
+
+ vb-state = VIDEOBUF_ACTIVE;
+
+ if (!pcdev-active) {
+ pcdev-active = buf;
+
+ /* setup sg list for future DMA */
+ if (!imx_camera_setup_dma(pcdev)) {
+ unsigned int temp;
+ /* enable SOF irq */
+ temp = __raw_readl(pcdev-base + CSICR1) |
+ CSICR1_SOF_INTEN;
Hm, looks like an error in the datasheet:
SOF_INTEN Start Of Frame Interrupt--SOF interrupt status bit; set Read:
Bit 16 when interrupt occurs. 0 = No
interrupt
1 = SOF
interrupt occurred
Write:
0 = No
action
1 =
Clears bit
This is not a status bit, but a control SoF interrupt enable bit, right?
Yes, probably it's only 'small' error in datasheet :)
+static void imx_camera_dma_irq(int channel, void *data)
+{
+ struct imx_camera_dev *pcdev = data;
+ struct imx_buffer *buf;
+ unsigned long flags;
+ struct videobuf_buffer *vb;
+
+ spin_lock_irqsave(pcdev-lock, flags);
+
+ imx_dma_disable(channel);
+
+ if (unlikely(!pcdev-active)) {
+ dev_err(pcdev-dev, DMA End IRQ with no active buffer\n);
+ goto out;
+ }
+
+ vb = pcdev-active-vb;
+ buf = container_of(vb, struct imx_buffer, vb);
+ WARN_ON(buf-inwork || list_empty(vb-queue));
+ dev_dbg(pcdev-dev, %s (vb=0x%p) 0x%08lx %d\n, __func__,
+ vb, vb-baddr, vb-bsize);
+
+ imx_camera_wakeup(pcdev, vb, buf);
AFAIU, your flow looks as follows:
1. configure DMA, enable Start of Frame FIQ
2. SoF FIQ enable DMA, DMA IRQ, disable SoF FIQ
3. DMA done IRQ disable DMA, report completed buffer, goto 1
is it ok?
+static int imx_camera_set_bus_param(struct soc_camera_device *icd, __u32
pixfmt)
+{
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-dev.parent);
+ struct imx_camera_dev *pcdev = ici-priv;
+ unsigned long camera_flags, common_flags;
+ unsigned int csicr1;
+ int ret;
+
+ camera_flags = icd-ops-query_bus_param(icd);
+
+ common_flags = soc_camera_bus_param_compatible(camera_flags,
+ CSI_BUS_FLAGS);
+ if (!common_flags)
+ return -EINVAL;
+
+ if (!(common_flags SOCAM_DATAWIDTH_8)) {
I don't understand this. In your CSI_BUS_FLAGS you only support 8 bits. If
the camera doesn't support it, you get a 0 back in common_flags and return
-EINVAL above. So, this test seems redundant.
yes, this is uneeded. I removed this already.
+static struct soc_camera_host_ops imx_soc_camera_host_ops = {
+ .owner = THIS_MODULE,
+ .add= imx_camera_add_device,
+ .remove = imx_camera_remove_device,
+ .set_fmt= imx_camera_set_fmt,
+ .try_fmt= imx_camera_try_fmt,
+ .init_videobuf = imx_camera_init_videobuf,
+ .reqbufs= imx_camera_reqbufs,
+ .poll = imx_camera_poll,
+ .querycap = imx_camera_querycap,
+ .set_bus_param = imx_camera_set_bus_param,
You are not implementing this against a current v4l tree. Please, rebase
onto, e.g., linux-next. You will have to at least implement a
Re: [PATCH 1/5] CSI camera interface driver for MX1
On Fri, Mar 27, 2009 at 05:18:18PM +0200, Darius Augulis wrote: You use an FIQ for SoF, and spin_lock_irqsave() to protect. Don't they only disable IRQs and not FIQs? But it seems your FIQ cannot cause any trouble, so, it should be fine. Do you really need an FIQ? This is precisely the area where FIQs can't be used. You can't take spinlocks (even IRQ-safe spinlocks) from FIQs. Why? You'll deadlock. Consider: spin_lock_irqsave(lock, flags); ... FIQ happens FIQ:spin_lock_irqsave(lock, flags); === deadlock And there's nothing you can do about that. And no, converting this locking primitive to also disable FIQs means that then FIQs will be subject to the same latency as normal IRQs. In fact, in uniprocessor mode, you might as well completely forget the spinlock, because the lock part is a no-op, and the IRQ disable has no effect on FIQs. If you're going to be using FIQs in C code, you need to be _very_ _very_ careful about what you do. Calling normal kernel functions is generally not going to be safe in any way. -- 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
trouble with v4l-dvb compilation, compat.h: redefinition of 'usb_endpoint_type'
Hello, I went to /usr/src/linux and run git pull (so i get 2.6.29-git1), and make new kernel. Then i updated v4l-dvb repository(hg pull, hg update) and configured to compile, for example dsbr100 radio driver. I get such message: tux v4l-dvb # make make -C /w/new/v4l-dvb/v4l make[1]: Entering directory `/w/new/v4l-dvb/v4l' ./scripts/make_myconfig.pl make[1]: Leaving directory `/w/new/v4l-dvb/v4l' make[1]: Entering directory `/w/new/v4l-dvb/v4l' perl scripts/make_config_compat.pl /lib/modules/2.6.29/source ./.myconfig ./config-compat.h creating symbolic links... Kernel build directory is /lib/modules/2.6.29/build make -C /lib/modules/2.6.29/build SUBDIRS=/w/new/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-2.6' CC [M] /w/new/v4l-dvb/v4l/tuner-xc2028.o CC [M] /w/new/v4l-dvb/v4l/tuner-simple.o CC [M] /w/new/v4l-dvb/v4l/tuner-types.o CC [M] /w/new/v4l-dvb/v4l/mt20xx.o CC [M] /w/new/v4l-dvb/v4l/tda8290.o CC [M] /w/new/v4l-dvb/v4l/tea5767.o CC [M] /w/new/v4l-dvb/v4l/tea5761.o CC [M] /w/new/v4l-dvb/v4l/tda9887.o CC [M] /w/new/v4l-dvb/v4l/xc5000.o CC [M] /w/new/v4l-dvb/v4l/mc44s803.o CC [M] /w/new/v4l-dvb/v4l/v4l2-dev.o CC [M] /w/new/v4l-dvb/v4l/v4l2-ioctl.o CC [M] /w/new/v4l-dvb/v4l/v4l2-device.o CC [M] /w/new/v4l-dvb/v4l/v4l2-subdev.o LD [M] /w/new/v4l-dvb/v4l/videodev.o CC [M] /w/new/v4l-dvb/v4l/v4l2-int-device.o CC [M] /w/new/v4l-dvb/v4l/v4l2-common.o /w/new/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_i2c_new_subdev': /w/new/v4l-dvb/v4l/v4l2-common.c:834: warning: format not a string literal and no format arguments /w/new/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_i2c_new_probed_subdev': /w/new/v4l-dvb/v4l/v4l2-common.c:902: warning: format not a string literal and no format arguments CC [M] /w/new/v4l-dvb/v4l/v4l1-compat.o CC [M] /w/new/v4l-dvb/v4l/dsbr100.o In file included from /w/new/v4l-dvb/v4l/dsbr100.c:94: /w/new/v4l-dvb/v4l/compat.h:396: error: redefinition of 'usb_endpoint_type' include/linux/usb/ch9.h:377: error: previous definition of 'usb_endpoint_type' was here make[3]: *** [/w/new/v4l-dvb/v4l/dsbr100.o] Error 1 make[2]: *** [_module_/w/new/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6' make[1]: *** [default] Error 2 make[1]: Leaving directory `/w/new/v4l-dvb/v4l' make: *** [all] Error 2 tux v4l-dvb # Well, i have such messages for radio-si470x and radio-mr800 too. This drivers compile ok in kernel from kernel.org. As i understand this is compat.h trouble ? -- Best regards, Klimov Alexey -- 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/5] CSI camera interface driver for MX1
On Fri, 27 Mar 2009, Russell King - ARM Linux wrote: On Fri, Mar 27, 2009 at 05:18:18PM +0200, Darius Augulis wrote: You use an FIQ for SoF, and spin_lock_irqsave() to protect. Don't they only disable IRQs and not FIQs? But it seems your FIQ cannot cause any trouble, so, it should be fine. Do you really need an FIQ? This is precisely the area where FIQs can't be used. You can't take spinlocks (even IRQ-safe spinlocks) from FIQs. Why? You'll deadlock. Consider: spin_lock_irqsave(lock, flags); ... FIQ happens FIQ: spin_lock_irqsave(lock, flags); === deadlock And there's nothing you can do about that. And no, converting this locking primitive to also disable FIQs means that then FIQs will be subject to the same latency as normal IRQs. In fact, in uniprocessor mode, you might as well completely forget the spinlock, because the lock part is a no-op, and the IRQ disable has no effect on FIQs. If you're going to be using FIQs in C code, you need to be _very_ _very_ careful about what you do. Calling normal kernel functions is generally not going to be safe in any way. No, they are not calling C from FIQs and they are not protecting against FIQs with a spinlock_irq*, that was my misinterpretation, sorry. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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 review] gspca - mr97310a: return error instead of -1 in sd_mod_init
Hello, Jean-Francois
What do you think about such small cleanup ?
---
Patch reformats sd_mod_init in the way to make it return error code from
usb_register instead of -1.
Signed-off-by: Alexey Klimov klimov.li...@gmail.com
--
diff -r 56cf0f1772f7 linux/drivers/media/video/gspca/mr97310a.c
--- a/linux/drivers/media/video/gspca/mr97310a.cMon Mar 23 19:18:34
2009 -0300
+++ b/linux/drivers/media/video/gspca/mr97310a.cFri Mar 27 01:42:28
2009 +0300
@@ -347,8 +347,10 @@
/* -- module insert / remove -- */
static int __init sd_mod_init(void)
{
- if (usb_register(sd_driver) 0)
- return -1;
+ int ret;
+ ret = usb_register(sd_driver);
+ if (ret 0)
+ return ret;
PDEBUG(D_PROBE, registered);
return 0;
}
--
Best regards, Klimov Alexey
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2: fill reserved fields of VIDIOC_ENUMAUDIO also
On Wed, 25 Mar 2009 17:51:39 +0100 Németh Márton nm...@freemail.hu wrote: From: Márton Németh nm...@freemail.hu When enumerating audio inputs with VIDIOC_ENUMAUDIO the gspca_sunplus driver does not fill the reserved fields of the struct v4l2_audio with zeros as required by V4L2 API revision 0.24 [1]. Add the missing initializations to the V4L2 framework. The patch was tested with v4l-test 0.10 [2] with gspca_sunplus driver and with Trust 610 LCD pow...@m ZOOM webcam. It didn't apply against the development tree. Anyway, a recent patch removed the need of memset there. the memory fill with zero now happens at the same code we copy the structure values. 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 implementing V4L2_CAP_STREAMING for zr364xx driver
On Wed, 25 Mar 2009 20:25:10 -0300
Lamarque Vieira Souza lamar...@gmail.com wrote:
Hi,
I have implemented V4L2_CAP_STREAMING for the zr364xx driver (see the
attached file). Could you review the code for me? My
Creative PC-CAM 880 works, but I do not have any other webcam to test the
code. Besides the streaming implementation the patch also does:
. re-implement V4L2_CAP_READWRITE using videobuf.
. copy cam-udev-product to the card field of the v4l2_capability struct.
That gives more information to the users about the webcam.
. move the brightness setting code from before requesting a frame (in
read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is
executed only when the application request a change in brightness and not
before every frame read. Is there any reason to set the brightness before
every frame read?
. comment part of zr364xx_vidioc_try_fmt_vid_cap. Skype + libv4l do not work
if it is there and libv4's maintainer told me it is a driver bug, so I fix it.
This patch is needed for applications such as mplayer, Kopete+libv4l
and
Skype+libv4l can make use of the webcam that comes with zr364xx chip. The
patch is big, if you need it splitted into small patches I can do it.
Your patch didn't apply:
patching file drivers/media/video/zr364xx.c
Hunk #4 FAILED at 37.
Hunk #5 succeeded at 114 (offset 2 lines).
Hunk #7 succeeded at 474 (offset 2 lines).
Hunk #9 succeeded at 782 (offset 2 lines).
Hunk #11 succeeded at 848 (offset 2 lines).
Hunk #13 succeeded at 918 (offset 2 lines).
Hunk #15 succeeded at 1198 (offset 2 lines).
Hunk #17 succeeded at 1242 (offset 2 lines).
Hunk #19 succeeded at 1373 (offset 2 lines).
Hunk #21 succeeded at 1409 (offset 2 lines).
Hunk #23 succeeded at 1532 (offset 2 lines).
1 out of 24 hunks FAILED -- saving rejects to file
drivers/media/video/zr364xx.c.rej
Patch doesn't apply
Probably because you didn't generate it against the development tree. Could you
please re-generate it against:
http://linuxtv.org/hg/v4l-dvbg/v4l-dvb
The better is to clone it using:
hg clone http://linuxtv.org/hg/v4l-dvb
Also, please test it against checkpatch tool, since there are a few coding
style issues like:
}
else {
and
if (foo)
{
Violating Linux codingstyle. For more info, please read the README.patches file
at the tree.
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
Legal! outro brasileiro na lista! Bem vindo ao time.
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 1/5] CSI camera interface driver for MX1
On Fri, 27 Mar 2009 15:39:59 +0200 Darius Augulis augulis.dar...@gmail.com wrote: Mauro Carvalho Chehab wrote: On Fri, 27 Mar 2009 11:37:23 +0200 Darius Augulis augulis.dar...@gmail.com wrote: Mauro Carvalho Chehab wrote: Hi Darius, Please always base your patches against the last v4l-dvb tree or linux-next. This is specially important those days, where v4l core is suffering several changes. Btw, you shouldn't be c/c a list that requires subscription. Every time I send something, I got such errors: I sent it to ARM Linux ML, because it has lot of ARM stuff and there are people who maintain ARM/MXC. You probably could remove some CC from your reply message? If the subject is important to ARM people, the reply messages should be there as well. Otherwise you shouldn't c/c it since the beginning ;) Subscribers only list are not good for patches discussion, and aren't recommended by Linux practices. The issues become evident on such discussions where more than one subsystem is envolved. We've switched this year to linux-media@vger.kernel.org mainly due to that: the anti-spam filters at VGER are so efficient that we don't need to be subscribers-only anymore. I suggest that you try to argue with ARM list maintainer to do the same. At the mean time, please c/c only lists that don't require subscriptions, since people shouldn't be forced to subscribe just to reply an email, and it is not polite to send emails refusing their comments. 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: [RFC][PATCH 1/2] Sensor orientation reporting
On Sun, 15 Mar 2009 22:29:48 +
Adam Baker li...@baker-net.org.uk wrote:
Add support to the SQ-905 driver to pass back to user space the
sensor orientation information obtained from the camera during init.
Modifies gspca and the videodev2.h header to create the necessary
API.
Please provide also the V4L2 specs change to include those new controls.
Signed-off-by: Adam Baker li...@baker-net.org.uk
---
diff -r 1248509d8bed linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Sat Mar 14 08:44:42 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Sun Mar 15 22:25:34 2009 +
@@ -1147,6 +1147,7 @@ static int vidioc_enum_input(struct file
if (input-index != 0)
return -EINVAL;
input-type = V4L2_INPUT_TYPE_CAMERA;
+ input-status = gspca_dev-input_flags;
strncpy(input-name, gspca_dev-sd_desc-name,
sizeof input-name);
return 0;
diff -r 1248509d8bed linux/drivers/media/video/gspca/gspca.h
--- a/linux/drivers/media/video/gspca/gspca.h Sat Mar 14 08:44:42 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.h Sun Mar 15 22:25:34 2009 +
@@ -168,6 +168,7 @@ struct gspca_dev {
__u8 alt; /* USB alternate setting */
__u8 nbalt; /* number of USB alternate settings */
u8 bulk;/* image transfer by 0:isoc / 1:bulk */
+ u32 input_flags;/* value for ENUM_INPUT status flags */
};
int gspca_dev_probe(struct usb_interface *intf,
diff -r 1248509d8bed linux/drivers/media/video/gspca/sq905.c
--- a/linux/drivers/media/video/gspca/sq905.c Sat Mar 14 08:44:42 2009 +0100
+++ b/linux/drivers/media/video/gspca/sq905.c Sun Mar 15 22:25:34 2009 +
@@ -357,6 +357,12 @@ static int sd_init(struct gspca_dev *gsp
gspca_dev-cam.nmodes = ARRAY_SIZE(sq905_mode);
if (!(ident SQ905_HIRES_MASK))
gspca_dev-cam.nmodes--;
+
+ if (ident SQ905_ORIENTATION_MASK)
+ gspca_dev-input_flags = V4L2_IN_ST_VFLIP;
+ else
+ gspca_dev-input_flags = V4L2_IN_ST_VFLIP |
+ V4L2_IN_ST_HFLIP;
return 0;
}
diff -r 1248509d8bed linux/include/linux/videodev2.h
--- a/linux/include/linux/videodev2.h Sat Mar 14 08:44:42 2009 +0100
+++ b/linux/include/linux/videodev2.h Sun Mar 15 22:25:34 2009 +
@@ -736,6 +736,11 @@ struct v4l2_input {
#define V4L2_IN_ST_NO_SIGNAL 0x0002
#define V4L2_IN_ST_NO_COLOR0x0004
+/* field 'status' - sensor orientation */
+/* If sensor is mounted upside down set both bits */
+#define V4L2_IN_ST_HFLIP 0x0010 /* Output is flipped horizontally
*/
+#define V4L2_IN_ST_VFLIP 0x0020 /* Output is flipped vertically */
+
/* field 'status' - analog */
#define V4L2_IN_ST_NO_H_LOCK 0x0100 /* No horizontal sync lock */
#define V4L2_IN_ST_COLOR_KILL 0x0200 /* Color killer is active */
--
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
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: [question] about open/release and vidioc_g_input/vidioc_s_input functions
On Fri, Mar 27, 2009 at 7:50 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On Friday 27 March 2009 17:44:05 Alexey Klimov wrote:
Hello, Hans
On Tue, 2009-03-24 at 08:06 +0100, Hans Verkuil wrote:
On Tuesday 24 March 2009 00:14:07 Alexey Klimov wrote:
Hello, all
...
static int terratec_open(struct file *file)
{
return 0;
}
static int terratec_release(struct file *file)
{
return 0;
}
...
...
Such code used in many radio-drivers as i understand.
Is it good to place this empty and almost empty functions in:
(here i see two variants)
1) In header file that be in linux/drivers/media/radio/ directory.
Later, we can move some generic/or repeating code in this header.
2) In any v4l header. What header may contain this ?
?
For what ? Well, as i understand we can decrease amount of lines and
provide this simple generic functions. It's like
video_device_release_empty function behaviour. Maybe not only radio
drivers can use such vidioc_g_input and vidioc_s_input.
Is it worth ?
I don't think it is worth doing this for g/s_input. I think it is
useful to have them here: it makes it very clear that there is just a
single input and the overhead in both lines and actual bytes is
minimal.
But for the empty open and release functions you could easily handle
that in v4l2-dev.c: if you leave the open and release callbacks to
NULL, then v4l2_open and v4l2_release can just return 0. That would be
nice.
Regards,
Hans
May i ask help with this ?
Hans, should it be looks like:
diff -r 56cf0f1772f7 linux/drivers/media/radio/radio-terratec.c
--- a/linux/drivers/media/radio/radio-terratec.c Mon Mar 23 19:18:34
2009
-0300 +++ b/linux/drivers/media/radio/radio-terratec.cFri Mar 27
19:32:38 2009 +0300 @@ -333,20 +333,8 @@
return a-index ? -EINVAL : 0;
}
-static int terratec_open(struct file *file)
-{
- return 0;
-}
-
-static int terratec_release(struct file *file)
-{
- return 0;
-}
-
static const struct v4l2_file_operations terratec_fops = {
.owner = THIS_MODULE,
- .open = terratec_open,
- .release= terratec_release,
.ioctl = video_ioctl2,
};
diff -r 56cf0f1772f7 linux/drivers/media/video/v4l2-dev.c
--- a/linux/drivers/media/video/v4l2-dev.cMon Mar 23 19:18:34 2009 -0300
+++ b/linux/drivers/media/video/v4l2-dev.cFri Mar 27 19:32:38 2009 +0300
@@ -264,7 +264,10 @@
/* and increase the device refcount */
video_get(vdev);
mutex_unlock(videodev_lock);
- ret = vdev-fops-open(filp);
+ if (vdev-fops-open == NULL)
+ ret = 0;
+ else
+ ret = vdev-fops-open(filp);
/* decrease the refcount in case of an error */
if (ret)
video_put(vdev);
@@ -275,7 +278,12 @@
static int v4l2_release(struct inode *inode, struct file *filp)
{
struct video_device *vdev = video_devdata(filp);
- int ret = vdev-fops-release(filp);
+ int ret;
+
+ if (vdev-fops-release == NULL)
+ ret = 0;
+ else
+ ret = vdev-fops-release(filp);
/* decrease the refcount unconditionally since the release()
return value is ignored. */
?
Or in v4l2_open function i can check if vdev-fops-open == NULL before
video_get(vdev); (increasing the device refcount), and if it's NULL then
unlock_mutex and return 0 ?
And the same in v4l2_release - just return 0 in the begining of function
in case vdev-fops-release == NULL ?
What approach is better ?
This is simpler:
diff -r 2e0c6ff1bda3 linux/drivers/media/video/v4l2-dev.c
--- a/linux/drivers/media/video/v4l2-dev.c Mon Mar 23 19:01:18 2009
+0100
+++ b/linux/drivers/media/video/v4l2-dev.c Fri Mar 27 17:47:51 2009
+0100
@@ -250,7 +250,7 @@
static int v4l2_open(struct inode *inode, struct file *filp)
{
struct video_device *vdev;
- int ret;
+ int ret = 0;
/* Check if the video device is available */
mutex_lock(videodev_lock);
@@ -264,7 +264,9 @@
/* and increase the device refcount */
video_get(vdev);
mutex_unlock(videodev_lock);
- ret = vdev-fops-open(filp);
+ if (vdev-fops-open)
+ ret = vdev-fops-open(filp);
+
/* decrease the refcount in case of an error */
if (ret)
video_put(vdev);
@@ -275,7 +277,10 @@
static int v4l2_release(struct inode *inode, struct file *filp)
{
struct video_device *vdev = video_devdata(filp);
- int ret = vdev-fops-release(filp);
+ int ret = 0;
+
+ if (vdev-fops-release)
+ ret = vdev-fops-release(filp);
/* decrease the refcount unconditionally since the release()
return value is ignored. */
Looks like you already did right patch ;-)
I don't know what to do, should i repost
Re: Patch implementing V4L2_CAP_STREAMING for zr364xx driver
Here is the patch with the modifications you asked.
Em Friday 27 March 2009, Mauro Carvalho Chehab escreveu:
On Wed, 25 Mar 2009 20:25:10 -0300
Lamarque Vieira Souza lamar...@gmail.com wrote:
Hi,
I have implemented V4L2_CAP_STREAMING for the zr364xx driver (see
the attached file). Could you review the code for me? My
Creative PC-CAM 880 works, but I do not have any other webcam to test the
code. Besides the streaming implementation the patch also does:
. re-implement V4L2_CAP_READWRITE using videobuf.
. copy cam-udev-product to the card field of the v4l2_capability
struct. That gives more information to the users about the webcam.
. move the brightness setting code from before requesting a frame (in
read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is
executed only when the application request a change in brightness and not
before every frame read. Is there any reason to set the brightness before
every frame read?
. comment part of zr364xx_vidioc_try_fmt_vid_cap. Skype + libv4l do not
work if it is there and libv4's maintainer told me it is a driver bug, so
I fix it.
This patch is needed for applications such as mplayer, Kopete+libv4l and
Skype+libv4l can make use of the webcam that comes with zr364xx chip. The
patch is big, if you need it splitted into small patches I can do it.
Your patch didn't apply:
patching file drivers/media/video/zr364xx.c
Hunk #4 FAILED at 37.
Hunk #5 succeeded at 114 (offset 2 lines).
Hunk #7 succeeded at 474 (offset 2 lines).
Hunk #9 succeeded at 782 (offset 2 lines).
Hunk #11 succeeded at 848 (offset 2 lines).
Hunk #13 succeeded at 918 (offset 2 lines).
Hunk #15 succeeded at 1198 (offset 2 lines).
Hunk #17 succeeded at 1242 (offset 2 lines).
Hunk #19 succeeded at 1373 (offset 2 lines).
Hunk #21 succeeded at 1409 (offset 2 lines).
Hunk #23 succeeded at 1532 (offset 2 lines).
1 out of 24 hunks FAILED -- saving rejects to file
drivers/media/video/zr364xx.c.rej Patch doesn't apply
Probably because you didn't generate it against the development tree. Could
you please re-generate it against: http://linuxtv.org/hg/v4l-dvbg/v4l-dvb
The better is to clone it using:
hg clone http://linuxtv.org/hg/v4l-dvb
Also, please test it against checkpatch tool, since there are a few coding
style issues like:
}
else {
and
if (foo)
{
Violating Linux codingstyle. For more info, please read the README.patches
file at the tree.
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
Legal! outro brasileiro na lista! Bem vindo ao time.
Hehe, obrigado.
--
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
--- v4l-dvb/linux/drivers/media/video/zr364xx.c 2009-03-27 15:18:54.050413997 -0300
+++ v4l-dvb/linux-lvs/drivers/media/video/zr364xx.c 2009-03-27 15:22:47.914414277 -0300
@@ -1,5 +1,5 @@
/*
- * Zoran 364xx based USB webcam module version 0.72
+ * Zoran 364xx based USB webcam module version 0.73
*
* Allows you to use your USB webcam with V4L2 applications
* This is still in heavy developpement !
@@ -10,6 +10,8 @@
* Heavily inspired by usb-skeleton.c, vicam.c, cpia.c and spca50x.c drivers
* V4L2 version inspired by meye.c driver
*
+ * Some video buffer code by Lamarque based on s2255drv.c and vivi.c drivers.
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -25,7 +27,6 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-
#include linux/version.h
#include linux/module.h
#include linux/init.h
@@ -36,25 +37,34 @@
#include linux/highmem.h
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
+#include media/videobuf-vmalloc.h
#include compat.h
/* Version Information */
-#define DRIVER_VERSION v0.72
+#define DRIVER_VERSION v0.73
+#define ZR364_VERSION_CODE KERNEL_VERSION(0, 7, 3)
#define DRIVER_AUTHOR Antoine Jacquet, http://royale.zerezo.com/;
#define DRIVER_DESC Zoran 364xx
/* Camera */
-#define FRAMES 2
+#define FRAMES 1
#define MAX_FRAME_SIZE 10
#define BUFFER_SIZE 0x1000
#define CTRL_TIMEOUT 500
+#define ZR364XX_DEF_BUFS 4
+#define ZR364XX_READ_IDLE 0
+#define ZR364XX_READ_FRAME 1
/* Debug macro */
-#define DBG(x...) if (debug) printk(KERN_INFO KBUILD_MODNAME x)
-
+#define DBG(fmt, args...) \
+ do { \
+ if (debug) { \
+ printk(KERN_INFO KBUILD_MODNAME fmt, ##args); \
+ } \
+ } while (0)
/* Init methods, need to find nicer names for these
* the exact names of the chipsets would be the best if someone finds it */
@@ -103,24 +113,97 @@ static struct usb_device_id device_table
MODULE_DEVICE_TABLE(usb, device_table);
+struct zr364xx_mode {
+ u32 color; /* output
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ for: changeset: 11224:2258bd92f522 gspca - vc032x: Remove the JPEG tables of mi1320_soc. changeset: 11225:ea6d8f0cd083 gspca - m5602-s5k4aa: No more default mode changeset: 11226:630fa8f75f42 gspca - m5602-s5k4aa: Add start function and VGA resolution init. changeset: 11227:7b14d00aa61c gspca - m5602: Simplify error handling changeset: 11228:89647a4acf75 gspca - m5602-ov9650: Add QCIF resolution support changeset: 11229:7578294f06cd gspca - m5602-ov9650: Clean up ov9650_start() function. changeset: 11230:8863f4fdf25e gspca - m5602-s5k83a: Add led support to the s5k83a sensor. changeset: 11231:817e36da4fd9 gspca - m5602-ov9650: Set the ov9650 sensor in soft sleep when inactive. changeset: 11232:9d0a113a28a4 gspca - m5602-ov9650: Always init the ov9650 before starting a stream changeset: 11233:871b2546315d gspca - m5602: Rework v4l ctrl handling in all sensors changeset: 11234:04c1227d412f gspca - m5602-ov9650: Checkpatch fixes changeset: 11235:089b896afa94 gspca - m5602-mt9m111: Separate mode vectors per sensor. changeset: 11236:531f8383ff70 gspca - m5602-mt9m111: Move v4l2 controls to main sensor file. changeset: 11237:ea5335dfb00e gspca - m5602: Remove an unused member in the sd struct. changeset: 11238:f915d64a686e gspca - m5602: Constify all sensor structs changeset: 11239:be006d6783fb gspca - m5602-ov9650: Autogain is on by default changeset: 11240:ad9622150aea gspca - m5602-ov9650: Auto white balancing is on by default changeset: 11241:82263c1cbdee gspca - m5602-ov9650: Don't read exposure data from COM1. changeset: 11242:a640fe97ac35 gspca - m5602: Improve error handling in the ov9650 driver changeset: 11243:9d70484bfca5 gspca - m5602-ov9650: Synthesize modesetting. changeset: 11244:dc66997ccf36 gspca - m5602-ov9650: Replace a magic constant with a define changeset: 11245:ecbaf91c8745 gspca - m5602-ov9650: Add a disconnect hook, setup a ctrl cache ctrl. changeset: 11246:0310786ebedc gspca - m5602-ov9650: Use the local ctrl cache. Adjust image on vflip. changeset: 11247:1bebd29cecc3 gspca - m5602: Move the vflip quirk to probe stage. changeset: 11248:6b4f4f173a66 gspca - m5602: Don't touch hflip/vflip register on Read/Modify/Write changeset: 11249:7c1aa8d0507f gspca - m5602: Minor cleanups Cheers. -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote: On Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham abraham.m...@gmail.com wrote: Sure, of course. Here is an updated list based on the information that you accumulated. I have corrected some of them, which were not accurate. Before I comment any further on your email, could you please clarify what you mean by Relative, confirms to API. The current DVB API specification does not specify any units of measure for the content of the field, so I am not sure what you mean by this. Sorry about not responding earlier, wasn't feeling well at all and hence. By Relative, i meant dimensionless, but still it makes some sense based on some documented references. What i mean relative is that the API expects something like this. http://linuxtv.org/hg/dvb-apps/file/5fbdd3f898b1/util/szap/README Regards, Manu -- 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] Remove debug output from stb6100_cfg.h
Mauro Carvalho Chehab wrote: Manu, If ok to you, please ack. On Thu, 26 Mar 2009 10:45:53 +0100 Artem Makhutov ar...@makhutov.org wrote: This patch removes the debug output from stb6100_cfg.h as it is flooding the syslog with tuning data during normal operation. Signed-off-by: Artem Makhutov ar...@makhutov.org Looks okay, Acked-by: Manu Abraham abraham.m...@linuxtv.org --- linux.old/drivers/media/dvb/frontends/stb6100_cfg.h 2009-03-26 10:28:57.0 +0100 +++ linux/drivers/media/dvb/frontends/stb6100_cfg.h 2009-03-26 10:29:52.0 +0100 @@ -36,7 +36,6 @@ return err; } *frequency = t_state.frequency; - printk(%s: Frequency=%d\n, __func__, t_state.frequency); } return 0; } @@ -59,7 +58,6 @@ return err; } } - printk(%s: Frequency=%d\n, __func__, t_state.frequency); return 0; } @@ -81,7 +79,6 @@ } *bandwidth = t_state.bandwidth; } - printk(%s: Bandwidth=%d\n, __func__, t_state.bandwidth); return 0; } @@ -103,6 +100,5 @@ return err; } } - printk(%s: Bandwidth=%d\n, __func__, t_state.bandwidth); return 0; } -- 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]: gspca: use usb interface as parent
On Fri, 27 Mar 2009 10:35:43 +0100 Hans de Goede hdego...@redhat.com wrote: Hi all, Hi Hans, As discussed in the: v4l parent for usb device interface or device? thread, here is a patch for gspca to make it use the usb interface as its parent device, instead of the usb device. [snip] Applied, thanks. This patch may solve the microphone problem that some people have... Cheers. -- 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: [PATCH] v4l2: fill reserved fields of VIDIOC_ENUMAUDIO also
On Fri, 27 Mar 2009, Mauro Carvalho Chehab wrote: On Wed, 25 Mar 2009 17:51:39 +0100 N?meth M?rton nm...@freemail.hu wrote: From: M?rton N?meth nm...@freemail.hu When enumerating audio inputs with VIDIOC_ENUMAUDIO the gspca_sunplus driver does not fill the reserved fields of the struct v4l2_audio with zeros as required by V4L2 API revision 0.24 [1]. Add the missing initializations to the V4L2 framework. The patch was tested with v4l-test 0.10 [2] with gspca_sunplus driver and with Trust 610 LCD pow...@m ZOOM webcam. It didn't apply against the development tree. Anyway, a recent patch removed the need of memset there. the memory fill with zero now happens at the same code we copy the structure values. That code is in video_ioctl2, which gspca doesn't use. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH resend] DVB: firedtv: FireDTV S2 problems with tuning solved
This came in via linux1394-devel. If there are no objections, I'll include it in my pull request to Linus which I want to send in a few hours. It's also good to send to stable. Date: Thu, Mar 26, 2009 22:36:52 +0100 (CET) From: Beat Michel Liechti bml...@gmail.com Subject: DVB: firedtv: FireDTV S2 problems with tuning solved Signed-off-by: Beat Michel Liechti bml...@gmail.com Tuning was broken on FireDTV S2 (and presumably FloppyDTV S2) because a wrong opcode was sent. The box only gave not implemented responses. Changing the opcode to _TUNE_QPSK2 fixes this for good. Cc: sta...@kernel.org Signed-off-by: Stefan Richter stef...@s5r6.in-berlin.de --- drivers/media/dvb/firewire/firedtv-avc.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) Index: linux/drivers/media/dvb/firewire/firedtv-avc.c === --- linux.orig/drivers/media/dvb/firewire/firedtv-avc.c +++ linux/drivers/media/dvb/firewire/firedtv-avc.c @@ -135,6 +135,7 @@ static const char *debug_fcp_opcode(unsi case SFE_VENDOR_OPCODE_REGISTER_REMOTE_CONTROL: return RegisterRC; case SFE_VENDOR_OPCODE_LNB_CONTROL: return LNBControl; case SFE_VENDOR_OPCODE_TUNE_QPSK: return TuneQPSK; + case SFE_VENDOR_OPCODE_TUNE_QPSK2: return TuneQPSK2; case SFE_VENDOR_OPCODE_HOST2CA: return Host2CA; case SFE_VENDOR_OPCODE_CA2HOST: return CA2Host; } @@ -266,7 +267,10 @@ static void avc_tuner_tuneqpsk(struct fi c-operand[0] = SFE_VENDOR_DE_COMPANYID_0; c-operand[1] = SFE_VENDOR_DE_COMPANYID_1; c-operand[2] = SFE_VENDOR_DE_COMPANYID_2; - c-operand[3] = SFE_VENDOR_OPCODE_TUNE_QPSK; + if (fdtv-type == FIREDTV_DVB_S2) + c-operand[3] = SFE_VENDOR_OPCODE_TUNE_QPSK2; + else + c-operand[3] = SFE_VENDOR_OPCODE_TUNE_QPSK; c-operand[4] = (params-frequency 24) 0xff; c-operand[5] = (params-frequency 16) 0xff; -- Stefan Richter -=-==--= --== ==-== http://arcgraph.de/sr/ -- 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: v4l parent for usb device interface or device?
On Thu, Mar 26, 2009 at 06:31:55PM -0700, David Brownell wrote:
On Thursday 26 March 2009, Janne Grunau wrote:
I noticed a problem after
changing the hdpvr driver accordingly.
With parent set to the usb interface there is no longer easy access to
the usb device properties like the serial number through sysfs. I know
that a couple of user with more than one device use the serial number
to set static device nodes through udev.
The serial number is still available, but it's coupled to the USB
device not its interface. Make your udev script hop up a level or
two in the driver model tree, as appropriate.
yes, ATTRS{} still matches. There are udev howtos around which suggest
ATTRS{} just matches one level up and not the entire path. I tried it but
had unfortunately a typo in the udev rule. Sorry for the noise.
Janne
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2: fill reserved fields of VIDIOC_ENUMAUDIO also
On Fri, 27 Mar 2009, Hans Verkuil wrote: On Friday 27 March 2009 20:45:40 Trent Piepho wrote: On Fri, 27 Mar 2009, Mauro Carvalho Chehab wrote: On Wed, 25 Mar 2009 17:51:39 +0100 N?meth M?rton nm...@freemail.hu wrote: From: M?rton N?meth nm...@freemail.hu When enumerating audio inputs with VIDIOC_ENUMAUDIO the gspca_sunplus driver does not fill the reserved fields of the struct v4l2_audio with zeros as required by V4L2 API revision 0.24 [1]. Add the missing initializations to the V4L2 framework. The patch was tested with v4l-test 0.10 [2] with gspca_sunplus driver and with Trust 610 LCD pow...@m ZOOM webcam. It didn't apply against the development tree. Anyway, a recent patch removed the need of memset there. the memory fill with zero now happens at the same code we copy the structure values. That code is in video_ioctl2, which gspca doesn't use. Yes, gspca does use video_ioctl2. You're probably confused with uvcvideo, which doesn't use it. You're right, I was thinking about N?meth's earlier patches for the same things in uvcvideo. This patch wasn't for gspca anyway, it was for the v4l2 core, and Mauro's right it's not necessary as my patch series fixed all these problems. -- 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] TechnoTrend C-1501 - Locking issues on 388Mhz
Hi, Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab: On Fri, 27 Mar 2009 02:39:07 +0100 hermann pitton hermann-pit...@arcor.de wrote: But my main concern is, if it once arrived at patchwork formally, it is out of sight for most of us and might miss proper review, except you are sure you can always guarantee that. I don't want to start to argue about all what happened in the past. So, at least, if some patch arrived there mysteriously ;), the linux-media list should be informed that it is there now and last time to speak off, in case anything is not fully clear, before vanishing into some black hole until you find it in the next kernel release ... The only way to send patches to patchwork is to submit it via linux-media list. There's no other way. So, all patch discussions and reviews should happen at the ML, by replying at the patch email (or by replying another reply). Patchwork will keep track of such replies as well. What happened so far with this patches is quite funny, for me some black hole seems to be involved. Klaas did send them the first time, also directly to me, on Tue, 24 Mar 2009 23:14:11 +0100. Now I can see you have pulled them in already on Wednesday. http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88 There is no trace anymore on patchwork visible to me. http://patchwork.kernel.org/project/linux-media/list So I don't know how you processed them. Most confusing is, that Klaas obviously did not receive a mail notification from linuxtv-commits that his patch came in. Last message date: Fri Feb 15 19:45:02 CET 2008 Archived on: Fri Feb 15 19:45:04 CET 2008 Is it broken or only the archive not up to date? Why else he would have posted a second time on Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of his patches, which made me believe I should try to help him? The timestamp on your mercurial commit of them is Wed Mar 25 20:53:02 2009 + (2 days ago) That is the time when his second email arrived converted to Greenwich time? Or how could you commit within the same second that mail arrived? This is the time the patches have on both of his original mails. --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 + --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 + How can I ever know when they were really added and if they went through patchwork :) I was just about to suggest Klaas should try again with [PATCH] in the subject until they are listed at patchwork. 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://hg.jannau.net/hdpvr-merge/
Hi Mauro, please pull from http://hg.jannau.net/hdpvr-merge/ for hdpvr: add struct v4l2_device hdpvr: convert printing macros to v4l2_* with struct v4l2_device hdpvr: empty internal device buffer after stopping streaming hdpvr-control.c | 22 +++--- hdpvr-core.c| 65 + hdpvr-video.c | 87 +--- hdpvr.h |4 ++ 4 files changed, 114 insertions(+), 64 deletions(-) thanks, Janne -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] Sensor orientation reporting
On Friday 27 Mar 2009, Mauro Carvalho Chehab wrote: On Sun, 15 Mar 2009 22:29:48 + Adam Baker li...@baker-net.org.uk wrote: Add support to the SQ-905 driver to pass back to user space the sensor orientation information obtained from the camera during init. Modifies gspca and the videodev2.h header to create the necessary API. Please provide also the V4L2 specs change to include those new controls. I hadn't forgotten this, it was just taking rather longer than expected to put together a working build system for the documentation (In the end I concluded the quickest approach was a complete OS upgrade to get working versions of the docbook tools and config files). Adam -- 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: how about adding FOCUS mode?
Hi,
2009. 03. 28, 오전 1:19, Laurent Pinchart 작성:
Hi,
On Friday 27 March 2009 08:24:27 Hans Verkuil wrote:
On Friday 27 March 2009 07:20:51 Kim, Heung Jun wrote:
Hello, Hans everyone.
I'm trying to adapt the various FOCUS MODE int the NEC ISP driver.
NEC ISP supports 4 focus mode, AUTO/MACRO/MANUAL/FULL or NORMAL.
but, i think that it's a little insufficient to use V4L2 FOCUS
Feature.
so, suggest that,
- change V4L2_CID_FOCUS_AUTO's type from boolean to interger, and
add
the following enumerations for CID values.
enum v4l2_focus_mode {
V4L2_FOCUS_AUTO= 0,
V4L2_FOCUS_MACRO= 1,
V4L2_FOCUS_MANUAL= 2,
V4L2_FOCUS_NORMAL= 3,
V4L2_FOCUS_LASTP= 3,
};
how about this usage? i wanna get some advice about FOCUS MODE.
V4L2_CID_FOCUS_AUTO is meant to change the auto-focus mode. Can you
describe
FOCUS_MACRO and FOCUS_NORMAL in more details ? Are they auto-focus
modes or
just focus presets ?
As far as I know, they represent focus lens movement range.
If you set to AF macro, focus lens scans near range first, so that
focusing movement could finish earlier.
This seems more logical to me:
enum v4l2_focus_mode {
V4L2_FOCUS_MANUAL = 0,
V4L2_FOCUS_AUTO_NORMAL = 1,
V4L2_FOCUS_AUTO_MACRO = 2,
};
At least this maps the current boolean values correctly. I'm not
sure from
your decription what the fourth auto focus mode is supposed to be.
Does an auto-macro focus mode really exists ?
Sure, you can find in some digital camera or brand new high end camera
phones.
By the way, sorry for answering instead of heungjun Kim. I work with
him actually.
Is it OK?
Cheers,
Nate
But I think it might be better to have a separate control that
allows you
to set the auto-focus mode. I can imagine that different devices
might have
different auto-focus modes.
I've CC-ed Laurent since this is more his field than mine.
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-
media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] TechnoTrend C-1501 - Locking issues on 388Mhz
On Sat, 28 Mar 2009 00:23:55 +0100 hermann pitton hermann-pit...@arcor.de wrote: Hi, Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab: On Fri, 27 Mar 2009 02:39:07 +0100 hermann pitton hermann-pit...@arcor.de wrote: But my main concern is, if it once arrived at patchwork formally, it is out of sight for most of us and might miss proper review, except you are sure you can always guarantee that. I don't want to start to argue about all what happened in the past. So, at least, if some patch arrived there mysteriously ;), the linux-media list should be informed that it is there now and last time to speak off, in case anything is not fully clear, before vanishing into some black hole until you find it in the next kernel release ... The only way to send patches to patchwork is to submit it via linux-media list. There's no other way. So, all patch discussions and reviews should happen at the ML, by replying at the patch email (or by replying another reply). Patchwork will keep track of such replies as well. What happened so far with this patches is quite funny, for me some black hole seems to be involved. Klaas did send them the first time, also directly to me, on Tue, 24 Mar 2009 23:14:11 +0100. Now I can see you have pulled them in already on Wednesday. http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88 There is no trace anymore on patchwork visible to me. http://patchwork.kernel.org/project/linux-media/list So I don't know how you processed them. The above link uses the default patchwork filtering. By default it shows only patches where there's an action required (e. g. New or Under Review patches). To view a full list of the patches, you need to click at filters and select any. You'll see all patches: http://patchwork.kernel.org/project/linux-media/list/?state=* In the specific case od Klaas, this is his patch: http://patchwork.kernel.org/patch/14405/ Most confusing is, that Klaas obviously did not receive a mail notification from linuxtv-commits that his patch came in. Last message date: Fri Feb 15 19:45:02 CET 2008 Archived on: Fri Feb 15 19:45:04 CET 2008 Is it broken or only the archive not up to date? I've received the notification here: From: Patch from klaas de waal hg-com...@linuxtv.org To: linuxtv-comm...@linuxtv.org Cc: , Mauro Carvalho Chehab mche...@redhat.com, klaas de waal klaas.de.w...@gmail.com Subject: [linuxtv-commits] [hg:v4l-dvb] tda827x: fix locking issues with DVB-C Date: Fri, 27 Mar 2009 18:05:01 +0100 Reply-To: klaas de waal via Mercurial klaas.de.w...@gmail.com Sender: linuxtv-commits-boun...@linuxtv.org The patch number 11236 was added via Mauro Carvalho Chehab mche...@redhat.com to http://linuxtv.org/hg/v4l-dvb master development tree. Klaas should be received this also. Maybe some anti-spam filtering on his side? You'll probably see this also at the linuxtv-commits archives. Why else he would have posted a second time on Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of his patches, which made me believe I should try to help him? The timestamp on your mercurial commit of them is Wed Mar 25 20:53:02 2009 + (2 days ago) That is the time when his second email arrived converted to Greenwich time? Or how could you commit within the same second that mail arrived? This is the time the patches have on both of his original mails. --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 + --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 + The import scripts will try to preserve the original date of the sent email. So, the date there is when the code were presented to public. How can I ever know when they were really added and if they went through patchwork :) I was just about to suggest Klaas should try again with [PATCH] in the subject until they are listed at patchwork. If the patch was received by patchwork, and disappeared, all you need to do is to click on filter and select a proper filter, like: http://patchwork.kernel.org/project/linux-media/list/?submitter=klaasstate=* This will present all patches authored by klaas, and their state. Ah, if you click on the patch, you'll see all the patch history, including the sent/received emails. Even this email should be added there by patchwork ;) 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: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
Am Samstag, den 28.03.2009, 00:58 -0300 schrieb Mauro Carvalho Chehab: On Sat, 28 Mar 2009 00:23:55 +0100 hermann pitton hermann-pit...@arcor.de wrote: Hi, Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab: On Fri, 27 Mar 2009 02:39:07 +0100 hermann pitton hermann-pit...@arcor.de wrote: But my main concern is, if it once arrived at patchwork formally, it is out of sight for most of us and might miss proper review, except you are sure you can always guarantee that. I don't want to start to argue about all what happened in the past. So, at least, if some patch arrived there mysteriously ;), the linux-media list should be informed that it is there now and last time to speak off, in case anything is not fully clear, before vanishing into some black hole until you find it in the next kernel release ... The only way to send patches to patchwork is to submit it via linux-media list. There's no other way. So, all patch discussions and reviews should happen at the ML, by replying at the patch email (or by replying another reply). Patchwork will keep track of such replies as well. What happened so far with this patches is quite funny, for me some black hole seems to be involved. Klaas did send them the first time, also directly to me, on Tue, 24 Mar 2009 23:14:11 +0100. Now I can see you have pulled them in already on Wednesday. http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88 There is no trace anymore on patchwork visible to me. http://patchwork.kernel.org/project/linux-media/list So I don't know how you processed them. The above link uses the default patchwork filtering. By default it shows only patches where there's an action required (e. g. New or Under Review patches). To view a full list of the patches, you need to click at filters and select any. You'll see all patches: http://patchwork.kernel.org/project/linux-media/list/?state=* In the specific case od Klaas, this is his patch: http://patchwork.kernel.org/patch/14405/ Most confusing is, that Klaas obviously did not receive a mail notification from linuxtv-commits that his patch came in. Last message date: Fri Feb 15 19:45:02 CET 2008 Archived on: Fri Feb 15 19:45:04 CET 2008 Is it broken or only the archive not up to date? I've received the notification here: From: Patch from klaas de waal hg-com...@linuxtv.org To: linuxtv-comm...@linuxtv.org Cc: , Mauro Carvalho Chehab mche...@redhat.com, klaas de waal klaas.de.w...@gmail.com Subject: [linuxtv-commits] [hg:v4l-dvb] tda827x: fix locking issues with DVB-C Date: Fri, 27 Mar 2009 18:05:01 +0100 Reply-To: klaas de waal via Mercurial klaas.de.w...@gmail.com Sender: linuxtv-commits-boun...@linuxtv.org The patch number 11236 was added via Mauro Carvalho Chehab mche...@redhat.com to http://linuxtv.org/hg/v4l-dvb master development tree. Klaas should be received this also. Maybe some anti-spam filtering on his side? You'll probably see this also at the linuxtv-commits archives. Why else he would have posted a second time on Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of his patches, which made me believe I should try to help him? The timestamp on your mercurial commit of them is Wed Mar 25 20:53:02 2009 + (2 days ago) That is the time when his second email arrived converted to Greenwich time? Or how could you commit within the same second that mail arrived? This is the time the patches have on both of his original mails. --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 + --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 + The import scripts will try to preserve the original date of the sent email. So, the date there is when the code were presented to public. How can I ever know when they were really added and if they went through patchwork :) I was just about to suggest Klaas should try again with [PATCH] in the subject until they are listed at patchwork. If the patch was received by patchwork, and disappeared, all you need to do is to click on filter and select a proper filter, like: http://patchwork.kernel.org/project/linux-media/list/?submitter=klaasstate=* This will present all patches authored by klaas, and their state. Ah, if you click on the patch, you'll see all the patch history, including the sent/received emails. Even this email should be added there by patchwork ;) Cheers, Mauro Mauro, you are joking. How I ever could come to that from here? http://patchwork.kernel.org/project/linux-media/list I'm forced to read the source code. There seems to be some serious utf8 bug too. 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
