Re: Embedded Linux Conference
On Tuesday 17 March 2009 01:14:28 Steve Sakoman wrote: On Mon, Mar 16, 2009 at 3:56 PM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@deeprootsystems.com [090316 15:52]: Hans Verkuil hverk...@xs4all.nl writes: Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. I will be there as well, and while not directly involved with V4L2, I'm involved in various parts of getting OMAP and DaVinci devices supported in mainline kernels. Yeah I'll be in town too and will be dropping by at the conf here and there. Maybe let's arrange something to get some beers one night during the conf? I'll be there too. How about Wednesday evening for beers? Steve On Wednesday evening there is the 'social event', which means free food and beer :-). So I'd say that evening is covered. However, I'd welcome dinner on Sunday evening. Having arrived that day from Europe I won't be a sparkling conversationalist but it beats having dinner by your own and gives us a chance to meet one another. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/2] Sensor orientation reporting
Adam Baker wrote: On Monday 16 March 2009, Hans de Goede wrote: Both patches look good to me. A complaint about lack of documentation wouldn't have gone amiss. Er, good point. Regards, Hans Unfortunately having just remembered that I should have done that I'm struggling to get the current docbook to compile (So far I've suffered Ubuntu not packaging an old enough docbook, missing character set definition files and the Makefile depending on bash but not explicitly requesting it so getting dash). It looks like it now builds the docs so I'm ready to start updating them. 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] LED control
On Sun, 15 Mar 2009 08:14:56 -0700 (PDT) Trent Piepho xy...@speakeasy.org wrote: - this asks to have a kernel generated with CONFIG_NEW_LEDS, So? - the user must use some new program to access /sys/class/leds/device, echo, cat? - he must know how the LEDs of his webcam are named in the /sys tree. Just give them a name like video0:power and it will be easy enough to associate them with the device. I think links in sysfs would do it to, /sys/class/video4linux/video0/device/ledname or something like that. The advantage of using the led class is that you get support for triggers and automatic blink functions, etc. Sorry for I don't see the usage of blinking the LEDs for a webcam. Again, using the led class makes me wonder about: 1) The end users. Many Linux users don't know the kernel internal, nor which of the too many applications they should use to make their devices work. If no developper creates a tool to handle the webcams, the users have to search again and again. Even if there is a full documentation, they will try anything and eventually ask the kernel developpers why they cannot have their LEDs switched on. Actually, there are a few programs that can handle the webcam parameters. In fact I know only 'v4l2-ctl': I did not succeeded to compile qv4l2; v4l2ucp has been removed from Debian; and, anyway, these programs don't handle the VIDIOC_G_JPEGCOMP and VIDIOC_S_JPEGCOMP ioctls. 2) The memory overhead. Using the led class adds more kernel code and asks the webcam drivers to create a new device. Also, the function called for changing the LED brighness cannot sleep, so the use a workqueue is required. On contrary, with a webcam control, only one byte (for 8 LEDs) is added to the webcam structure and the change is immediatly done in the ioctl. 3) The development time. I already spent 2 hours to look how the led class was working. I am not sure to develop a full LED mechanism in less than 5 to 8 hours, and, as I cannot test it by myself, I will have to wait for testers to know if the various protections (USB access, USB disconnection) work in all cases. Otherwise, adding a new control in a driver may be done in less than half an hour, and, sure, it will work well at the first go! -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Are there drivers for Tx Hollywood Hybrid usb2 linux?
Hi, is the card in the $subject supported by some official or unofficial tree? In the latest mercurial a quick grep didn't reveal anything useful. Thanks. -- 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: Strange card
On Mon, 2009-03-16 at 22:40 -0400, Eduardo Kaftanski wrote: I bought today a card that was packaged as a PICO2000-compatible but I can't get it to work... I read all the archives and wikis I could find but the only one thread with the same card description but the recipe won't work for me. Here is the lspci... is this card supported? 01:0a.0 Multimedia video controller: Brooktree Corporation Unknown device 016e (rev 11) That looks wrong - 016e is not valid for a BrookTree device according to the PCI ID database. A value of 036e would be correct for some Bt878 Video Capture devices. Pull out your PCI cards, blow the dust out of all the slots, reseat the cards, and try again. Regards, Andy Flags: bus master, fast devsel, latency 32, IRQ 11 Memory at d9fff000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 01:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) Flags: bus master, fast devsel, latency 32, IRQ 11 Memory at d9ffe000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 THanks. -- 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
No subsystem id (and therefore no cx88_dvb loaded) after reboot
I'm looking for some pointers on debugging a problem with my DVICO FusionHDTV Hybrid DVB-T card. The device was working perfectly prior to a reconfiguration of my machine, kernel upgrade etc... Now, on a cold start everything seems to start smoothly but I can't tune channels. Then, after a reboot the device is not detected due to invalid subsystem id. As below lspci reports no subsystem information at all. Comparing the lspci output seems to be around the Region 0: Memory at ee00 v de00, but I'm not sure what this means, and whether fixing the reboot problem will fix the channel tuning problem. Running mythbuntu 8.10 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux lspci -vvnn after cold start 00:0a.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at de00 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx8800 Kernel modules: cx8800 00:0a.1 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:8811] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1000ns min, 63750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at df00 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel modules: cx88-alsa 00:0a.2 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1500ns min, 22000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at e000 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 lspci -vvnn after warm reboot 00:0a.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx8800 Kernel modules: cx8800 -- 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: Embedded Linux Conference
Hans Verkuil wrote: On Tuesday 17 March 2009 01:14:28 Steve Sakoman wrote: On Mon, Mar 16, 2009 at 3:56 PM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@deeprootsystems.com [090316 15:52]: Hans Verkuil hverk...@xs4all.nl writes: Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. I will be there as well, and while not directly involved with V4L2, I'm involved in various parts of getting OMAP and DaVinci devices supported in mainline kernels. Yeah I'll be in town too and will be dropping by at the conf here and there. Maybe let's arrange something to get some beers one night during the conf? I'll be there too. How about Wednesday evening for beers? Steve On Wednesday evening there is the 'social event', which means free food and beer :-). So I'd say that evening is covered. However, I'd welcome dinner on Sunday evening. Having arrived that day from Europe I won't be a sparkling conversationalist but it beats having dinner by your own and gives us a chance to meet one another. I won't be arriving until late Sunday night, and I imagine others may be arrving Monday morning. How about Monday night after the Dinner (ends at 7pm [1]) we meet for beers. I'll let someone local (Tony) pick the venue. Kevin [1] http://www.embeddedlinuxconference.com/elc_2009/program.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: Improve DKMS build of v4l-dvb?
Op vrijdag 13-03-2009 om 02:12 uur [tijdzone -0700], schreef Trent Piepho: On Mon, 9 Mar 2009, Alain Kalker wrote: Martin has an older version of the drivers packaged for building with DKMS on Ubuntu in his PPA[5], but it currently has some disadvantages: A. It builds all available drivers, no matter which hardware is actually installed in the system. This takes a lot of time, and may not be practical at all on systems with limited resources (e.g. embedded, MIDs, netbooks) B. It currently has no support for Jockey to detect installed hardware, so individual drivers can be selected. To address these issues, I would like to propose the following: A. Building individual drivers (i.e. sets of modules which constitute a fully-functional driver), without having to manually configure them using make menuconfig I see two possibilities for realizing this: Firstly: generating a .config with just one config variable for the requested driver set to 'm' merged with the config for the kernel being built for, and then doing a make silentoldconfig. Big disatvantage is that full kernel source is required for the 'silentoldconfig' target to be available. Does that actually work? Figuring out that needs to be turned on to enable some config options is a hard problem. It's not just simple dependencies between modules, but complex expressions that need to be satisfied. E.g., something depends on A || B, which do you turn on, A or B? There are multiple solutions so how does the code decide which is best? Well, make_kconfig.pl does quite a nice job trying to select as many drivers without causing conflicts. Anyway, you're quite right about this being a hard problem, and the fact that the Kconfig system wasn't designed to be very helpful in auto-selecting dependencies and resolving conflicts the same way modern package managers are, doesn't make it any easier. For the moment, I would suggest either to choose a default which works for most people, or ask the user (using any Kconfig menu tool, if only they didn't need write access to the kernel source, grrr!) to choose among alternatives if no combination of options can be selected automatically. Secondly, the script v4l/scripts/analyze_build.pl generates a list of modules that will get built for each Kconfig variable selected, but it currently has no way of determing all the module dependencies that make up a fully functional driver. I just wrote analyze_build.pl to make it easier for developers to figure out that source files make up a module and how to enable it. It's not actually used by the build system. It's also not perfect when it comes to parsing makefiles, i.e. it no where near a re-implementation of make's parser in perl. It understands the typical syntax used by the kernel makefiles but sometimes there is some unusual bit of make code that it won't parse. Nice work! I've been using it a lot while testing. I expect to use it also in a tool which will work like 'modinfo', except using module source files as input. I plan to add some nice extensions like showing the config options which enable a module, symbolic DeviceID/VendorID, values, etc. Kind regards, Alain -- 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] CXUSB D680 DMB using unified lgs8gxx driver
This patch replace the use of lgs8gl5 driver by unified lgs8gxx driver, for
CXUSB D680 DMB (MagicPro ProHDTV)
David T.L. Wong
diff -r 626c136ec221 linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c Fri Mar 13 14:35:14 2009 -0700
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c Tue Mar 17 23:17:16 2009 +0800
@@ -38,7 +38,7 @@
#include mxl5005s.h
#include dib7000p.h
#include dib0070.h
-#include lgs8gl5.h
+#include lgs8gxx.h
/* debug */
static int dvb_usb_cxusb_debug;
@@ -1097,8 +1097,18 @@
return -EIO;
}
-static struct lgs8gl5_config lgs8gl5_cfg = {
+static struct lgs8gxx_config d680_lgs8gl5_cfg = {
+ .prod = LGS8GXX_PROD_LGS8GL5,
.demod_address = 0x19,
+ .serial_ts = 0,
+ .ts_clk_pol = 0,
+ .ts_clk_gated = 1,
+ .if_clk_freq = 30400, /* 30.4 MHz */
+ .if_freq = 5725, /* 5.725 MHz */
+ .if_neg_center = 0,
+ .ext_adc = 0,
+ .adc_signed = 0,
+ .if_neg_edge = 0,
};
static int cxusb_d680_dmb_frontend_attach(struct dvb_usb_adapter *adap)
@@ -1138,7 +1148,7 @@
msleep(100);
/* Attach frontend */
- adap-fe = dvb_attach(lgs8gl5_attach, lgs8gl5_cfg, d-i2c_adap);
+ adap-fe = dvb_attach(lgs8gxx_attach, d680_lgs8gl5_cfg, d-i2c_adap);
if (adap-fe == NULL)
return -EIO;
RE: Embedded Linux Conference
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, March 17, 2009 4:22 AM To: Hans Verkuil Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Hadli, Manjunath; DongSoo(Nathaniel) Kim; Aguirre Rodriguez, Sergio Alberto; Hiremath, Vaibhav Subject: Re: Embedded Linux Conference Hans Verkuil hverk...@xs4all.nl writes: Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. [Hiremath, Vaibhav] Unfortunately I will not be able to attend :) Thanks, Vaibhav Hiremath I will be there as well, and while not directly involved with V4L2, I'm involved in various parts of getting OMAP and DaVinci devices supported in mainline kernels. Kevin -- 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] Remove stream pipe draining code for CXUSB D680 DMB
CXUSB D680 DMB pipe draining code found to be problematic for new
kernels (eg. kernel 2.6.27 @ Ubuntu 8.10)
David T.L. Wong
diff -r 626c136ec221 linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c Fri Mar 13 14:35:14 2009 -0700
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c Tue Mar 17 23:20:00 2009 +0800
@@ -322,58 +322,11 @@
return 0;
}
-static void cxusb_d680_dmb_drain_message(struct dvb_usb_device *d)
-{
- int ep = d-props.generic_bulk_ctrl_endpoint;
- const int timeout = 100;
- const int junk_len = 32;
- u8*junk;
- int rd_count;
-
- /* Discard remaining data in video pipe */
- junk = kmalloc(junk_len, GFP_KERNEL);
- if (!junk)
- return;
- while (1) {
- if (usb_bulk_msg(d-udev,
- usb_rcvbulkpipe(d-udev, ep),
- junk, junk_len, rd_count, timeout) 0)
- break;
- if (!rd_count)
- break;
- }
- kfree(junk);
-}
-
-static void cxusb_d680_dmb_drain_video(struct dvb_usb_device *d)
-{
- struct usb_data_stream_properties *p = d-props.adapter[0].stream;
- const int timeout = 100;
- const int junk_len = p-u.bulk.buffersize;
- u8*junk;
- int rd_count;
-
- /* Discard remaining data in video pipe */
- junk = kmalloc(junk_len, GFP_KERNEL);
- if (!junk)
- return;
- while (1) {
- if (usb_bulk_msg(d-udev,
- usb_rcvbulkpipe(d-udev, p-endpoint),
- junk, junk_len, rd_count, timeout) 0)
- break;
- if (!rd_count)
- break;
- }
- kfree(junk);
-}
-
static int cxusb_d680_dmb_streaming_ctrl(
struct dvb_usb_adapter *adap, int onoff)
{
if (onoff) {
u8 buf[2] = { 0x03, 0x00 };
- cxusb_d680_dmb_drain_video(adap-dev);
return cxusb_ctrl_msg(adap-dev, CMD_STREAMING_ON,
buf, sizeof(buf), NULL, 0);
} else {
@@ -1118,13 +1081,6 @@
usb_clear_halt(d-udev,
usb_rcvbulkpipe(d-udev, d-props.adapter[0].stream.endpoint));
- /* Drain USB pipes to avoid hang after reboot */
- for (n = 0; n 5; n++) {
- cxusb_d680_dmb_drain_message(d);
- cxusb_d680_dmb_drain_video(d);
- msleep(200);
- }
-
/* Reset the tuner */
if (cxusb_d680_dmb_gpio_tuner(d, 0x07, 0) 0) {
err(clear tuner gpio failed);
Re: Embedded Linux Conference
* Kevin Hilman khil...@deeprootsystems.com [090317 07:50]: Hans Verkuil wrote: On Tuesday 17 March 2009 01:14:28 Steve Sakoman wrote: On Mon, Mar 16, 2009 at 3:56 PM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@deeprootsystems.com [090316 15:52]: Hans Verkuil hverk...@xs4all.nl writes: Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. I will be there as well, and while not directly involved with V4L2, I'm involved in various parts of getting OMAP and DaVinci devices supported in mainline kernels. Yeah I'll be in town too and will be dropping by at the conf here and there. Maybe let's arrange something to get some beers one night during the conf? I'll be there too. How about Wednesday evening for beers? Steve On Wednesday evening there is the 'social event', which means free food and beer :-). So I'd say that evening is covered. However, I'd welcome dinner on Sunday evening. Having arrived that day from Europe I won't be a sparkling conversationalist but it beats having dinner by your own and gives us a chance to meet one another. I won't be arriving until late Sunday night, and I imagine others may be arrving Monday morning. How about Monday night after the Dinner (ends at 7pm [1]) we meet for beers. I'll let someone local (Tony) pick the venue. OK, let's plan for Monday night then. I'll find some place with drinks easily available, and within walking distance from the conference. I've added a placeholder for the event where I'll post the details later on: http://www.muru.com/linux/omap/events/ To get a rough idea how many people we'll have, please reply to this thread, or send me an email if you're planning to attend. Cheers, Tony [1] http://www.embeddedlinuxconference.com/elc_2009/program.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new frequency table for Strasbourg, France
Then there must be something ``wrong'' with `w_scan' making incorrect assumptions about the data which it's parsing. No - i do not think so. All of the frequencies found are with 166kHz offset. w_scan does not use any of these 166k offsets, that means this frequency data was transmitted as exactly such a number in some NIT w_scan parsed. w_scan calculates DVB-T center freqs as center freq = (30600 + channel * 800) Hz for this range. And NIT parsing is the same as dvbscan. What has disturbed me is how this offset has been applied across the board by `w_scan', Again, w_scan does not use these offsets. Some dvbsnoop output as suggested and additional some scan with service names (either dvbscan or w_scan), vdr channels.conf would be fine, would really help to see whats going on here. -- 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: Embedded Linux Conference
Hi Tony, I think I can join you. And also Kyungmin Park I guess. See you then. Nate 2009. 03. 18, 오전 1:45, Tony Lindgren 작성: * Kevin Hilman khil...@deeprootsystems.com [090317 07:50]: Hans Verkuil wrote: On Tuesday 17 March 2009 01:14:28 Steve Sakoman wrote: On Mon, Mar 16, 2009 at 3:56 PM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@deeprootsystems.com [090316 15:52]: Hans Verkuil hverk...@xs4all.nl writes: Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. I will be there as well, and while not directly involved with V4L2, I'm involved in various parts of getting OMAP and DaVinci devices supported in mainline kernels. Yeah I'll be in town too and will be dropping by at the conf here and there. Maybe let's arrange something to get some beers one night during the conf? I'll be there too. How about Wednesday evening for beers? Steve On Wednesday evening there is the 'social event', which means free food and beer :-). So I'd say that evening is covered. However, I'd welcome dinner on Sunday evening. Having arrived that day from Europe I won't be a sparkling conversationalist but it beats having dinner by your own and gives us a chance to meet one another. I won't be arriving until late Sunday night, and I imagine others may be arrving Monday morning. How about Monday night after the Dinner (ends at 7pm [1]) we meet for beers. I'll let someone local (Tony) pick the venue. OK, let's plan for Monday night then. I'll find some place with drinks easily available, and within walking distance from the conference. I've added a placeholder for the event where I'll post the details later on: http://www.muru.com/linux/omap/events/ To get a rough idea how many people we'll have, please reply to this thread, or send me an email if you're planning to attend. Cheers, Tony [1] http://www.embeddedlinuxconference.com/elc_2009/program.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
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 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:Tue Mar 17 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11038:626c136ec221 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-rc8-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc8-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc8-armv5-omap2: OK 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-rc8-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc8-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc8-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc8-powerpc64: OK 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-rc8-x86_64: WARNINGS fw/apps: WARNINGS sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc8): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: Improve DKMS build of v4l-dvb?
On Tue, 17 Mar 2009, Alain Kalker wrote: Op vrijdag 13-03-2009 om 02:12 uur [tijdzone -0700], schreef Trent Piepho: On Mon, 9 Mar 2009, Alain Kalker wrote: Firstly: generating a .config with just one config variable for the requested driver set to 'm' merged with the config for the kernel being built for, and then doing a make silentoldconfig. Big disatvantage is that full kernel source is required for the 'silentoldconfig' target to be available. Does that actually work? Figuring out that needs to be turned on to enable some config options is a hard problem. It's not just simple dependencies between modules, but complex expressions that need to be satisfied. E.g., something depends on A || B, which do you turn on, A or B? There are multiple solutions so how does the code decide which is best? Well, make_kconfig.pl does quite a nice job trying to select as many drivers without causing conflicts. What I did in make_kconfig.pl was just turn everything on, then recursively disable anything that has a failed dependency. There isn't any intelligence when it comes to choices where you can have driver set A or driver set B, but not both. Options that we want disabled, like some drivers' advanced debug controls, must be explicitly disabled in make_kconfig. Still, it ends up doing what we want in the end, which is to compile all the drivers that we can compile. Anyway, you're quite right about this being a hard problem, and the fact that the Kconfig system wasn't designed to be very helpful in auto-selecting dependencies and resolving conflicts the same way modern package managers are, doesn't make it any easier. From what I can tell, solving the dependency problem is easily shown to be the same as the classical satisfiability problem, which is proven to be NP complete. Now, there are heuristics that can usually solve SAT problems quicker but finding the best solution quickly is quite a bit harder. For the moment, I would suggest either to choose a default which works for most people, or ask the user (using any Kconfig menu tool, if only they didn't need write access to the kernel source, grrr!) to choose among alternatives if no combination of options can be selected automatically. You don't need write access to the kernel source. The kernel's config programs have to be built, but that can be done ahead of time. Once they are, then you can use that menu tool from v4l-dvb without write access to the kernel source. There is support for an alternate output directory for the kernel that can work too. In the kernel dir, run make O=~/kernel-output-dir menuconfig. That should not require write access to the kernel source dir and will put the necessary config programs in ~/kernel-output-dir. Then point v4l-dvb at the kernel output dir, with make release DIR=~/kernel-output-dir. See the explanation from my changeset that added this, http://linuxtv.org/hg/v4l-dvb/log/6331 Good thing I wrote this 17 months ago when I did the work, instead of just using some two word patch description, since I sure wouldn't remember how all that works today. -- 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] add new frequency table for Strasbourg, France
wk wrote: Then there must be something ``wrong'' with `w_scan' making incorrect assumptions about the data which it's parsing. No - i do not think so. All of the frequencies found are with 166kHz offset. w_scan does not use any of these 166k offsets, that means this frequency data was transmitted as exactly such a number in some NIT w_scan parsed. w_scan calculates DVB-T center freqs as center freq = (30600 + channel * 800) Hz for this range. And NIT parsing is the same as dvbscan. What has disturbed me is how this offset has been applied across the board by `w_scan', Again, w_scan does not use these offsets. Again, I've added these offsets to w_scan results as it was written in linuxtv wiki. Ben -- 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: Topro 6800 driver [JPEG decoding solved]
Hello Anders Good news, I could decode a frame which I extracted from the usbsnoobs I did :-). See attached picture frame3-03.jpg. It uses the quality 0. Your black frame you sent me gets now correctly decode, too (frameA-01.jpg) I found the Huffman table in the Windoz driver file (TP6810.sys) at offset 0x2a59c. The QTable which I found in a text file on my Windoz box can be found in this driver file, also. I attached some binary files which I used to build the 2 attached jpeg. For example use: cat FFD8-Q0-320x240.bin huffman1.bin FFDA.bin frame3-3.bin frame3-03.jpg to make the picture frame3-03.jpg. This information should the cam get going in Linux ;-) Happy Hacking, Thomas PS: I sent this to the linux-media mail list, because somebody else is interested about this information, too. inline: frame3-03.jpginline: frameA-01.jpg FFD8-Q0-320x240.bin Description: Binary data FFD8-Q0-640x480.bin Description: Binary data FFD8-Q1-320x280.bin Description: Binary data FFD8-Q1-640x480.bin Description: Binary data FFDA.bin Description: Binary data huffman1.bin Description: Binary data frame3-3.bin Description: Binary data
Re: bttv, tvaudio and ir-kbd-i2c probing conflict
On Tue, 17 Mar 2009, Jean Delvare wrote: On Mon, 16 Mar 2009 15:47:17 -0700 (PDT), Trent Piepho wrote: On Mon, 16 Mar 2009, Jean Delvare wrote: You are unfair. The pull request came with a short log of all the changes. short log. His entire series was decribed with fewer words than I would use on a single patch that changes ten lines. In general I tend to like detailed patch logs as much as you do. But in this case Hans is doing almost all the work by himself and it is very needed, and the faster completed, the better. So I am really to trade log details for a faster conversion. I guess that I don't consider documentation to be optional. (...) I am not familiar enough with this part of the code to say. But I guess it doesn't really matter, as it wasn't my point anyway. It seems like your point was that conversions to v4l2_subdev allow drivers to be more efficient remove lots of code. The numbers I see just don't support that claim. No, sorry if I didn't make it clear, but that wasn't my point. My point was only about the change in i2c binding model. This change clearly results in a net shrink as far as lines of code are concerned. Does it? When we can use the model as it's designed, then I think it's clearly much better. But when one is emulating the detection behaviour, like it appears the bttv patches do, I don't see what's better. -- 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: Strange card
Ok card was bad I replaced the card and now this is detected: 01:08.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 01:08.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) BUt it only shows me one /dev/video device. Should;t it be 4? Thanks (yes, I am a total video newbie) On Tue, Mar 17, 2009 at 6:37 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-03-16 at 22:40 -0400, Eduardo Kaftanski wrote: I bought today a card that was packaged as a PICO2000-compatible but I can't get it to work... I read all the archives and wikis I could find but the only one thread with the same card description but the recipe won't work for me. Here is the lspci... is this card supported? 01:0a.0 Multimedia video controller: Brooktree Corporation Unknown device 016e ( rev 11) That looks wrong - 016e is not valid for a BrookTree device according to the PCI ID database. A value of 036e would be correct for some Bt878 Video Capture devices. Pull out your PCI cards, blow the dust out of all the slots, reseat the cards, and try again. Regards, Andy Flags: bus master, fast devsel, latency 32, IRQ 11 Memory at d9fff000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 01:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11 ) Flags: bus master, fast devsel, latency 32, IRQ 11 Memory at d9ffe000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 THanks. -- --- Eduardo Kaftanski ekaf...@gmail.com edua...@orsus.cl -- 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
no video device
Hi, dvb professionals, I followed the advices on http://www.linuxtv.org/wiki/index.php/How_to_Obtain%2C_Build_and_Install_V4L-DVB_Device_Drivers#Optional_Pre-Compilation_Steps Build and Installation Instructions downloaded the v4l sources via mercurial, make and sudo make install finished without error messages. rebooted the computer dmesg shows the device: --- usb 2-1: new high speed USB device using ehci_hcd and address 6 usb 2-1: configuration #1 chosen from 1 choice usb 2-1: New USB device found, idVendor=0b48, idProduct=300d usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1: Product: TT-USB2.0 usb 2-1: Manufacturer: TechnoTrend usb 2-1: SerialNumber: LHKAMG --- no error if I unplug and plug it on USB again the connected box is a TechnoTrend CT 3560 CI I googled and found chipset names like TDA8274 + TDA10023 did not find anything in wiki, so I could not determine module or driver names to be identified with lsmod. there is no created /dev/dvb or /dev/video device google did not help me answering the question do I need firmware, and if so where to get it uname -a shows Linux rolf9 2.6.28-7.slh.6-sidux-686 #1 SMP PREEMPT Sat Mar 14 02:30:40 UTC 2009 i686 GNU/Linux for now I got stuck. Do you know of a next step towards having tv on my laptop? Rolf -- 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-mr800.c: Missing mutex include
radio-mr800.c uses struct mutex, so while linux/mutex.h seems to be pulled in indirectly by one of the headers it already includes, the right thing is to include it directly. Signed-off-by: Alessio Igor Bogani abog...@texware.it --- drivers/media/radio/radio-mr800.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/radio/radio-mr800.c b/drivers/media/radio/radio-mr800.c index fdfc7bf..4d91148 100644 --- a/drivers/media/radio/radio-mr800.c +++ b/drivers/media/radio/radio-mr800.c @@ -58,6 +58,7 @@ #include media/v4l2-ioctl.h #include linux/usb.h #include linux/version.h /* for KERNEL_VERSION MACRO */ +#include linux/mutex.h /* driver and module definitions */ #define DRIVER_AUTHOR Alexey Klimov klimov.li...@gmail.com -- 1.6.0.4 -- 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] add new frequency table for Strasbourg, France
Benjamin Zores schrieb: wk wrote: Then there must be something ``wrong'' with `w_scan' making incorrect assumptions about the data which it's parsing. No - i do not think so. All of the frequencies found are with 166kHz offset. w_scan does not use any of these 166k offsets, that means this frequency data was transmitted as exactly such a number in some NIT w_scan parsed. w_scan calculates DVB-T center freqs as center freq = (30600 + channel * 800) Hz for this range. And NIT parsing is the same as dvbscan. What has disturbed me is how this offset has been applied across the board by `w_scan', Again, w_scan does not use these offsets. Again, I've added these offsets to w_scan results as it was written in linuxtv wiki. Ben If you manually edited the frequencies, we can stop searching here. This is definitely wrong. If somebody wrote something like this to linuxtv wiki, we should remove that lines. -- 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: 4vl + usb + arm
On Tue, Mar 17, 2009 at 2:58 PM, Pete Eberlein p...@sensoray.com wrote: On Tue, 2009-03-03 at 11:51 -0700, Paul Thomas wrote: Hello, is anyone using a USB v4l device on an arm processor? While I haven't used a USB video device on an ARM board, I have tried cross compiling the v4l sources for ARM. Here's what I found: The v4l/Makefile.media uses the host strip binary on the ARM .ko files, which doesn't work. It could use $(CROSS_COMPILE)strip instead. I worked around the problem using a strip soft-link to arm-eabi-strip in my cross tools bin directory. The v4l/firmware/Makefile assumes /lib/firmware, this could be $(DESTDIR)/lib/firmware instead. Here are the make commands I used to build the v4l tree: PATH=/path/to/devkitARM/bin:$PATH make ARCH=arm CROSS_COMPILE=arm-eabi- SRCDIR=/path/to/arm/kernel-src PATH=/path/to/devkitARM/bin:$PATH make ARCH=arm CROSS_COMPILE=arm-eabi- DESTDIR=/path/to/arm/sysroot install I'd like to know if modules built this way work on actual hardware. Regards. -- Pete Eberlein Sensoray Co., Inc. Email: p...@sensoray.com http://www.sensoray.com Pete, I've been able to get the v4l tree to compile fine. I use the make release DIR= to set the kernel DIR then make with the normal ARCH= and CROSS_COMPILE=, and this seems to work correctly. Since I posted we've had some limited success getting v4l devices working with arm. The main problem now seems to be that the processor we're using (at91rm9200) doesn't have a high-speed USB host. I've been talking with some of the folks at sensoray (Danil Konstantin) about getting the 2251 or 2255 to work on our arm board. thanks, Paul -- 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: No subsystem id (and therefore no cx88_dvb loaded) after reboot
I experience similar problem with HVR4000 Lite cards that we have in the lab. The card can't tune after cold boot, but a reboot will fix the problem. I will check whether it has the similar invalid subsystem id problem. Grant Gardner wrote: I'm looking for some pointers on debugging a problem with my DVICO FusionHDTV Hybrid DVB-T card. The device was working perfectly prior to a reconfiguration of my machine, kernel upgrade etc... Now, on a cold start everything seems to start smoothly but I can't tune channels. Then, after a reboot the device is not detected due to invalid subsystem id. As below lspci reports no subsystem information at all. Comparing the lspci output seems to be around the Region 0: Memory at ee00 v de00, but I'm not sure what this means, and whether fixing the reboot problem will fix the channel tuning problem. Running mythbuntu 8.10 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux lspci -vvnn after cold start 00:0a.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at de00 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx8800 Kernel modules: cx8800 00:0a.1 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:8811] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1000ns min, 63750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at df00 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel modules: cx88-alsa 00:0a.2 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1500ns min, 22000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at e000 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 lspci -vvnn after warm reboot 00:0a.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx8800 Kernel modules: cx8800 -- 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: Problems with Hauppauge HVR 1600 and cx18 driver
Andy, thanks for writing back. Here's the info you asked for.. Well, no. It's more likely a system level issue. 1. Can you provide the output of $ cat /proc/interrupts CPU0 0:104 IO-APIC-edge timer 1: 2 IO-APIC-edge i8042 4: 8 IO-APIC-edge 7: 1 IO-APIC-edge parport0 8: 0 IO-APIC-edge rtc0 9: 0 IO-APIC-fasteoi acpi 12: 4 IO-APIC-edge i8042 14: 777839 IO-APIC-edge pata_amd 15: 0 IO-APIC-edge pata_amd 17: 760893 IO-APIC-fasteoi EMU10K1 18: 189462 IO-APIC-fasteoi cx18-0 19:5936140 IO-APIC-fasteoi nvidia 20: 19869131 IO-APIC-fasteoi eth0 21: 158197 IO-APIC-fasteoi sata_nv 22: 2 IO-APIC-fasteoi ehci_hcd:usb2 23:307 IO-APIC-fasteoi ohci_hcd:usb1 NMI: 0 Non-maskable interrupts LOC:6194711 Local timer interrupts RES: 0 Rescheduling interrupts CAL: 0 function call interrupts TLB: 0 TLB shootdowns TRM: 0 Thermal event interrupts THR: 0 Threshold APIC interrupts SPU: 0 Spurious interrupts ERR: 1 2. To turn on debugging to /var/log/messages and save some memory, as root, could you # service mythbackend stop(or otherwise kill the backend) # modprobe -r cx18 # modprobe cx18 debug=7 enc_ts_bufsize=32 enc_ts_bufs=64 \ enc_yuv_bufs=0 enc_idx_bufs=0 Please provide your /var/log/messages output to the list (or to me, if it is too big). I didn't test with mplayer, but I played some Live TV in MythTV and here is some debug output I got once I started watching. The video was still tearing and artifact-ing. Mar 17 20:54:19 codebeast kernel: [96935.942665] cx18-0: info: Start feed: pid = 0x1ffb index = 7 Mar 17 20:55:41 codebeast kernel: [97017.160151] cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 12 msecs for RPU acknowledgement Mar 17 20:55:56 codebeast kernel: [97032.184180] cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 12 msecs for RPU acknowledgement Mar 17 20:55:56 codebeast kernel: [97032.280670] cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 12 msecs for RPU acknowledgement Mar 17 20:56:12 codebeast kernel: [97048.676352] cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 12 msecs for RPU acknowledgement Mar 17 20:56:30 codebeast kernel: [97066.160835] cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 12 msecs for RPU acknowledgement Mar 17 20:56:31 codebeast kernel: [97067.260070] cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 12 msecs for RPU acknowledgement Mar 17 20:57:17 codebeast kernel: [97113.900127] cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 12 msecs for RPU acknowledgement Mar 17 20:57:23 codebeast kernel: [97119.308397] cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 12 msecs for RPU acknowledgement Mar 17 20:57:48 codebeast kernel: [97144.551274] cx18-0: info: Stop feed: pid = 0x0 index = 0 Do I need a new motherboard? This board only has 2 PCI slots. The other one is populated with an SB Live 5.1 sound card. Should I try removing the sound card and put the TV card in its place? I can always use the on-board sound if the SB Live card is causing some sort of conflict or IRQ contention. What about tweaking my BIOS settings. Would messing with IRQ or HyperTransport settings make a difference? Does my motherboard not have the bandwidth to keep up with this card? Thanks again! -- 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: Improve DKMS build of v4l-dvb?
Op dinsdag 17-03-2009 om 12:50 uur [tijdzone -0700], schreef Trent Piepho: On Tue, 17 Mar 2009, Alain Kalker wrote: Op vrijdag 13-03-2009 om 02:12 uur [tijdzone -0700], schreef Trent Piepho: On Mon, 9 Mar 2009, Alain Kalker wrote: Firstly: generating a .config with just one config variable for the requested driver set to 'm' merged with the config for the kernel being built for, and then doing a make silentoldconfig. Big disatvantage is that full kernel source is required for the 'silentoldconfig' target to be available. Does that actually work? Figuring out that needs to be turned on to enable some config options is a hard problem. It's not just simple dependencies between modules, but complex expressions that need to be satisfied. E.g., something depends on A || B, which do you turn on, A or B? There are multiple solutions so how does the code decide which is best? Well, make_kconfig.pl does quite a nice job trying to select as many drivers without causing conflicts. What I did in make_kconfig.pl was just turn everything on, then recursively disable anything that has a failed dependency. There isn't any intelligence when it comes to choices where you can have driver set A or driver set B, but not both. Options that we want disabled, like some drivers' advanced debug controls, must be explicitly disabled in make_kconfig. Still, it ends up doing what we want in the end, which is to compile all the drivers that we can compile. Anyway, you're quite right about this being a hard problem, and the fact that the Kconfig system wasn't designed to be very helpful in auto-selecting dependencies and resolving conflicts the same way modern package managers are, doesn't make it any easier. From what I can tell, solving the dependency problem is easily shown to be the same as the classical satisfiability problem, which is proven to be NP complete. Now, there are heuristics that can usually solve SAT problems quicker but finding the best solution quickly is quite a bit harder. Yet, most of us are quite content with the solutions which the dependency resolvers in package managers offer, even if they're possibly non-optimal. Package maintainers try very hard to find ways to ease the dependency problem by supplying acceptable defaults. And like I said before, when no unique solution can be found, the user should have the final say on which solution should be applied. Back to the problem of DKMS builds, I'm not looking for a perfect solution for a single driver (neither does make_kconfig.pl look for a perfect solution for all drivers at once :-) ), I'm looking for a way to reduces the total number of modules that have to be rebuilt when the v4l-dvb source or the kernel is upgraded. How about disabling all modules which don't affect the dependencies of the target driver? Attacking the problem from the other side, so to speak. Even when unneccessary modules are still left enabled in the .config, this is still better than building everything but the kitchen sink, which is what the current DKMS script does (it simply does a make all). You don't need write access to the kernel source. The kernel's config programs have to be built, but that can be done ahead of time. Once they are, then you can use that menu tool from v4l-dvb without write access to the kernel source. There is support for an alternate output directory for the kernel that can work too. In the kernel dir, run make O=~/kernel-output-dir menuconfig. That should not require write access to the kernel source dir and will put the necessary config programs in ~/kernel-output-dir. Then point v4l-dvb at the kernel output dir, with make release DIR=~/kernel-output-dir. See the explanation from my changeset that added this, http://linuxtv.org/hg/v4l-dvb/log/6331 Good thing I wrote this 17 months ago when I did the work, instead of just using some two word patch description, since I sure wouldn't remember how all that works today. Thanks for the info, I will try this. Kind regards, Alain -- 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
SNR status for demods
Hello all, I have updated my compiled list of the various demods and how they currently report SNR info (including feedback from people in the last round). http://www.devinheitmueller.com/snr.txt Here's how you can help out: If you are a maintainer for a device in this list, please let me know so I can update the document. If you are the maintainer and somebody else's name is listed by the device, please do not take offense to this (it's probably just an error on my part [please email and correct me]). If you have specs for a device in this list where the format is currently unknown, please let me know as this will be helpful in identifying which demods we can get accurate information for. If you know something about how SNR is currently reported by the driver, and it is not reflected in this list, please let me know and I will update the document. All of the above information will be helpful once a format has been decided on, so we can pull together and finally get a consistent interface. Thank you for your time, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SNR status for demods
Thank you very much, Devin Heitmueller. This list is a god-sent :). Devin Heitmueller wrote: Hello all, I have updated my compiled list of the various demods and how they currently report SNR info (including feedback from people in the last round). http://www.devinheitmueller.com/snr.txt Here's how you can help out: If you are a maintainer for a device in this list, please let me know so I can update the document. If you are the maintainer and somebody else's name is listed by the device, please do not take offense to this (it's probably just an error on my part [please email and correct me]). If you have specs for a device in this list where the format is currently unknown, please let me know as this will be helpful in identifying which demods we can get accurate information for. If you know something about how SNR is currently reported by the driver, and it is not reflected in this list, please let me know and I will update the document. All of the above information will be helpful once a format has been decided on, so we can pull together and finally get a consistent interface. Thank you for your time, Devin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
