Re: help: Can't get DViCO FusionHDTV DVB-T Dual Digital 4 to work with new kernels
2.6.27 worked for me - exact same board (ignoring revisions - mine is an older board, rev.1, I think) 2.6.28 and up failed for me in exactly this manner. Same with a head-of-tree v4l-dvb 'hg clone' AFAICT it's a v4l-dvb driver problem - at least no-one here refutes it since I reported it here on 20090615. Cheers Bob On Wed, 19 Aug 2009 12:09:24 +0800 treblid treb...@gmail.com wrote: Been grappling with this problem for a while now.. I am using stock linux kernel 2.6.28.9 together with Mythtv (SVN trunk) For some reason I cannot use 2.6.29.x or 2.6.30.x (latest version I tried is 2.6.30.5). Everytime i start mythbackend, the console is littered with the following messages, and the keyboard input freezes sporadically. the messages as below: dvb-usb: recv bulk message failed: -110 cxusb: i2c read failed i googled for a solution and it seems some got around this by inserted the IR receiver, I tried but it still doesn't work. is this a mythtv problem or cxusb issue? Please help, any pointers appreciated. regards, -- 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 -- Bob Hepple bhep...@promptu.com ph: 07-5584-5908 Fx: 07-5575-9550 -- 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] Anysee E30 C Plus + MPEG-4?
Pásztor Szilárd: With scan -vv I could find the video PIDs for the HD channels and indeed they were missing in my channels.conf (values were 0) as scan detected them as OTHER, but with a type 0x1b addition with which I don't know what to do for the time being... Stream type 0x1B precisely means AVC / H.264 video stream (cf. ISO 138181-1:2000/FDAM 3) Try VLC instead of mplayer. VLC does render H.264 HD video, provided you have a (very) good CPU. -Thierry -- 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] Anysee E30 C Plus + MPEG-4?
Thierry Lelegard: Stream type 0x1B precisely means AVC / H.264 video stream (cf. ISO 138181-1:2000/FDAM 3) Try VLC instead of mplayer. VLC does render H.264 HD video, provided you have a (very) good CPU. Thanks for the info. Anyway, mplayer also does render H.264 of course, it's the stream that's not very cleverly muxed, it seems. And with mplayer I have vdpau acceleration on my nvidia card that can render 1920x1...@50 fps in real time. s. - | After all is said and done, a hell of a lot more is said than done. | - -- 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] Anysee E30 C Plus + MPEG-4?
On 08/19/2009 10:42 AM, Pásztor Szilárd wrote: Thierry Lelegard: Stream type 0x1B precisely means AVC / H.264 video stream (cf. ISO 138181-1:2000/FDAM 3) Try VLC instead of mplayer. VLC does render H.264 HD video, provided you have a (very) good CPU. Thanks for the info. Anyway, mplayer also does render H.264 of course, it's the stream that's not very cleverly muxed, it seems. And with mplayer I have vdpau acceleration on my nvidia card that can render 1920x1...@50 fps in real time. Actually I met just similar case some months ago (I have also Anysee E30C and fi-3ktv cable). Only audio no video. HD-video PIDs were missing. I zapped to the channel and looked correct PIDs from dvbtraffic traffic output and added those to the channels.conf. Mplayer and Totem still resists to show video, but VLC does! After that I looked transmission parameters by using dvbsnoop and there was H.262 (MPEG2) set those H.264 (MPEG4-AVC) channels. I think that was reason for my problems. 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
USB Wintv HVR-900 Hauppauge
Hello, I am trying to set up the dvb-t device in my ubuntu 9.04. As far as i can see , this device has tm6000 chipset but I don't get it works. I have followed the guide of tvlinux.org: http://www.linuxtv.org/wiki/index.php/Trident_TM6000#TM6000_based_Devices I have compile v4l-dvb, make, and make install and it seems that the modules are loaded: em28xx 90668 0 ir_common 57732 1 em28xx v4l2_common25600 1 em28xx videobuf_vmalloc 14724 1 em28xx videobuf_core 26244 2 em28xx,videobuf_vmalloc tveeprom 20228 1 em28xx videodev 44832 3 em28xx,v4l2_common,uvcvideo But by the moment, I don't know which driver I should you. Actually, when I switch the usb wintv on , my so doesn't recognize it: [11107.449900] usb 1-3: new high speed USB device using ehci_hcd and address 8 [11107.593094] usb 1-3: configuration #1 chosen from 1 choice how can I get this device run? thank you in advance. Miguel -- 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: [Q] sensors, corrupting the top line
On Mon, Aug 17, 2009 at 7:09 PM, Guennadi Liakhovetskig.liakhovet...@gmx.de wrote: Hi Hans, all In soc-camera since its first version we have a parameter y_skip_top, which the sensor uses to tell the host (bridge) driver I am sending you that many lines more than what is requested, and you should drop those lines from the top of the image. I never investigated this in detail, originally this was a strong tip that the top line is always corrupted. Now I did investigate it a bit by setting this parameter to 0 and looking what the sensors actually produce. I am working with four sensor: mt9m001, mt9v022, mt9t031 and ov7725, of which only the first two had that parameter set to 1 from the beginning, the others didn't have it and also showed no signs of a problem. mt9m001 (monochrome) doesn't have the problem either, but mt9v022 does. It does indeed deliver the first line with randomly coloured pixels. Notice - this is not the top line of the sensor, this is the first read-out line, independent of the cropping position. So, it seems we do indeed need a way to handle such sensors. Do you have a suggestion for a meaningful v4l2-subdev API for this? Yep I also went through similar cases and I just skipped corrupted lines. That happens in various sensor devices isn't it? Moreover, we sometimes have whole corrupted image frames which are due to stabilization issue when we initialize the sensor device. In this case I decide to drop corresponding image frames with enough number.(3 frames enough in my experience). So, how about making an API which can cover all over these phonomenum? which can drop or skip line and frames. Host (bridge) queries through the API and get how many lines should skip or how many frames should drop or something like that.. Sounds fair to make an API which can cover general H/W defects or characteristics (even though that is not a defect) Cheers, Nate -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Wintv HVR-900 Hauppauge
On Wed, Aug 19, 2009 at 7:01 AM, Miguelm...@moviquity.com wrote: Hello, I am trying to set up the dvb-t device in my ubuntu 9.04. As far as i can see , this device has tm6000 chipset but I don't get it works. I have followed the guide of tvlinux.org: http://www.linuxtv.org/wiki/index.php/Trident_TM6000#TM6000_based_Devices I have compile v4l-dvb, make, and make install and it seems that the modules are loaded: em28xx 90668 0 ir_common 57732 1 em28xx v4l2_common 25600 1 em28xx videobuf_vmalloc 14724 1 em28xx videobuf_core 26244 2 em28xx,videobuf_vmalloc tveeprom 20228 1 em28xx videodev 44832 3 em28xx,v4l2_common,uvcvideo But by the moment, I don't know which driver I should you. Actually, when I switch the usb wintv on , my so doesn't recognize it: [11107.449900] usb 1-3: new high speed USB device using ehci_hcd and address 8 [11107.593094] usb 1-3: configuration #1 chosen from 1 choice how can I get this device run? thank you in advance. Miguel Hello Miguel, Can you confirm the exact model number of the device (or provide the USB ID)? I suspect you probably have what is often referred to as an HVR-900 R2, which is not currently supported under Linux. I've got it working here but still need to write the firmware extract script so I can release it, but the work has been delayed due to other priorities. 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: Hauppauge 2250 - second tuner is only half working
I'd really appreciate any help or guidance on this problem as i'm fully perplexed by it. Hey Seth, I ran the same tests on my cable system (channel 103) on 669Mhz and had no issue, and my snr's reported as (0x172 and 0x17c). One possibility is that you're overwhelming the frontend. Try adding a small mount of attenuation to the signal for test purposes. Hard to believe but this is where I'd start looking. -- Steven Toth - Kernel Labs http://www.kernellabs.com Thank you for reply! Hearing that the same frequency works on another card is pretty positive confirmation in my mind that this is a hardware/setup issue. I tried stopping by a local radio shack last night, but wouldn't you know they no longer carried simple attenuators. Looks like i'll be picking one up online (or maybe ill lookup a schematic online and try building a simple one). On a side note - Thank you very much for hacking on the saa7164 - other than this frequency glitch its been working great for me! -- 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
V4L-DVB issue in systems with 4Gb RAM?
Hi, we are experiencing a problem with the V4L-DVB drivers. It seems that when the system has over 4Gb the drivers do no longer work properly. Either nothing or rubbish comes out of them, although tuning using szap seems to work. If we force the system to use only 4Gb by appending mem=4GB as a kernel parameter things are working like a charm. Our setup: Dell 2850 server with a Magma PCI extender. There are 6 DVB boards in the machine: 5 KNC TV STAR DVB-S and 1 Hauppauge Nova-S-Plus DVB-S. The system has 8GB of RAM and runs an up-to-date Centos5.3, kernel 2.6.18-128.4.1.el5 x86_64. The V4L-DVB driver we are using is v4l-dvb-2009.08.18.tar.bz2 On this setup some of the KNC boards are working, the Hauppauge does not. In a similar setup where we have only KNCs none of them is working unless you force the system to use 4Gb of the available memory. I would like to know if this is a known issue and if so what can be done to fix/work around the problem. Any help/suggestion/hint is highly welcome. Thanks in advance! Kind regards, Helmut -- 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
Problem with Hauppauge Nova-500
Hi there, I have a Hauppauge Nova-T 500 that is displaying some odd behaviour. Often the device fails to tune after rebooting the host machine, due to a failure to load firmware. when the firmware fails to load, dmesg shows: dib0700: loaded with support for 9 different device-types dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' dib0700: firmware download failed at 7 with -22 usbcore: registered new interface driver dvb_usb_dib0700 When firmware loading is successful I see: dib0700: loaded with support for 9 different device-types dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering adapter 1 frontend 0 (DiBcom 3000MC/P)... MT2060: successfully identified (IF1 = 1242) dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering adapter 2 frontend 0 (DiBcom 3000MC/P)... MT2060: successfully identified (IF1 = 1233) input: IR-receiver inside an USB DVB receiver as /class/input/input7 dvb-usb: schedule remote query interval to 50 msecs. dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected. usbcore: registered new interface driver dvb_usb_dib0700 Powering down the host machine seems to help as, so far, I have 100% success when restarting this way, whereas after reboot the success is much lower, firmware failing to load maybe 50% of the time. Has anyone seen this behaviour before, any advice on what the cause might be? Many thanks, Lou -- 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: Problem with Hauppauge Nova-500
On Wed, Aug 19, 2009 at 12:19 PM, Lou Otwaylot...@nildram.co.uk wrote: Hi there, I have a Hauppauge Nova-T 500 that is displaying some odd behaviour. Often the device fails to tune after rebooting the host machine, due to a failure to load firmware. when the firmware fails to load, dmesg shows: dib0700: loaded with support for 9 different device-types dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' dib0700: firmware download failed at 7 with -22 usbcore: registered new interface driver dvb_usb_dib0700 When firmware loading is successful I see: dib0700: loaded with support for 9 different device-types dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering adapter 1 frontend 0 (DiBcom 3000MC/P)... MT2060: successfully identified (IF1 = 1242) dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering adapter 2 frontend 0 (DiBcom 3000MC/P)... MT2060: successfully identified (IF1 = 1233) input: IR-receiver inside an USB DVB receiver as /class/input/input7 dvb-usb: schedule remote query interval to 50 msecs. dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected. usbcore: registered new interface driver dvb_usb_dib0700 Powering down the host machine seems to help as, so far, I have 100% success when restarting this way, whereas after reboot the success is much lower, firmware failing to load maybe 50% of the time. Has anyone seen this behaviour before, any advice on what the cause might be? Many thanks, Lou Hello Lou, Yes, this is a known issue with the Nova-T 500 that others have reported. We believe it has something to do with the onboard Via USB host controller on the board. A user mailed me a card and it is out being repaired, but hopefully when it comes back I will be able to track down the problem. 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: DM6467 VPIF adding support for HD resolution capture and display standards
Hans,
You have done a great job in putting up a quick proposal. I was just trying to
understand the intentions/rational behind your proposal to be on the same page.
Thanks for the education. I think this will help others as well.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
Snip
Shouldn't this be in fractional form? how do we represent 74.25 MHz?
We represent that as 7425 :-) The unit is in Hz.
A more interesting question is if we should make this a u64 to be prepared
for frequencies 4GHz. Or am I paranoid?
The highest pixel clock that I have seen for DaVinci platforms is 128MHz. So I
believe it will be a while before someone use 4GHz :)
Snip
__u32 width, height;
__u32 polarities;
Is it a bit mask of polarities such as vsync, hsync etc?
Yes.
Then we would need to define POLARITIES as bit mask for user space usage.
like
#define V4L2_DV_VSYNC_POL 0x1
#define V4L2_DV_HSYNC_POL 0x2
and so forth?
Snip
/* timings for bottom frame for interlaced formats */
__u32 il_hfrontporch, il_hsync, il_htotal;
__u32 il_vfrontporch, il_vsync, il_vtotal;
Looking at a typical vesa timing values, I don't see them defined
separately for top and bottom fields. Is it for BT1120/BT656 and camera
capture timing?
Front porch, sync length and htotal can be removed, but I think il_vtotal
can
be different from vtotal by one line so we should keep that one.
I think it is safer to keep them and mark them as experimental?.
enum dv_timings_type {
V4L2_DV_BT_656_1120,
Why combine BT656 and BT1120? They have different set of timing values.
Also if custom timing to be allowed, shouldn't there be a type
V4L2_CUSTOM_TIMING as one of the type. So only then bt_timings values
will be used.
No. BT656 and BT1120 define how bitstreams for video are formatted. There
is
very little difference between the two. I would have to do research as to
what
exactly the differences are, but based on my experience so far I think
there
is no need to separate them.
Also note that both use the same timing parameters, so the custom settings
are
actually following the bt656/1120 timings.
What I see from the VPIF hardware spec is that they use different values for
first line of top/bottom field, first line of active video, last line of active
video and so forth. That means timing parameters are different, right?
Snip
};
VPIF supports SMPTE 296 mode in which different timing values are used
than BT1120. So I see V4L2_DV_SMPTE_296 as well to begin with.
Someone needs to put these standards next to one another and research what
the differences are and whether those differences are enough to require
adding a new type. Do you have access to those standards and can you go
through them and see what the differences are exactly and whether those
require adding a special type + associated timings struct?
I don't have access to the specs. But VPIF hardware manual says hardware use
different values for first line of top/bottom field, first line of active
video, last line of active video and so forth. i.e they are different for
BT656, BT1120, SMPTE 296.
struct dv_timings {
enum dv_timings_type type;
union {
struct bt_timings bt;
__u32 reserved[32];
};
};
and ioctls:
VIDIOC_S/G_DV_PRESET, VIDIOC_ENUM_DV_PRESETS and VIDIOC_S/G_DV_TIMINGS.
I don't think we need to have ioctls to determine what custom timings
are possible: if you are going to use that, then we can safely assume
that
you know what you are doing.
There are some details to hammer out: what does G_DV_TIMINGS return if
e.g.
the 720P60 preset is active? Does it return the timings for 720P60 or
the
last
set custom timings?
Why last set custom timing? If preset is used, then it should return
preset timing which mostly will be standard timing values as defined in the
respective standard, right?
My reasoning was that returning the preset timings would require that a
driver
will need to know those timings. For some hardware a programmer can just
write
a single 'standards' register and the hardware will do its own timings
lookup.
So in those cases a driver would need to keep a timings table around just
for
this API.
Make sense.
It is also slightly cleaner since if a driver only supports presets, then
there
is no need for the DV_TIMINGS ioctls.
Agree.
Remember, this is just an initial API proposal that's quickly put together.
For one thing, for the presets we really want to put that in a struct:
struct v4l2_dv_preset {
__u32 preset;
__u32 reserved[4];
};
And instead of an enum I would use a list of #defines for the preset IDs.
Using enum makes compat32 conversion harder (I believe they have different
sizes under 32 vs 64 bits).
The enum struct would be:
struct v4l2_dv_enum_preset {
__u32 preset;
char name[32];
__u32 reserved[4];
};
Ok.
Where 'name' is the name of
[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:Wed Aug 19 19:00:02 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12458:3f7e382dfae5 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-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-rc5-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-rc5-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc5-i686: OK linux-2.6.23.12-m32r: ERRORS 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-rc5-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc5-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc5-powerpc64: OK linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc5-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc5): 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: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS 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: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: DM6467 VPIF adding support for HD resolution capture and display standards
On Wednesday 19 August 2009 19:44:24 Karicheri, Muralidharan wrote:
Hans,
You have done a great job in putting up a quick proposal. I was just trying
to understand the intentions/rational behind your proposal to be on the same
page. Thanks for the education. I think this will help others as well.
You're welcome :-)
It's not complete though. Other things to consider are:
1) How to detect what format is received on e.g. an HDMI or DVI-A/D receiver?
I think we need a VIDIOC_QUERY_DV_PRESET. Either this returns the actual
preset, or it returns V4L2_DV_CUSTOM and you have to call
VIDIOC_QUERY_DV_TIMINGS to get the full timings, or it returns something like
V4L2_DV_NO_SIGNAL (no input signal) or V4L2_DV_UNKNOWN.
When querying the timings we have to realize that not all fields may be filled
in. E.g. when receiving an HDMI or DVI-D signal quite often you can only get
hold of the width and height of the image and some framerate information.
Timings like front porch etc. may no be possible to obtain.
2) How to specify timings when using embedded syncs? We probably have to add
a flag to toggle between embedded (SAV/EAV codes) or separate syncs (actually,
it is possible to do both at the same time). For the timings we can just set
the sync length and porch length to 0 since those are no longer relevant for
embedded syncs.
3) What is the relationship (if any) between these new ioctls and the old
G/S/QUERY/ENUM_STD and the ENUM_FRAMESIZES/FRAMEINTERVALS ioctls? To prevent
terminal confusion this should be made very clear in the v4l2 spec.
snip
__u32 width, height;
__u32 polarities;
Is it a bit mask of polarities such as vsync, hsync etc?
Yes.
Then we would need to define POLARITIES as bit mask for user space usage.
like
#define V4L2_DV_VSYNC_POL 0x1
#define V4L2_DV_HSYNC_POL 0x2
and so forth?
Yes.
snip
/* timings for bottom frame for interlaced formats */
__u32 il_hfrontporch, il_hsync, il_htotal;
__u32 il_vfrontporch, il_vsync, il_vtotal;
Looking at a typical vesa timing values, I don't see them defined
separately for top and bottom fields. Is it for BT1120/BT656 and camera
capture timing?
Front porch, sync length and htotal can be removed, but I think il_vtotal
can
be different from vtotal by one line so we should keep that one.
I think it is safer to keep them and mark them as experimental?.
No, they definitely can be removed. I wasn't thinking when I added them.
It's only the il_vtotal that we need to keep.
enum dv_timings_type {
V4L2_DV_BT_656_1120,
Why combine BT656 and BT1120? They have different set of timing values.
Also if custom timing to be allowed, shouldn't there be a type
V4L2_CUSTOM_TIMING as one of the type. So only then bt_timings values
will be used.
No. BT656 and BT1120 define how bitstreams for video are formatted. There
is
very little difference between the two. I would have to do research as to
what
exactly the differences are, but based on my experience so far I think
there
is no need to separate them.
Also note that both use the same timing parameters, so the custom settings
are
actually following the bt656/1120 timings.
What I see from the VPIF hardware spec is that they use different values for
first line of top/bottom field, first line of active video, last line of
active video and so forth. That means timing parameters are different, right?
But these parameters can all be defined in terms of the timings parameters.
The question is: are there differences in the generated signal that are not
covered by the timing parameters. One thing that springs to mind is how the
sync signal is formed. I remember reading about two or three level syncs. We
may well need to either specify the sync format or let it depend on the timings
type. Note that you can also have syncs embedded in the data stream (not to
be confused with the SAV/EAV codes). This is used for component inputs/outputs
where a sync signal is carried in the Y data signal.
However, I think we have to be careful not to attempt to do too much here.
A certain amount of intelligence can be expected from a driver.
Snip
};
VPIF supports SMPTE 296 mode in which different timing values are used
than BT1120. So I see V4L2_DV_SMPTE_296 as well to begin with.
Someone needs to put these standards next to one another and research what
the differences are and whether those differences are enough to require
adding a new type. Do you have access to those standards and can you go
through them and see what the differences are exactly and whether those
require adding a special type + associated timings struct?
I don't have access to the specs. But VPIF hardware manual says hardware use
different values for first line of top/bottom field, first line of active
video, last line of active video and so forth. i.e they are different for
BT656, BT1120, SMPTE 296.
But all those values are programmable through the
[PATCH] cx23885: fix support for TBS 6920 card
fix: GPIO initialization for TBS 6920
fix: wrong I2C address for demod on TBS 6920
fix: wrong I2C bus number for demod on TBS 6920
fix: wrong gen_ctrl_val value for TS1 port on TBS 6920 (and some other cards)
add: module_param lnb_pwr_ctrl as option to choose between type 0 and type
1 of LNB power control (two TBS 6920 boards no matter that they are marked as
the same hardware revision may have different types of LNB power control)
fix: LNB power control function for type 0 doesn't preserve the previous GPIO
state, which is critical
add: LNB power control function for type 1
Signed-off-by: Bob Liu b...@turbosight.com
Signed-off-by: Konstantin Dimitrov kosio.dimit...@gmail.com
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-08-19
14:11:49.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-08-19
14:30:10.0 +0300
@@ -704,7 +704,14 @@ void cx23885_gpio_setup(struct cx23885_d
case CX23885_BOARD_TEVII_S470:
cx_write(MC417_CTL, 0x0036);
cx_write(MC417_OEN, 0x1000);
- cx_write(MC417_RWD, 0x1800);
+
+ cx_set(MC417_RWD, 0x0002);
+ mdelay(200);
+
+ cx_clear(MC417_RWD, 0x0800);
+ mdelay(200);
+ cx_set(MC417_RWD, 0x0800);
+ mdelay(200);
break;
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
/* GPIO-0 INTA from CiMax1
@@ -880,7 +887,7 @@ void cx23885_card_setup(struct cx23885_d
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_TBS_6920:
case CX23885_BOARD_DVBWORLD_2005:
- ts1-gen_ctrl_val = 0x5; /* Parallel */
+ ts1-gen_ctrl_val = 0x4; /* Parallel */
ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c 2009-08-19
14:11:49.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c 2009-08-19
15:25:57.0 +0300
@@ -55,6 +55,7 @@
#include netup-eeprom.h
#include netup-init.h
#include lgdt3305.h
+#include tbs_lnb_pwr.h
static unsigned int debug;
@@ -71,6 +72,10 @@ MODULE_PARM_DESC(alt_tuner, Enable alte
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+static unsigned int lnb_pwr_ctrl;
+module_param(lnb_pwr_ctrl, int, 0644);
+MODULE_PARM_DESC(lnb_pwr_ctrl,set LNB power control 0=default type, 1=another
type);
+
/* -- */
static int dvb_buf_setup(struct videobuf_queue *q,
@@ -419,22 +424,31 @@ static struct stv6110_config netup_stv61
.clk_div = 1,
};
-static int tbs_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
+static int tbs6920_set_voltage(struct dvb_frontend *fe,
+ fe_sec_voltage_t voltage)
{
struct cx23885_tsport *port = fe-dvb-priv;
struct cx23885_dev *dev = port-dev;
- if (voltage == SEC_VOLTAGE_18)
- cx_write(MC417_RWD, 0x1e00);/* GPIO-13 high */
- else if (voltage == SEC_VOLTAGE_13)
- cx_write(MC417_RWD, 0x1a00);/* GPIO-13 low */
- else
- cx_write(MC417_RWD, 0x1800);/* GPIO-12 low */
+ switch (voltage) {
+ case SEC_VOLTAGE_13:
+ cx_set(MC417_RWD, 0x0200);
+ cx_clear(MC417_RWD, 0x0400);
+ break;
+ case SEC_VOLTAGE_18:
+ cx_set(MC417_RWD, 0x0200);
+ cx_set(MC417_RWD, 0x0400);
+ break;
+ case SEC_VOLTAGE_OFF:
+ cx_clear(MC417_RWD, 0x0200);
+ break;
+ }
+
return 0;
}
static struct cx24116_config tbs_cx24116_config = {
- .demod_address = 0x05,
+ .demod_address = 0x55,
};
static struct cx24116_config tevii_cx24116_config = {
@@ -768,14 +782,18 @@ static int dvb_register(struct cx23885_t
}
break;
case CX23885_BOARD_TBS_6920:
- i2c_bus = dev-i2c_bus[0];
+ i2c_bus = dev-i2c_bus[1];
fe0-dvb.frontend = dvb_attach(cx24116_attach,
tbs_cx24116_config,
i2c_bus-i2c_adap);
- if (fe0-dvb.frontend != NULL)
- fe0-dvb.frontend-ops.set_voltage = tbs_set_voltage;
-
+ if (fe0-dvb.frontend != NULL) {
+ if (!lnb_pwr_ctrl)
+ fe0-dvb.frontend-ops.set_voltage =
tbs6920_set_voltage;
+ else
+ fe0-dvb.frontend-ops.set_voltage =
tbs_set_voltage;
+ }
+
break;
case CX23885_BOARD_TEVII_S470:
i2c_bus = dev-i2c_bus[1];
@@ -784,7 +802,7 @@ static int dvb_register(struct cx23885_t
Re: USB Wintv HVR-900 Hauppauge
On Wed, Aug 19, 2009 at 5:35 PM, Stefano De Dionigidedio...@gmail.com wrote: Hello Devin, I own a HVR-900 R2 and if you need help in testing i'd be more than happy to help. It's nice to see that for this device could there finally be light at the end of the tunnel. Hello Dedioste, Fortunately, in this case I have the device pretty well tested using the generator. I just have to get the firmware extract script written so that the changes can actually be released. Keep an eye on the Kernellabs blog (http://www.kernellabs.com/blog), since when I have a tree setup I will likely put out a call for testers before the changes go upstream into the v4l-dvb mainline. 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: USB Wintv HVR-900 Hauppauge
On Wed, Aug 19, 2009 at 3:42 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Wed, Aug 19, 2009 at 7:01 AM, Miguelm...@moviquity.com wrote: Hello, I am trying to set up the dvb-t device in my ubuntu 9.04. As far as i can see , this device has tm6000 chipset but I don't get it works. I have followed the guide of tvlinux.org: http://www.linuxtv.org/wiki/index.php/Trident_TM6000#TM6000_based_Devices how can I get this device run? thank you in advance. Miguel Hello Miguel, Can you confirm the exact model number of the device (or provide the USB ID)? I suspect you probably have what is often referred to as an HVR-900 R2, which is not currently supported under Linux. I've got it working here but still need to write the firmware extract script so I can release it, but the work has been delayed due to other priorities. Hello Devin, I own a HVR-900 R2 and if you need help in testing i'd be more than happy to help. It's nice to see that for this device could there finally be light at the end of the tunnel. -- Thank you, regards, dedioste -- 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
Terratec Cinergy C HD tuning problems
Hello, I'm having some problems with my Terratec Cinergy C PCI DVB-C card. I installed the mantis driver via DKMS, following the instructions at http://www.linuxtv.org/wiki/index.php/Mantis_with_DKMS The card is recognized, and it even works, but after a while (typically 5 to 20 minutes) the card no longer tunes to any channels and the scan command no longer works. If I modprobe -r and modprobe -i the mantis module everything works again for a while, until the same thing happens. So I assume this is something driver related? Any help would be appreciated, I will be happy to provide any additional information if needed. Some information that may or may not be useful: uname -a : Linux ss-home-server 2.6.28-14-server #47-Ubuntu SMP Sat Jul 25 02:03:55 UTC 2009 x86_64 GNU/Linux lsmod | grep mantis : mantis 53892 4 lnbp21 11008 1 mantis mb86a1630464 1 mantis stb610016388 1 mantis tda10021 15364 1 mantis tda10023 15748 1 mantis ir_common 65924 1 mantis stb089945060 1 mantis stv029919720 1 mantis dvb_core 111792 2 mantis,stv0299 dmesg (after reloading mantis module): [50413.810181] mantis_core_exit (0): DMA engine stopping [50413.810185] mantis_dma_exit (0): DMA=0x3794 cpu=0x88003794 size=65536 [50413.810191] mantis_dma_exit (0): RISC=0x37953000 cpu=0x880037953000 size=1000 [50413.810195] mantis_hif_exit (0): Adapter(0) Exiting Mantis Host Interface [50413.810200] mantis_ca_exit (0): Unregistering EN50221 device [50413.810712] mantis_pci_remove (0): Removing --Mantis irq: 21, latency: 32 [50413.810714] memory: 0xd080, mmio: 0xc200101ce000 [50413.810729] Mantis :02:00.0: PCI INT A disabled [50414.116512] Mantis :02:00.0: PCI INT A - GSI 21 (level, low) - IRQ 21 [50414.117498] irq: 21, latency: 32 [50414.117499] memory: 0xd080, mmio: 0xc200104fe000 [50414.117502] found a VP-2040 PCI DVB-C device on (02:00.0), [50414.117504] Mantis Rev 1 [153b:1178], irq: 21, latency: 32 [50414.117507] memory: 0xd080, mmio: 0xc200104fe000 [50414.120219] MAC Address=[00:08:ca:1e:10:7a] [50414.120238] mantis_alloc_buffers (0): DMA=0x3794 cpu=0x88003794 size=65536 [50414.120245] mantis_alloc_buffers (0): RISC=0xb58a4000 cpu=0x8800b58a4000 size=1000 [50414.120248] DVB: registering new adapter (Mantis dvb adapter) [50414.670213] mantis_frontend_init (0): Probing for CU1216 (DVB-C) [50414.673722] TDA10023: i2c-addr = 0x0c, id = 0x7d [50414.673724] mantis_frontend_init (0): found Philips CU1216 DVB-C frontend (TDA10023) @ 0x0c [50414.673727] mantis_frontend_init (0): Mantis DVB-C Philips CU1216 frontend attach success [50414.673731] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... [50414.673789] mantis_ca_init (0): Registering EN50221 device [50414.673865] mantis_ca_init (0): Registered EN50221 device [50414.673874] mantis_hif_init (0): Adapter(0) Initializing Mantis Host Interface [50414.673934] input: Mantis VP-2040 IR Receiver as /devices/virtual/input/input11 [50414.840123] Mantis VP-2040 IR Receiver: unknown key: key=0x00 raw=0x00 down=1 [50414.940104] Mantis VP-2040 IR Receiver: unknown key: key=0x00 raw=0x00 down=0 /var/log/syslog (when tuning stops working): kernel: [55125.206428] mantis start feed dma kernel: [55125.206633] mantis stop feed and dma kernel: [55125.206641] mantis start feed dma kernel: [55125.206719] mantis stop feed and dma kernel: [55125.206736] mantis start feed dma vdr: [16282] frontend 0 lost lock on channel 80, tp 162 vdr: [16282] frontend 0 timed out while tuning to channel 80, tp 162 kernel: [55141.275154] mantis stop feed and dma vdr: [16282] frontend 0 timed out while tuning to channel 70, tp 234 kernel: [55168.360122] mantis_ack_wait (0): Slave RACK Fail ! vdr: [16282] frontend 0 timed out while tuning to channel 84, tp 242 vdr: [16282] frontend 0 timed out while tuning to channel 90, tp 250 kernel: [55202.040188] mantis_ack_wait (0): Slave RACK Fail ! Regards, Daniel Sjöblom PS. The repository I checked out from http://mercurial.intuxication.org/hg/s2-liplianin was (and still is) broken. A bad merge in v4l/Kconfig, lines 3164-3168. -- 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-next: suspend tree build warnings
On Wednesday 19 August 2009, Stephen Rothwell wrote: Hi Rafael, Hi, Today's linux-next build (x86_64 allmodconfig) produced these warnings: drivers/media/dvb/frontends/dib7000p.c: In function ‘dib7000p_i2c_enumeration’: drivers/media/dvb/frontends/dib7000p.c:1315: warning: the frame size of 2256 bytes is larger than 2048 bytes drivers/media/dvb/frontends/dib3000mc.c: In function ‘dib3000mc_i2c_enumeration’: drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2160 bytes is larger than 2048 bytes Introduced by commit 99307958cc9c1b0b2e0dad4bbefdafaf9ac5a681 (PM: Introduce core framework for run-time PM of I/O devices (rev. 17)). Well. This commit increases the size of struct device quite a bit and both of the drivers above create a state object on the stack that contains struct device among other things. I think they should allocate these objects using kmalloc() and I don't know what I can do about this, really. Maybe except for modifying the drivers to use kmalloc(). Thanks, Rafael -- 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: Hauppauge 2250 - second tuner is only half working
On Wed, 2009-08-19 at 07:12 -0700, s...@cyberseth.com wrote: I'd really appreciate any help or guidance on this problem as i'm fully perplexed by it. Hey Seth, I ran the same tests on my cable system (channel 103) on 669Mhz and had no issue, and my snr's reported as (0x172 and 0x17c). One possibility is that you're overwhelming the frontend. Try adding a small mount of attenuation to the signal for test purposes. Hard to believe but this is where I'd start looking. -- Steven Toth - Kernel Labs http://www.kernellabs.com Thank you for reply! Hearing that the same frequency works on another card is pretty positive confirmation in my mind that this is a hardware/setup issue. I tried stopping by a local radio shack last night, but wouldn't you know they no longer carried simple attenuators. Looks like i'll be picking one up online (or maybe ill lookup a schematic online and try building a simple one). You can build a bridged-T, they are pretty simple. Z 2 +/\/\/\---+ | | | Z Z | | 0 0| V ---+--/\/\/\--+--/\/\/\--+ V i | o Z 1 | | | = = = Assuming that the source impedance and load impedance (not shown) are also Z0 (e.g. 75 ohms) then Z = a Z 1 0 Z 0 Z = -- 2 a V o 1 -- = - V 1 i1 + - a V o Power Gain in dB = 20 log V i So pick an attenuation that you want to achieve, and that tells you a. a will tell you the resistor values you need. Then try and pick ones that are close. All this of course assumes I created and solved my system of equations without making an error. Regards, Andy On a side note - Thank you very much for hacking on the saa7164 - other than this frequency glitch its been working great for me! -- 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: help: Can't get DViCO FusionHDTV DVB-T Dual Digital 4 to work with new kernels
On Thu, 20 Aug 2009 06:50:25 +0800 treblid treb...@gmail.com wrote: On Wed, Aug 19, 2009 at 3:02 PM, Bob Hepplebhep...@promptu.com wrote: 2.6.27 worked for me - exact same board (ignoring revisions - mine is an older board, rev.1, I think) Mine is rev 1 too, I think.. :p 2.6.28 and up failed for me in exactly this manner. Same with a head-of-tree v4l-dvb 'hg clone' AFAICT it's a v4l-dvb driver problem - at least no-one here refutes it since I reported it here on 20090615. cool at least I'm not alone.. is this error related to the IR receiver? coz I noticed the IR receiver is detected for 1 tuner and not the other. I don't _think_ it's anything to do with the IR. Mind you, I don't use the IR at all (I prefer using a bluetooth mini-keyboard for mythTV - the IR remote provided with the DViCO doesn't have enough functions/buttons for me). Anne Aileus also confirmed the regression on 20090727 and offered to do some tests if someone could provide guidance. Haven't heard any more on that thread so far. Cheers Bob -- Bob Hepple bhep...@promptu.com ph: 07-5584-5908 Fx: 07-5575-9550 -- 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] saa7134-input: don't probe for the Pinnacle remotes anymore
With the recent improvements we don't need to probe anymore, if we know
the i2c address of the receiver.
The address of the receiver for the remote with the gray buttons is not
confirmed anywhere, but it is very unlikely to see it on something else.
We want to have that information anyway.
BTW, those remaining still probing, please join.
Signed-off-by: hermann pitton hermann-pit...@arcor.de
diff -r 3f7e382dfae5 linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Sun Aug 16 21:53:17
2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Thu Aug 20 00:56:31
2009 +0200
@@ -782,6 +782,7 @@
#else
init_data.get_key = get_key_pinnacle_color;
init_data.ir_codes = ir_codes_pinnacle_color;
+ info.addr = 0x47;
#endif
} else {
#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 30)
@@ -790,6 +791,7 @@
#else
init_data.get_key = get_key_pinnacle_grey;
init_data.ir_codes = ir_codes_pinnacle_grey;
+ info.addr = 0x47;
#endif
}
break;
diff -r 3f7e382dfae5 linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Sun Aug 16 21:53:17 2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Thu Aug 20 00:56:31 2009 +0200
@@ -782,6 +782,7 @@
#else
init_data.get_key = get_key_pinnacle_color;
init_data.ir_codes = ir_codes_pinnacle_color;
+ info.addr = 0x47;
#endif
} else {
#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 30)
@@ -790,6 +791,7 @@
#else
init_data.get_key = get_key_pinnacle_grey;
init_data.ir_codes = ir_codes_pinnacle_grey;
+ info.addr = 0x47;
#endif
}
break;
Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]
Am Dienstag, den 18.08.2009, 10:07 -0400 schrieb Devin Heitmueller: On Tue, Aug 18, 2009 at 7:00 AM, Johannes Stezenbachj...@linuxtv.org wrote: I would be interested to know if someone _actually_ managed to break their hardware by using buggy drivers. The short answer is *absolutely*. /me takes off driver developer hat and puts on hardware developer hat In a world of flash, eeproms, and software programmable clocks, there are all sorts of ways where a driver bug can damage the hardware. Looking for some simple examples? 1. Think of the overclocking community and what happens when they reconfigure a GPU's software controlled clock to perform beyond its maximum expected rating without extra cooling. 2. Think of all the reports of corrupted eeproms you read about on the mailing list. Sure, in many cases a good developer can hack a way to reprogram the eeprom in software, but in many cases the board won't even come up, so you end up with an RMA. It's not damaged in the more traditional sense, but the net effect is the same - the board is rendered inoperable and has to be sent back to the manufacturer. 3. Try loading the xc3028 tuner firmware onto the low power version of the chip (xc3028l). It took me a minute before I realized the smell of burning plastic was coming from my tuner. Don't get me wrong, in many cases things can be designed into the hardware to mitigate the effects of software bugs. In any hardware design, your goal is to minimize the return rate, so you build failsafes for the most likely to occur problems. However, in many cases this adds additional cost to the BOM, and you make educated decisions about the probability of certain classes of failure and instead build the reliability into the driver instead (making sure that the Windows driver can *never* put the hardware into a state). A random open source developer doesn't know what these sorts of decisions were, and would not be able to replicate the corresponding checks in a Linux driver. 4. Ever see a user complaint of how a tuner runs hot under Linux compared to the same device running under Windows? Almost certainly an improperly GPIO configuration which resulted in a condition such as having the digital demod powered on at the same time as the analog decoder. Sure, it will work for a while but you're running the device outside of the expected thermal profile and shortening the life of the hardware. The above are just a few *simple* examples. The nastier ones are often too difficult to explain in less than fifty words. IANAL but I think that consumer electronics hardware which can be damaged by software is broken by design. A vendor selling such hardware is stupid because people would return the broken hardware and get a replacement. I don't see how a vendor could proof that the device was not damaged by an obscure bug in the Windows driver to get around their responsibility to replace broken hardware within the warranty period. Yeah, you're right. Usually they cannot tell right away and will perform an RMA. And the board will end up on a lab bench with a hardware engineering isolating which component failed, and then working with the driver developer trying to figure out how the hell their Windows driver put the board in such a state. The risk of trusting some random Linux developer's driver work is a reason why some vendors don't want to support Linux. If I were a vendor, and I endorsed a Linux driver written by someone without the appropriate knowledge of the hardware, I could end up with large number of product returns, and I would incur the cost of those losses. Also, in many cases the board doesn't burn out immediately. But because of crappy drivers it takes three or four months to burn out, and the result is a board that is designed to run without problems for tens of thousands of hours dies in a significantly shorter time. Good device driver developers realize and accept this risk whenever they attempt to write a reverse engineered driver. I certainly don't want to discourage people from learning how to write Linux drivers for tuners, but caveat emptor - you can end up permanently damaging your hardware. Devin Hi, again, both can be right. I don't deny the smell you had, what a crap on the other hand. But Johannes is right too. I did not manage to burn a single Philips device during the last seven years. And i did all the worst every single day ;) So, there might be still a slight difference ... Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Em Wed, 19 Aug 2009 10:32:07 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, Kevin has approved the architecture part of this patch. When can I expect these to be merged to linux-next? Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: Karicheri, Muralidharan Sent: Tuesday, August 18, 2009 5:51 PM To: 'Mauro Carvalho Chehab' Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; davinci-linux-open- sou...@linux.davincidsp.com; khil...@deeprootsystems.com; Hans Verkuil Subject: RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver Mauro, Here are the patches from Chaithrika that I am referring to. http://www.mail-archive.com/linux-media@vger.kernel.org/msg08254.html There's something wrong with this patch: $ patch -p1 -i 12453a.patch patching file arch/arm/mach-davinci/board-dm646x-evm.c Reversed (or previously applied) patch detected! Assume -R? [n] y Hunk #1 succeeded at 52 (offset -11 lines). Hunk #2 succeeded at 218 with fuzz 1 (offset -70 lines). Hunk #3 succeeded at 286 with fuzz 2 (offset -14 lines). Hunk #4 FAILED at 293. Hunk #5 succeeded at 254 (offset -79 lines). 1 out of 5 hunks FAILED -- saving rejects to file arch/arm/mach-davinci/board-dm646x-evm.c.rej patching file arch/arm/mach-davinci/dm646x.c Hunk #1 succeeded at 40 with fuzz 2 (offset 8 lines). Hunk #2 succeeded at 550 with fuzz 1 (offset -145 lines). Hunk #3 succeeded at 866 with fuzz 1 (offset 12 lines). patching file arch/arm/mach-davinci/include/mach/dm646x.h Hunk #1 succeeded at 47 with fuzz 2 (offset 18 lines). It seems that this patch is not based on my linux-next -git tree. Probably, this patch is dependent on some patch at Kevin tree. Kevin, As this patch touches only arch/arm/ stuff, I suspect that we'll have less conflicts if you could merge this one. From my side: Acked-by: Mauro Carvalho Chehab mche...@redhat.com http://www.mail-archive.com/linux-media@vger.kernel.org/msg07676.html Hmm... the second patch shows that bisect will be broken with the platform changes. This patch should be fold with the one that renamed the field, or before Kconfig/Makefile changes. I've applied this one on my tree, just before the Kbuild patch. Due to the DaVinci dependency order, I'll need to hold the DaVinci patches at the next upstream window to happen after Russell/Kevin trees, to avoid bisect troubles 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
