Re: [Fwd: TV kaart donatie]
Hoi, Stefan weet je nog welke driver die kaart gebruikt en / of kan je hem in een machine stoppen en lspci doen, als ik die gegevens heb dan zal ik een mailtje naar de linux-media list sturen om te kijken of een v4l contributor interesse heeft. Misschien is het makkelijker als je zelf direct de mail stuurt: linux-media@vger.kernel.org, is open voor non subscribers. MvG, Hans On 07/02/2009 09:31 AM, S.A. Hartsuiker wrote: Hoi Hans, On 07/01/2009 09:57 PM, Hans Verkuil wrote: On Monday 29 June 2009 10:33:27 Hans de Goede wrote: Hoi Hans, Ik ben van het weekend (linuxtag Berlijn) een Fedora contributer tegen gekomen die een TV-kaart heeft die niet werkt onder Linux, de bridge is wel al indersteund dus waarschijnlijk een kwestie van een board definitie toevoegen, als ik het goed onthouden heb dan heeft de kaart (is een PCI-E kaart) een cx23885 bridge. De eigenaar van de kaart wil deze graag doneren aan een v4l developer zodat deze ondersteund kan worden, is dit iets voor jou? Ik ben niet echt een cx88-driver expert, en zeker geen DVB expert. Vraag dit even op de linux-media mailinglist, er zal vast wel iemand zijn die die kaart wil hebben. Kijk wel eerst even goed wat voor kaart het nu is. PCI-E is iets heel anders dan een ExpressCard. Inderdaad. Het is een Expresscard (qua formaat een pcmcia slot, maar dan smaller, in dit geval 34mm). Ik heb hem nu voor me en op de kaart staat dat het een 'AVerMedia AVerTV Hybrid Express' is. Het claimt een DVB-T te zijn. De doos is compleet, inclusief alle kabels, handleiding en originele cdrom met windows drivers. Mvgr, Stefan Groeten, Hans En zo ja, kan die hem dan direct naar een Nederlands adres van jou sturen, of is het beter als die hem naar mij stuurt en ik hem maandag 13 juli als we elkaar zien aan jouw geef? Zo nee, wie kunnen we er dan blij mee maken? MvG, Hans Original Message Subject: TV kaart donatie Date: Sat, 27 Jun 2009 12:49:37 +0200 From: S.A. Hartsuikerba...@fedoraproject.org To: hdego...@redhat.com Hoi, als je mij een shipping address geeft dan zal ik je die tv kaart toesturen waar we het tijdens LinuxNacht over gehad hebben. Off the top of my head is het een Avermedia Hybrid Expresscard, al zijn daar meerdere, en verschillende, van. Mvgr, Stefan Hartsuiker -- 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: Afatech AF9013 DVB-T not working with mplayer radio streams
Jelle de Jong wrote: Jelle de Jong wrote: Hi all, Because i now use a new kernel and new mplayer versions I did some testing again on one of my long standing issues. My Afatech AF9015 DVB-T USB2.0 stick does not work with mplayer, other em28xx devices do work with mplayer. Would somebody be willing to do some tests and see if mplayers works on your devices? Debian 2.6.30-1 /usr/bin/mplayer -identify -v -dvbin timeout=10 dvb://3FM(Digitenne) See the attachments for full details. Best regards, Jelle de Jong I am going to give this thread a ping, because I believe this is one of the few out of the box supported usb dvb-t devices. And I would like to have at least one device that I can currently buy and that works. So could somebody with a AF9015 device test if it works with mplayer? Also please test the stability. When I use my device with totem it has issues getting video, I have to replug the device to get it working again, no dmesg error messages and dvb-t signal is very strong. I need to be able to just boot the system start totem or mplayer let it run stable until the system gets shutdown by the user. (like as a normal TV or a DVB-T system with Apple OSX stability) Some extra information about the lockups of my AF9015, this is a serious blocker issue for me. It happens when I watch a channel with totem-xine and switch to an other channel, the device is then unable to lock to the new channel, and totem-xine hangs. There are no messages in dmesg. Rebooting the system does not help getting the device working again, the only way i found is to replug the usb device and this is not an option for my systems because the usb devices are hidden. Is there an other USB DVB-T device that works out of the box with the 2.9.30 kernel? Could somebody show me a link or name of this device so I can buy and test it? Thanks in advance, Jelle -- 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
Writing a tv tuner device driver: example source code?
Hello, Can anyone please direct me to the source code for a fully-functional device driver for a tv tuner please? I intend to write one and would need to have a look at the source for one (ideally an archive). I did not find my way in the repository and if someone could spare some time providing me with an answer to my question it would be great. Thanks in advance, Julien. -- 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] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 30 Jun 2009 14:39:55 -0500
Karicheri, Muralidharan m-kariche...@ti.com escreveu:
Mauro,
Thanks for responding...
You should note that I'm not asking you to remove that code, but just to
use
the already existing color balance ioctls, for the existing features, or
otherwise to discuss the need of extra controls.
Ok.
The case of image color controlling, we already have several controls:
#define V4L2_CID_SATURATION (V4L2_CID_BASE+2)
#define V4L2_CID_RED_BALANCE(V4L2_CID_BASE+14)
#define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15)
#define V4L2_CID_GAMMA (V4L2_CID_BASE+16)
#define V4L2_CID_GAIN (V4L2_CID_BASE+19)
Also, some got deprecated, since they were just duplicating existing
controls,
using a different way, as discussed at ML:
Ok. I need to investigate this when I support control IOCTLs in vpfe
capture. As of now control IOCTLs are not supported in vpfe capture.
#define V4L2_CID_BLACK_LEVEL(V4L2_CID_BASE+11) /* Deprecated */
#define V4L2_CID_WHITENESS (V4L2_CID_GAMMA) /* Deprecated */
So, you basically need to rewrite your logic in order to control the device
in
terms of gain and red/blue balance.
Ok. I get it.
Hans had an issue with the way we implemented control IOCTL handling in the
driver. So the piece of code you had objected to is redundant. I will clean
it up or modify it when I support control IOCTLs handling in vpfe capture or
alternately remove it using a separate patch. So please go ahead and merge
the patches if everything else looks good.
I guess you didn't understand me. For me to pull from this pull request, I need
to be sure that no uneeded/duplicated/undocumented userspace controls are added
to V4L2 API.
So, we need to solve all PRIVATE controls:
$ grep PRIVATE /tmp/newpatches/hg_v4l-dvb-vpfe-cap_*
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_02.patch:+#define
VPFE_CMD_S_CCDC_RAW_PARAMS _IOW('V', BASE_VIDIOC_PRIVATE + 1, \
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_R_GAIN
(V4L2_CID_PRIVATE_BASE + 0)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GR_GAIN
(V4L2_CID_PRIVATE_BASE + 1)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GB_GAIN
(V4L2_CID_PRIVATE_BASE + 2)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_B_GAIN
(V4L2_CID_PRIVATE_BASE + 3)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_OFFSET
(V4L2_CID_PRIVATE_BASE + 4)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_MAX
(V4L2_CID_PRIVATE_BASE + 5)
(btw, the grep above also showed another of such control at the second patch)
Most of the above controls are duplicated, in the sense that the current color
controls (eventually with some math) are capable of controlling the color gains.
The CCDC_CID_MAX is not even implemented.
The VPFE_CMD_S_CCDC_RAW_PARAMS and CCDC_CID_OFFSET are not properly documented,
so, I have no idea about what you want to control with them.
One quick alternative for them, while they are being under discussions, would
be to put them into #if 0/#endif blocks, but you need to provide a patch to
solve it for me to merge VPFE
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] USBVision device defaults
On Wed, 1 Jul 2009, Andy Walls wrote: It's unclear to me if the PowerOnAtOpen module parameter works properly when set to 0. It might actually prevent the automatic shutoff in 3 seconds if set to zero. I hadn't spotted that option, it does seem to work and enables the device to stay active after the programme using it has exited, preserving the settings. With PowerOnAtOpen=0, using the normal unmodified driver, I can't get a picture using either flash or kdetv. However, using my bodged driver which forces use of the SVideo input, I can now get a colour picture in flash by starting and exiting kdetv first. Odd, but it does at least provide a workable solution to my problem. Also, by inspection I think the driver has a bug you may be able to exploit. If you already have the driver open with an application, trying to open it with another application will fail, but not before reseting the poweroff timer back to three seconds. So if you have an app that attempts to open() and close() the usbvision device node every 1 second, I think you can keep it from powering down and losing it's settings. Here's a useless little program to do just that. Compile it and invoke it as 'program-name /dev/video0' I gave the code a try, it works up to a point, I get a colour picture in flash, but the picture is frozen. I suspect your programme is grabbing the video device back from flash before I can kill it. Thankyou for your help ! If anybody on this list decides to try and neaten up the code for the usbvision driver, I'm happy to do a bit of testing work (contant me on t...@autotrain.org, I may not stay subscribed to this email list permanantly). Tim W -- Tim Williams BSc MSc MBCS Euromotor Autotrain LLP 58 Jacoby Place Priory Road Edgbaston Birmingham B5 7UW United Kingdom Web : http://www.autotrain.org Tel : +44 (0)121 414 2214 EuroMotor-AutoTrain is a company registered in the UK, Registration number: OC317070. -- 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] cx88: High resolution timer for Remote Controls
From: Andrzej Hajda andrzej.ha...@wp.pl
Patch solves problem of missed keystrokes on some remote controls,
as reported on http://bugzilla.kernel.org/show_bug.cgi?id=9637 .
Signed-off-by: Andrzej Hajda andrzej.ha...@wp.pl
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
Resending because last attempt resulted in folded lines:
http://www.spinics.net/lists/linux-media/msg06884.html
Patch was already resent by Andrzej on June 4th but apparently it was
overlooked.
Trent Piepho commented on the compatibility with kernels older than
2.6.20 being possibly broken:
http://www.spinics.net/lists/linux-media/msg06885.html
I don't think this is the case. The kernel version test was there
because the workqueue API changed in 2.6.20, but the hrtimer API did
not have such a change. This is why the version check has gone.
It is highly probable that the hrtimer API had its own incompatible
changes since it was introduced in kernel 2.6.16. By looking at the
code, I found the following ones:
* hrtimer_forward_now() was added with kernel 2.6.25 only:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5e05ad7d4e3b11f935998882b5d9c3b257137f1b
But this is an inline function, so I presume this shouldn't be too
difficult to add to a compatibility header.
* Before 2.6.21, HRTIMER_MODE_REL was named HRTIMER_REL:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c9cb2e3d7c9178ab75d0942f96abb3abe0369906
This too should be solvable in a compatibility header.
The rest doesn't seem to cause compatibility issues, but only actual
testing would confirm that.
This bug affects me, which is why I am motivated to get this fix
upstream. Please let me know how I can help.
linux/drivers/media/video/cx88/cx88-input.c | 37 ---
1 file changed, 17 insertions(+), 20 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx88/cx88-input.c2009-07-02
15:13:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx88/cx88-input.c 2009-07-02
15:35:04.0 +0200
@@ -23,10 +23,10 @@
*/
#include linux/init.h
-#include linux/delay.h
#include linux/input.h
#include linux/pci.h
#include linux/module.h
+#include linux/hrtimer.h
#include compat.h
#include cx88.h
@@ -49,7 +49,7 @@ struct cx88_IR {
/* poll external decoder */
int polling;
- struct delayed_work work;
+ struct hrtimer timer;
u32 gpio_addr;
u32 last_gpio;
u32 mask_keycode;
@@ -145,31 +145,28 @@ static void cx88_ir_handle_key(struct cx
}
}
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
-static void cx88_ir_work(void *data)
-#else
-static void cx88_ir_work(struct work_struct *work)
-#endif
+enum hrtimer_restart cx88_ir_work(struct hrtimer *timer)
{
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
- struct cx88_IR *ir = data;
-#else
- struct cx88_IR *ir = container_of(work, struct cx88_IR, work.work);
-#endif
+ unsigned long missed;
+ struct cx88_IR *ir = container_of(timer, struct cx88_IR, timer);
cx88_ir_handle_key(ir);
- schedule_delayed_work(ir-work, msecs_to_jiffies(ir-polling));
+ missed = hrtimer_forward_now(ir-timer,
+ktime_set(0, ir-polling * 100));
+ if (missed 1)
+ ir_dprintk(Missed ticks %ld\n, missed - 1);
+
+ return HRTIMER_RESTART;
}
void cx88_ir_start(struct cx88_core *core, struct cx88_IR *ir)
{
if (ir-polling) {
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
- INIT_DELAYED_WORK(ir-work, cx88_ir_work, ir);
-#else
- INIT_DELAYED_WORK(ir-work, cx88_ir_work);
-#endif
- schedule_delayed_work(ir-work, 0);
+ hrtimer_init(ir-timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ ir-timer.function = cx88_ir_work;
+ hrtimer_start(ir-timer,
+ ktime_set(0, ir-polling * 100),
+ HRTIMER_MODE_REL);
}
if (ir-sampling) {
core-pci_irqmask |= PCI_INT_IR_SMPINT;
@@ -186,7 +183,7 @@ void cx88_ir_stop(struct cx88_core *core
}
if (ir-polling)
- cancel_delayed_work_sync(ir-work);
+ hrtimer_cancel(ir-timer);
}
/* -- */
--
Jean Delvare
--
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] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro,
I will recreate the patches to take out these controls from
the code and take care of other comments you have and
request Hans to send you a pull request.
Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
Sent: Thursday, July 02, 2009 7:39 AM
To: Karicheri, Muralidharan
Cc: Hans Verkuil; linux-media@vger.kernel.org
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 30 Jun 2009 14:39:55 -0500
Karicheri, Muralidharan m-kariche...@ti.com escreveu:
Mauro,
Thanks for responding...
You should note that I'm not asking you to remove that code, but just to
use
the already existing color balance ioctls, for the existing features, or
otherwise to discuss the need of extra controls.
Ok.
The case of image color controlling, we already have several controls:
#define V4L2_CID_SATURATION (V4L2_CID_BASE+2)
#define V4L2_CID_RED_BALANCE(V4L2_CID_BASE+14)
#define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15)
#define V4L2_CID_GAMMA (V4L2_CID_BASE+16)
#define V4L2_CID_GAIN (V4L2_CID_BASE+19)
Also, some got deprecated, since they were just duplicating existing
controls,
using a different way, as discussed at ML:
Ok. I need to investigate this when I support control IOCTLs in vpfe
capture. As of now control IOCTLs are not supported in vpfe capture.
#define V4L2_CID_BLACK_LEVEL(V4L2_CID_BASE+11) /* Deprecated
*/
#define V4L2_CID_WHITENESS (V4L2_CID_GAMMA) /* Deprecated
*/
So, you basically need to rewrite your logic in order to control the
device
in
terms of gain and red/blue balance.
Ok. I get it.
Hans had an issue with the way we implemented control IOCTL handling in
the driver. So the piece of code you had objected to is redundant. I will
clean it up or modify it when I support control IOCTLs handling in vpfe
capture or alternately remove it using a separate patch. So please go ahead
and merge the patches if everything else looks good.
I guess you didn't understand me. For me to pull from this pull request, I
need
to be sure that no uneeded/duplicated/undocumented userspace controls are
added
to V4L2 API.
So, we need to solve all PRIVATE controls:
$ grep PRIVATE /tmp/newpatches/hg_v4l-dvb-vpfe-cap_*
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_02.patch:+#define
VPFE_CMD_S_CCDC_RAW_PARAMS _IOW('V', BASE_VIDIOC_PRIVATE + 1, \
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_R_GAIN
(V4L2_CID_PRIVATE_BASE + 0)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GR_GAIN
(V4L2_CID_PRIVATE_BASE + 1)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GB_GAIN
(V4L2_CID_PRIVATE_BASE + 2)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_B_GAIN
(V4L2_CID_PRIVATE_BASE + 3)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_OFFSET
(V4L2_CID_PRIVATE_BASE + 4)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_MAX
(V4L2_CID_PRIVATE_BASE + 5)
(btw, the grep above also showed another of such control at the second
patch)
Most of the above controls are duplicated, in the sense that the current
color
controls (eventually with some math) are capable of controlling the color
gains.
The CCDC_CID_MAX is not even implemented.
The VPFE_CMD_S_CCDC_RAW_PARAMS and CCDC_CID_OFFSET are not properly
documented,
so, I have no idea about what you want to control with them.
One quick alternative for them, while they are being under discussions,
would
be to put them into #if 0/#endif blocks, but you need to provide a patch to
solve it for me to merge VPFE
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: XC2028 Tuner - firmware issues
On Wed, Jul 1, 2009 at 12:19 AM, Andrej Faloutand...@falout.org wrote: Devin, thank you for your reply, please see below; I did the work for the au0828 bridge, which is used in the US based HVR-950q tuner. I've also done alot of work on the em28xx bridge. I understand the problem but unfortunately this is of little use to identify the product to purchase :-( All I need is a USB hybrid analog PAL/DVB-T TV with FM tuner. (I'm in Australia) That's a tough one. I am in the United States, so I'm not in a good position to recommend DVB-T tuners. To make matters worse, vendors often come out with new hardware designs with the same name as tuners that were previously supported under Linux, so even when a user looks in the LinuxTV wiki, there's a chance that the tuner he then goes out and buys will not be the same hardware. Well we can always return such devices, and send a thank-you-not! email to the vendor in question. Maybe if they knew why are people returning there products, they'll stop doing it and label there products correctly depending on hardware built-in... So a list of known working devices would still be of great help http://devinjh.livejournal.com/174527.html Please see my response, and my donation. Also see: http://www.smolts.org/static/stats/by_class_CAPTURE.html We know there are few million Linux boxes out there, but even for 100.000, 0.4% means There are 400 Bt878 devices out there on Linux... plus, look at the second, and fifth lines :-) I would doubt any vendor would ignore sale of few thousand of there devices, especially the maker of the chip used in all of them. Just for example. And Smolts is a) a very new thing, b) disabled by default so user must explicitly enable collection of data from his/hers PC, c) still not included in all major distros. So regardless of absolute numbers, take a look at percentages - they are the key for getting both vendor and user support. Cheers, Andrej Falout Hello Andrej, I took the ideas you put forth and put together a reply in the form of a blog post. http://devinjh.livejournal.com/ Cheers, 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: [linux-dvb] Pinnacle dual Hybrid pro PCI-express - linuxTV!
Hi, Is this thread saying that the Pinnacle 3010i is now supported under linux? if so does this go for the Pinnacle 7010i too? Thanks, Matt 2009/3/27 dCrypt dcr...@telefonica.net: Hi, I also own a pair of Pinnacle 3010ix. Luca, where should the PCI ID go? I can't believe that adding a new card to the supported card list is just that simple. Do you know a web page with information about it?. Thanks -Mensaje original- De: linux-dvb-boun...@linuxtv.org [mailto:linux-dvb-boun...@linuxtv.org] En nombre de Luca Tettamanti Enviado el: jueves, 15 de enero de 2009 16:44 Para: Catimimi CC: linux-...@linuxtv.org; Linux-media Asunto: Re: [linux-dvb] Pinnacle dual Hybrid pro PCI-express - linuxTV! On Wed, Jan 14, 2009 at 10:28 AM, Catimimi catim...@libertysurf.fr wrote: try without the .ko, i.e. instead, use: modprobe saa716x_hybrid OK, shame on me, it works but nothing happens. Of course ;-) The PCI ID of the card is not listed. I happen to have the same card, you can add the ID to the list but note that the frontend is not there yet... so the module will load, will print some something... and that's it. I have a couple of patches queued and I plan to do some experimentation in the weekend though ;) Luca ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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] Pinnacle dual Hybrid pro PCI-express - linuxTV!
Nobody has answered my question yet, I am still waiting to know how to enable 3010i in linux - Mensaje original - De: Matt mattmora...@gmail.com Enviado: jueves, 02 de julio de 2009 17:26 Para: linux-media@vger.kernel.org CC: linux-...@linuxtv.org Asunto: Re: [linux-dvb] Pinnacle dual Hybrid pro PCI-express - linuxTV! Hi, Is this thread saying that the Pinnacle 3010i is now supported under linux? if so does this go for the Pinnacle 7010i too? Thanks, Matt 2009/3/27 dCrypt dcr...@telefonica.net: Hi, I also own a pair of Pinnacle 3010ix. Luca, where should the PCI ID go? I can't believe that adding a new card to the supported card list is just that simple. Do you know a web page with information about it?. Thanks -Mensaje original- De: linux-dvb-boun...@linuxtv.org [mailto:linux-dvb-boun...@linuxtv.org] En nombre de Luca Tettamanti Enviado el: jueves, 15 de enero de 2009 16:44 Para: Catimimi CC: linux-...@linuxtv.org; Linux-media Asunto: Re: [linux-dvb] Pinnacle dual Hybrid pro PCI-express - linuxTV! On Wed, Jan 14, 2009 at 10:28 AM, Catimimi catim...@libertysurf.fr wrote: try without the .ko, i.e. instead, use: modprobe saa716x_hybrid OK, shame on me, it works but nothing happens. Of course ;-) The PCI ID of the card is not listed. I happen to have the same card, you can add the ID to the list but note that the frontend is not there yet... so the module will load, will print some something... and that's it. I have a couple of patches queued and I plan to do some experimentation in the weekend though ;) Luca ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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: Afatech AF9013 DVB-T not working with mplayer radio streams
On Thu, Jul 2, 2009 at 4:43 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Is there an other USB DVB-T device that works out of the box with the 2.9.30 kernel? Could somebody show me a link or name of this device so I can buy and test it? You might want to check out the WinTV-Ministick, which is both currently available for sale and supported in Linux. http://www.hauppauge.co.uk/site/products/data_ministickhd.html 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Thu, 2 Jul 2009 10:13:08 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, I will recreate the patches to take out these controls from the code and take care of other comments you have and request Hans to send you a pull request. Ok. for me, it is also fine if you just send the new patches, provided that you ask me to pull together with the previous ones. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Hauppauge HVR-1800 not working at all
On Tuesday 30 June 2009 05:50:59 pm Michael Krufky wrote: George Czerw wrote: On Tuesday 30 June 2009 15:56:08 Devin Heitmueller wrote: On Tue, Jun 30, 2009 at 3:48 PM, George Czerwgcz...@comcast.net wrote: Devin, thanks for the reply. Lsmod showed that tuner was NOT loaded (wonder why?), a modprobe tuner took care of that and now the HVR-1800 is displaying video perfectly and the tuning function works. I guess that I'll have to add tuner into modprobe.preload.d Now if only I can get the sound functioning along with the video! George Admittedly, I don't know why you would have to load the tuner module manually on the HVR-1800. I haven't had to do this on other products? If you are doing raw video capture, then you need to manually tell applications where to find the ALSA device that provides the audio. If you're capturing via the MPEG encoder, then the audio will be embedded in the stream. Devin I don't understand why the audio/mpeg ports of the HVR-1800 don't show up in output of lspci: 03:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8880 (rev 0f) Subsystem: Hauppauge computer works Inc. Device 7801 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at f9c0 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [80] Power Management version 2 Capabilities: [90] Vital Product Data Capabilities: [a0] MSI: Mask- 64bit+ Count=1/1 Enable- Capabilities: [100] Advanced Error Reporting Capabilities: [200] Virtual Channel ? Kernel driver in use: cx23885 Kernel modules: cx23885 even though the dmesg output clearly shows this: tveeprom 0-0050: decoder processor is CX23887 (idx 37) tveeprom 0-0050: audio processor is CX23887 (idx 42) -- 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 Please try this: When you have tvtime open and running with video working already, do: mplayer /dev/video1 (assuming that tvtime is open on video0) Then, you'll get mplayer complete with both audio and video. -Mike OK, I tried this again after downloading the firmware (HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip) from Stoth's webpage and re-ran mplayer using a command that I found on a Ubuntu wikki: * $ mplayer /dev/video1 -vo x11 -nobps -autosync 30 -forceidx -hardframedrop -vc ffmpeg12 -idle -menu -cache 16384 -cache-seek-min 50 -mc 0 -ni MPlayer SVN-1.rc2.23.r28791.2mdv2009.1-4.3.2 (C) 2000-2009 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Struct fs_cfg doesn't have any auto-close field [MENU] bad attribute auto-close=yes in menu 'open_list' at line 57 Menu initialized: /home/george/.mplayer/menu.conf Playing /dev/video1. Cache fill: 19.63% (3293184 bytes) MPEG-PS file format detected. VIDEO: MPEG2 720x480 (aspect 2) 29.970 fps 8000.0 kbps (1000.0 kbyte/s) == Forced video codec: ffmpeg12 Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Unsupported PixelFormat -1 Selected video codec: [ffmpeg12] vfm: ffmpeg (FFmpeg MPEG-1/2) == == Trying to force audio codec driver family libmad... Opening audio decoder: [libmad] libmad mpeg audio decoder AUDIO: 48000 Hz, 2 ch, s16le, 224.0 kbit/14.58% (ratio: 28000-192000) Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3) == [pulse] working around probably broken pause functionality, see http://www.pulseaudio.org/ticket/440 socket(): Address family not supported by protocol AO: [pulse] Init failed: Connection refused Failed to initialize audio driver 'pulse' AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starting playback... VDec: vo config request - 720 x 480 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. VO: [x11] 720x480 = 720x540 Planar YV12 [zoom] [swscaler @ 0x8958820]using unscaled yuv420p - rgb32 special converter [mpegvideo @ 0x88aff40]ac-tex damaged at 7 0 [mpegvideo @ 0x88aff40]Warning MVs not available [mpegvideo @ 0x88aff40]concealing 1350 DC, 1350 AC, 1350 MV errors A: 79.2 V: 79.3 A-V: -0.078 ct:
Re: Patch: Schedule obsolete v4l1 quickcam_messenger and ov511 drivers for removal
Hi Hans, Em Tue, 23 Jun 2009 13:39:38 +0200 Hans de Goede hdego...@redhat.com escreveu: Schedule obsolete v4l1 quickcam_messenger and ov511 drivers for removal It would be better to add the Files: field to explicitly indicate what files will be removed, like the modified version of your patch. Please check if those are the files you're meaning to remove: --- From: Hans de Goede hdego...@redhat.com Schedule obsolete v4l1 quickcam_messenger and ov511 drivers for removal [mche...@redhat.com: add the files: tag to indicate what will be removed] Signed-off-by: Hans de Goede hdego...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index f8cd450..8a8c045 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -458,3 +458,19 @@ Why: Remove the old legacy 32bit machine check code. This has been but the old version has been kept around for easier testing. Note this doesn't impact the old P5 and WinChip machine check handlers. Who: Andi Kleen a...@firstfloor.org + + + +What: usbvideo quickcam_messenger driver +When: 2.6.32 +Why: obsolete v4l1 driver replaced by gspca_stv06xx +Who: Hans de Goede hdego...@redhat.com +Files: drivers/media/video/c-qcam.c drivers/media/video/bw-qcam.c + + + +What: ov511 v4l1 driver +When: 2.6.32 +Why: obsolete v4l1 driver replaced by gspca_ov519 +Who: Hans de Goede hdego...@redhat.com +Files: drivers/media/video/ov511.[ch] 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Jul 2 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12167:966ce12c444d gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc1-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-rc1-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc1-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc1-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc1-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc1-x86_64: ERRORS sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS 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 V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/11 - v3] vpfe capture bridge driver for DM355 and DM6446
On Thursday 02 July 2009 19:05:51 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
Re-sending to add description for VPFE_CMD_S_CCDC_RAW_PARAMS and
updating debug prints with \n and fixing an error coder ENOMEM
VPFE Capture bridge driver
This is version, v3 of vpfe capture bridge driver for doing video
capture on DM355 and DM6446 evms. The ccdc hw modules register with the
driver and are used for configuring the CCD Controller for a specific
decoder interface. The driver also registers the sub devices required
for a specific evm. More than one sub devices can be registered.
This allows driver to switch dynamically to capture video from
any sub device that is registered. Currently only one sub device
(tvp5146) is supported. But in future this driver is expected
to do capture from sensor devices such as Micron's MT9T001,MT9T031
and MT9P031 etc. The driver currently supports MMAP based IO.
Following are the updates based on review comments:-
1) clean up of setting bus parameters in ccdc
2) removed v4l2_routing structure type
3) module authors, description changes
4) pixel aspect constants removed
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be
Reviewed by: Alexey Klimov klimov.li...@gmail.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/vpfe_capture.c | 2136
include/media/davinci/vpfe_capture.h | 194 +++
include/media/davinci/vpfe_types.h | 51 +
3 files changed, 2381 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpfe_capture.c
create mode 100644 include/media/davinci/vpfe_capture.h
create mode 100644 include/media/davinci/vpfe_types.h
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
snip
+/**
+ * VPFE_CMD_S_CCDC_RAW_PARAMS - Driver private IOCTL to set raw capture
params
+ * This ioctl is used to configure the ccdc module such as defect pixel
+ * correction, color space conversion, culling etc. in raw capture mode.
+ * TODO: This is to be split into multiple ioctls and also explore the
+ * possibility of extending the v4l2 api to include them
+ **/
+#define VPFE_CMD_S_CCDC_RAW_PARAMS _IOW('V', BASE_VIDIOC_PRIVATE + 1, \
+ void *)
+#endif /* _DAVINCI_VPFE_H */
I've only one request: can you add something along the lines of:
This is an experimental ioctl that will change in future kernels.
Use with care.
And at the top add: EXPERIMENTAL IOCTL
That way it is unambiguous that this will change. And it definitely has
to change! On the other hand I can imagine that it is useful to have this
available to experiment with. We have made experimental APIs before, so
there is a precedent for this, as long as it is very clearly marked as
experimental.
In fact, it would be even better if there is a KERN_WARNING message issued
mentioning the experimental status of this ioctl whenever it is used.
If you can do this asap, then I'll merge everything tomorrow morning and
make a new pull request for this.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/11 - v3] vpfe capture bridge driver for DM355 and DM6446
Hans, snip I've only one request: can you add something along the lines of: This is an experimental ioctl that will change in future kernels. Use with care. And at the top add: EXPERIMENTAL IOCTL That way it is unambiguous that this will change. And it definitely has to change! On the other hand I can imagine that it is useful to have this available to experiment with. We have made experimental APIs before, so there is a precedent for this, as long as it is very clearly marked as experimental. In fact, it would be even better if there is a KERN_WARNING message issued mentioning the experimental status of this ioctl whenever it is used. If you can do this asap, then I'll merge everything tomorrow morning and make a new pull request for this. Done. Let me know how it goes. Thanks Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Afatech AF9013 DVB-T not working with mplayer radio streams
Devin Heitmueller wrote: On Thu, Jul 2, 2009 at 4:43 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Is there an other USB DVB-T device that works out of the box with the 2.9.30 kernel? Could somebody show me a link or name of this device so I can buy and test it? You might want to check out the WinTV-Ministick, which is both currently available for sale and supported in Linux. http://www.hauppauge.co.uk/site/products/data_ministickhd.html Devin Hi Devin, Thanks for your response, I am kind of hitting a deadline next Tuesday. I must a kind of working dvb-t system here. The af9013 will be a backup plan. So this is my local supplier. Can I ask you to just make a list of product ids (ArtNr) and I will order them, if they do not work I will sent them out to developers that volunteer: http://www.informatique.nl/cgi-bin/iqshop.cgi?M=ARTG=167 I am only interested in USB DVB-T devices. I will try to make the order tomorrow morning. Thanks in advance, Cheers, Jelle -- 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: Afatech AF9013 DVB-T not working with mplayer radio streams
On Thu, Jul 2, 2009 at 4:51 PM, Jelle de Jongjelledej...@powercraft.nl wrote: Devin Heitmueller wrote: On Thu, Jul 2, 2009 at 4:43 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Is there an other USB DVB-T device that works out of the box with the 2.9.30 kernel? Could somebody show me a link or name of this device so I can buy and test it? You might want to check out the WinTV-Ministick, which is both currently available for sale and supported in Linux. http://www.hauppauge.co.uk/site/products/data_ministickhd.html Devin Hi Devin, Thanks for your response, I am kind of hitting a deadline next Tuesday. I must a kind of working dvb-t system here. The af9013 will be a backup plan. So this is my local supplier. Can I ask you to just make a list of product ids (ArtNr) and I will order them, if they do not work I will sent them out to developers that volunteer: http://www.informatique.nl/cgi-bin/iqshop.cgi?M=ARTG=167 I am only interested in USB DVB-T devices. I will try to make the order tomorrow morning. Thanks in advance, Cheers, Jelle Jelle, Well, before I offer any suggestions, bear in mind that I actually don't use DVB-T and I don't have these products, so I cannot claim that they work from my own experience. Looking at the DVB-T USB entries in list you sent: the ASUS U3000 works according to the Wiki: http://linuxtv.org/wiki/index.php/ASUS_My_Cinema-U3000_Mini From the Hauppauge list, the any HVR-900 you would buy today would almost certainly be an HVR-900 R2, which is known to not be supported in the current tree. From the Pinnacle list, I can tell you that both versions of the 340e are not supported (I am actively developing the xc4000 driver required for them this week). According to the wiki, both the 72e and 73e do work: http://linuxtv.org/wiki/index.php/Pinnacle_PCTV_72e http://linuxtv.org/wiki/index.php/Pinnacle_PCTV_nano_Stick_%2873e%29 I'm not familiar with the products from Plextor and Technisat. 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: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 10:34 AM, George Adamsg_adam...@hotmail.com wrote: Y'all are very kind to help - thank you. I am indeed running Ubuntu Hardy (8.04.2 LTS), kernel on a quad-core Q9550 box. I'll be happy to provide any other system details that may assist. uname -a returns: Linux spurgeon 2.6.24-24-server #1 SMP Wed Apr 15 16:36:01 UTC 2009 i686 GNU/Linux George, FYI: The fix got merged into the mainline two days ago, so if you update to the latest v4l-dvb code, the analog support should now be working properly under your Ubuntu Hardy setup. Cheers, 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: Afatech AF9013 DVB-T not working with mplayer radio streams
On 06/26/2009 11:07 AM, Jelle de Jong wrote: Hi all, Because i now use a new kernel and new mplayer versions I did some testing again on one of my long standing issues. My Afatech AF9015 DVB-T USB2.0 stick does not work with mplayer, other em28xx devices do work with mplayer. Would somebody be willing to do some tests and see if mplayers works on your devices? Debian 2.6.30-1 /usr/bin/mplayer -identify -v -dvbin timeout=10 dvb://3FM(Digitenne) See the attachments for full details. For me, this works. I tested this with MT2060 tuner device, as you have also. If I remember correctly it worked for you also when channel is selected by using tzap. I don't know what mplayer does differently. Do the television channels in that same multiplex work with mplayer? /usr/bin/mplayer -identify -v -dvbin timeout=10 dvb://TELEVISION CHANNEL I added some delay for demod to wait lock. Could you try if this helps? http://linuxtv.org/hg/~anttip/af9015_delay/ 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
Re: Afatech AF9013 DVB-T not working with mplayer radio streams
On 07/02/2009 11:43 AM, Jelle de Jong wrote: Some extra information about the lockups of my AF9015, this is a serious blocker issue for me. It happens when I watch a channel with totem-xine and switch to an other channel, the device is then unable to lock to the new channel, and totem-xine hangs. There are no messages in dmesg. Rebooting the system does not help getting the device working again, the only way i found is to replug the usb device and this is not an option for my systems because the usb devices are hidden. I have seen that also with Totem-xine few times. Totem-xine hags totally and it must be killed. But after that my device starts working without replug (if I remember correctly). One thing could be power issue. If you have possibility to test with powered USB -hub please do. Is there an other USB DVB-T device that works out of the box with the 2.9.30 kernel? Could somebody show me a link or name of this device so I can buy and test it? DibCOM based sticks are usually good choice. There is many models from many vendors, TerraTec, Artec (Artec T14BR is sold here in Finland 20-30e). DibCOM also uses big USB block size which seems to reduce system load. Look examples from here: http://www.linuxtv.org/wiki/index.php/User:Hlangos Could someone explain why USB block size have so big effect to load? 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
Re: [PATCH] Implement V4L2_CAP_STREAMING for zr364xx driver
Hi all, I have noticed the patch mentioned in the subject was not included in 2.6.30. Do you plan to add it to 2.6.31? Em Saturday 28 March 2009, Lamarque Vieira Souza escreveu: This patch implements V4L2_CAP_STREAMING for the zr364xx driver, by converting the driver to use videobuf. Tested with Creative PC-CAM 880. It basically: . implements V4L2_CAP_STREAMING using videobuf; . re-implements V4L2_CAP_READWRITE using videobuf; . copies cam-udev-product to the card field of the v4l2_capability struct. That gives more information to the users about the webcam; . moves the brightness setting code from before requesting a frame (in read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is executed only when the application requests a change in brightness and not before every frame read; . comments part of zr364xx_vidioc_try_fmt_vid_cap that says that Skype + libv4l do not work. This patch fixes zr364xx for applications such as mplayer, Kopete+libv4l and Skype+libv4l can make use of the webcam that comes with zr364xx chip. Signed-off-by: Lamarque V. Souza lamar...@gmail.com --- --- v4l-dvb/linux/drivers/media/video/zr364xx.c 2009-03-27 15:18:54.050413997 -0300 +++ v4l-dvb/linux-lvs/drivers/media/video/zr364xx.c 2009-03-27 15:22:47.914414277 -0300 ... stripped off to not bloat the e-mail. -- Lamarque V. Souza http://www.geographicguide.com/brazil.htm Linux User #57137 - http://counter.li.org/ -- 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] libv4l: add support for RGB565 format
Currently, em28xx driver outputs webcams only at RGB565 format. However,
several webcam applications don't support this format.
In order to properly work with those applications, a RGB565 handler should be
added at libv4l.
Tested with Silvercrest 1.3 mpix with v4l2grab (V4L2, with native libv4l
support) and two LD_PRELOAD applications: camorama (V4L1 API) and skype (using
compat32).
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h
b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h
--- a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h
+++ b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h
@@ -184,6 +184,15 @@ void v4lconvert_swap_rgb(const unsigned
void v4lconvert_swap_uv(const unsigned char *src, unsigned char *dst,
const struct v4l2_format *src_fmt);
+void v4lconvert_rgb565_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height);
+
+void v4lconvert_rgb565_to_bgr24(const unsigned char *src, unsigned char *dest,
+ int width, int height);
+
+void v4lconvert_rgb565_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt, int yvu);
+
void v4lconvert_spca501_to_yuv420(const unsigned char *src, unsigned char *dst,
int width, int height, int yvu);
diff --git a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c
b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c
--- a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c
+++ b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c
@@ -46,6 +46,7 @@ static const struct v4lconvert_pixfmt su
{ V4L2_PIX_FMT_YUYV, 0 },
{ V4L2_PIX_FMT_YVYU, 0 },
{ V4L2_PIX_FMT_UYVY, 0 },
+ { V4L2_PIX_FMT_RGB565, 0 },
{ V4L2_PIX_FMT_SN9C20X_I420, V4LCONVERT_NEEDS_CONVERSION },
{ V4L2_PIX_FMT_SBGGR8, V4LCONVERT_NEEDS_CONVERSION },
{ V4L2_PIX_FMT_SGBRG8, V4LCONVERT_NEEDS_CONVERSION },
@@ -787,6 +788,23 @@ static int v4lconvert_convert_pixfmt(str
}
break;
+case V4L2_PIX_FMT_RGB565:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ v4lconvert_rgb565_to_rgb24(src, dest, width, height);
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_rgb565_to_bgr24(src, dest, width, height);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ v4lconvert_rgb565_to_yuv420(src, dest, fmt, 0);
+ break;
+ case V4L2_PIX_FMT_YVU420:
+ v4lconvert_rgb565_to_yuv420(src, dest, fmt, 1);
+ break;
+ }
+ break;
+
case V4L2_PIX_FMT_RGB24:
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_BGR24:
diff --git a/v4l2-apps/libv4l/libv4lconvert/rgbyuv.c
b/v4l2-apps/libv4l/libv4lconvert/rgbyuv.c
--- a/v4l2-apps/libv4l/libv4lconvert/rgbyuv.c
+++ b/v4l2-apps/libv4l/libv4lconvert/rgbyuv.c
@@ -1,8 +1,10 @@
/*
# RGB - YUV conversion routines
+# (C) 2008 Hans de Goede j.w.r.dego...@hhs.nl
-# (C) 2008 Hans de Goede j.w.r.dego...@hhs.nl
+# RGB565 conversion routines
+# (C) 2009 Mauro Carvalho Chehab mche...@redhat.com
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
@@ -472,3 +474,103 @@ void v4lconvert_swap_uv(const unsigned c
src += src_fmt-fmt.pix.bytesperline / 2;
}
}
+
+void v4lconvert_rgb565_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height)
+{
+ int j;
+ while (--height = 0) {
+for (j = 0; j width; j++) {
+ unsigned short tmp = *(unsigned short *)src;
+
+ /* Original format: rggg gggb */
+ *dest++ = 0xf8 (tmp 8);
+ *dest++ = 0xfc (tmp 3);
+ *dest++ = 0xf8 (tmp 3);
+
+ src += 2;
+}
+ }
+}
+
+void v4lconvert_rgb565_to_bgr24(const unsigned char *src, unsigned char *dest,
+ int width, int height)
+{
+ int j;
+ while (--height = 0) {
+for (j = 0; j width; j++) {
+ unsigned short tmp = *(unsigned short *)src;
+
+ /* Original format: rggg gggb */
+ *dest++ = 0xf8 (tmp 3);
+ *dest++ = 0xfc (tmp 3);
+ *dest++ = 0xf8 (tmp 8);
+
+ src += 2;
+}
+ }
+}
+
+void v4lconvert_rgb565_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt, int yvu)
+{
+ int x, y;
+ unsigned short tmp;
+ unsigned char *udest, *vdest;
+ unsigned r[4], g[4], b[4];
+ int avg_src[3];
+
+ /* Y */
+ for (y = 0; y src_fmt-fmt.pix.height; y++) {
+for (x = 0; x src_fmt-fmt.pix.width; x++) {
+ tmp = *(unsigned short *)src;
+ r[0] = 0xf8 (tmp 3);
+ g[0] = 0xfc (tmp 3);
+ b[0] = 0xf8 (tmp 8);
+ RGB2Y(r[0], g[0], b[0], *dest++);
+ src += 2;
+}
+src += src_fmt-fmt.pix.bytesperline - 2 * src_fmt-fmt.pix.width;
+ }
+ src -= src_fmt-fmt.pix.height * src_fmt-fmt.pix.bytesperline;
+
+ /* U + V */
+ if (yvu) {
+vdest = dest;
+udest = dest + src_fmt-fmt.pix.width *
