Re: WinTV 1400 broken with recent versions?
On Sat, Mar 12, 2011 at 9:22 PM, Jean-Michel Bruenn wrote: > So i guess, nobody here can help me to solve that problems? > > xc2028 1-0064: i2c output error: rc = -6 (should be 64) > xc2028 1-0064: -6 returned from send > xc2028 1-0064: Error -22 while loading base firmware > xc2028 1-0064: Loading firmware for type=BASE F8MHZ (3), id > . > > and nobody can tell me, whether thats a firmware problem, or is it an > i2c problem? At least someone who could explain me, what the above > errors mean? It means the i2c bus failed to get an ACK back when talking to the xc3028. It could be a number of different things: * broken cx23885 i2c master implementation * bug in the xc3028 driver * screwed up GPIOs causing the xc3028 to be held in reset * i2c bus wedged > Also, nobody has any idea what i could try (except for what > i already did, including reverting patches and downgrading the kernel)? If you're knowledgeable enough to downgrade the kernel, then your best bet is to learn how to use git bisect so you can identify exactly which patch introduced the regression. > I don't think the card is that uncommon, because i've already seen some > pages stating problems with that card, at least 3 on this maillinglist > with exactly the same problem (not to talk about those people, who just > send the card back and replace it with something else/people who don't > use maillinglists/bugtracker) however, whether the card is common or > uncommon is not very helpful/useful, so.. it shouldn't really matter. Tens of thousands of cards sold. Three complaints. That should indeed give you an idea how few people are using the card under Linux. That said, the likelihood of a card getting fixed is largely related to how popular it is and the probability that some developer who actually cares has the card. > heh. I'm about to give up. just a pity because the card wasn't > cheap when it came out and every page states "supported in linux" which > seems to be not true anymore. I know that it was, back in 2008 when i > wrote with S. Toth about it. Well with Linux and open source in general, you get what you paid for. The only reason the card worked at all is because of the thousands of dollars worth of man-hours that developers like Steve donated to bring up the board in the first place. The downside of course is that since you paid *nothing* for Linux support, you cannot really complain when it stops working. If the card is unpopular and therefore there aren't developers willing to work on it, and you're not knowledgeable enough to fix it yourself, then you are largely SOL. > http://git.linuxtv.org/anttip/media_tree.git?a=commit;h=6676237398d0c2e61e5a3a27e0951f60d6ef6fe3 > > Here's the commit when the card was added. I was using it without any > trouble around that time. Well if someone knows what i could try (i > could also hack around in the source if someone tells me what to > change/where to change) i'd be very happy about ANY information. Yeah, if you can git bisect to identify which patch broke the support, Andy can probably offer some idea what is going on. 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: WinTV 1400 broken with recent versions?
So i guess, nobody here can help me to solve that problems? xc2028 1-0064: i2c output error: rc = -6 (should be 64) xc2028 1-0064: -6 returned from send xc2028 1-0064: Error -22 while loading base firmware xc2028 1-0064: Loading firmware for type=BASE F8MHZ (3), id . and nobody can tell me, whether thats a firmware problem, or is it an i2c problem? At least someone who could explain me, what the above errors mean? Also, nobody has any idea what i could try (except for what i already did, including reverting patches and downgrading the kernel)? I don't think the card is that uncommon, because i've already seen some pages stating problems with that card, at least 3 on this maillinglist with exactly the same problem (not to talk about those people, who just send the card back and replace it with something else/people who don't use maillinglists/bugtracker) however, whether the card is common or uncommon is not very helpful/useful, so.. it shouldn't really matter. heh. I'm about to give up. just a pity because the card wasn't cheap when it came out and every page states "supported in linux" which seems to be not true anymore. I know that it was, back in 2008 when i wrote with S. Toth about it. http://git.linuxtv.org/anttip/media_tree.git?a=commit;h=6676237398d0c2e61e5a3a27e0951f60d6ef6fe3 Here's the commit when the card was added. I was using it without any trouble around that time. Well if someone knows what i could try (i could also hack around in the source if someone tells me what to change/where to change) i'd be very happy about ANY information. thanks so far. -- 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] Ngene cam device name
Hi, On Saturday 12 March 2011 14:29:08 Andreas Oberritter wrote: > On 03/11/2011 10:44 PM, Martin Vidovic wrote: > > Andreas Oberritter wrote: > >> It's rather unintuitive that some CAMs appear as ca0, while others as > >> cam0. > >> > > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used > > as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write > > transport stream. To me it looks like an extension of the current API. > > I see. This raises another problem. How to find out, which ca device > cam0 relates to, in case there are more ca devices than cam devices? Hm, I do not see a problem here. The API extension is simple: (1) camX is optional. If camX exists, it is tied to caX. (2) If there is no camX, the CI/CAM operates in 'legacy mode'. (3) If camX exists, the encrypted transport stream of the CI/CAM is sent through camX, and the decrypted stream is received from camX. caX behaves the same way as in (2). Btw, we should choose a more meaningful name for 'camX'. I would prefer something like cainoutX or caioX or cinoutX or cioX. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/20] world-writable files in sysfs and debugfs
> Vasiliy Kulikov (20): > mach-ux500: mbox-db5500: world-writable sysfs fifo file > leds: lp5521: world-writable sysfs engine* files > leds: lp5523: world-writable engine* sysfs files > misc: ep93xx_pwm: world-writable sysfs files > rtc: rtc-ds1511: world-writable sysfs nvram file > scsi: aic94xx: world-writable sysfs update_bios file > scsi: iscsi: world-writable sysfs priv_sess file These are still not merged :( -- 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: 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:Sat Mar 12 19:00:30 CET 2011 git hash:41f3becb7bef489f9e8c35284dd88a1ff59b190c gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: radio-maestro broken (conflicts with snd-es1968)
On Saturday, March 12, 2011 19:19:00 Ondrej Zary wrote: > Hello, > the radio-maestro driver is badly broken. It's intended to drive the radio on > MediaForte ESS Maestro-based sound cards with integrated radio (like > SF64-PCE2-04). But it conflicts with snd_es1968, ALSA driver for the sound > chip itself. > > If one driver is loaded, the other one does not work - because a driver is > already registered for the PCI device (there is only one). This was probably > broken by conversion of PCI probing in 2006: > ttp://lkml.org/lkml/2005/12/31/93 > > How to fix it properly? Include radio functionality in snd-es1968 and delete > radio-maestro? Interesting. I don't know anyone among the video4linux developers who has this hardware, so the radio-maestro driver hasn't been tested in at least 6 or 7 years. The proper fix would be to do it like the fm801.c alsa driver does: have the radio functionality as an i2c driver. In fact, it would not surprise me at all if you could use the tea575x-tuner.c driver (in sound/i2c/other) for the es1968 and delete the radio-maestro altogether. Both are for the tea575x tuner, although radio-maestro seems to have better support for the g_tuner operation. It doesn't seem difficult to add that to tea575x-tuner.c. The fm801 code for driving the tea575x is pretty horrible and it should be possible to improve that. I suspect that those read/write/mute functions really belong in tea575x-tuner.c and that only the low-level gpio actions need to be in the fm801/es1968 drivers. Hope this helps. Regards, Hans BTW: if anyone has spare hardware for testing the radio-maestro/tea575x-tuner, then I'm interested. -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
radio-maestro broken (conflicts with snd-es1968)
Hello, the radio-maestro driver is badly broken. It's intended to drive the radio on MediaForte ESS Maestro-based sound cards with integrated radio (like SF64-PCE2-04). But it conflicts with snd_es1968, ALSA driver for the sound chip itself. If one driver is loaded, the other one does not work - because a driver is already registered for the PCI device (there is only one). This was probably broken by conversion of PCI probing in 2006: ttp://lkml.org/lkml/2005/12/31/93 How to fix it properly? Include radio functionality in snd-es1968 and delete radio-maestro? -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[bug] radio: wl128x: sleep inside of spinlock
Hi,
There is a copy_to_user() call inside of
spin_lock_irqsave()/spin_unlock_irqrestore():
drivers/media/radio/wl128x/fmdrv_common.c:
/* Copies RDS data from internal buffer to user buffer */
u32 fmc_transfer_rds_from_internal_buff(struct fmdev *fmdev, struct file
*file,
u8 __user *buf, size_t count)
{
...
spin_lock_irqsave(&fmdev->rds_buff_lock, flags);
...
if (copy_to_user(buf, &fmdev->rx.rds.buff[fmdev->rx.rds.rd_idx],
...
spin_unlock_irqrestore(&fmdev->rds_buff_lock, flags);
return ret;
}
--
Vasiliy
--
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
Problems with analog sound on Pinnacle Dazzle TV hybrid USB stick
Hi all, I have read serveral newsgroups about this problem and did not find any solution. The closest to a solution was a suggestion to install a em28xx-new module but it is no longer available. I have loaded em28xx em28xx-alsa and em28xx-dvb with this output ( I have forced the card on 56 using options em28xx card=56) [51556.500765] em28xx: New device USB 2881 Video @ 480 Mbps (eb1a:2881, interface 0, class 0) [51556.500949] em28xx #0: chip ID is em2882/em2883 [51556.687042] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 00 6a 20 6a 00 [51556.687056] em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 [51556.687068] em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 02 00 b8 00 00 00 5b 1e 00 00 [51556.687080] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 02 00 00 00 00 00 00 [51556.687091] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687102] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687114] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 [51556.687125] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 [51556.687137] em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 [51556.687148] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687160] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687171] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687182] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687194] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687205] em28xx #0: i2c eeprom e0: 5a 00 55 aa 79 55 54 03 00 17 98 01 00 00 00 00 [51556.687216] em28xx #0: i2c eeprom f0: 0c 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687229] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb8846b20 [51556.687232] em28xx #0: EEPROM info: [51556.687234] em28xx #0: AC97 audio (5 sample rates) [51556.687236] em28xx #0: USB Remote wakeup capable [51556.687238] em28xx #0: 500mA max power [51556.687241] em28xx #0: Table at 0x04, strings=0x206a, 0x006a, 0x [51556.687915] em28xx #0: Identified as Pinnacle Hybrid Pro (card=53) [51556.690103] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0) [51556.694727] tuner 1-0061: chip found @ 0xc2 (em28xx #0) [51556.694862] xc2028 1-0061: creating new instance [51556.694864] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [51556.694872] usb 2-6: firmware: requesting xc3028-v27.fw [51556.696352] xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [51556.752531] xc2028 1-0061: Loading firmware for type=BASE (1), id . [51557.679461] xc2028 1-0061: Loading firmware for type=(0), id b700. [51557.693080] SCODE (2000), id b700: [51557.693088] xc2028 1-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. [51557.900062] em28xx #0: Config register raw data: 0x58 [51557.900812] em28xx #0: AC97 vendor ID = 0x [51557.901178] em28xx #0: AC97 features = 0x6a90 [51557.901181] em28xx #0: Empia 202 AC97 audio processor detected [51558.050427] tvp5150 1-005c: tvp5150am1 detected. [51558.153287] em28xx #0: v4l2 driver version 0.1.2 [51558.237283] em28xx #0: V4L2 video device registered as /dev/video1 [51558.237287] em28xx #0: V4L2 VBI device registered as /dev/vbi1 [51558.250087] usbcore: registered new interface driver em28xx [51558.250092] em28xx driver loaded [51558.420877] xc2028 1-0061: attaching existing instance [51558.420881] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [51558.420884] em28xx #0/2: xc3028 attached [51558.420888] DVB: registering new adapter (em28xx #0) [51558.420893] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... [51558.421536] Successfully loaded em28xx-dvb [51558.421540] Em28xx: Initialized (Em28xx dvb Extension) extension [51558.421968] Em28xx: Initialized (Em28xx Audio Extension) extension [51560.520457] tvp5150 1-005c: tvp5150am1 detected. [51561.024168] tvp5150 1-005c: tvp5150am1 detected. [51561.332517] xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3), id . [51562.259446] (0), id 00ff: [51562.259452] xc2028 1-0061: Loading firmware for type=(0), id 00010007. [51562.273059] xc2028 1-0061: Loading SCODE for type=MONO SCODE HAS_IF_5320 (60008000), id 000f000 I can get video. I see in alsa a third card (in fact I have a second internal TV capture card) But I cannot get sound out of it. I used mplayer to play TV. I did get no errors about opening the card but again no sound. I used this command : mplayer -tv immediatemode=0:outfmt=yuy2:width=768:height=576:adevice=hw.2,0:forceaudio:alsa:amode=1:norm=PAL:normid=5:chanlist=europe-west:freq=203.25:device=/dev/video1:input=0
Re: [PATCH 09/10] MCDE: Add build files and bus
On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter wrote: > On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote: >> This doesn't seem that different from the graphics chips we support >> with kms. I don't think it would require much work to use KMS. One >> thing we considered, but never ended up implementing was a generic >> overlay API for KMS. Most PC hardware still has overlays, but we >> don't use them much any more on the desktop side. It may be >> worthwhile to design an appropriate API for them for these type of >> hardware. > > Just fyi about a generic overlay api: I've looked a bit into this when > doing the intel overlay support and I think adding special overlay crtcs > that can be attached real crtcs gives a nice clean api. We could the reuse > the existing framebuffer/pageflipping api to get the buffers to the > overlay engine. btw, has there been any further thought/discussion on this topic.. I've been experimenting with a drm driver interface on the OMAP SoC. It is working well now for framebuffer type usage (mode setting, virtual framebuffer spanning multiple diplays, and those types of xrandr things).. the next step that I've started thinking about is overlay (or underlay.. the z-order is flexible) support.. I was thinking in a similar direction (ie. a special, or maybe not so special, sort of crtc) and came across this thread, so I thought I'd resurrect the topic. In our case, most of the CRTCs in our driver could be used either with (A)RGB buffers as a traditional framebuffer, or with a few different formats of YUV as video under/overlays. So if you had one display attached, you might only use one CRTC for traditional GUI/gfx layer, and the rest are available for video. If you had two displays, then you'd steal one of the video CRTCs and use it for the gfx layer on the second display. And so on. Rough thinking: + add some 'caps' to the CRTC to indicate whether it can handle YUV, ARGB, scaling + add an x/y offset relative to the encoder (as opposed to the existing x/y offset relative to the framebuffer) + add a z-order parameter Not sure about intel hw if it is supporting clip-rects.. if so, maybe need to add something about that. In our case we jut put the video behind the gfx layer and use the alpha channel in the gfx framebuffer to clip/blend rather than using clip-rects. > The real pain starts when we want format discovery from userspace with all > the alignement/size/layout constrains. Add in tiling support and its > almost impossible to do in a generic way. But also for kms userspace needs > to know these constrains (implemented for generic use in libkms). I favor > such an approach for overlays, too (if it ever happens) - i.e. a few > helpers in libkms that allocate an appropriate buffer for a given format > and size and returns the buffer, strides and offsets for the different > planes. hmm, I guess I know about the OMAP display subsystem, and it's overlay formats/capabilities.. but not enough about other hw to say anything intelligent here. But I guess even if we ignore the format of the data in the buffer, at least the APIs to setup/attach overlay CRTCs at various positions could maybe be something we can start with as a first step. At least standardizing this part seems like a good first step. But I'm definitely interested if someone has some ideas. BR, -R > -Daniel > -- > Daniel Vetter > Mail: dan...@ffwll.ch > Mobile: +41 (0)79 365 57 48 > -- > 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: [PATCH 0/3] Another set of videobuf2 hotfixes
On Thu, Mar 10, 2011 at 08:04, Laurent Pinchart
wrote:
> On Thursday 10 March 2011 13:28:39 Marek Szyprowski wrote:
>> Hello!
>>
>> This is one more set of hotfixes for videobuf2 framework. I hope they
>> can be applied to staging/for-2.6.39 kernel tree once vb2 finally gets
>> into Linus tree.
>
> The commit message for the first patch could be slightly improved (it's not
> very descriptive as-is), but other than that
>
> Acked-by: Laurent Pinchart
Yeah, and the message for the second ("one more fix...") does leave
much to be desired as well.
But as for the patches:
Acked-by: Pawel Osciak
--
Best regards,
Pawel Osciak
--
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: Dib7000/mt2266 help
Hi Peter, (adding back the list to CC) On Saturday 12 March 2011 11:48:38 Peter Tilley wrote: > Hi Patrick, > My sincerest apologies for coming to you directly but I have tried the > Linux mailing list and received no response and noticed you seem to have > been heavily involved with much of the Dibcom driver development. > > I have an issue with a dual tuner which is sold under the brand of Kaiser > Baas KBA01004 but identifies itself as 1164:1e8c which is a Yaun device > and this device seems to have already been included in the driver files. > > It loads ok and reports not problems. It tunes ok and reports FE lock on > all channels however on all but one channel upon receiving FE lock the > BER stays at 1 instead of dropping to a low number which would > indicate I am not getting viterbi. > > The device is fitted with pairs of MT2266 and DIB7000 which I have > positive identified by opening the USB stick. > > am more than happy to try and work this out myself however the amount of > detail around in support of the Linux drivers is extremely low and a > search for manufacturers data sheets finds next to nothing.There > seems to be lots of what I would call "magic numbers" in the drivers and > little to determine what they are doing. Are you sure it is a driver problem? If the BER stays at this value it could also mean that the channel- configuration is wrong. Are you using a channels.conf which has all parameters set, or are you doing a channel-scan-like tune (all values are set to AUTO). > My question to you is are you able to offer either any pointers to solve > the problem or help me find detailed information about the devices so I > can help myself. > > I should point out that the device works perfectly under windows on the > same antenna and indeed I have even successfully extracted the firmware > from the supplied windows driver, renamed it so it loads and the problem > still remains. There are usually some adaptations board-designing companies do to improve reception quality (adding external LNAs and things like that) that are of course handled by the Window-driver, because it is created by the manufacturer and not by the Linux-driver, because (in this case) the driver was released by the chip-manufacturer. Is the device toggling between FE_HAS_LOCK and no FE_HAS_LOCK or does it stay constantly at Please try whether you can achieve the BER lowering by moving the antenna or using a better one. If this helps, it really means that the windows-driver does something more the board. I doubt that the chip-driver needs to be changed, more likely the GPIOs of the dib0700 (in dib0700_core.c) or of the dib7000 are used to turn on or off a frequency switch or a LNA. Good point, what are the frequencies you're tuning ? regards, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter > > I'm not against adding a new node if its behaviour is well defined and > documented and if it integrates well into the existing API. Integration is okay; current API is left untouched. The behaviour is defined as a write encrypted stream / read decrypted stream device. > > > You might find that adding a new node is lazy, but there are advantages: > > - current API isn't broken, namely, ca devices are still used for the control > > messages, nothing more; > > "nothing more" is wrong, as ca devices are used for descramblers, too. I don't understand your point here, do you mean these DVB descramblers currently use ca device for more than the control messages ? > > > - for applications using the DVB API, it is also easier to debug while reading > > the code, in my opinion, because of the usage of two distinct devices (ca / > > cam) instead of one (ca / ioctls); > > That's just a matter of taste. Okay, so you agree that choosing ca/ioctls over ca/cam is just a matter of taste. -- 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] Ngene cam device name
On 03/12/2011 03:57 PM, Martin Vidovic wrote: > Andreas Oberritter wrote: >> On 03/12/2011 03:10 PM, Issa Gorissen wrote: >> >>> From: Andreas Oberritter >>> On 03/11/2011 10:44 PM, Martin Vidovic wrote: > Andreas Oberritter wrote: > >> It's rather unintuitive that some CAMs appear as ca0, while others as >> cam0. >> > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used > as usual, to setup the CAM. The cam0 (or sec0) node is used to > read/write > transport stream. To me it looks like an extension of the current > API. > I see. This raises another problem. How to find out, which ca device cam0 relates to, in case there are more ca devices than cam devices? >>> Are you sure there can be more ca devices than cam devices ? >>> >> >> Yes. See my previous response to Ralph. >> > > Isn't this the same as asking which 'dvr' device relates to which > 'frontend' device? No, because this is defined. If demuxN is configured to output to a dvr device, then it outputs to dvrN. The input of demuxN is configured by using DMX_SET_SOURCE, which can be frontendX or dvrY. Regards, Andreas -- 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] Ngene cam device name
Andreas Oberritter writes: > > They should be in different adapterX directories. > > Even on the cards where you can connect up to 4 dual frontends or CAM > > adapters > > I currently use one adapter directory for every frontend and CAM. > > That looks like a hack to me, that may work well for your PC style > adapter, e.g frontends and CAMs attached to PCI or USB. But how would Exactly what I want to support with this. > you integrate audio and video decoders and hardware demux devices into > that scenario? Would you expect adapterN's frontend to be able to feed a > TS into adapterN+1's hardware demux and then into adapterN+2's video > decoder? This would be up to the application since there is no hardware stream routing on these cards and no general stream routing protocol for DVB in the kernel. > > If you want to "save" adapters one could put them in the same > > directory and caX would belong to camX. > > More ca than cam devices could only occur on cards with mixed old and > > new style hardware. I am not aware of such cards. > > DVB descramblers use ca devices, too. So it's certainly possible to occur. Not in the same adapter directory. > And even if no hardware exists that uses CAM slots with such different > capabilities, we should be prepared when such hardware appears. Then we also should not use the current API (or any) for the same reason? > > I think there are cards with dual frontend and two CAM adapters where > > normally data from frontendX is passed through caX (they are in the same > > adapter > > directory) but the paths can also be switched. I do not now how this is > > handled. > > On our STB platform. we have four frontends and four CAM slots. > Frontends and CAM slots get connected on demand or even chained to allow > multiple CAMs to try to decode parts of the same TS. I don't see how > multiple adapters could fit in that situation. Is this routing in hardware? If yes, it is totally different because your devices are not independent. How do you support this with the current API? Regards, Ralph -- 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] Ngene cam device name
On 03/12/2011 03:34 PM, Issa Gorissen wrote: > From: Ralph Metzler >> Andreas Oberritter writes: >> > > Unless you want to move the writing to/reading from the CI module into >> > > ioctls of the ci device you need another node. >> > > Even nicer would be having the control messages moved to ioctls and > the >> > > TS IO in read/write of ci, but this would break the old interface. >> > >> > It's possible to keep compatibility. Just add ioctls to get and set the >> > interface version. Default to the current version, not supporting TS >> > I/O. If the version is set to e.g. 1, switch from the current interface >> > to the new one, using ioctls for control messages. >> >> A possibility, but also requires rewrites in existing software like > libdvben50221. >> Right now you can e.g. tune with /dev/dvb/adapter0/frontend0, point an > unchanged >> libdvben50221 to /dev/dvb/adapter1/ci0 (separate adapter since it can even >> be on a different card) and pipe all PIDs of cam_pmt of the program >> you are watching through /dev/dvb/adapter1/sec0(cam0) and it is decoded. Obviously, adapting libdvben50221 would be the first thing to do for an enhanced CI API. Probably not a big deal. > This is KISS compliant by the way. > > Andreas, please explain what *really* bothers you with this architecture > choice of having a new node, leaving the current API as is. I'm not against adding a new node if its behaviour is well defined and documented and if it integrates well into the existing API. > You might find that adding a new node is lazy, but there are advantages: > - current API isn't broken, namely, ca devices are still used for the control > messages, nothing more; "nothing more" is wrong, as ca devices are used for descramblers, too. > - for applications using the DVB API, it is also easier to debug while reading > the code, in my opinion, because of the usage of two distinct devices (ca / > cam) instead of one (ca / ioctls); That's just a matter of taste. Regards, Andreas -- 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] Ngene cam device name
Andreas Oberritter wrote: On 03/12/2011 03:10 PM, Issa Gorissen wrote: From: Andreas Oberritter On 03/11/2011 10:44 PM, Martin Vidovic wrote: Andreas Oberritter wrote: It's rather unintuitive that some CAMs appear as ca0, while others as cam0. Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write transport stream. To me it looks like an extension of the current API. I see. This raises another problem. How to find out, which ca device cam0 relates to, in case there are more ca devices than cam devices? Are you sure there can be more ca devices than cam devices ? Yes. See my previous response to Ralph. Isn't this the same as asking which 'dvr' device relates to which 'frontend' device? Regards, Martin -- 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] Ngene cam device name
On 03/12/2011 03:10 PM, Issa Gorissen wrote: > From: Andreas Oberritter >> On 03/11/2011 10:44 PM, Martin Vidovic wrote: >>> Andreas Oberritter wrote: It's rather unintuitive that some CAMs appear as ca0, while others as cam0. >>> Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used >>> as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write >>> transport stream. To me it looks like an extension of the current API. >> >> I see. This raises another problem. How to find out, which ca device >> cam0 relates to, in case there are more ca devices than cam devices? >> > > Are you sure there can be more ca devices than cam devices ? Yes. See my previous response to Ralph. Regards, Andreas -- 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] Ngene cam device name
On 03/12/2011 03:05 PM, Ralph Metzler wrote: > Andreas Oberritter writes: > > On 03/11/2011 10:44 PM, Martin Vidovic wrote: > > > Andreas Oberritter wrote: > > >> It's rather unintuitive that some CAMs appear as ca0, while others as > > >> cam0. > > >> > > > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used > > > as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write > > > transport stream. To me it looks like an extension of the current API. > > > > I see. This raises another problem. How to find out, which ca device > > cam0 relates to, in case there are more ca devices than cam devices? > > > > They should be in different adapterX directories. > Even on the cards where you can connect up to 4 dual frontends or CAM adapters > I currently use one adapter directory for every frontend and CAM. That looks like a hack to me, that may work well for your PC style adapter, e.g frontends and CAMs attached to PCI or USB. But how would you integrate audio and video decoders and hardware demux devices into that scenario? Would you expect adapterN's frontend to be able to feed a TS into adapterN+1's hardware demux and then into adapterN+2's video decoder? > If you want to "save" adapters one could put them in the same > directory and caX would belong to camX. > More ca than cam devices could only occur on cards with mixed old and > new style hardware. I am not aware of such cards. DVB descramblers use ca devices, too. So it's certainly possible to occur. And even if no hardware exists that uses CAM slots with such different capabilities, we should be prepared when such hardware appears. > I think there are cards with dual frontend and two CAM adapters where > normally data from frontendX is passed through caX (they are in the same > adapter > directory) but the paths can also be switched. I do not now how this is > handled. On our STB platform. we have four frontends and four CAM slots. Frontends and CAM slots get connected on demand or even chained to allow multiple CAMs to try to decode parts of the same TS. I don't see how multiple adapters could fit in that situation. Regards, Andreas -- 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] Ngene cam device name
From: Ralph Metzler > Andreas Oberritter writes: > > > Unless you want to move the writing to/reading from the CI module into > > > ioctls of the ci device you need another node. > > > Even nicer would be having the control messages moved to ioctls and the > > > TS IO in read/write of ci, but this would break the old interface. > > > > It's possible to keep compatibility. Just add ioctls to get and set the > > interface version. Default to the current version, not supporting TS > > I/O. If the version is set to e.g. 1, switch from the current interface > > to the new one, using ioctls for control messages. > > A possibility, but also requires rewrites in existing software like libdvben50221. > Right now you can e.g. tune with /dev/dvb/adapter0/frontend0, point an unchanged > libdvben50221 to /dev/dvb/adapter1/ci0 (separate adapter since it can even > be on a different card) and pipe all PIDs of cam_pmt of the program > you are watching through /dev/dvb/adapter1/sec0(cam0) and it is decoded. This is KISS compliant by the way. Andreas, please explain what *really* bothers you with this architecture choice of having a new node, leaving the current API as is. You might find that adding a new node is lazy, but there are advantages: - current API isn't broken, namely, ca devices are still used for the control messages, nothing more; - for applications using the DVB API, it is also easier to debug while reading the code, in my opinion, because of the usage of two distinct devices (ca / cam) instead of one (ca / ioctls); -- Issa -- 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] Ngene cam device name
From: Andreas Oberritter > On 03/11/2011 10:44 PM, Martin Vidovic wrote: > > Andreas Oberritter wrote: > >> It's rather unintuitive that some CAMs appear as ca0, while others as > >> cam0. > >> > > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used > > as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write > > transport stream. To me it looks like an extension of the current API. > > I see. This raises another problem. How to find out, which ca device > cam0 relates to, in case there are more ca devices than cam devices? > Are you sure there can be more ca devices than cam devices ? Shouldn't they come by pair ? -- 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] Ngene cam device name
Andreas Oberritter writes: > On 03/11/2011 10:44 PM, Martin Vidovic wrote: > > Andreas Oberritter wrote: > >> It's rather unintuitive that some CAMs appear as ca0, while others as > >> cam0. > >> > > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used > > as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write > > transport stream. To me it looks like an extension of the current API. > > I see. This raises another problem. How to find out, which ca device > cam0 relates to, in case there are more ca devices than cam devices? > They should be in different adapterX directories. Even on the cards where you can connect up to 4 dual frontends or CAM adapters I currently use one adapter directory for every frontend and CAM. If you want to "save" adapters one could put them in the same directory and caX would belong to camX. More ca than cam devices could only occur on cards with mixed old and new style hardware. I am not aware of such cards. I think there are cards with dual frontend and two CAM adapters where normally data from frontendX is passed through caX (they are in the same adapter directory) but the paths can also be switched. I do not now how this is handled. Regards, Ralph -- 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: WinTV 1400 broken with recent versions?
On Mar 11, 2011, at 6:35 PM, Devin Heitmueller wrote: > On Fri, Mar 11, 2011 at 6:30 PM, wrote: >> >>> Doesn't seem weird to me at all. This is a pretty uncommon card, so >>> it is entirely possible that many revisions could go by without >>> someone noticing a regression. I know for example that the HVR-1500Q >>> (the US version of that board) was broken for months and nobody >>> noticed. >> >> Well. How was it solved at the hvr-1500q? :) Any other information i >> could provide maybe? > > It's not clear to me that it ever was resolved for the 1500q. If the > goal is for it to get fixed, it's usually a matter of getting a sample > unit in the hands of a developer who knows how to debug the issue. A > common problem is the lack of overlap between people who have the > board versus people who know what to do with it. The HVR-1500Q I've got works fine with the latest media_tree code, but admittedly, it sits unused most of the time, so it had been several months since I last tried it before about a week ago... (Got it for my thinkpad, planning to just leave it plugged in all the time, until finding out it stuck out a good inch from the side of the machine). -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
Andreas Oberritter writes: > > Unless you want to move the writing to/reading from the CI module into > > ioctls of the ci device you need another node. > > Even nicer would be having the control messages moved to ioctls and the > > TS IO in read/write of ci, but this would break the old interface. > > It's possible to keep compatibility. Just add ioctls to get and set the > interface version. Default to the current version, not supporting TS > I/O. If the version is set to e.g. 1, switch from the current interface > to the new one, using ioctls for control messages. A possibility, but also requires rewrites in existing software like libdvben50221. Right now you can e.g. tune with /dev/dvb/adapter0/frontend0, point an unchanged libdvben50221 to /dev/dvb/adapter1/ci0 (separate adapter since it can even be on a different card) and pipe all PIDs of cam_pmt of the program you are watching through /dev/dvb/adapter1/sec0(cam0) and it is decoded. Regards, Ralph -- 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] Ngene cam device name
On 03/11/2011 10:44 PM, Martin Vidovic wrote: > Andreas Oberritter wrote: >> It's rather unintuitive that some CAMs appear as ca0, while others as >> cam0. >> > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used > as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write > transport stream. To me it looks like an extension of the current API. I see. This raises another problem. How to find out, which ca device cam0 relates to, in case there are more ca devices than cam devices? Regards, Andreas -- 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] Ngene cam device name
On 03/11/2011 10:46 PM, Ralph Metzler wrote: > Andreas Oberritter writes: > > >> On 03/10/2011 04:29 PM, Issa Gorissen wrote: > > > Now, according to Mauro comments, he has put this code into staging > because of > > > the usage of sec0 name for a cam device. > > > > > > Please comment on Oliver's explanations from this thread > > > > > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26901.html > > > > Oliver explained that he's not going to put work into this driver, > > because he's not using it. > > > > Until now, I haven't heard any reasons for just adding another device > > node other than it being easier than defining a proper interface. The > > fact that a solution "just works as is" is not sufficient to move a > > driver from staging. IMO the CI driver should not have been included at > > all in its current shape. > > Unless you want to move the writing to/reading from the CI module into > ioctls of the ci device you need another node. > Even nicer would be having the control messages moved to ioctls and the > TS IO in read/write of ci, but this would break the old interface. It's possible to keep compatibility. Just add ioctls to get and set the interface version. Default to the current version, not supporting TS I/O. If the version is set to e.g. 1, switch from the current interface to the new one, using ioctls for control messages. > What kind of proper interface were you thinking about? At least something that's documented and has a defined behaviour. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.39] Core prio support and global release callback
Hi Mauro! This changeset adds core support for VIDIOC_S/G_PRIORITY and adds a release callback to struct v4l2_device. vivi and cx18 are modified to use the core prio support and dsbr100 was changed to use the release callback and unlocked_ioctl. I fixed a few related ivtv problems as well. Tested with cx18, ivtv, vivi and bttv. We don't have hardware for the DSB-R100, so those changed are untested. There is one on its way to me, so I should be able to verify it in 2-3 weeks. The core prio support makes vivi fully pass v4l2-compliance (and it's the first driver to do so :-) ). It is also required to have the control framework honor the priority ioctls. Without this file descriptors with a lower prio could still change controls. Note that the prio core support only kicks in for drivers that use struct v4l2_fh and do not set vidioc_s_priority in the ioctl_ops. Regards, Hans The following changes since commit 41f3becb7bef489f9e8c35284dd88a1ff59b190c: [media] V4L DocBook: update V4L2 version (2011-03-11 18:09:02 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git core Hans Verkuil (17): v4l2_prio: move from v4l2-common to v4l2-dev. v4l2: add v4l2_prio_state to v4l2_device and video_device v4l2-fh: implement v4l2_priority support. v4l2-fh: add v4l2_fh_open and v4l2_fh_release helper functions v4l2-fh: add v4l2_fh_is_singular v4l2-ioctl: add priority handling support. ivtv: convert to core priority handling. v4l2-framework.txt: improve v4l2_fh/priority documentation cx18: use v4l2_fh as preparation for adding core priority support. cx18: use core priority handling v4l2-device: add kref and a release function v4l2-framework.txt: document new v4l2_device release() callback dsbr100: convert to unlocked_ioctl dsbr100: ensure correct disconnect sequence. vivi: convert to core priority handling. ivtv: add missing v4l2_fh_exit. ivtv: replace ugly casts with a proper container_of. Documentation/video4linux/v4l2-framework.txt | 135 -- drivers/media/radio/dsbr100.c| 128 ++--- drivers/media/radio/radio-si4713.c |3 +- drivers/media/video/cpia2/cpia2_v4l.c|3 +- drivers/media/video/cx18/cx18-driver.h | 14 ++- drivers/media/video/cx18/cx18-fileops.c | 20 ++- drivers/media/video/cx18/cx18-ioctl.c| 128 ++--- drivers/media/video/davinci/vpfe_capture.c |2 +- drivers/media/video/ivtv/ivtv-driver.h |2 - drivers/media/video/ivtv/ivtv-fileops.c |3 +- drivers/media/video/ivtv/ivtv-ioctl.c| 159 +++--- drivers/media/video/meye.c |3 +- drivers/media/video/mxb.c|3 +- drivers/media/video/pwc/pwc-v4l.c|3 +- drivers/media/video/v4l2-common.c| 63 -- drivers/media/video/v4l2-dev.c | 80 + drivers/media/video/v4l2-device.c| 17 +++ drivers/media/video/v4l2-fh.c| 46 drivers/media/video/v4l2-ioctl.c | 64 +- drivers/media/video/vivi.c | 17 +-- include/media/v4l2-common.h | 15 --- include/media/v4l2-dev.h | 18 +++ include/media/v4l2-device.h | 14 +++ include/media/v4l2-fh.h | 29 + include/media/v4l2-ioctl.h |2 +- 25 files changed, 546 insertions(+), 425 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
