Re: Digital Devices Cine S2 V6.5, PCIe, Dual
Hi, Am 30.12.2013 11:10, schrieb Rudy Zijlstra: Dear List, I have a DVB card as mentioned in the subject 03:00.0 Multimedia controller [0480]: Device [dd01:0003] Subsystem: Device [dd01:0021] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 17 Region 0: Memory at f090 (64-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+ RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range A, TimeoutDis+ DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+ LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB Capabilities: [100 v1] Vendor Specific Information: ID= Rev=0 Len=00c ? Kernel driver in use: DDBridge Kernel modules: ddbridge Kernel 3.12.3 sees the device, but does not enable it. Only the ddbridge driver is loaded, none of the tuner/demod drivers: root@mythtest:~# lsmod Module Size Used by ddbridge 17766 0 Nor, judging from dmesg output, is the firmware loaded: [1.624996] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH [1.652565] pci :01:19.0: enabling device ( - 0002) [1.677601] DDBridge driver detected: Digital Devices PCIe bridge [1.683598] HW FW [2.160410] Adding 2097148k swap on /dev/sda3. Priority:-1 extents:1 across:2097148k [2.190386] Switched to clocksource tsc What is the best kernel to have this dvb-card working? Or, alternatively, the best combination of kernel version and out-of-kernel stack? I think the best out-of-kernel stack at the moment ist the one by Oliver Endriss. http://www.vdr-portal.de/board18-vdr-hardware/board102-dvb-karten/p1077194-#post1077194 I use it for my Cine C/T and it's working really good. Regards, Lars. Thanks, Rudy -- 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: Not receiving any messages since 2012-11-04
Hi, Am 01.12.2012 16:05, schrieb Andreas Regel: am I the only one that is receiveing no mails from linux-media since Nov 04, 2012? Here's everything fine AICT. Regards, Lars. Best 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 -- 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] [media] ddbridge: fix error handling in module_init_ddbridge()
Hi,
Am 15.08.2012 22:42, schrieb Alexey Khoroshilov:
If pci_register_driver() failed, resources allocated in
ddb_class_create() are leaked. The patch fixes it.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/media/dvb/ddbridge/ddbridge-core.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb/ddbridge/ddbridge-core.c
b/drivers/media/dvb/ddbridge/ddbridge-core.c
index ebf3f05..36aa4e4 100644
--- a/drivers/media/dvb/ddbridge/ddbridge-core.c
+++ b/drivers/media/dvb/ddbridge/ddbridge-core.c
@@ -1705,7 +1705,11 @@ static __init int module_init_ddbridge(void)
Copyright (C) 2010-11 Digital Devices GmbH\n);
if (ddb_class_create())
return -1;
- return pci_register_driver(ddb_pci_driver);
+ if (pci_register_driver(ddb_pci_driver) 0) {
+ ddb_class_destroy();
+ return -1;
Difference to before: the return value of pci_register_driver is not passed
through.
Is this a problem? I'm just an interested application developer, not a driver
developer.
Regards,
Lars.
+ }
+ return 0;
}
static __exit void module_exit_ddbridge(void)
--
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: [DVB Digital Devices Cine CT V6] status support
Hi, Please use reply all, otherwise the list will not benefit from your experience. ;-) Am 27.02.2012 19:27, schrieb Martin Herrman: Op 26 februari 2012 11:11 heeft Lars Hanischd...@cinnamon-sage.de het volgende geschreven: Since you are using Ubuntu, you can find a nearly up-to-date dkms of linux-media with the patches of Oliver Endriss at https://launchpad.net/~yavdr/+archive/main called linux-media-dkms With this my Cine-C/T with a ddbridge runs without any problems. Thomas and Lars, thanks to both of you for your input. I first tried the solution proposed by Lars because it seems to be more future-proof. After install of linux-media-dkms package (note: it took me a while to find out which kernel packages I had to install to have linux-media-dkms installation find the kernel sources) and a reboot, dmesg shows: [7.316117] WARNING: You are using an experimental version of the media stack. [7.316124] As the driver is backported to an older kernel, it doesn't offer [7.316125] enough quality for its usage in production. [7.316125] Use it with care. [7.316126] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [7.316127] 59b30294e14fa6a370fdd2bc2921cca1f977ef16 Merge branch 'v4l_for_linus' into staging/for_v3.4 [7.316128] 72565224609a23a60d10fcdf42f87a2fa8f7b16d [media] cxd2820r: sleep on DVB-T/T2 delivery system switch [7.316129] 46de20a78ae4b122b79fc02633e9a6c3d539ecad [media] anysee: fix CI init [7.355344] cfg80211: Calling CRDA to update world regulatory domain [7.612757] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH [7.612805] DDBridge :03:00.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [7.612813] DDBridge driver detected: Digital Devices DVBCT V6.1 DVB adapter [7.612838] HW 00010007 REG 00010003 [7.613010] DDBridge :03:00.0: irq 45 for MSI/MSI-X [7.614652] Port 0 (TAB 1): DUAL DVB-C/T [7.615277] Port 1 (TAB 2): NO MODULE [7.615904] Port 2 (TAB 3): NO MODULE [7.616278] DVB: registering new adapter (DDBridge) [7.616280] DVB: registering new adapter (DDBridge) (..) [7.873616] Linux media interface: v0.10 [8.021310] stv0367 found [8.028799] Linux video capture interface: v2.00 [8.028801] WARNING: You are using an experimental version of the media stack. [8.028802] As the driver is backported to an older kernel, it doesn't offer [8.028803] enough quality for its usage in production. [8.028804] Use it with care. [8.028804] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [8.028805] 59b30294e14fa6a370fdd2bc2921cca1f977ef16 Merge branch 'v4l_for_linus' into staging/for_v3.4 [8.028806] 72565224609a23a60d10fcdf42f87a2fa8f7b16d [media] cxd2820r: sleep on DVB-T/T2 delivery system switch [8.028808] 46de20a78ae4b122b79fc02633e9a6c3d539ecad [media] anysee: fix CI init [8.216959] skipping empty audio interface (v1) [8.216970] snd-usb-audio: probe of 1-3:1.0 failed with error -5 [8.216979] skipping empty audio interface (v1) [8.216984] snd-usb-audio: probe of 1-3:1.1 failed with error -5 [8.227179] AV200 :05:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [8.229650] uvcvideo: disagrees about version of symbol video_devdata [8.229653] uvcvideo: Unknown symbol video_devdata (err -22) [8.229670] uvcvideo: disagrees about version of symbol video_unregister_device [8.229672] uvcvideo: Unknown symbol video_unregister_device (err -22) [8.229681] uvcvideo: disagrees about version of symbol video_device_alloc [8.229683] uvcvideo: Unknown symbol video_device_alloc (err -22) [8.229691] uvcvideo: disagrees about version of symbol v4l2_device_register [8.229693] uvcvideo: Unknown symbol v4l2_device_register (err -22) [8.229701] uvcvideo: disagrees about version of symbol __video_register_device [8.229703] uvcvideo: Unknown symbol __video_register_device (err -22) [8.229707] uvcvideo: disagrees about version of symbol v4l2_device_unregister [8.229709] uvcvideo: Unknown symbol v4l2_device_unregister (err -22) [8.229713] uvcvideo: disagrees about version of symbol video_usercopy [8.229715] uvcvideo: Unknown symbol video_usercopy (err -22) [8.229718] uvcvideo: disagrees about version of symbol video_device_release [8.229720] uvcvideo: Unknown symbol video_device_release (err -22) [8.311744] tda18212dd: ChipID 4724 [8.312165] tda18212dd: PowerState 02 [8.331053] HDA Intel :01:00.1: PCI INT B - GSI 17 (level, low) - IRQ 17 [8.331107] HDA Intel :01:00.1: irq 46 for MSI/MSI-X [8.331131] HDA Intel :01:00.1: setting latency timer to 64 I think that the second part indicates a problem with my webcam, which worked like a charm before :-) (it is a logitech 9000 pro) In mixed environments it's always difficult to combine all the various developer and mainline trees to
Re: [DVB Digital Devices Cine CT V6] status support
Hi, Am 25.02.2012 20:35, schrieb Martin Herrman: Op 10 januari 2012 09:12 schreef Martin Herrman martin.herr...@gmail.com het volgende: 2012/1/9 Thomas Kaiserlinux-...@kaiser-linux.li: Hello Martin I use the DD Cine CT V6 with DVB-C. It works without problems. I got the driver before Oliver integrated it in his tree. Therefor I did not compile Olivers tree, yet. At the moment I run the card on Ubuntu 11.10 with kernel 3.0.0-14. Hope this helps. Thomas Hi Thomas, that is very good news, thanks a lot for the confirmation. Time to order one myself! Regards, Martin So.. couple of weeks later, the card arrived, and I have some time to play with it. Note that I'm running latest stable Ubuntu 64-bit with kernel 3.0.0-16-generic. Since you are using Ubuntu, you can find a nearly up-to-date dkms of linux-media with the patches of Oliver Endriss at https://launchpad.net/~yavdr/+archive/main called linux-media-dkms With this my Cine-C/T with a ddbridge runs without any problems. Regards, Lars. First I tried the drivers from http://linuxtv.org/hg/~endriss/media_build_experimental/. In that case, dmesg output is: [ 11.728370] WARNING: You are using an experimental version of the media stack. [ 11.728372] As the driver is backported to an older kernel, it doesn't offer [ 11.728373] enough quality for its usage in production. [ 11.728373] Use it with care. [ 11.728374] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 11.728375] 59b30294e14fa6a370fdd2bc2921cca1f977ef16 Merge branch 'v4l_for_linus' into staging/for_v3.4 [ 11.728376] 72565224609a23a60d10fcdf42f87a2fa8f7b16d [media] cxd2820r: sleep on DVB-T/T2 delivery system switch [ 11.728377] 46de20a78ae4b122b79fc02633e9a6c3d539ecad [media] anysee: fix CI init [ 11.728852] ddbridge: disagrees about version of symbol cxd2099_attach [ 11.728856] ddbridge: Unknown symbol cxd2099_attach (err -22) So I started to try the build instructions found here: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers And after compile, install and a reboot, dmesg output is: (..) [ 11.592959] Adding 976892k swap on /dev/sdb2. Priority:-2 extents:1 across:976892k [ 11.628781] WARNING: You are using an experimental version of the media stack. [ 11.628784] As the driver is backported to an older kernel, it doesn't offer [ 11.628785] enough quality for its usage in production. [ 11.628785] Use it with care. [ 11.628786] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 11.628787] a3db60bcf7671cc011ab4f848cbc40ff7ab52c1e [media] xc5000: declare firmware configuration structures as static const [ 11.628788] 6fab81dfdc7b48c2e30ab05e9b30afb0c418bbbe [media] xc5000: drivers should specify chip revision rather than firmware [ 11.628790] ddea427fb3e64d817d4432e5efd2abbfc4ddb02e [media] xc5000: remove static dependencies on xc5000 created by previous changesets [ 11.629238] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH [ 11.629298] DDBridge :03:00.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 11.629306] DDBridge driver detected: Digital Devices PCIe bridge [ 11.629331] HW 00010007 FW 00010003 [ 11.632593] cfg80211: Calling CRDA to update world regulatory domain [ 11.643411] rt2800pci :05:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19 (..) [ 11.781023] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 11.844516] skipping empty audio interface (v1) [ 11.844528] snd-usb-audio: probe of 1-3:1.0 failed with error -5 [ 11.844540] skipping empty audio interface (v1) [ 11.844546] snd-usb-audio: probe of 1-3:1.1 failed with error -5 [ 11.845406] Linux media interface: v0.10 [ 11.868177] Linux video capture interface: v2.00 [ 11.868181] WARNING: You are using an experimental version of the media stack. [ 11.868182] As the driver is backported to an older kernel, it doesn't offer [ 11.868183] enough quality for its usage in production. [ 11.868184] Use it with care. [ 11.868184] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 11.868185] a3db60bcf7671cc011ab4f848cbc40ff7ab52c1e [media] xc5000: declare firmware configuration structures as static const [ 11.868187] 6fab81dfdc7b48c2e30ab05e9b30afb0c418bbbe [media] xc5000: drivers should specify chip revision rather than firmware [ 11.868188] ddea427fb3e64d817d4432e5efd2abbfc4ddb02e [media] xc5000: remove static dependencies on xc5000 created by previous changesets [ 12.110903] EXT4-fs (md1): re-mounted. Opts: errors=remount-ro,user_xattr [ 12.213875] usbcore: registered new interface driver snd-usb-audio [ 12.213906] uvcvideo: Found UVC 1.00 deviceunnamed (046d:0990) [ 12.229795] input: UVC Camera (046d:0990) as /devices/pci:00/:00:1a.7/usb1/1-3/1-3:1.0/input/input6 [ 12.229904] usbcore: registered new
Re: Cine CT v6
Hi, Am 22.02.2012 14:05, schrieb Edd Barker: Hi Members I've just got a Cine CT v6 card and have having a bit of trouble. I want to use dvb-t only, I've followed the instructions here... http://linuxtv.org/wiki/index.php/Digital_Devices_DuoFlex_C%26T The card is now appearing in /dev/dvb/adapter0 /dev/dvb/adapter1. However only one frontend is showing up and if I try to scan dvb-t I get an error that I'm sure means I'm trying to use dvb-c tuner. WARNING: frontend type (QAM) is not compatible with requested tuning type (OFDM) I'm running on Ubuntu 11.10, 3.0.0-16 kernal. Is this something anyone else has come across or knows what I can do to use the dvb-t frontend? You can use dvb-fe-tool to switch the type of delivery system used as a default for old applications. In the near past the drivers of hybrid cards were changed so there's only one frontend for all delivery systems, since they can only be opened mutually exclusive. There should be an PPA at Launchpad with a recent version of the tools/utils, but I don't have the URL at the moment. Regards, Lars. Thanks Edd -- 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: DVB TS/PES filters
Hi, Am 01.02.2012 14:32, schrieb Tony Houghton: On Thu, 26 Jan 2012 15:40:15 + Tony Houghtonh...@realh.co.uk wrote: I could do with a little more information about DMX_SET_PES_FILTER. Specifically I want to use an output type of DMX_OUT_TS_TAP. I believe there's a limit on how many filters can be set, but I don't know whether the kernel imposes such a limit or whether it depends on the hardware, If the latter, how can I read the limit? Can anyone help me get more information about this (and the magic number pid of 8192 for the whole stream)? In the TS-header there are 13 bits for the PID, so it can be from 0 to 8191. Therefore dvb-core interprets 8192 (and greater values I think) as all PIDs. Regards, Lars. -- 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] dvb: satellite channel routing (unicable) support
Hi, Am 24.01.2012 14:01, schrieb Mauro Carvalho Chehab: [...] That would be awesome to have this functionality in the kernel. I maintained the unicable-patch for the vdr (written by some guy from the vdr-portal.de who sadly doesn't seem to respond to mails via that forum anymore). It would be great if all the work could be summarized in one ioctl. I don't think that SCR/Unicable, bandstacking, LNBf settings, rotor control, etc. should belong to the Kernel. There are too many variants, and several of them are not properly standardized or properly implemented. Also, the actual options to use will depend on what type of DiSEqC components used on his particular setup. So, it would be very difficult to write something at the Kernel that will fit in all cases. What the Kernel should support is the capability of sending/receiving DiSEqC commands, allowing userspace libraries to do the job of setting it. Such feature is already there, so there's no need to change anything there. That's said, I'm working on a library to be used by applications that want to talk with DVB devices. Together, with the library, there are a scanning tool and a zapping tool. So, inspired by this patch, and using a public tech note about SCR/Unicable [1], I wrote an Unicable patch for such library: http://git.linuxtv.org/v4l-utils.git/commit/6c2c00ed3722465ed781ad49567e34dc7a5f92e7 I'm currently without DVB-S/DVB-S2 antennas, so, I was not able to test it. It would be very nice if you could help us by testing if those tools are working with DVB-S with SCR, and, if not, help fixing its support. Maybe the absence of a good libdvb lead to such patches as the SCR-patch. I understand why such functionality should not be in the kernel. Hopefully the libdvb will combine all nice features for dvb hardware so no application has to build its own implementations. Another advantage will be that there will be only one place where to configure your hardware setup (like SCR, use only specific delivery system of hybrid cards etc.). I myself have only DVB-C but I know someone with a SCR-setup and will try to convince him to test this. Thanks, Lars. [1] http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00045084.pdf Regards, 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 -- 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: HVR 4000 hybrid card still producing multiple frontends for single adapter
Hi, Am 24.01.2012 16:16, schrieb Devin Heitmueller: On Tue, Jan 24, 2012 at 9:58 AM, Antti Palosaaricr...@iki.fi wrote: So what was the actual benefit then just introduce one way more to implement same thing. As I sometime understood from Manu's talk there will not be difference if my device is based of DVB-T + DVB-C demod combination or just single chip that does same. Now there is devices that have same characteristics but different interface. For one thing, you cannot use DVB-T and DVB-C at the same time if they're on the same demod. With many of the devices that have S/S2 and DVB-T, you can be using them both in parallel. Having multiple frontends actually makes sense since you don't want two applications talking to the same frontend at the same time but operating on different tuners/streams. The two frontends of the HVR 4000 can only be open mutually exclusive so I think the recent changes are for those devices, aren't they? Sure you can connect DVB-T and DVB-S at the same time to the HVR 4000, but you can't use it in parallel. Lars. That said, there could be opportunities for consolidation if the demods could not be used in parallel, but I believe that would require a nontrivial restructuring of the core code and API. In my opinion the entry point for the kernel ABI should *never* have been the demodulator but rather the bridge driver (where you can exercise greater control over what can be used in parallel). Devin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Am 03.11.2011 08:49, schrieb Steffen Barszus: Hi ! From a users point of view i would like to have some clarification on this discussion. Lets take a (now real world) example. Having /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/net0 /dev/dvb/adapter1/demux0 /dev/dvb/adapter1/dvr0 /dev/dvb/adapter1/frontend0 /dev/dvb/adapter1/frontend1 /dev/dvb/adapter1/net0 for a C/T card, where one fe is C and the other is T , connector is only one per adapter. How is the logic to handle this ? Two big issues i don't properly understand at the moment. 1.) VDR does not know that frontend1 is related to demux0. since no application changes magically on its own, can someone provide some information of what an application is expected to do, to handle this properly. With this information it could be discussed at i.e. vdr mailing list. 2.) How does an application/user/whatever know what can be used ? I mean there is only C connected OR T - how can the application know what fe can be used (assumed point 1. has been fixed). How would the user know, which is which and how one should specify what is connected ? 3.) ca/caio device handling - is this something an application should implement ... and how. Please help me to understand these points as this is something which pops up regular in discussion with our (yavdr.org) users. For 1 and 2 the only proper solution i see would be 1 frontend instead of 2 with a possibility to specifiy the transport in one way or another. (which - to be discussed) For me as an application developer it wouldn't make sense if the frontend handles multiple delivery types as outlined in approach 2 and 3 from below. That would mean that *every* application has to ask the user and must provide some configuration possibility. And there has to be a new ioctl to set the delivery type (or is there one I don't know about?). Either I have DVB-C or DVB-T. So I would like to specify the delivery type at module load time with an option. Then there would be one frontend and every (existent) application would just work. And it's configured at one place. Everyone who changes the connection frequently should learn to reload the module... :-) Regards, Lars. Regards Steffen On Sat, 16 Jul 2011 17:40:53 +0200 Oliver Endrisso.endr...@gmx.de wrote: On Saturday 16 July 2011 16:54:50 Mauro Carvalho Chehab wrote: Em 16-07-2011 11:16, Antti Palosaari escreveu: On 07/16/2011 03:25 PM, Mauro Carvalho Chehab wrote: Em 15-07-2011 20:41, Antti Palosaari escreveu: On 07/15/2011 08:01 PM, Andreas Oberritter wrote: On 15.07.2011 15:25, Mauro Carvalho Chehab wrote: Em 15-07-2011 05:26, Ralph Metzler escreveu: At the same time I want to add delivery system properties to support everything in one frontend device. Adding a parameter to select C or T as default should help in most cases where the application does not support switching yet. If I understood well, creating a multi-delivery type of frontend for devices like DRX-K makes sense for me. We need to take some care about how to add support for them, to avoid breaking userspace, or to follow kernel deprecating rules, by adding some legacy compatibility glue for a few kernel versions. So, the sooner we add such support, the better, as less drivers will need to support a fallback mechanism. The current DVB version 5 API doesn't prevent some userspace application to change the delivery system[1] for a given frontend. This feature is actually used by DVB-T2 and DVB-S2 drivers. This actually improved the DVB API multi-fe support, by avoiding the need of create of a secondary frontend for T2/S2. Userspace applications can detect that feature by using FE_CAN_2G_MODULATION flag, but this mechanism doesn't allow other types of changes like from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such type of delivery system switch, using the same chip ended by needing to add two frontends. Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and add a way to query the type of delivery systems supported by a driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM I don't think it's necessary to add a new flag. It should be sufficient to add a property like DTV_SUPPORTED_DELIVERY_SYSTEMS, which should be read-only and return an array of type fe_delivery_system_t. Querying this new property on present kernels hopefully fails with a non-zero return code. in which case FE_GET_INFO should be used to query the delivery system. In future kernels we can provide a default implementation, returning exactly one fe_delivery_system_t for unported drivers. Other drivers should be able to override this default implementation in their get_property callback. One thing I want to say is that consider about devices which does have MFE using two different *physical* demods, not
Re: RFC: exposing controls in sysfs
Am 08.04.2010 02:47, schrieb Mike Isely: On Thu, 8 Apr 2010, hermann pitton wrote: Hi, Am Mittwoch, den 07.04.2010, 20:50 +0200 schrieb Lars Hanisch: Am 06.04.2010 16:33, schrieb Mike Isely: [snip] Mike, do you know of anyone actively using that additional information? Yes. The VDR project at one time implemented a plugin to directly interface to the pvrusb2 driver in this manner. I do not know if it is still being used since I don't maintain that plugin. Just FYI: The PVR USB2 device is now handled by the pvrinput-plugin, which uses only ioctls. The old pvrusb2-plugin is obsolete. http://projects.vdr-developer.org/projects/show/plg-pvrinput Lars: Thanks for letting me know about that - until this message I had no idea if VDR was still using that interface. Regards, Lars. [snip] thanks Lars. Mike is really caring and went out for even any most obscure tuner bit to help to improve such stuff in the past, when we have been without any data sheets. Hermann: You might have me confused with Mike Krufky there - he's the one who did so much of the tuner driver overhauling in v4l-dvb in the past. To open second, maybe third and even forth ways for apps to use a device, likely going out of sync soon, does only load maintenance work without real gain. Well it was an experiment at the time to see how well such a concept would work. I had done it in a way to minimize maintenance load going forward. On both counts I feel the interface actually has done very well, nonstandard though it may be. I still get the general impression that the user community really has liked the sysfs interface, but the developers never really got very fond of it :-( From my point of view as an application developer I never tried to use sysfs at all. I admit that it's nice to use from a shell script in known environments (like setting up a card for recording with cat etc.) but what about error handling? How will I (the script) know, if setting a control is successful or not? Currently I don't know if v4l2-ctl returns some useful exit code, but with ioctls it's a lot easier to track errors. I never liked to handle with directories and files, reading and writing if there's a function which is doing the same thing in a much easier way. :-) But all this might be related to my not-really-present knowledge of using sysfs in the right way. And reading other posts debugfs seems to be the better choice (just read some articles on it to get a general survey of it). Regards, Lars. We should stay sharp to discover something others don't want to let us know about. All other ideas about markets are illusions. Or? So, debugfs sounds much better than sysfs for my taste. Any app and any driver, going out of sync on the latter, will remind us that backward compat _must always be guaranteed_ ... Or did change anything on that and is sysfs excluded from that rule? Backwards compatibility is very important and thus any kind of new interface deserves a lot of forethought to ensure that choices are made in the present that people will regret in the future. Making an interface self-describing is one way that helps with compatibility: if the app can discover on its own how to use the interface then it can adapt to interface changes in the future. I think a lot of people get their brains so wrapped around the ioctl-way of doing things and then they try to map that concept into a sysfs-like (or debugfs-like) abstraction that they don't see how to naturally take advantage of what is possible there. -Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: exposing controls in sysfs
Am 06.04.2010 16:33, schrieb Mike Isely: Comments below... On Mon, 5 Apr 2010, Hans Verkuil wrote: Hi all, The new control framework makes it very easy to expose controls in sysfs. The way it is implemented now in the framework is that each device node will get a 'controls' subdirectory in sysfs. Below which are all the controls associated with that device node. So different device nodes can have different controls if so desired. The name of each sysfs file is derived from the control name, basically making it lowercase, replacing ' ', '-' and '_' with '_' and skipping any other non- alphanumerical characters. Seems to work well. For numerical controls you can write numbers in decimal, octal or hexadecimal. When you write to a button control it will ignore what you wrote, but still execute the action. It looks like this for ivtv: $ ls /sys/class/video4linux/video1 controls dev device index name power subsystem uevent $ ls /sys/class/video4linux/video1/controls audio_crcchroma_gain spatial_chroma_filter_type video_bitrate_mode audio_emphasis contrast spatial_filter video_encoding audio_encoding hue spatial_filter_mode video_gop_closure audio_layer_ii_bitrate insert_navigation_packets spatial_luma_filter_typevideo_gop_size audio_mute median_chroma_filter_maximum stream_type video_mute audio_sampling_frequency median_chroma_filter_minimum stream_vbi_format video_mute_yuv audio_stereo_modemedian_filter_typetemporal_filter video_peak_bitrate audio_stereo_mode_extension median_luma_filter_maximumtemporal_filter_mode video_temporal_decimation balance median_luma_filter_minimumvideo_aspect volume brightness mute video_b_frames chroma_agc saturationvideo_bitrate The question is, is this sufficient? One of the few drivers that exposes controls in sysfs is pvrusb2. As far as I can tell from the source it will create subdirectories under the device node for each control. Those subdirs have the name ctl_control-name (e.g. ctl_volume), and below that are files exposing all the attributes of that control: name, type, min_val, max_val, def_val, cur_val, custom_val, enum_val and bit_val. Most are clear, but some are a bit more obscure. enum_val is basically a QUERYMENU and returns all menu options. bit_val seems to be used for some non-control values like the TV standard that pvrusb2 also exposes and where bit_val is a bit mask of all the valid bits that can be used. Mike, if you have any additional information, just let us know. My pvrusb2 is in another country at the moment so I can't do any testing. Hans: What you see in the pvrusb2 driver is the result of an idea I had back in 2005. The pvrusb2 driver has an internal control API; my original idea back then was to then reimplement other interfaces on top of that API, in a manner that is as orthogonal as possible. The reality today is still pretty close to that concept (except for DVB unfortunately since that framework's architecture effectively has to take over the RF tuner...); the V4L2 implementation in the driver certainly works this way. The sysfs interface you see here is the result of implementing the same API through sysfs. Right now with the pvrusb2 driver the only thing not exported through sysfs is the actual streaming of video itself. The entire sysfs implementation in the driver can be found in pvrusb2-sysfs.c. Notice that the file is generic; there is not anything in it that is specific to any particular control. Rather, pvrusb2-sysfs.c is able to iterate through the driver's controls, picking up the control's name, its type, and accessors. Based on what it finds, this module then synthesizes the interface that you see in /class/pvrusb2/* - it's actually possible to add new controls to the driver without changing anything in pvrusb2-sysfs.c. Personally I think that it is overkill to basically expose the whole QUERYCTRL information to sysfs. I see it as an easy and quick way to read and modify controls via a command line. Over time, I have ended up using pretty much every control in that interface. Obviously not every control always gets touched, but I have found it extremely valuable to have such direct access to every knob in the driver this way. Also, the original concept was that the interface was to be orthogonal; in theory any kind of control action in one interface should be just as valid in another. Mike, do you know of anyone actively using that additional information? Yes. The VDR project at one time implemented a plugin to directly interface to the pvrusb2 driver in this manner. I do not know if it is still being used
Re: cx18: where do the transport stream PIDs come from?
Am 28.02.2010 14:04, schrieb Andy Walls: On Fri, 2010-02-26 at 17:23 +0100, Lars Hanisch wrote: Hi, while working on a small test app which repacks the ivtv-PS into a TS, I received a sample from a cx18-based card. The TS contains the video PID 301, audio PID 300 and PCR pid 101. Where do these PIDs come from, are they set by the driver or are they firmware given? For analog captures, for which the firmware creates the TS, the firmware sets them. That's what I thought. So I will use the same IDs for my conversion of an ivtv-PS. Is it possible to change them? It is not possible to tell the firmware to change them. There are two documented CX23418 API commands in cx23418.h: CX18_CPU_SET_VIDEO_PID CX18_CPU_SET_AUDIO_PID Unfortunately, I know they do nothing and will always directly return 0x200800ff, which is a CX23418 API error code. Good to know. Thanks! Lars. Regards, Andy Regards, Lars. -- 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
cx18: where do the transport stream PIDs come from?
Hi, while working on a small test app which repacks the ivtv-PS into a TS, I received a sample from a cx18-based card. The TS contains the video PID 301, audio PID 300 and PCR pid 101. Where do these PIDs come from, are they set by the driver or are they firmware given? Is it possible to change them? Regards, Lars. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] add missing 'p' at card name 'Hauppauge HD PVR'
I don't know if there are applications which rely on this name, but after all it's a spelling mistake. Signed-off-by: Lars Hanisch d...@cinnamon-sage.de --- drivers/media/video/hdpvr/hdpvr-video.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/hdpvr/hdpvr-video.c b/drivers/media/video/hdpvr/hdpvr-video.c index 1c49c07..196f82d 100644 --- a/drivers/media/video/hdpvr/hdpvr-video.c +++ b/drivers/media/video/hdpvr/hdpvr-video.c @@ -573,7 +573,7 @@ static int vidioc_querycap(struct file *file, void *priv, struct hdpvr_device *dev = video_drvdata(file); strcpy(cap-driver, hdpvr); - strcpy(cap-card, Haupauge HD PVR); + strcpy(cap-card, Hauppauge HD PVR); usb_make_path(dev-udev, cap-bus_info, sizeof(cap-bus_info)); cap-version = HDPVR_VERSION; cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | -- 1.6.3.3 -- 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: ivtv-utils/test/ps-analyzer.cpp: error in extracting SCR?
Hi, Just for completeness, attached is the patch against the subversion repository at ivtvdriver.org. Regards, Lars. Am 04.02.2010 08:25, schrieb Hans Verkuil: On Thursday 04 February 2010 04:16:03 Andy Walls wrote: On Thu, 2010-02-04 at 01:18 +0100, Lars Hanisch wrote: Hi, I'm writing some code repacking the program stream that ivtv delivers into a transport stream (BTW: is there existing code for this?). Buy a CX23418 based board. That chip's firmware can produce a TS. I think Compro and LeadTek cards are available in Europe and are supported by the cx18 driver. Since many players needs the PCR I would like to use the SCR of the PS and place it in the adaption field of the TS (if wikipedia [1] and my interpretation of it is correct it should be the same). I stumbled upon the ps-analyzer.cpp in the test-directory of the ivtv-utils (1.4.0). From line 190 to 198 the SCR and SCR extension are extracted from the PS-header. But referring to [2] the SCR extension has 9 bits, the highest 2 bits in the fifth byte after the sync bytes and the lower 7 bits in the sixth byte. The last bit is a marker bit (always 1). So instead of scr_ext = (hdr[4] 0x1) 8; scr_ext |= hdr[5]; I think it should be scr_ext = (unsigned)(hdr[4] 0x3) 7; scr_ext |= (hdr[5] 0xfe) 1; Given the non-authoritative MPEG-2 documents I have, yes, you appear to be correct on this. Please keep in mind that ps-analyzer.cpp is simply a debug tool from an ivtv developer perspective. You base prodcution software off of it at your own risk. :) And the bitrate is coded in the next 22 bits, so it should be mux_rate = (unsigned)(hdr[6]) 14; mux_rate |= (unsigned)(hdr[7]) 6; mux_rate |= (unsigned)(hdr[8] 0xfc) 2; Am I correct? Yes, you are correct. I miscounted the bits when I wrote this originally. Thanks for reporting this! Regards, Hans I did not check this one, but I would not be surprised if ps-analyzer had this wrong too. Regards, Andy Regards, Lars. [1] http://en.wikipedia.org/wiki/Presentation_time_stamp [2] http://en.wikipedia.org/wiki/MPEG_program_stream -- -- 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 Index: test/ps-analyzer.cpp === --- test/ps-analyzer.cpp(Revision 4152) +++ test/ps-analyzer.cpp(Arbeitskopie) @@ -194,11 +194,11 @@ scr |= (u64)(hdr[2] 3) 13; scr |= (u64)hdr[3] 5; scr |= (u64)(hdr[4] 0xf8) 3; - scr_ext = (hdr[4] 0x1) 8; - scr_ext |= hdr[5]; - mux_rate = (hdr[6] 0x7f) 15; - mux_rate |= hdr[7] 7; - mux_rate |= (hdr[8] 0xfe) 1; + scr_ext = (unsigned)(hdr[4] 0x3) 7; + scr_ext |= (hdr[5] 0xfe) 1; + mux_rate = (unsigned)(hdr[6]) 14; + mux_rate |= (unsigned)(hdr[7]) 6; + mux_rate |= (unsigned)(hdr[8] 0xfc) 2; if (g_verbose) printf(%lld: pack scr=%lld scr_ext=%3u scr=%lld ns mux_rate=%u\n, pos, scr, scr_ext, scr2ns(scr, scr_ext), mux_rate);
Re: ivtv-utils/test/ps-analyzer.cpp: error in extracting SCR?
Am 04.02.2010 08:25, schrieb Hans Verkuil: On Thursday 04 February 2010 04:16:03 Andy Walls wrote: On Thu, 2010-02-04 at 01:18 +0100, Lars Hanisch wrote: Hi, I'm writing some code repacking the program stream that ivtv delivers into a transport stream (BTW: is there existing code for this?). Buy a CX23418 based board. That chip's firmware can produce a TS. I think Compro and LeadTek cards are available in Europe and are supported by the cx18 driver. My PVR150 and 350 are still ok and I hope I have DVB-S-access in one or two years... But I will keep that in mind in case I need a new card. Since many players needs the PCR I would like to use the SCR of the PS and place it in the adaption field of the TS (if wikipedia [1] and my interpretation of it is correct it should be the same). I stumbled upon the ps-analyzer.cpp in the test-directory of the ivtv-utils (1.4.0). From line 190 to 198 the SCR and SCR extension are extracted from the PS-header. But referring to [2] the SCR extension has 9 bits, the highest 2 bits in the fifth byte after the sync bytes and the lower 7 bits in the sixth byte. The last bit is a marker bit (always 1). So instead of scr_ext = (hdr[4] 0x1) 8; scr_ext |= hdr[5]; I think it should be scr_ext = (unsigned)(hdr[4] 0x3) 7; scr_ext |= (hdr[5] 0xfe) 1; Given the non-authoritative MPEG-2 documents I have, yes, you appear to be correct on this. Please keep in mind that ps-analyzer.cpp is simply a debug tool from an ivtv developer perspective. You base prodcution software off of it at your own risk. :) Of course I will. :-) I already had coded my part and was looking for references... And the bitrate is coded in the next 22 bits, so it should be mux_rate = (unsigned)(hdr[6]) 14; mux_rate |= (unsigned)(hdr[7]) 6; mux_rate |= (unsigned)(hdr[8] 0xfc) 2; Am I correct? Yes, you are correct. I miscounted the bits when I wrote this originally. Thanks for reporting this! You're welcome! Regards, Lars. Regards, Hans I did not check this one, but I would not be surprised if ps-analyzer had this wrong too. Regards, Andy Regards, Lars. [1] http://en.wikipedia.org/wiki/Presentation_time_stamp [2] http://en.wikipedia.org/wiki/MPEG_program_stream -- -- 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: POLL: for/against dropping support for kernels 2.6.22
Should we drop support for kernels 2.6.22 in our v4l-dvb repository? _: Yes _: No Yes. Why: I'm a v4l-user, I use my VDR for a couple of years now. These were the steps I took, before I assembled my box: - I have analog cable, so what hardware does exist, that is capable to record video on an old PC (even my desktop had only a 400MHz Celeron)? - Which of these pieces are supported by Linux? For me it ended up with a PVR150 and an DXR3, later replaced by a PVR350. I started with kernel 2.6.9, that time ivtv wasn't part of the kernel, it was even outside v4l-dvb (am I correct?). Without a large amount of help from the ivtv-lists and VDR forum, that would have been a disaster for me. I can't say how glad I was, when I read the news, that ivtv was integrated in the kernel. What I'm trying to say is: when you need support for hardware, you have to upgrade your kernel and there are many other people beside the main driver developer which can help you. In the hot time of integrating ivtv in the kernel, I back off asking Hans for supporting an older kernel, since all I wanted was a working driver. And if that means I have to upgrade the kernel, I just have to do it. I get paid for developing and maintaining some specialized desktop applications since ~15 years now (~200 users), and from that point of view, sometimes you have to drop support for older installations respectively have to upgrade those to some level, because it's just a pain. I can remember what a relief it was, to be able to drop support for Windows 98 and base my company's (rather complex and large) ERP-app on some real Windows (= 2000). (right now we're right in the middle of porting from Win32/C++ to .Net3.5/C#, guess who will make a jig when it's done...) Reading the diverse postings and from my point of knowledge and experience, I think it's best to swap the development model to an in kernel-tree, that feeds a compat-tree, which supports kernel-versions that are reasonable. And if someone has fun backporting (i2c-related) drivers below 2.6.22, than let him do it. But let the main developer do their work in keeping uptodate with new hardware and new kernels. They get old soon enough. (the kernel, not the developers...) ;-) Lars. -- 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] Cross-posting linux-media, linux-dvb etc
Mike Isely wrote: On Fri, 16 Jan 2009, Hans Verkuil wrote: On Friday 16 January 2009 15:48:45 Patrick Boettcher wrote: Hi Mauro, Since the creation of linux-media@vger.kernel.org I'm seeing lots of cross-postings between linux-dvb, linux-media and video4linux. This is a little bit annoying if you are subscribed to all of those lists. Worse is, that some people only send requests to linux-media. Like that linux-dvb-only subscribers can't help... Why not closing linux-dvb (and video4linux) and transferring the currently subscribed users to linux-media automatically? I agree with Patrick. I suggest a daily automatic posting to linux-dvb and video4linux telling people that on February 1st these lists disappear and that they should use linux-media instead. Then they can be closed down at the end of the month. I definitely wouldn't wait any longer since it is rather messy right now. One month transition period seems reasonable to me. Amen to that. I've been telling people to go over to linux-media, but old habits are hard to break. It's time to actually make a clean break from the old lists. +1 from me Although I'm not an active developer (I'm just an interested user), reading the lists at the moment is hard... Lars. -- 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
