Re: Digital Devices Cine S2 V6.5, PCIe, Dual

2013-12-30 Thread Lars Hanisch
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

2012-12-01 Thread Lars Hanisch
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()

2012-08-15 Thread Lars Hanisch
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

2012-02-27 Thread Lars Hanisch

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

2012-02-26 Thread Lars Hanisch

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

2012-02-22 Thread Lars Hanisch

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

2012-02-01 Thread Lars Hanisch

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

2012-01-24 Thread Lars Hanisch

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

2012-01-24 Thread Lars Hanisch

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)

2011-11-03 Thread Lars Hanisch

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

2010-04-08 Thread Lars Hanisch

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

2010-04-07 Thread Lars Hanisch

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?

2010-03-02 Thread Lars Hanisch

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?

2010-02-26 Thread Lars Hanisch

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'

2010-02-14 Thread Lars Hanisch

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?

2010-02-07 Thread Lars Hanisch

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?

2010-02-04 Thread Lars Hanisch

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


ivtv-utils/test/ps-analyzer.cpp: error in extracting SCR?

2010-02-03 Thread Lars Hanisch

Hi,

 I'm writing some code repacking the program stream that ivtv delivers 
into a transport stream (BTW: is there existing code for this?). 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;

 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?

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


Re: POLL: for/against dropping support for kernels 2.6.22

2009-02-25 Thread Lars Hanisch

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

2009-01-16 Thread Lars Hanisch

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