Re: [PATCH] newport: newport_*wait() return 0 on timeout
roel kluin wrote: 2009/2/2 Mauro Carvalho Chehab mche...@infradead.org: Hi Roel, It seems that you've sent this driver to the wrong ML. Video adapters are not handled on those ML's. Any idea where it should be sent? drivers/video/* generally go to here AFAIK: FRAMEBUFFER LAYER P: Antonino Daplas M: adap...@gmail.com L: linux-fbdev-de...@lists.sourceforge.net (moderated for non-subscribers) W: http://linux-fbdev.sourceforge.net/ S: Maintained ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~anttip/mc44s803/
Hello Mauro, Please pull from http://linuxtv.org/hg/~anttip/mc44s803/ for the following: Add Freescale MC44S803 tuner driver af9015: add MC44S803 support Jochen, could you also test with your device that nothing has gone broken. regards Antti -- 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
[PATCH] support for channel numbers in scan with Finnish DVB-C Welho
Hi,
Attached is small patch to enable channel numbering for FI DVB-C Welho
(similar to UK Freeview). Works for me though resulting list needs to be
sorted before using or else VDR gets channel numbers wrong.
--
Anssi Kolehmainen
anssi.kolehmai...@iki.fi
040-5085390
diff -r 98d3c06e5ef9 util/scan/scan.c
--- a/util/scan/scan.c Tue Jan 27 12:39:11 2009 +0100
+++ b/util/scan/scan.c Mon Feb 02 20:52:30 2009 +0200
@@ -363,6 +363,16 @@
}
buf += 4;
}
+}
+
+static void parse_cable_fi_channel_number (const unsigned char *buf, struct service *s)
+{
+ //We should have four bytes of data
+ if (buf[1] != 0x04)
+ return;
+
+ s-channel_num = buf[3];
+ verbosedebug(Channel number is %d\n, s-channel_num);
}
@@ -685,6 +695,13 @@
* problems when 0x83 is something entirely different... */
if (t == NIT vdr_dump_channum)
parse_terrestrial_uk_channel_number (buf, data);
+ break;
+
+ case 0x91:
+ /* 0x91 is also in private range so parse only when we want
+ * channel numbers */
+ if (t == SDT vdr_dump_channum)
+parse_cable_fi_channel_number (buf, data);
break;
default:
@@ -2103,7 +2120,7 @@
Vdr version 1.3.x and up implies -p.\n
-l lnb-type (DVB-S Only) (use -l help to print types) or \n
-l low[,high[,switch]] in Mhz\n
- -u UK DVB-T Freeview channel numbering for VDR\n\n
+ -u UK DVB-T Freeview / FI DVB-C Welho channel numbering for VDR\n\n
-P do not use ATSC PSIP tables for scanning\n
(but only PAT and PMT) (applies for ATSC only)\n
-A N check for ATSC 1=Terrestrial [default], 2=Cable or 3=both\n
Re: TinyTwin (af9015) - tuner 0 not working
Lindsay Mathieson wrote: I've had a DigitalNow TinyTwin dual usb tuner working on my mythbox for a week now (latest v4l-dvb trunk). A odd problem with the tuner has surfaced. Today Tuner 0 stopped getting a lock on any channel. Signal strength is 95%+, Bit Errors are Zero. However Tuner 1 is locking on and displaying channels just fine. Tuner 0 used to work fine. I've rebooted, but the problem hasn't gone away. Any suggestions? Have you tried replug stick? Hopefully it does not have burned. Could you test whether this driver works: http://linuxtv.org/hg/~anttip/af9015-mxl500x/ It uses different tuner driver. regards Antti -- 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
[PATCH]Add green balance v4l2 ctrl support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The m5602 gspca driver has two sensors offering the possiblity to control the green balance. This patch adds a v4l2 ctrl for this. Regards, Erik Signed-off-by: Erik Andrén erik.and...@gmail.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmHRhEACgkQN7qBt+4UG0FAKACgsnXERjLdZL/D+2Ze3KkC6GJc PowAnAkr/0+IT2jB00qCUuqS7OhBmhtG =UfNN -END PGP SIGNATURE- diff -r 24361cfb8615 linux/include/linux/videodev2.h --- a/linux/include/linux/videodev2.h Wed Jan 28 16:55:17 2009 +0100 +++ b/linux/include/linux/videodev2.h Wed Jan 28 17:11:39 2009 +0100 @@ -879,8 +879,10 @@ #define V4L2_CID_BACKLIGHT_COMPENSATION (V4L2_CID_BASE+28) #define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29) #define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30) + +#define V4L2_CID_GREEN_BALANCE (V4L2_CID_BASE+31) /* last CID + 1 */ -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+31) +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+32) /* MPEG-class control IDs defined by V4L2 */ #define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
Re: PXA Quick capture interface with HV7131RP-Camera
struct pxacamera_platform_data gumstix_pxacamera_platform_data = {
.init = gumstix_pxacamera_init,
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN | PXA_CAMERA_PCP,
.mclk_10khz = 1000,
};
^^ some register values are overwritten by my driver, so the more
interesting part are the register values of the quick capture
interface.
Here are the register values taken at the end of the capture:
CICR0: 93FF
- DMAEN = 1
- ENB = 1
- All interrupts masked
CICR1: 13F8012
- DW = 2 (8 Bit)
- COLOR_SP = 2 (YCbCr)
- PPL = 639
CICR2: 0
CICR3: 1DF
- LPF = 479
CICR4: D80005
- DIV = 5
- MCLK_EN = 1
- VSP = 1
- PCP = 1
- PCLK_EN = 1
CISR: 0
^^ No interrupt flag is set
CITOR: 0
CIFR: 0 (even by enabling the fifos with 7 it doesn't work)
So according to the registers it should work. I even checked if the
PCLK, FV and LV signals arrive at the CPU by reading the according
pins as GPIOs.
2009/2/1 Guennadi Liakhovetski g.liakhovet...@gmx.de:
On Sat, 31 Jan 2009, Bennet Fischer wrote:
Hi
I am trying to get a camera to work together with an PXA270 processor.
My system has the following specs:
Platform: Gumstix Verdex Pro
Camera: HV7131RP
OS: Linux 2.6.28
I wrote a simple driver for the camera which omits all the i2c-stuff
because the camera starts already in a default configuration which
works fine for me.
A V4L2-device is generated and everything looks fine. But when i start
to capture, no data arrives BUT the Quick Capture Interface outputs a
MCLK and the camera responds with a PCLK, LV and FV (and data of
couse).
For getting a bit closer to the origin of the problem I disabled DMA
in pxa_camera.c and enabled all Interrupts in the CICR0 register. No
interrupt is generated. Even by disabling DMA and IRQ and looking into
CISR nothing happens.
I checked all the CIF registers bitwise. The polarity of the LV and FV
is correct, the alternate pin functions are correct, the interrupt bit
is non-masked, the size of the pixel matrix is correct. I'm a bit
desperate because at the moment I have no idea what to do next. I
would be thankful for any hint.
Maybe you could post your platform data, i.e., your struct
pxacamera_platform_data?
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
Bug in gspca USB webcam driver
On Mon, 2 Feb 2009 kilg...@banach.math.auburn.edu wrote: The attached file is an extract from dmesg from the Pentium4 Dual Core machine. One can see that the camera has been attached, and then an svv session has been run. The kernel is the stock Slackware 2.6.27.7 kernel (*). We have a situation, again, in which svv (**) can not be exited. We have an oops in the log, and we have a filesystem check on reboot, which is going on as I write this. Well, the problem is clear enough, and it is in the gspca.c module, not your sq905-3 driver. I'm not sure what the best way is to fix it, so I'm CC'ing the people responsible for the gspca driver. To summarize: Unplugging the camera while it is in use by a program causes an oops (particularly on an SMP machine). The problem is that gspca_stream_off() calls destroy_urbs(), which in turn calls usb_buffer_free() -- but this happens too late, after gspca_disconnect() has returned. By that time gspca_dev-dev is a stale pointer, so it shouldn't be passed to usb_buffer_free(). What should happen is that as part of disconnect processing, the existing stream(s) should be put in an error state and destroy_urbs() should be called immediately. Then when gspca_stream_off() calls destroy_urbs() again there would be no more work left to do. Alan Stern -- 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: Bug in gspca USB webcam driver
On Monday 02 February 2009, Alan Stern wrote: On Mon, 2 Feb 2009 kilg...@banach.math.auburn.edu wrote: The attached file is an extract from dmesg from the Pentium4 Dual Core machine. One can see that the camera has been attached, and then an svv session has been run. The kernel is the stock Slackware 2.6.27.7 kernel (*). We have a situation, again, in which svv (**) can not be exited. We have an oops in the log, and we have a filesystem check on reboot, which is going on as I write this. Well, the problem is clear enough, and it is in the gspca.c module, not your sq905-3 driver. I'm not sure what the best way is to fix it, so I'm CC'ing the people responsible for the gspca driver. Thanks for confirming that Alan. I'd been looking at this too and suspected this was the case but as it wouldn't fail on my uniprocessor machine I couldn't prove it. (Theodore, if you can generate the log we discussed of this failing it might still be helpful in tracking down the underlying problem.) To summarize: Unplugging the camera while it is in use by a program causes an oops (particularly on an SMP machine). The problem is that gspca_stream_off() calls destroy_urbs(), which in turn calls usb_buffer_free() -- but this happens too late, after gspca_disconnect() has returned. By that time gspca_dev-dev is a stale pointer, so it shouldn't be passed to usb_buffer_free(). By my reading it should be OK for gspca_disconnect to have returned as long as video_unregister_device waits for the last close to complete before calling gspca_release. I know that there were some patches a while back that attempted to ensure that was the case so I suspect there is still a hole there. What should happen is that as part of disconnect processing, the existing stream(s) should be put in an error state and destroy_urbs() should be called immediately. Then when gspca_stream_off() calls destroy_urbs() again there would be no more work left to do. Alan Stern Adam Baker -- 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] newport: newport_*wait() return 0 on timeout
Hi Roel,
It seems that you've sent this driver to the wrong ML. Video adapters are not
handled on those ML's.
On Sat, 31 Jan 2009 16:29:39 +0100
Roel Kluin roel.kl...@gmail.com wrote:
With a postfix decrement t reaches -1 on timeout which results in a
return of 0.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/include/video/newport.h b/include/video/newport.h
index 1f5ebea..001b935 100644
--- a/include/video/newport.h
+++ b/include/video/newport.h
@@ -453,7 +453,7 @@ static __inline__ int newport_wait(struct newport_regs
*regs)
{
int t = BUSY_TIMEOUT;
- while (t--)
+ while (--t)
if (!(regs-cset.status NPORT_STAT_GBUSY))
break;
return !t;
@@ -463,7 +463,7 @@ static __inline__ int newport_bfwait(struct newport_regs
*regs)
{
int t = BUSY_TIMEOUT;
- while (t--)
+ while (--t)
if(!(regs-cset.status NPORT_STAT_BBUSY))
break;
return !t;
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: Bug in gspca USB webcam driver
On Mon, 2 Feb 2009, Adam Baker wrote: Thanks for confirming that Alan. I'd been looking at this too and suspected this was the case but as it wouldn't fail on my uniprocessor machine I couldn't prove it. (Theodore, if you can generate the log we discussed of this failing it might still be helpful in tracking down the underlying problem.) Note that I'm looking at the gspca.c routine from 2.6.29-rc3. If changes have been made since that version, I don't know what they are. To summarize: Unplugging the camera while it is in use by a program causes an oops (particularly on an SMP machine). The problem is that gspca_stream_off() calls destroy_urbs(), which in turn calls usb_buffer_free() -- but this happens too late, after gspca_disconnect() has returned. By that time gspca_dev-dev is a stale pointer, so it shouldn't be passed to usb_buffer_free(). By my reading it should be OK for gspca_disconnect to have returned as long as video_unregister_device waits for the last close to complete before calling gspca_release. I know that there were some patches a while back that attempted to ensure that was the case so I suspect there is still a hole there. gspca_disconnect() should _not_ wait for the last close. It should do what it needs to do and return as quickly as possible. This means there must be two paths for releasing USB resources: release upon last close and release upon disconnect. I suppose the easiest way to work around the problem would be to take a reference to the usb_device structure (usb_get_dev()) for each open and to drop the reference when the stream is closed. But it would be preferable to do things the way I described before: Make disconnect put an open stream into an error state and release all the USB resources immediately. Alan Stern -- 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] decrement address_err as well as retries.
Since we want to determine whether every retry we had an address_err,
and we decrement retries, we should decrement address_err as well.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/drivers/media/common/saa7146_i2c.c
b/drivers/media/common/saa7146_i2c.c
index c11da4d..2fac001 100644
--- a/drivers/media/common/saa7146_i2c.c
+++ b/drivers/media/common/saa7146_i2c.c
@@ -293,7 +293,7 @@ static int saa7146_i2c_transfer(struct saa7146_dev *dev,
const struct i2c_msg *m
int i = 0, count = 0;
__le32 *buffer = dev-d_i2c.cpu_addr;
int err = 0;
- int address_err = 0;
+ int address_err = retries;
int short_delay = 0;
if (mutex_lock_interruptible(dev-i2c_lock))
@@ -342,7 +342,7 @@ static int saa7146_i2c_transfer(struct saa7146_dev *dev,
const struct i2c_msg *m
if( 0 != (SAA7146_USE_I2C_IRQ
dev-ext-flags)) {
goto out;
}
- address_err++;
+ address_err--;
}
DEB_I2C((error while sending message(s).
starting again.\n));
break;
--
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] Re : Technotrend Budget S2-3200 Digital artefacts on HDchannels
On Tue, Jan 27, 2009 at 9:13 PM, Manu Abraham abraham.m...@gmail.com wrote: Alex Betis wrote: On Tue, Jan 27, 2009 at 9:56 PM, Manu Abraham abraham.m...@gmail.comwrote: Hmm OK, but is there by any chance a fix for those issues somewhere or in the pipe at least? I am willing to test (as I already offered), I can compile the drivers, spread printk or whatever else is needed to get useful reports. Let me know if I can help sort this problem. BTW in my case it is DVB-S2 3 SR and FEC 5/6. It was quite not appreciable on my part to provide a fix or reply in time nor spend much time on it earlier, but that said i was quite stuck up with some other things. Can you please pull a copy of the multiproto tree http://jusst.de/hg/multiproto or the v4l-dvb tree from http://jusst.de/hg/v4l-dvb and apply the following patch and comment what your result is ? Before applying please do check whether you still have the issues. Manu, I've tried to increase those timers long ago when played around with my card (Twinhan 1041) and scan utility. I must say that I've concentrated mostly on DVB-S channels that wasn't always locking. I didn't notice much improvements. The thing that did help was increasing the resolution of scan zigzags. With regards to the zig-zag, one bug is fixed in the v4l-dvb tree. Most likely you haven't tried that change. I've sent a patch on that ML and people were happy with the results. I did look at your patch, but that was completely against the tuning algorithm. [..] I believe DVB-S2 lock suffer from the same problem, but in that case the zigzag is done in the chip and not in the driver. Along with the patch i sent, does the attached patch help you in anyway (This works out for DVB-S2 only)? Manu, I've tried both multiproto branches you indicated above, *with* and *without* the patches you sent to the ML (fix_iterations.patch and increase timeout.patch) on this thread. Sadly, same behavior as S2API V4L-DVB current branch. No lock on 3 3/4 channels. It achieves a 0.5 second jittery sound but no image. It seems the driver is struggling to correctly lock on that channel, but doesn't get there in time... Or maybe the hardware... Dunno... Channels like ASTRA HD+;BetaDigital:11914:hC910M2O35S1:S19.2E:27500:1279=27:0;1283=deu:0:0:131:133:6:0 PREMIERE HD,PREM HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:767=27:0;771=deu,772=eng:32:1837,1833,1834,9C4:129:133:6:0 DISCOVERY HD,DISC HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:1023=27:0;1027=deu:32:1837,1833,1834,9C4:130:133:6 work just fine. But channels like National Geographic HD;National Geographic HD:11731:vC34M5O25S1:S30.0W:29000:6496=27:6497:0:1802:943:54:47:0 MOV HD;MOV HD:11731:vC34M5O25S1:S30.0W:29000:6512=27:6513=por:0:1802:944:54:47:0 Sport TV - HD;Sport TV - HD:11731:vC34M5O25S1:S30.0W:29000:6528=27:6529=por:0:1802:945:54:47:0 RTP HD;RTP HD:11731:vC34M5O25S1:S30.0W:29000:6544=27:6545:0:1802:946:54:47:0 TVCine 4 HD;TVCine 4 HD:11731:vC34M5O25S1:S30.0W:29000:6560=27:6561:0:1802:947:54:47:0 Disney Cinemagic HD:11731:vC34M5O25S1:S30.0W:29000:6576=27:6577=por:0:1802:948:54:47:0 Eurosport HD:11731:vC34M5O25S1:S30.0W:29000:6592=27:6593=por:0:1802:949:54:47:0 or [0065];:12012:hC34M5S1:S30.0W:3:4097:4098:4100:100:101:0:0:0 [0066];:12012:hC34M5S1:S30.0W:3:4105:4106:4100:100:102:0:0:0 [0067];:12012:hC34M5S1:S30.0W:3:4113:4114:4100:100:103:0:0:0 [0068];:12012:hC34M5S1:S30.0W:3:4121:4122:4100:100:104:0:0:0 [0069];:12012:hC34M5S1:S30.0W:3:4129:4130:4100:100:105:0:0:0 [006a];:12012:hC34M5S1:S30.0W:3:4137:4138:4100:100:106:0:0:0 [006b];:12012:hC34M5S1:S30.0W:3:4145:4146:4100:100:107:0:0:0 simply don't work. BTW, I think the channels above that don't work have a 0x0B stream indication. Satellite operators are misleading on the stream (h.222) when in fact they are h.264. Read that were on the ML. Don't know if it affects anything, but hey... I have to try everything! ;) I'm available to any tests necessary to fix this once and for all, if possible. Just let me know. Thanks for all your hard work. Chris -- 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: PV143N watchdog
On Monday 02 February 2009 10:34, Getcho Getchev wrote: Greetings, I am trying to control the PV143N watchdog via bttv driver under linux kernel 2.6.24.3. According to the specification the watchdog is located at address 0x56, subaddress 0x01. However when I try to write something (a value of 0, 1 or 2) on that address I get NACK result. I am using i2c_master_send() function and software bitbanging algorithm, implemented in bttv-i2c.c At the beginning I suspected the SCL line (the clock for the communication must be set at 100 KHz) but when I saw the delay time is 5 microseconds I realized the period is 10 microseconds which makes 100 KHz. I tried to write the same data on address 0x2B and I succeeded (although I do not know what is there on that address) so it That really sounds like a common i2c miss-understanding. Linux kernel i2c functions use only the 7bit address part of the i2c address. So it sounds like your device has address 0x56 for writing and 0x57 for reading. (is this correct?) Now you give i2c_master_send or i2c_transfer the 7bit part, 0x56 1, and that is 0x2B. Regards Matthias -- 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: Bug in gspca USB webcam driver
On Monday 02 February 2009, Alan Stern wrote: On Mon, 2 Feb 2009, Adam Baker wrote: snip To summarize: Unplugging the camera while it is in use by a program causes an oops (particularly on an SMP machine). The problem is that gspca_stream_off() calls destroy_urbs(), which in turn calls usb_buffer_free() -- but this happens too late, after gspca_disconnect() has returned. By that time gspca_dev-dev is a stale pointer, so it shouldn't be passed to usb_buffer_free(). By my reading it should be OK for gspca_disconnect to have returned as long as video_unregister_device waits for the last close to complete before calling gspca_release. I know that there were some patches a while back that attempted to ensure that was the case so I suspect there is still a hole there. gspca_disconnect() should _not_ wait for the last close. It should do what it needs to do and return as quickly as possible. This means there must be two paths for releasing USB resources: release upon last close and release upon disconnect. I was being slightly imprecise in saying it waits, it uses the device_register / unregister mechanism so it does effectively set a flag that results in the release being called on last close. video_unregister_device does use a mutex while updating some internal flags but as far as I can tell the USB subsystem won't call gspca_disconnect in interrupt context so that should be OK. What I hadn't noticed before is that usb_buffer_free needs the usb device pointer and as you say that is no longer valid after gspca_disconnect returns even if gspca_release hasn't freed the rest of the gspca struct. If that is the problem then I presume the correct behaviour is for gspca_disconnect to ensure that all URBs are killed and freed before gspca_disconnect returns. This shouldn't be a problem for sq905 (which doesn't use these URBs) or isochronous cameras (which don't need to resubmit URBs) but the finepix driver (the other supported bulk device) will need some careful consideration to avoid a race between killing the URB and resubmitting it. Theodore, could you check if adding a call to destroy_urbs() in gspca_disconnect fixes the crash. (destroy_urbs only frees non NULL urb pointers so should be safe to call from both disconnect and stream_off, whichever occurs first). I suppose the easiest way to work around the problem would be to take a reference to the usb_device structure (usb_get_dev()) for each open and to drop the reference when the stream is closed. But it would be preferable to do things the way I described before: Make disconnect put an open stream into an error state and release all the USB resources immediately. Alan Stern 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: [PATCH] newport: newport_*wait() return 0 on timeout
2009/2/2 Mauro Carvalho Chehab mche...@infradead.org: Hi Roel, It seems that you've sent this driver to the wrong ML. Video adapters are not handled on those ML's. Any idea where it should be sent? Thanks, Roel -- 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] Re : Technotrend Budget S2-3200 Digital artefacts on HDchannels
Le 02.02.2009 18:43:33, Chris Silva a écrit : On Tue, Jan 27, 2009 at 9:13 PM, Manu Abraham abraham.m...@gmail.com wrote: Alex Betis wrote: On Tue, Jan 27, 2009 at 9:56 PM, Manu Abraham abraham.m...@gmail.comwrote: Hmm OK, but is there by any chance a fix for those issues somewhere or in the pipe at least? I am willing to test (as I already offered), I can compile the drivers, spread printk or whatever else is needed to get useful reports. Let me know if I can help sort this problem. BTW in my case it is DVB-S2 3 SR and FEC 5/6. It was quite not appreciable on my part to provide a fix or reply in time nor spend much time on it earlier, but that said i was quite stuck up with some other things. Can you please pull a copy of the multiproto tree http://jusst.de/hg/multiproto or the v4l-dvb tree from http://jusst.de/hg/v4l-dvb and apply the following patch and comment what your result is ? Before applying please do check whether you still have the issues. Manu, I've tried to increase those timers long ago when played around with my card (Twinhan 1041) and scan utility. I must say that I've concentrated mostly on DVB-S channels that wasn't always locking. I didn't notice much improvements. The thing that did help was increasing the resolution of scan zigzags. With regards to the zig-zag, one bug is fixed in the v4l-dvb tree. Most likely you haven't tried that change. I've sent a patch on that ML and people were happy with the results. I did look at your patch, but that was completely against the tuning algorithm. [..] I believe DVB-S2 lock suffer from the same problem, but in that case the zigzag is done in the chip and not in the driver. Along with the patch i sent, does the attached patch help you in anyway (This works out for DVB-S2 only)? Manu, I've tried both multiproto branches you indicated above, *with* and *without* the patches you sent to the ML (fix_iterations.patch and increase timeout.patch) on this thread. Sadly, same behavior as S2API V4L-DVB current branch. No lock on 3 3/4 channels. It achieves a 0.5 second jittery sound but no image. It seems the driver is struggling to correctly lock on that channel, but doesn't get there in time... Or maybe the hardware... Dunno... Channels like ASTRA HD +;BetaDigital:11914:hC910M2O35S1:S19.2E:27500:1279=27:0;1283=deu:0:0:131:133:6:0 PREMIERE HD,PREM HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:767=27:0;771=deu,772=eng:32:1837,1833,1834,9C4:129:133:6:0 DISCOVERY HD,DISC HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:1023=27:0;1027=deu:32:1837,1833,1834,9C4:130:133:6 work just fine. But channels like National Geographic HD;National Geographic HD:11731:vC34M5O25S1:S30.0W:29000:6496=27:6497:0:1802:943:54:47:0 MOV HD;MOV HD:11731:vC34M5O25S1:S30.0W:29000:6512=27:6513=por:0:1802:944:54:47:0 Sport TV - HD;Sport TV - HD:11731:vC34M5O25S1:S30.0W:29000:6528=27:6529=por:0:1802:945:54:47:0 RTP HD;RTP HD:11731:vC34M5O25S1:S30.0W:29000:6544=27:6545:0:1802:946:54:47:0 TVCine 4 HD;TVCine 4 HD:11731:vC34M5O25S1:S30.0W:29000:6560=27:6561:0:1802:947:54:47:0 Disney Cinemagic HD:11731:vC34M5O25S1:S30.0W:29000:6576=27:6577=por:0:1802:948:54:47:0 Eurosport HD:11731:vC34M5O25S1:S30.0W:29000:6592=27:6593=por:0:1802:949:54:47:0 or [0065];:12012:hC34M5S1:S30.0W:3:4097:4098:4100:100:101:0:0:0 [0066];:12012:hC34M5S1:S30.0W:3:4105:4106:4100:100:102:0:0:0 [0067];:12012:hC34M5S1:S30.0W:3:4113:4114:4100:100:103:0:0:0 [0068];:12012:hC34M5S1:S30.0W:3:4121:4122:4100:100:104:0:0:0 [0069];:12012:hC34M5S1:S30.0W:3:4129:4130:4100:100:105:0:0:0 [006a];:12012:hC34M5S1:S30.0W:3:4137:4138:4100:100:106:0:0:0 [006b];:12012:hC34M5S1:S30.0W:3:4145:4146:4100:100:107:0:0:0 simply don't work. BTW, I think the channels above that don't work have a 0x0B stream indication. Satellite operators are misleading on the stream (h.222) when in fact they are h.264. Read that were on the ML. Don't know if it affects anything, but hey... I have to try everything! ;) I'm available to any tests necessary to fix this once and for all, if possible. Could I suggest something (probably stupid): I think that the TT 3650 is the same card but using USB, right (I mean it uses the stb0899/ stb6100 chips also)? So if someone could sniff the usb transactions during a successfull lock on a problematic channel (using windows then), we could see what is different. I do not have neither Windows, neither this card, but a good soul could help us here. Manu, is that sensible? Bye Manu (the other one ;-) -- 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: Bug in gspca USB webcam driver
On Mon, 2 Feb 2009, Adam Baker wrote:
On Monday 02 February 2009, Alan Stern wrote:
On Mon, 2 Feb 2009, Adam Baker wrote:
snip
To summarize: Unplugging the camera while it is in use by a program
causes an oops (particularly on an SMP machine).
The problem is that gspca_stream_off() calls destroy_urbs(), which in
turn calls usb_buffer_free() -- but this happens too late, after
gspca_disconnect() has returned. By that time gspca_dev-dev is a
stale pointer, so it shouldn't be passed to usb_buffer_free().
By my reading it should be OK for gspca_disconnect to have returned as
long as video_unregister_device waits for the last close to complete
before calling gspca_release. I know that there were some patches a while
back that attempted to ensure that was the case so I suspect there is
still a hole there.
gspca_disconnect() should _not_ wait for the last close. It should do
what it needs to do and return as quickly as possible. This means
there must be two paths for releasing USB resources: release upon last
close and release upon disconnect.
I was being slightly imprecise in saying it waits, it uses the
device_register / unregister mechanism so it does effectively set a flag that
results in the release being called on last close. video_unregister_device
does use a mutex while updating some internal flags but as far as I can tell
the USB subsystem won't call gspca_disconnect in interrupt context so that
should be OK.
What I hadn't noticed before is that usb_buffer_free needs the usb device
pointer and as you say that is no longer valid after gspca_disconnect returns
even if gspca_release hasn't freed the rest of the gspca struct. If that is
the problem then I presume the correct behaviour is for gspca_disconnect to
ensure that all URBs are killed and freed before gspca_disconnect returns.
This shouldn't be a problem for sq905 (which doesn't use these URBs) or
isochronous cameras (which don't need to resubmit URBs) but the finepix
driver (the other supported bulk device) will need some careful consideration
to avoid a race between killing the URB and resubmitting it.
Theodore, could you check if adding a call to destroy_urbs() in
gspca_disconnect fixes the crash. (destroy_urbs only frees non NULL urb
pointers so should be safe to call from both disconnect and stream_off,
whichever occurs first).
Yes, this seems to help a great deal. I have tried it at this point on
both machines. Now we have
void gspca_disconnect(struct usb_interface *intf)
{
struct gspca_dev *gspca_dev = usb_get_intfdata(intf);
gspca_dev-present = 0;
destroy_urbs(gspca_dev);
usb_set_intfdata(intf, NULL);
/* release the device */
/* (this will call gspca_release() immediatly or on last close) */
video_unregister_device(gspca_dev-vdev);
PDEBUG(D_PROBE, disconnect complete);
}
and the results are as follows:
The Pentium 4 Dual Core:
No visible problems, no error messages. I pulled the cord and then
in a very leisurely way killed the window. New on this machine and the
other one, too, is the very desirable side effect that svv can be killed
by clicking the x on the window which used not to work! Then dmesg
(with gspca_main in debug mode, too) has many times gspca:dqbuf (obvious:
I had not yet closed the window). After that come, in the order that they
are listed,
kill transfer
stream off OK
svv close
frame free
close done
device released
(all of these preceded by gspca:)
So this all looks very nice.
The Athlon K8 dual core:
Not so excellent, but still not bad. The experiment has been simiilarly
conducted, as before. The output of dmesg says pretty much the same thing.
The difference is, lots of repetitions of an error message in the
xterm which says
libv4l2: error dequeuing buf: Resource temporarily unavailable
This could of course result from libv4l2 and not from the modules. I feel
pretty sure that I am not running the same version on both machines. The
one on the Pentium 4 is quite likely to be newer than what is on the
Athlon box.
It seems to me that with this we are much better on the way.
Theodore Kilgore
--
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 1/8] radio-mr800: codingstyle cleanups
Cleanups of many if-check constructions.
Signed-off-by: Alexey Klimov klimov.li...@gmail.com
--
diff -r 1dce9d4e2179 linux/drivers/media/radio/radio-mr800.c
--- a/linux/drivers/media/radio/radio-mr800.c Sun Feb 01 11:40:27 2009 -0200
+++ b/linux/drivers/media/radio/radio-mr800.c Mon Feb 02 02:22:56 2009 +0300
@@ -378,13 +378,15 @@
struct v4l2_frequency *f)
{
struct amradio_device *radio = video_get_drvdata(video_devdata(file));
+ int retval;
/* safety check */
if (radio-removed)
return -EIO;
radio-curfreq = f-frequency;
- if (amradio_setfreq(radio, radio-curfreq) 0)
+ retval = amradio_setfreq(radio, radio-curfreq);
+ if (retval 0)
amradio_dev_warn(radio-videodev-dev,
set frequency failed\n);
return 0;
@@ -443,6 +445,7 @@
struct v4l2_control *ctrl)
{
struct amradio_device *radio = video_get_drvdata(video_devdata(file));
+ int retval;
/* safety check */
if (radio-removed)
@@ -451,13 +454,15 @@
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
if (ctrl-value) {
- if (amradio_stop(radio) 0) {
+ retval = amradio_stop(radio);
+ if (retval 0) {
amradio_dev_warn(radio-videodev-dev,
amradio_stop failed\n);
return -1;
}
} else {
- if (amradio_start(radio) 0) {
+ retval = amradio_start(radio);
+ if (retval 0) {
amradio_dev_warn(radio-videodev-dev,
amradio_start failed\n);
return -1;
@@ -508,20 +513,24 @@
static int usb_amradio_open(struct file *file)
{
struct amradio_device *radio = video_get_drvdata(video_devdata(file));
+ int retval;
lock_kernel();
radio-users = 1;
radio-muted = 1;
- if (amradio_start(radio) 0) {
+ retval = amradio_start(radio);
+ if (retval 0) {
amradio_dev_warn(radio-videodev-dev,
radio did not start up properly\n);
radio-users = 0;
unlock_kernel();
return -EIO;
}
- if (amradio_setfreq(radio, radio-curfreq) 0)
+
+ retval = amradio_setfreq(radio, radio-curfreq);
+ if (retval 0)
amradio_dev_warn(radio-videodev-dev,
set frequency failed\n);
@@ -554,8 +563,10 @@
static int usb_amradio_suspend(struct usb_interface *intf, pm_message_t
message)
{
struct amradio_device *radio = usb_get_intfdata(intf);
+ int retval;
- if (amradio_stop(radio) 0)
+ retval = amradio_stop(radio);
+ if (retval 0)
dev_warn(intf-dev, amradio_stop failed\n);
dev_info(intf-dev, going into suspend..\n);
@@ -567,8 +578,10 @@
static int usb_amradio_resume(struct usb_interface *intf)
{
struct amradio_device *radio = usb_get_intfdata(intf);
+ int retval;
- if (amradio_start(radio) 0)
+ retval = amradio_start(radio);
+ if (retval 0)
dev_warn(intf-dev, amradio_start failed\n);
dev_info(intf-dev, coming out of suspend..\n);
@@ -619,16 +632,16 @@
.release= usb_amradio_device_release,
};
-/* check if the device is present and register with v4l and
-usb if it is */
+/* check if the device is present and register with v4l and usb if it is */
static int usb_amradio_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
struct amradio_device *radio;
+ int retval;
radio = kmalloc(sizeof(struct amradio_device), GFP_KERNEL);
- if (!(radio))
+ if (!radio)
return -ENOMEM;
radio-buffer = kmalloc(BUFFER_LENGTH, GFP_KERNEL);
@@ -657,7 +670,8 @@
mutex_init(radio-lock);
video_set_drvdata(radio-videodev, radio);
- if (video_register_device(radio-videodev, VFL_TYPE_RADIO, radio_nr)) {
+ retval = video_register_device(radio-videodev, VFL_TYPE_RADIO,
radio_nr);
+ if (retval 0) {
dev_warn(intf-dev, could not register video device\n);
video_device_release(radio-videodev);
kfree(radio-buffer);
--
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
[patch review 3/8] radio-mr800: add more dev_err messages in probe
Patch adds 3 dev_err messages in usb_amradio_probe() function.
Signed-off-by: Alexey Klimov klimov.li...@gmail.com
--
diff -r c9f51bda84de linux/drivers/media/radio/radio-mr800.c
--- a/linux/drivers/media/radio/radio-mr800.c Mon Feb 02 02:53:50 2009 +0300
+++ b/linux/drivers/media/radio/radio-mr800.c Mon Feb 02 03:08:13 2009 +0300
@@ -641,19 +641,23 @@
radio = kmalloc(sizeof(struct amradio_device), GFP_KERNEL);
- if (!radio)
+ if (!radio) {
+ dev_err(intf-dev, kmalloc for amradio_device failed\n);
return -ENOMEM;
+ }
radio-buffer = kmalloc(BUFFER_LENGTH, GFP_KERNEL);
- if (!(radio-buffer)) {
+ if (!radio-buffer) {
+ dev_err(intf-dev, kmalloc for radio-buffer failed\n);
kfree(radio);
return -ENOMEM;
}
radio-videodev = video_device_alloc();
- if (!(radio-videodev)) {
+ if (!radio-videodev) {
+ dev_err(intf-dev, video_device_alloc failed\n);
kfree(radio-buffer);
kfree(radio);
return -ENOMEM;
--
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
[patch review 6/8] radio-mr800: add stereo support
Patch introduces new amradio_set_stereo function.
Driver calls this func to make stereo radio reception.
Signed-off-by: Alexey Klimov klimov.li...@gmail.com
--
diff -r 34b045702595 linux/drivers/media/radio/radio-mr800.c
--- a/linux/drivers/media/radio/radio-mr800.c Tue Feb 03 03:02:39 2009 +0300
+++ b/linux/drivers/media/radio/radio-mr800.c Tue Feb 03 03:04:54 2009 +0300
@@ -94,10 +94,15 @@
*/
#define AMRADIO_SET_FREQ 0xa4
#define AMRADIO_SET_MUTE 0xab
+#define AMRADIO_SET_MONO 0xae
/* Comfortable defines for amradio_set_mute */
#define AMRADIO_START 0x00
#define AMRADIO_STOP 0x01
+
+/* Comfortable defines for amradio_set_stereo */
+#define WANT_STEREO0x00
+#define WANT_MONO 0x01
/* module parameter */
static int radio_nr = -1;
@@ -266,12 +271,48 @@
return retval;
}
- radio-stereo = 0;
+ mutex_unlock(radio-lock);
+
+ return retval;
+}
+
+static int amradio_set_stereo(struct amradio_device *radio, char argument)
+{
+ int retval;
+ int size;
+
+ /* safety check */
+ if (radio-removed)
+ return -EIO;
+
+ mutex_lock(radio-lock);
+
+ radio-buffer[0] = 0x00;
+ radio-buffer[1] = 0x55;
+ radio-buffer[2] = 0xaa;
+ radio-buffer[3] = 0x00;
+ radio-buffer[4] = AMRADIO_SET_MONO;
+ radio-buffer[5] = argument;
+ radio-buffer[6] = 0x00;
+ radio-buffer[7] = 0x00;
+
+ retval = usb_bulk_msg(radio-usbdev, usb_sndintpipe(radio-usbdev, 2),
+ (void *) (radio-buffer), BUFFER_LENGTH, size, USB_TIMEOUT);
+
+ if (retval) {
+ radio-stereo = -1;
+ mutex_unlock(radio-lock);
+ return retval;
+ }
+
+ radio-stereo = 1;
mutex_unlock(radio-lock);
return retval;
}
+
+
/* USB subsystem interface begins here */
@@ -310,6 +351,7 @@
struct v4l2_tuner *v)
{
struct amradio_device *radio = video_get_drvdata(video_devdata(file));
+ int retval;
/* safety check */
if (radio-removed)
@@ -321,7 +363,16 @@
/* TODO: Add function which look is signal stereo or not
* amradio_getstat(radio);
*/
- radio-stereo = -1;
+
+/* we call amradio_set_stereo to set radio-stereo
+ * Honestly, amradio_getstat should cover this in future and
+ * amradio_set_stereo shouldn't be here
+ */
+ retval = amradio_set_stereo(radio, WANT_STEREO);
+ if (retval 0)
+ amradio_dev_warn(radio-videodev-dev,
+ set stereo failed\n);
+
strcpy(v-name, FM);
v-type = V4L2_TUNER_RADIO;
v-rangelow = FREQ_MIN * FREQ_MUL;
@@ -342,6 +393,7 @@
struct v4l2_tuner *v)
{
struct amradio_device *radio = video_get_drvdata(video_devdata(file));
+ int retval;
/* safety check */
if (radio-removed)
@@ -349,6 +401,25 @@
if (v-index 0)
return -EINVAL;
+
+ /* mono/stereo selector */
+ switch (v-audmode) {
+ case V4L2_TUNER_MODE_MONO:
+ retval = amradio_set_stereo(radio, WANT_MONO);
+ if (retval 0)
+ amradio_dev_warn(radio-videodev-dev,
+ set mono failed\n);
+ break;
+ case V4L2_TUNER_MODE_STEREO:
+ retval = amradio_set_stereo(radio, WANT_STEREO);
+ if (retval 0)
+ amradio_dev_warn(radio-videodev-dev,
+ set stereo failed\n);
+ break;
+ default:
+ return -EINVAL;
+ }
+
return 0;
}
@@ -508,6 +579,11 @@
return -EIO;
}
+ retval = amradio_set_stereo(radio, WANT_STEREO);
+ if (retval 0)
+ amradio_dev_warn(radio-videodev-dev,
+ set stereo failed\n);
+
retval = amradio_setfreq(radio, radio-curfreq);
if (retval 0)
amradio_dev_warn(radio-videodev-dev,
@@ -649,6 +725,7 @@
radio-users = 0;
radio-usbdev = interface_to_usbdev(intf);
radio-curfreq = 95.16 * FREQ_MUL;
+ radio-stereo = -1;
mutex_init(radio-lock);
--
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: KWorld ATSC 115 all static
On Sun, Jan 18, 2009 at 01:10:16PM -0500, CityK wrote: But as I have demonstrated above, and as Mauro explained, the previous hack/workaround no longer works in the case of with the Hans source code. The if case fails! Consequently, the else case should be don't merge. Why? Because we have now gone from: * circa pre-2.6.25, Mauro's changes that broke the boards analog TV support, but which could somewhat be corrected by Mike's hack/workaround * to present, where merging Hans' code eliminates the usability of Mike's hack/workaround ... in essence, analog TV function has now been completely killed with these boards. Now, if it is a case that a resolution to the problem is imminently forthcoming, then I don't think that the merge would be much of a problem. However, given the breadth of the conversation so far (and I really do appreciate the depth of Trent's and Jean's discussion/consideration on the matter), it is entirely unclear to me that such a resolution will be found in short order (although, I don't discount the possibility of it either). As far as I can tell, this thread petered out without a resolution. CityK later posted on avsforum, however, that analog on his card was after more changes by Hans. I'm confused. Is analog on the KWorld 115 supposed to be working again or not? I saw that some changes by Hans made it into the main Hg repository, but as of yesterday, analog still didn't work for me. David -- David Engel da...@istwok.net -- 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] radio-si470x Documentation: add note about mplayer
Hello, all This small patch adds information about si470x radio listening. Probably, it's useful to add such notes in doc file, right ? Feel free to change words in the right way due to my possible bad english. --- Patch adds information in si470x doc file about mplayer using to listening to the radio with this radio device. Signed-off-by: Alexey Klimov klimov.li...@gmail.com -- diff -r aba639a17195 linux/Documentation/video4linux/si470x.txt --- a/linux/Documentation/video4linux/si470x.txtMon Feb 02 21:09:06 2009 +0300 +++ b/linux/Documentation/video4linux/si470x.txtTue Feb 03 06:20:29 2009 +0300 @@ -52,6 +52,8 @@ - gradio - GTK FM radio tuner - kradio - Comfortable Radio Application for KDE - radio - ncurses-based radio application +- mplayer - media player for Linux http://www.mplayerhq.hu/ +(see Audio Listening section below) There is also a library libv4l, which can be used. It's going to have a function for frequency seeking, either by using hardware functionality as in radio-si470x @@ -80,6 +82,12 @@ If you use arts try: arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B - +You can also try mplayer: +mplayer radio://95.23/capture -radio adevice=hw=1.0:arate=96000 -rawaudio rate=96000 +Of course, you should place right adevice=hw=x.x option, and you can read +man mplayer to know more about others parameters. Mplayer handles both v4l2-radio +control and sound redirecting, that's why this method is interesting. + Module Parameters = -- 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] Documentation update for New V4L2 ioctls for OMAP
On Tuesday 03 February 2009 07:30:14 Hardik Shah wrote: 1. Added documentation for VIDIOC_COLOR_S_SPACE_CONV and VIDIOC_G_COLOR_SPACE_CONV 2. Added documentation for new CID V4L2_CID_ROTATION and V4L2_CID_BG_COLOR See comments below. Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Hari Nagalla hnaga...@ti.com Signed-off-by: Hardik Shah hardik.s...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- Makefile |4 + controls.sgml | 12 +++- v4l2.sgml |1 + vidioc-g-color-space-conv.sgml | 182 4 files changed, 198 insertions(+), 1 deletions(-) create mode 100644 vidioc-g-color-space-conv.sgml diff --git a/Makefile b/Makefile index 9a13c91..b76b4a7 100644 --- a/Makefile +++ b/Makefile @@ -67,6 +67,7 @@ SGMLS = \ vidioc-g-audio.sgml \ vidioc-g-audioout.sgml \ vidioc-dbg-g-chip-ident.sgml \ + vidioc-g-color-space-conv.sgml \ vidioc-g-crop.sgml \ vidioc-g-ctrl.sgml \ vidioc-g-enc-index.sgml \ @@ -156,6 +157,7 @@ IOCTLS = \ VIDIOC_ENUM_FRAMESIZES \ VIDIOC_G_AUDIO \ VIDIOC_G_AUDOUT \ + VIDIOC_G_COLOR_SPACE_CONV \ VIDIOC_G_CROP \ VIDIOC_G_CTRL \ VIDIOC_G_ENC_INDEX \ @@ -186,6 +188,7 @@ IOCTLS = \ VIDIOC_STREAMON \ VIDIOC_S_AUDIO \ VIDIOC_S_AUDOUT \ + VIDIOC_S_COLOR_SPACE_CONV \ VIDIOC_S_CROP \ VIDIOC_S_CTRL \ VIDIOC_S_EXT_CTRLS \ @@ -249,6 +252,7 @@ STRUCTS = \ v4l2_capability \ v4l2_captureparm \ v4l2_clip \ + v4l2_color_space_conv \ v4l2_control \ v4l2_crop \ v4l2_cropcap \ diff --git a/controls.sgml b/controls.sgml index 0df57dc..c9ef5e8 100644 --- a/controls.sgml +++ b/controls.sgml @@ -272,10 +272,20 @@ minimum value disables backlight compensation./entry entryEnable the color killer (ie; force a black amp; white image in case of a weak video signal)./entry /row row + entryconstantV4L2_CID_ROTATION/constant/entry + entryinteger/entry + entryRotates the image by specified angle./entry Please specify the units. How does this affect other ioctls like VIDIOC_S_FMT when it comes to width/height settings? Depending on how this works the VIDIOC_S_FMT documentation might have to refer back to this control as well. + /row + row + entryconstantV4L2_CID_BG_COLOR/constant/entry + entryinteger/entry + entrySets the background color on the current output device/entry +/row How is the color specified? RGB? YUV? See the V4L2_CID_MPEG_VIDEO_MUTE_YUV control description on how to specify the color format exactly. + row entryconstantV4L2_CID_LASTP1/constant/entry entry/entry entryEnd of the predefined control IDs (currently -constantV4L2_CID_COLOR_KILLER/constant + 1)./entry +constantV4L2_CID_BG_COLOR/constant + 1)./entry /row row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry diff --git a/v4l2.sgml b/v4l2.sgml index 9f43b6d..f9f0986 100644 --- a/v4l2.sgml +++ b/v4l2.sgml @@ -435,6 +435,7 @@ available here: ulink url=http://linuxtv.org/downloads/video4linux/API/V4L2_AP sub-querystd; sub-reqbufs; sub-s-hw-freq-seek; +sub-g-color-space-conv; sub-streamon; !-- End of ioctls. -- sub-mmap; diff --git a/vidioc-g-color-space-conv.sgml b/vidioc-g-color-space-conv.sgml new file mode 100644 index 000..a24ae4c --- /dev/null +++ b/vidioc-g-color-space-conv.sgml @@ -0,0 +1,182 @@ +refentry id=vidioc-g-color-space-conv + refmeta +refentrytitleioctl VIDIOC_S_COLOR_SPACE_CONV, VIDIOC_G_COLOR_SPACE_CONV/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_S_COLOR_SPACE_CONV/refname +refnameVIDIOC_G_COLOR_SPACE_CONV/refname +refpurposeGet or Set the color space conversion matrix /refpurpose + /refnamediv + + refsynopsisdiv +funcsynopsis + funcprototype + funcdefint functionioctl/function/funcdef + paramdefint parameterfd/parameter/paramdef + paramdefint parameterrequest/parameter/paramdef + paramdefstruct v4l2_color_space_conv +*parameterargp/parameter/paramdef + /funcprototype +/funcsynopsis + /refsynopsisdiv + + refsect1 +titleArguments/title + +variablelist + varlistentry + termparameterfd/parameter/term + listitem + parafd;/para + /listitem + /varlistentry + varlistentry + termparameterrequest/parameter/term + listitem + paraVIDIOC_G_COLOR_SPACE_CONV, VIDIOC_S_COLOR_SPACE_CONV/para + /listitem + /varlistentry + varlistentry + termparameterargp/parameter/term + listitem + para/para + /listitem + /varlistentry +/variablelist + /refsect1 + + refsect1 +
