Re: omap3isp: BT.656 support
Am 20.10.2011 08:56, schrieb Boris Todorov: On Wed, Oct 19, 2011 at 7:26 PM, Stefan Herbrechtsmeier sherb...@cit-ec.uni-bielefeld.de wrote: Am 18.10.2011 15:33, schrieb Boris Todorov: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I had the same issue. Make sure that you disable the xclk when you remove your sensor driver. isp-platform_cb.set_xclk(isp, 0, ISP_XCLK_A) How exactly did you solved your problem? I don't see how XCLK in _remove will help. Pls explain. Sorry, I mean deactive / power off your sensor. Btw I'm feeding TVP with external clock (not from xtal pins) - omap.cam_xclk - tvp.clk_in I mean the cam_xclk. And I'm using kind of hack to get it: isp_probe() + isp_set_xclk(isp, 2700, 1); This is your problem. You should control the clock via board / platform callback from your driver. Example: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg56627.html It is important that you set the clock to zero when your driver is not in use. The problem is connected to the use count of the ISP and some initialisation which only happen when the counter change between zero and one. Regards, Stefan -- 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] subdevice PM: .s_power() deprecation?
Hi Guennadi, On Tuesday 18 October 2011 23:38:11 Guennadi Liakhovetski wrote: On Tue, 18 Oct 2011, Sylwester Nawrocki wrote: On 10/18/2011 01:07 AM, Laurent Pinchart wrote: On Monday 17 October 2011 23:26:28 Sylwester Nawrocki wrote: On 10/17/2011 05:23 PM, Guennadi Liakhovetski wrote: On Mon, 17 Oct 2011, Sylwester Nawrocki wrote: [snip] The bridge driver could also choose to keep the sensor powered on, whenever it sees appropriate, to avoid re-enabling the sensor to often. On what basis would the bridge driver make these decisions? How would it know in advance, when it'll have to re-enable the subdev next time? Re-enabling by allowing a subdev driver to entirely control the power state. The sensor might implement lowest power consumption policy, while the user might want highest performance. Exactly, that's a policy decision. Would PM QoS help here ? Thanks for reminding about PM QoS. I didn't pay much attention to it but it indeed appears to be a good fit for this sort of tasks. But you anyway have to decide - who will implement those PM QoS callbacks? The bridge and then decide whether or not to call subdev's .s_power(), or the subdev driver itself? I think, the latter, in which case .s_power() remain unused. With a proper PM QoS framework in place, the .s_power() operation might disappear. However we can't get rid of it today, as PM QoS isn't there yet. As I mentioned before, low-latency requires decoupling sensor power on and video stream startup. The OMAP3 ISP driver currently implements such a low- latency policy by calling .s_power(1) on the sensor when a video node belonging to the same pipeline as the sensor is opened. This is not an ideal solution, but removing .s_power() would prevent that without providing any other mean to achieve the same low-latency policy. We would possibly just need to think of parameters which could be associated with video, e.g. video_latency, etc. ?... I'm curious whether the whole power handling could be contained within a subdev driver, most likely it could be done for subdevs exposing a devnode. I'm referring only to camera sensor subdevs, as I don't have much experience with other ones. Also there are some devices where you want to model power control explicitly, and it is critical to overall system operation. The s5p-tv driver is one example of these. The host driver knows exactly how the power state of its subdevs should be handled. The host probably knows about how to handle the power state of its internal subdevs, but what about external ones ? In this particular example there is no external subdevs associated with the host. But we don't seem to have separate callbacks for internal and external subdevs.. So removing s_power() puts the above described sort of drivers in trouble. I understand what you're saying, but can you give us a specific example, when a subdev driver (your SoC internal subdev, that is) doesn't have a way to react to an event itself and only the bridge driver gets called into at that time? Something like an interrupt or an internal timer or some other internal event? See above :-) I guess we all agree the power requirements of external subdevs are generally unknown to the hosts. For these it might make lot of sense to let the subdev driver handle the device power supplies on basis of requests like, s_ctrl, s_stream, etc. Yes, right, so, most external (sensor, decoder,...) subdev drivers should never need to implement .s_power(), regardless of whether we decide to keep it or not. Well, ok, no, put it differently - in those drivers .s_power() should only really be called during system-wide suspend / resume. With a PM QoS framework, that's right. With PM QoS it could be easier to decide in the driver when a device should be put in a low power state. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Staging questions: WAS Re: [PATCH 0/7] Staging submission: PCTV 74e drivers and some cleanup
Thank you for the suggestions (both of you). I'll submit a pull request by this weekend (as I want to test it again in Ubuntu 11.10 just to make sure everything works). And for Mauro, is there a direct link to the scripts? I looked for them after the last time I emailed, but couldn't find them (or I wasn't looking in the right place). Have a great day:) Patrick. On 10/19/2011 10:44 PM, Mauro Carvalho Chehab wrote: Em 19-10-2011 11:57, Devin Heitmueller escreveu: Hi Patrick, On Wed, Oct 19, 2011 at 8:36 AM, Patrick Dickey pdickeyb...@gmail.com wrote: I'm posting this question under this thread because the subject pertains to the question (in that I'm asking about staging and about the PCTV 80e drivers). You should definitely be looking at the as102 thread that is currently going on this mailing list. Piotr is actually going through the same process as you are (he is working on upstreaming the as102 driver from a kernellabs.com tree). He made some pretty common mistakes (all perfectly understandable), and your reading the thread might help you avoid them (and having to redo your patch series). I started cleaning up the drx39xx* drivers for the PCTV-80e and have them in a github repository. Ultimately I want to send a pull request, so other people can finish the cleaning (as I'm not comfortable with pulling out the #ifdef statements myself). You should definitely ask Mauro how he expects to do a staging driver for a demodulator before you do any further work. The staging tree works well for bridge drivers, but demod drivers such as the drx require code in the bridge driver (the em28xx in this case), so it's not clear how you would do staging for a product where the bridge driver isn't in staging as well. The answer to that question will likely guide you in how to get the driver into staging. Ah yes, good point. Well, just submit it as if it should be added at the right place, but putting the Kconfig changes in separate. If this driver is not that different than the other drx drivers, I may try to find some time to fix it on the same way. You may also take a look at the history for the drx-k merging patches. I basically wrote a few small perl scripts to correct coding style, and a few manual work. If you have specific questions regarding anything you see in the driver, let me know. I don't have much time nowadays but will find the time if you ask concise questions. Good luck. It will be great to finally see this merged upstream. Devin -- 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: Staging questions: WAS Re: [PATCH 0/7] Staging submission: PCTV 74e drivers and some cleanup
Em 20-10-2011 08:53, Patrick Dickey escreveu:
Thank you for the suggestions (both of you). I'll submit a pull request
by this weekend (as I want to test it again in Ubuntu 11.10 just to make
sure everything works). And for Mauro, is there a direct link to the
scripts? I looked for them after the last time I emailed, but couldn't
find them (or I wasn't looking in the right place).
Yes, but it is not easy to navigate into it. They were added as comments
at the git history. You can easily get them by using this command:
$ git log drivers/media/dvb/frontends/drxk_hard.c
It basically shows all changes for drxk_hard. Several of the initial changesets
contain the scripts I used to produce the patches.
For example, at changeset ea90f011fdcc3d4fde78532eab8af09637176765 contains one:
http://git.linuxtv.org/media_tree.git/commitdiff/ea90f011fdcc3d4fde78532eab8af09637176765
That script removes the ugly CHK_ERROR macro that can hide things, as the macro
contains a flow control change inside, and silently touches the status var.
At the drx drivers I've cleaned up, they used to do something like:
#define CHK_ERROR(s) if ((status = s) 0) break
...
int status = 0;
do {
CHK_ERROR(Write16_0(state, SIO_CC_PWD_MODE__A,
SIO_CC_PWD_MODE_LEVEL_NONE));
...
} while (0);
And, inside CHK_ERROR, there was a break if error.
It is worthy to comment that checkpatch did a very well job pointing this
problem:
this only works well if there aren't any loop inside the do. However, I got
several
cases where the above weren't work as expected, as there was an extra loop
inside
the do/while.
So, after appling the above change, I had to manually write a patch replacing
the
do/while logic with a goto error approach:
http://git.linuxtv.org/media_tree.git/commitdiff/be44eb283b97c29b06a125cb5527b299d84315f4
So, the above were rewritten as:
int status = 0;
status = Write16_0(state, SIO_CC_PWD_MODE__A,
SIO_CC_PWD_MODE_LEVEL_NONE);
if (status 0)
goto error;
...
error:
return status;
The end result is cleaner, easier to review, and won't contain hidden troubles
due to assumption that all calls to CHK_ERROR macro would happen from a do/while
logic with no extra loop inside.
It should be noticed that I wrote the scripts specifically to replace the bad
things
I found at the drx-k driver. They are similar to the ones I wrote for drx-d,
but I
had to change some things, as the logic was not identical (and/or because I've
improved
the scripts I used for drx-d). In other words, you'll need to verify if they
apply for
your drx driver or not, and review the diff patch, to be sure that the patch
won't
break anything.
At the end, you'll need to re-test the driver, as you might have added some bad
things
at the conversion.
I hope that helps.
Have a great day:)
Patrick.
On 10/19/2011 10:44 PM, Mauro Carvalho Chehab wrote:
Em 19-10-2011 11:57, Devin Heitmueller escreveu:
Hi Patrick,
On Wed, Oct 19, 2011 at 8:36 AM, Patrick Dickey pdickeyb...@gmail.com
wrote:
I'm posting this question under this thread because the subject pertains
to the question (in that I'm asking about staging and about the PCTV 80e
drivers).
You should definitely be looking at the as102 thread that is
currently going on this mailing list. Piotr is actually going through
the same process as you are (he is working on upstreaming the as102
driver from a kernellabs.com tree). He made some pretty common
mistakes (all perfectly understandable), and your reading the thread
might help you avoid them (and having to redo your patch series).
I started cleaning up the drx39xx* drivers for the PCTV-80e and have
them in a github repository. Ultimately I want to send a pull request,
so other people can finish the cleaning (as I'm not comfortable with
pulling out the #ifdef statements myself).
You should definitely ask Mauro how he expects to do a staging driver
for a demodulator before you do any further work. The staging tree
works well for bridge drivers, but demod drivers such as the drx
require code in the bridge driver (the em28xx in this case), so it's
not clear how you would do staging for a product where the bridge
driver isn't in staging as well. The answer to that question will
likely guide you in how to get the driver into staging.
Ah yes, good point. Well, just submit it as if it should be added at
the right place, but putting the Kconfig changes in separate. If this
driver is not that different than the other drx drivers, I may try to
find some time to fix it on the same way.
You may also take a look at the history for the drx-k merging patches.
I basically wrote a few small perl scripts to correct coding style, and
a few manual work.
If you have specific questions regarding anything you see in the
driver, let me know. I don't have much time nowadays but will find
the
Re: omap3isp: BT.656 support
On Thu, Oct 20, 2011 at 12:03 PM, Stefan Herbrechtsmeier sherb...@cit-ec.uni-bielefeld.de wrote: Am 20.10.2011 08:56, schrieb Boris Todorov: On Wed, Oct 19, 2011 at 7:26 PM, Stefan Herbrechtsmeier sherb...@cit-ec.uni-bielefeld.de wrote: Am 18.10.2011 15:33, schrieb Boris Todorov: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I had the same issue. Make sure that you disable the xclk when you remove your sensor driver. isp-platform_cb.set_xclk(isp, 0, ISP_XCLK_A) How exactly did you solved your problem? I don't see how XCLK in _remove will help. Pls explain. Sorry, I mean deactive / power off your sensor. Btw I'm feeding TVP with external clock (not from xtal pins) - omap.cam_xclk - tvp.clk_in I mean the cam_xclk. And I'm using kind of hack to get it: isp_probe() + isp_set_xclk(isp, 2700, 1); This is your problem. You should control the clock via board / platform callback from your driver. Example: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg56627.html It is important that you set the clock to zero when your driver is not in use. The problem is connected to the use count of the ISP and some initialisation which only happen when the counter change between zero and one. tvp_probe() needs clock for i2c detected/config. tvp5150_s_power call happens when video starts streaming and if tvp is not configured - kernel panic. And what about the case when TVP is used with OSC on XTAL pins and CLK_IN is not used at all? Maybe I don't fully understand what is happening... or isp_set_xclk() use is messing up with ISP -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] media: vb2: set buffer length correctly for all buffer types
Hello,
On Friday, October 14, 2011 2:54 PM Marek Szyprowski wrote:
v4l2_planes[plane].length field was not initialized for userptr buffers.
This patch fixes this issue.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index d8affb8..5656fdf 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -58,7 +58,6 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
/* Associate allocator private data with this plane */
vb-planes[plane].mem_priv = mem_priv;
- vb-v4l2_planes[plane].length = q-plane_sizes[plane];
After some more testing I've found that removing this assignment causes
regression for drivers that use buf_init callback. I will resend this patch
without removal of the above line.
}
return 0;
@@ -121,6 +120,7 @@ static void __setup_offsets(struct vb2_queue *q)
continue;
for (plane = 0; plane vb-num_planes; ++plane) {
+ vb-v4l2_planes[plane].length = q-plane_sizes[plane];
vb-v4l2_planes[plane].m.mem_offset = off;
dprintk(3, Buffer %d, plane %d offset 0x%08lx\n,
--
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: BT.656 support
Am 20.10.2011 14:14, schrieb Boris Todorov: On Thu, Oct 20, 2011 at 12:03 PM, Stefan Herbrechtsmeier sherb...@cit-ec.uni-bielefeld.de wrote: Am 20.10.2011 08:56, schrieb Boris Todorov: On Wed, Oct 19, 2011 at 7:26 PM, Stefan Herbrechtsmeier sherb...@cit-ec.uni-bielefeld.de wrote: Am 18.10.2011 15:33, schrieb Boris Todorov: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I had the same issue. Make sure that you disable the xclk when you remove your sensor driver. isp-platform_cb.set_xclk(isp, 0, ISP_XCLK_A) How exactly did you solved your problem? I don't see how XCLK in _remove will help. Pls explain. Sorry, I mean deactive / power off your sensor. Btw I'm feeding TVP with external clock (not from xtal pins) - omap.cam_xclk - tvp.clk_in I mean the cam_xclk. And I'm using kind of hack to get it: isp_probe() + isp_set_xclk(isp, 2700, 1); This is your problem. You should control the clock via board / platform callback from your driver. Example: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg56627.html It is important that you set the clock to zero when your driver is not in use. The problem is connected to the use count of the ISP and some initialisation which only happen when the counter change between zero and one. tvp_probe() needs clock for i2c detected/config. tvp5150_s_power call happens when video starts streaming and if tvp is not configured - kernel panic. I use an other sensor and driver and this config the sensor during start stream. And what about the case when TVP is used with OSC on XTAL pins and CLK_IN is not used at all? Then your system will work, as you never call isp_set_xclk. The problem is not the clock, but how the isp driver works. It expects, that the sensor driver disable the cam_xclk, if the sensor is not used. Maybe I don't fully understand what is happening... or isp_set_xclk() use is messing up with ISP On my system I have the same issues as you if I don't set the cam_xclk to zero during stop streaming. I haven't investigate in the real cause for the issue. I only released, that this issue stick together with an always enabled cam_xclk. Regards, Stefan -- 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: [PULL] git://linuxtv.org/mkrufky/mxl111sf aero-m-dvbt
Mauro, I had to push an additional patch to this tree, disabling some calculations to avoid potential math errors and some build problems on other architectures... Here is an updated pull request: The following changes since commit a461e0ad3d27b6342140566909a80db30d151a91: Steven Toth (1): [media] cx23885: Stop the risc video fifo before reconfiguring it are available in the git repository at: git://linuxtv.org/mkrufky/mxl111sf aero-m-dvbt Michael Krufky (3): DVB: add MaxLinear MxL111SF DVB-T demodulator driver mxl111sf: add DVB-T support mxl111sf: disable snr / ber calculations for DVB-T drivers/media/dvb/dvb-usb/Makefile |1 + drivers/media/dvb/dvb-usb/mxl111sf-demod.c | 614 drivers/media/dvb/dvb-usb/mxl111sf-demod.h | 55 +++ drivers/media/dvb/dvb-usb/mxl111sf.c | 228 ++- drivers/media/dvb/dvb-usb/mxl111sf.h |2 +- 5 files changed, 896 insertions(+), 4 deletions(-) create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-demod.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-demod.h Cheers, Mike Krufky On Tue, Oct 18, 2011 at 2:51 PM, Michael Krufky mkru...@kernellabs.com wrote: Mauro, Please pull from the aero-m-dvbt branch of my mxl111sf git tree. This adds DVB-T support to the WinTV Aero-M, which already supports ATSC. Once this is merged, the WinTV Aero-M will be the first USB device known to be supported under Linux that supports both ATSC and DVB-T. (I will have mine with me in Prague next week) ... Please pull asap so that we can play with the device next week using the merged repository. The following changes since commit a461e0ad3d27b6342140566909a80db30d151a91: Steven Toth (1): [media] cx23885: Stop the risc video fifo before reconfiguring it are available in the git repository at: git://linuxtv.org/mkrufky/mxl111sf aero-m-dvbt Michael Krufky (2): DVB: add MaxLinear MxL111SF DVB-T demodulator driver mxl111sf: add DVB-T support drivers/media/dvb/dvb-usb/Makefile | 1 + drivers/media/dvb/dvb-usb/mxl111sf-demod.c | 604 drivers/media/dvb/dvb-usb/mxl111sf-demod.h | 55 +++ drivers/media/dvb/dvb-usb/mxl111sf.c | 228 +++- drivers/media/dvb/dvb-usb/mxl111sf.h | 2 +- 5 files changed, 886 insertions(+), 4 deletions(-) create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-demod.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-demod.h Best Regards, Michael Krufky -- 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] [media] hdpvr: update picture controls to support firmware versions 0.15
I've attached a patch that correctly sets the max/min/default values
for the hdpvr picture controls. The reason the current values didn't
cause a problem until now is because any firmware = 0.15 didn't
support them. The latest firmware releases properly support picture
controls and the values in the patch are derived from the windows
driver using SniffUSB2.0.
Thanks to Devin Heitmueller for helping me.
Regards.
--
Taylor
diff -r abd3aac6644e linux/drivers/media/video/hdpvr/hdpvr-core.c
--- a/linux/drivers/media/video/hdpvr/hdpvr-core.c Fri Jul 02 00:38:54 2010 -0300
+++ b/linux/drivers/media/video/hdpvr/hdpvr-core.c Thu Oct 20 11:14:25 2011 -0400
@@ -262,10 +262,10 @@
.bitrate_mode = HDPVR_CONSTANT,
.gop_mode = HDPVR_SIMPLE_IDR_GOP,
.audio_codec = V4L2_MPEG_AUDIO_ENCODING_AAC,
- .brightness = 0x86,
- .contrast = 0x80,
- .hue = 0x80,
- .saturation = 0x80,
+ .brightness = 0x80,
+ .contrast = 0x40,
+ .hue = 0xf,
+ .saturation = 0x40,
.sharpness = 0x80,
};
diff -r abd3aac6644e linux/drivers/media/video/hdpvr/hdpvr-video.c
--- a/linux/drivers/media/video/hdpvr/hdpvr-video.c Fri Jul 02 00:38:54 2010 -0300
+++ b/linux/drivers/media/video/hdpvr/hdpvr-video.c Thu Oct 20 11:14:25 2011 -0400
@@ -731,13 +731,13 @@
switch (qc-id) {
case V4L2_CID_BRIGHTNESS:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x86);
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
case V4L2_CID_CONTRAST:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x40);
case V4L2_CID_SATURATION:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x40);
case V4L2_CID_HUE:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ return v4l2_ctrl_query_fill(qc, 0x0, 0x1e, 1, 0xf);
case V4L2_CID_SHARPNESS:
return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
case V4L2_CID_MPEG_AUDIO_ENCODING:
Re: [PATCH] [media] hdpvr: update picture controls to support firmware versions 0.15
On Thu, Oct 20, 2011 at 11:24 AM, Taylor Ralph taylor.ra...@gmail.com wrote: I've attached a patch that correctly sets the max/min/default values for the hdpvr picture controls. The reason the current values didn't cause a problem until now is because any firmware = 0.15 didn't support them. The latest firmware releases properly support picture controls and the values in the patch are derived from the windows driver using SniffUSB2.0. Thanks to Devin Heitmueller for helping me. Regards. -- Taylor Hi Taylor, What worries me here is the assertion that the controls didn't work at all in previous firmware and driver versions. Did you downgrade the firmware and see that the controls had no effect when using v4l2-ctl? Janne, any comment on whether the controls *ever* worked? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] hdpvr: update picture controls to support firmware versions 0.15
On Thu, Oct 20, 2011 at 11:30 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Thu, Oct 20, 2011 at 11:24 AM, Taylor Ralph taylor.ra...@gmail.com wrote: I've attached a patch that correctly sets the max/min/default values for the hdpvr picture controls. The reason the current values didn't cause a problem until now is because any firmware = 0.15 didn't support them. The latest firmware releases properly support picture controls and the values in the patch are derived from the windows driver using SniffUSB2.0. Thanks to Devin Heitmueller for helping me. Regards. -- Taylor Hi Taylor, What worries me here is the assertion that the controls didn't work at all in previous firmware and driver versions. Did you downgrade the firmware and see that the controls had no effect when using v4l2-ctl? I have 2 HD-PVRs. I ran one with 0x17 and one with 0x15. Using v4l2-ctl to control the 0x15 unit produced zero changes. It has been reported by mythtv users in the past the picture control changes did not work for the HD-PVR. Regards. -- Taylor -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.2] Anysee
Mauro, The following changes since commit 446b792c6bd87de4565ba200b75a708b4c575a06: [media] media: DocBook: Fix trivial typo in Sub-device Interface (2011-09-27 09:14:58 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git anysee Antti Palosaari (7): tda18212: add DVB-T2 support anysee: add support for Anysee E7 T2C anysee: I2C gate control DNOD44CDH086A tuner module anysee: CI/CAM support anysee: fix fronted pointers due to merge conflict anysee: add control message debugs anysee: fix style issues drivers/media/common/tuners/tda18212.c | 49 +++- drivers/media/common/tuners/tda18212.h |4 + drivers/media/dvb/dvb-usb/Kconfig |1 + drivers/media/dvb/dvb-usb/anysee.c | 418 +++- drivers/media/dvb/dvb-usb/anysee.h |6 + 5 files changed, 404 insertions(+), 74 deletions(-) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] hdpvr: update picture controls to support firmware versions 0.15
On Thu, Oct 20, 2011 at 11:30:11AM -0400, Devin Heitmueller wrote: On Thu, Oct 20, 2011 at 11:24 AM, Taylor Ralph taylor.ra...@gmail.com wrote: I've attached a patch that correctly sets the max/min/default values for the hdpvr picture controls. The reason the current values didn't cause a problem until now is because any firmware = 0.15 didn't support them. The latest firmware releases properly support picture controls and the values in the patch are derived from the windows driver using SniffUSB2.0. Thanks to Devin Heitmueller for helping me. What worries me here is the assertion that the controls didn't work at all in previous firmware and driver versions. Did you downgrade the firmware and see that the controls had no effect when using v4l2-ctl? Janne, any comment on whether the controls *ever* worked? I've looked at them only at very beginning and if I recall correctly they had no visible effects. The values in the linux driver were taken from sniffing the windows driver. I remember that I've verified the default brightness value since 0x86 looked odd. I'm not sure that I verified all controls. I might have assumed all controls shared the same value range. There were previous reports of the picture controls not working at all. 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] [media] hdpvr: update picture controls to support firmware versions 0.15
On Thu, Oct 20, 2011 at 12:23 PM, Janne Grunau ja...@jannau.net wrote: On Thu, Oct 20, 2011 at 11:30:11AM -0400, Devin Heitmueller wrote: On Thu, Oct 20, 2011 at 11:24 AM, Taylor Ralph taylor.ra...@gmail.com wrote: I've attached a patch that correctly sets the max/min/default values for the hdpvr picture controls. The reason the current values didn't cause a problem until now is because any firmware = 0.15 didn't support them. The latest firmware releases properly support picture controls and the values in the patch are derived from the windows driver using SniffUSB2.0. Thanks to Devin Heitmueller for helping me. What worries me here is the assertion that the controls didn't work at all in previous firmware and driver versions. Did you downgrade the firmware and see that the controls had no effect when using v4l2-ctl? Janne, any comment on whether the controls *ever* worked? I've looked at them only at very beginning and if I recall correctly they had no visible effects. The values in the linux driver were taken from sniffing the windows driver. I remember that I've verified the default brightness value since 0x86 looked odd. I'm not sure that I verified all controls. I might have assumed all controls shared the same value range. There were previous reports of the picture controls not working at all. Hi Janne, Thanks for taking the time to chime in. If the controls really were broken all along under Linux, then that's good to know. That said, I'm not confident the changes Taylor proposed should really be run against older firmwares. There probably needs to be a check to have the values in question only applied if firmware = 16. If the controls were broken entirely, then we should probably not advertise them in ENUM_CTRL and S_CTRL should return -EINVAL if running the old firmware (perhaps put a warning in the dmesg output saying the controls are unavailable because the user is not running firmware = 16). My immediate concern is about ensuring we don't cause breakage in older firmware. For example, we don't know if there are some older firmware revisions that *did* work with the driver. The controls might have worked up to firmware revision 10, then been broken from 11-15, then work again in 16 (with the new hue value needed). The safe approach is to only use these new settings if they're running firmware = 16. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] hdpvr: update picture controls to support firmware versions 0.15
On Thu, Oct 20, 2011 at 12:35:40PM -0400, Devin Heitmueller wrote: On Thu, Oct 20, 2011 at 12:23 PM, Janne Grunau ja...@jannau.net wrote: I've looked at them only at very beginning and if I recall correctly they had no visible effects. The values in the linux driver were taken from sniffing the windows driver. I remember that I've verified the default brightness value since 0x86 looked odd. I'm not sure that I verified all controls. I might have assumed all controls shared the same value range. There were previous reports of the picture controls not working at all. Thanks for taking the time to chime in. no problem, sorry for ignoring the other mails, I had no time to look at the problem immediately and then forgot about it. If the controls really were broken all along under Linux, then that's good to know. That said, I'm not confident the changes Taylor proposed should really be run against older firmwares. There probably needs to be a check to have the values in question only applied if firmware = 16. If the controls were broken entirely, then we should probably not advertise them in ENUM_CTRL and S_CTRL should return -EINVAL if running the old firmware (perhaps put a warning in the dmesg output saying the controls are unavailable because the user is not running firmware = 16). My immediate concern is about ensuring we don't cause breakage in older firmware. For example, we don't know if there are some older firmware revisions that *did* work with the driver. The controls might have worked up to firmware revision 10, then been broken from 11-15, then work again in 16 (with the new hue value needed). The safe approach is to only use these new settings if they're running firmware = 16. I think such scenario is unlikely but I don't know it for sure and I don't want to force anyone to test every firmware version. Ignoring them for firmware version 16 should be safe since we assume they had no effect. Returning -EINVAL might break API-ignoring applications written with the HD PVR in mind but I think it's a better approach than silently ignoring those controls. 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: OMAP3 ISP ghosting
On Thu, Oct 13, 2011 at 2:52 PM, Gary Thomas g...@mlbassoc.com wrote: On 2011-10-13 06:32, Enrico wrote: Looking at the single images (top and bottom) i don't see ghosting artifacts (not only in that image but in a sequence of 16 frames), just a little blurry in moving parts but that's expected in an interlaced video. So it seems to me that the images arrive correctly at the isp and the deinterlacing causes ghosting. Is there any way to prove this by doing the de-interlacing in software? I just tested software deinterlacing (with gstreamer) and i can confirm it works very well, it removes ghosting completely. It will cause other problems that have a big performance impact (colorspace conversions, doubled framerates...) but that's another story, and i don't know if this is the appropriate place to talk about them. So i don't think it's the tvp51xx to blame or the isp, you will have to deinterlace with any analog decoder (unless it has integrated deinterlacing). Enrico -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Oct 20 19:00:17 CEST 2011 git hash:35a912455ff5640dc410e91279b03e04045265b2 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] hdpvr: update picture controls to support firmware versions 0.15
On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau j...@jannau.net wrote: I think such scenario is unlikely but I don't know it for sure and I don't want to force anyone to test every firmware version. Ignoring them for firmware version 16 should be safe since we assume they had no effect. Returning -EINVAL might break API-ignoring applications written with the HD PVR in mind but I think it's a better approach than silently ignoring those controls. At this point, let's just make it so that the old behavior is unchanged for old firmwares, meaning from both an API standpoint as well as what the values are. At some point if somebody cares enough to go back and fix the support so that the controls actually work with old firmwares, they can take that up as a separate task. In reality, it is likely that nobody will ever do that, as the easy answer is just to upgrade to firmware 16. Taylor, could you please tweak your patch to that effect and resubmit? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pac7311
* Németh Márton nm...@freemail.hu [11-10-18 22:14]: Hi Lars, Lars Noschinski wrote: I'm using a webcam (Philipps SPC500NC) which identifies itself as 093a:2603 Pixart Imaging, Inc. PAC7312 Camera and is sort-of supported by the gspca_pac7311 module. sort-of because the image alternates quickly between having a red tint or a green tint (using the gspac driver from kernel 3.0.0, but this problem is present since at least 2.6.31). The most important source code for your webcam is drivers/media/video/gspca/pac7311.c . You can see it online at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/media/video/gspca/pac7311.c . If I remove and re-plugin the camera a few times (on average around 3 times), the colors are stable. When you plug and remove the webcam and the colors are wrong, do you get any message in the dmesg? I get the same messages; sometimes the order of the messages output by uhci_hcd ehci_hcd differs, but this seems to be unrelated to working/not working. Once the colors are stable and you unplug and replug the webcam, what happens then? Is there again around 3 times when the webcam is not working properly? I now did a longer series of unplugreplug: Over the time, status stable colors seemed to get more probable. After a while, it only falls back to alternating colors, when I unplug it for a longer time (say 10 seconds). Might be a hardware problem? Then a second issue becomes apparent: There is almost no saturation in the image. Toying around with Contrast, Gamma, Exposure or Gain does not help. What _does_ help is the Vflip switch: If I enable it, the image is flipped vertically (as expected), but also the color become a lot better. Is there any difference when you use the Mirror control? What about the combination of the Vflip and Mirror controls? Vflip and (Vflip and Mirror) change color; Mirror alone does not. What about the Auto Gain setting? Is it enabled or disabled in your case? Auto Gain is enabled; but colors also change if it is disabled Is there something I can do to debug/fix this problem? You can try testing the webcam with different resolutions. The webcam supports 160x120, 320x240 and 640x480 resolutions based on the source code. You can try the different resolutions for example with cheese ( http://projects.gnome.org/cheese/ ) or any of your favorite V4L2 program. This does not seem to make a difference; except that 160x120 is listed, but does not seem to be available. guvcview tells me: Checking video mode 640x480@32bpp : OK setting new resolution (320 x 240) checking format: 859981650 Checking video mode 320x240@32bpp : OK setting new resolution (160 x 120) checking format: 859981650 Checking video mode 160x120@32bpp : OK ioctl (-1067952623) retried 4 times - giving up: Die Ressource ist zur Zeit nicht verfügbar) VIDIOC_DQBUF - Unable to dequeue buffer : Die Ressource ist zur Zeit nicht verfügbar Error grabbing image (the last message is then repeated, till i change the resolution) [Also, since I switched to 160x120, cheese crashes with a segfault, without giving me the possibility to switch back and I cannot find the config file.] You can load the usbmon kernel module and use Wireshark to log the USB communication between your computer and the webcam starting with plug-in. You can compare the communication when the webcam starts to work correctly with the one when the webcam doesn't work as expected. I'll try to do this later this week. Greetings, Lars Noschinski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] hdpvr: update picture controls to support firmware versions 0.15
On Thu, Oct 20, 2011 at 2:14 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau j...@jannau.net wrote: I think such scenario is unlikely but I don't know it for sure and I don't want to force anyone to test every firmware version. Ignoring them for firmware version 16 should be safe since we assume they had no effect. Returning -EINVAL might break API-ignoring applications written with the HD PVR in mind but I think it's a better approach than silently ignoring those controls. At this point, let's just make it so that the old behavior is unchanged for old firmwares, meaning from both an API standpoint as well as what the values are. At some point if somebody cares enough to go back and fix the support so that the controls actually work with old firmwares, they can take that up as a separate task. In reality, it is likely that nobody will ever do that, as the easy answer is just to upgrade to firmware 16. Taylor, could you please tweak your patch to that effect and resubmit? Sure, I'll try to get to it tonight and have it tested. Regards. -- Taylor -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] [media] av7110: wrong limiter in av7110_start_feed()
On Tuesday 18 October 2011 08:12:09 Dan Carpenter wrote:
Smatch complains that the wrong limiter is used here:
drivers/media/dvb/ttpci/av7110.c +906 dvb_feed_start_pid(12)
error: buffer overflow 'npids' 5 = 19
Here is the problem code:
905 i = dvbdmxfeed-pes_type;
906 npids[i] = (pid[i]0x8000) ? 0 : pid[i];
npids is a 5 element array declared on the stack. If
dvbdmxfeed-pes_type is more than 4 we probably put a (u16)0 past
the end of the array.
If dvbdmxfeed-pes_type is over 4 the rest of the function doesn't
do anything. dvbdmxfeed-pes_type is capped at less than
DMX_TS_PES_OTHER (20) in the caller function, but I changed it to
less than or equal to DMX_TS_PES_PCR (4).
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/dvb/ttpci/av7110.c
b/drivers/media/dvb/ttpci/av7110.c
index 3d20719..abf6b55 100644
--- a/drivers/media/dvb/ttpci/av7110.c
+++ b/drivers/media/dvb/ttpci/av7110.c
@@ -991,7 +991,7 @@ static int av7110_start_feed(struct dvb_demux_feed *feed)
if (feed-type == DMX_TYPE_TS) {
if ((feed-ts_type TS_DECODER)
- (feed-pes_type DMX_TS_PES_OTHER)) {
+ (feed-pes_type = DMX_TS_PES_PCR)) {
switch (demux-dmx.frontend-source) {
case DMX_MEMORY_FE:
if (feed-ts_type TS_DECODER)
--
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
Acked-by: Oliver Endriss o.endr...@gmx.de
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] hdpvr: update picture controls to support firmware versions 0.15
On Thu, Oct 20, 2011 at 3:26 PM, Taylor Ralph taylor.ra...@gmail.com wrote:
On Thu, Oct 20, 2011 at 2:14 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau j...@jannau.net wrote:
I think such scenario is unlikely but I don't know it for sure and
I don't want to force anyone to test every firmware version.
Ignoring them for firmware version 16 should be safe since we assume
they had no effect. Returning -EINVAL might break API-ignoring
applications written with the HD PVR in mind but I think it's a better
approach than silently ignoring those controls.
At this point, let's just make it so that the old behavior is
unchanged for old firmwares, meaning from both an API standpoint as
well as what the values are. At some point if somebody cares enough
to go back and fix the support so that the controls actually work with
old firmwares, they can take that up as a separate task. In reality,
it is likely that nobody will ever do that, as the easy answer is
just to upgrade to firmware 16.
Taylor, could you please tweak your patch to that effect and resubmit?
Sure, I'll try to get to it tonight and have it tested.
OK, I've updated the patch per your requests. I made this patch
against the latest kernel source but I'm unable to test since my
2.6.32 kernel has symbol issues with the new v4l code.
Regards.
--
Taylor
diff --git a/drivers/media/video/hdpvr/hdpvr-core.c b/drivers/media/video/hdpvr/hdpvr-core.c
index 441dacf..687282d 100644
--- a/drivers/media/video/hdpvr/hdpvr-core.c
+++ b/drivers/media/video/hdpvr/hdpvr-core.c
@@ -154,10 +154,20 @@ static int device_authorization(struct hdpvr_device *dev)
}
#endif
+ dev-fw_ver = dev-usbc_buf[1];
+
v4l2_info(dev-v4l2_dev, firmware version 0x%x dated %s\n,
- dev-usbc_buf[1], dev-usbc_buf[2]);
+ dev-fw_ver, dev-usbc_buf[2]);
+
+ if (dev-fw_ver 0x15) {
+ dev-options.brightness = 0x80;
+ dev-options.contrast = 0x40;
+ dev-options.hue = 0xf;
+ dev-options.saturation = 0x40;
+ dev-options.sharpness = 0x80;
+ }
- switch (dev-usbc_buf[1]) {
+ switch (dev-fw_ver) {
case HDPVR_FIRMWARE_VERSION:
dev-flags = ~HDPVR_FLAG_AC3_CAP;
break;
@@ -169,7 +179,7 @@ static int device_authorization(struct hdpvr_device *dev)
default:
v4l2_info(dev-v4l2_dev, untested firmware, the driver might
not work.\n);
- if (dev-usbc_buf[1] = HDPVR_FIRMWARE_VERSION_AC3)
+ if (dev-fw_ver = HDPVR_FIRMWARE_VERSION_AC3)
dev-flags |= HDPVR_FLAG_AC3_CAP;
else
dev-flags = ~HDPVR_FLAG_AC3_CAP;
@@ -270,6 +280,8 @@ static const struct hdpvr_options hdpvr_default_options = {
.bitrate_mode = HDPVR_CONSTANT,
.gop_mode = HDPVR_SIMPLE_IDR_GOP,
.audio_codec = V4L2_MPEG_AUDIO_ENCODING_AAC,
+ /* original picture controls for firmware version = 0x15 */
+ /* updated in device_authorization() for newer firmware */
.brightness = 0x86,
.contrast = 0x80,
.hue = 0x80,
diff --git a/drivers/media/video/hdpvr/hdpvr-video.c b/drivers/media/video/hdpvr/hdpvr-video.c
index 087f7c0..36bb057 100644
--- a/drivers/media/video/hdpvr/hdpvr-video.c
+++ b/drivers/media/video/hdpvr/hdpvr-video.c
@@ -722,21 +722,39 @@ static const s32 supported_v4l2_ctrls[] = {
};
static int fill_queryctrl(struct hdpvr_options *opt, struct v4l2_queryctrl *qc,
- int ac3)
+ int ac3, int fw_ver)
{
int err;
+ if (fw_ver 0x15) {
+ switch (qc-id) {
+ case V4L2_CID_BRIGHTNESS:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ case V4L2_CID_CONTRAST:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x40);
+ case V4L2_CID_SATURATION:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x40);
+ case V4L2_CID_HUE:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0x1e, 1, 0xf);
+ case V4L2_CID_SHARPNESS:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ }
+ } else {
+ switch (qc-id) {
+ case V4L2_CID_BRIGHTNESS:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x86);
+ case V4L2_CID_CONTRAST:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ case V4L2_CID_SATURATION:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ case V4L2_CID_HUE:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ case V4L2_CID_SHARPNESS:
+ return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
+ }
+ }
+
switch (qc-id) {
- case V4L2_CID_BRIGHTNESS:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x86);
- case V4L2_CID_CONTRAST:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
- case V4L2_CID_SATURATION:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
- case V4L2_CID_HUE:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
- case V4L2_CID_SHARPNESS:
- return v4l2_ctrl_query_fill(qc, 0x0, 0xff, 1, 0x80);
case V4L2_CID_MPEG_AUDIO_ENCODING:
return v4l2_ctrl_query_fill(
qc, V4L2_MPEG_AUDIO_ENCODING_AAC,
@@ -794,7 +812,8 @@ static int vidioc_queryctrl(struct file *file, void *private_data,
if (qc-id == supported_v4l2_ctrls[i])
return
Re: pac7311
Lars Noschinski wrote: * Németh Márton nm...@freemail.hu [11-10-18 22:14]: Hi Lars, Lars Noschinski wrote: I'm using a webcam (Philipps SPC500NC) which identifies itself as 093a:2603 Pixart Imaging, Inc. PAC7312 Camera and is sort-of supported by the gspca_pac7311 module. sort-of because the image alternates quickly between having a red tint or a green tint (using the gspac driver from kernel 3.0.0, but this problem is present since at least 2.6.31). The most important source code for your webcam is drivers/media/video/gspca/pac7311.c . You can see it online at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/media/video/gspca/pac7311.c . If I remove and re-plugin the camera a few times (on average around 3 times), the colors are stable. When you plug and remove the webcam and the colors are wrong, do you get any message in the dmesg? I get the same messages; sometimes the order of the messages output by uhci_hcd ehci_hcd differs, but this seems to be unrelated to working/not working. Once the colors are stable and you unplug and replug the webcam, what happens then? Is there again around 3 times when the webcam is not working properly? I now did a longer series of unplugreplug: Over the time, status stable colors seemed to get more probable. After a while, it only falls back to alternating colors, when I unplug it for a longer time (say 10 seconds). Might be a hardware problem? You might want to try the same webcam on different USB port to exclude the connector problem on the computer. I don't know if you have the possibility to try the webcam on a completly different computer also. Then a second issue becomes apparent: There is almost no saturation in the image. Toying around with Contrast, Gamma, Exposure or Gain does not help. What _does_ help is the Vflip switch: If I enable it, the image is flipped vertically (as expected), but also the color become a lot better. Is there any difference when you use the Mirror control? What about the combination of the Vflip and Mirror controls? Vflip and (Vflip and Mirror) change color; Mirror alone does not. What about the Auto Gain setting? Is it enabled or disabled in your case? Auto Gain is enabled; but colors also change if it is disabled Is there something I can do to debug/fix this problem? You can try testing the webcam with different resolutions. The webcam supports 160x120, 320x240 and 640x480 resolutions based on the source code. You can try the different resolutions for example with cheese ( http://projects.gnome.org/cheese/ ) or any of your favorite V4L2 program. This does not seem to make a difference; except that 160x120 is listed, but does not seem to be available. guvcview tells me: Checking video mode 640x480@32bpp : OK setting new resolution (320 x 240) checking format: 859981650 Checking video mode 320x240@32bpp : OK setting new resolution (160 x 120) checking format: 859981650 Checking video mode 160x120@32bpp : OK ioctl (-1067952623) retried 4 times - giving up: Die Ressource ist zur Zeit nicht verfügbar) VIDIOC_DQBUF - Unable to dequeue buffer : Die Ressource ist zur Zeit nicht verfügbar Error grabbing image (the last message is then repeated, till i change the resolution) [Also, since I switched to 160x120, cheese crashes with a segfault, without giving me the possibility to switch back and I cannot find the config file.] You can try running cheese using the command line strace -f cheese to see what was the last system call before the crash. If you have the debug symbols installed for cheese then you can also try running gdb cheese. Once you get the (gdb) prompt enter the command run. Switch to 160x120 resolution. When cheese crashes you should get (gdb) prompt again. Execute bt (backtrace) and send the result. You can load the usbmon kernel module and use Wireshark to log the USB communication between your computer and the webcam starting with plug-in. You can compare the communication when the webcam starts to work correctly with the one when the webcam doesn't work as expected. I'll try to do this later this week. Greetings, Lars Noschinski -- 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
