Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi Andreas [...] You don't need to wait for write-only operations. Basically all demux ioctls are write-only. Since vtunerc is using dvb-core's software demux *locally*, errors for invalid arguments etc. will be returned as usual. What's left is one call to FE_SET_FRONTEND for each frequency to tune to, and one FE_READ_STATUS for each time the lock status is queried. Note that one may use FE_GET_EVENT instead of FE_READ_STATUS to get notified of status changes asynchronously if desired. Btw.: FE_SET_FRONTEND doesn't block either, because the driver callback is called from a dvb_frontend's *local* kernel thread. Still, vtunerc waits for write operations: http://code.google.com/p/vtuner/source/browse/vtunerc_proxyfe.c?repo=linux-driver#285 No matter if they are read or write, all of them call this function: http://code.google.com/p/vtuner/source/browse/vtunerc_ctrldev.c?repo=linux-driver#390 That has a wait_event inside that function, as everything is directed to the userspace. Please, stop writing such bullshit! Just before the call to wait_event there's code to return from the function if waiting has not been requested. This is probably the way Florian found to return the errors returned by the ioctls. This driver is synchronous, with simplifies it, at the lack of performance. The fix is easy: set the third parameter to 0. A DVB application doesn't need to know whether SET_VOLTAGE etc. succeeded or not, because it won't get any feedback from the switch. If tuning fails, it has to retry anyway, even if all ioctls returned 0. Ok, the driver could be smarter than that, and some heuristics could be added into it, in order to foresee the likely error code, returning it in advance, and then implementing some asynchronous mechanism that would handle the error later, but that would be complex and may still introduce some bad behaviors. There's no need to handle errors that don't occur. Nobody said that the implementation of vtunerc was perfect. I've already listed many things that need to be changed in order to even consider it for merging. Exactly that was an intention for my first RFC - to get driver reviewed by kernel hackers and enhance/fixe it to prepare it for merging. I'm going to address all your findings during Xmass, so hopefully I will spam here again after New Year :-) I very appreciate your POV which helped me stay remembering it is not way to the wall. Thanks Honza -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi 2011/12/5 Florian Fainelli f.faine...@gmail.com: Hello, On 12/03/11 01:37, HoP wrote: Hi Alan. 2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk: On Thu, 1 Dec 2011 15:58:41 +0100 HoPjpetr...@gmail.com wrote: Hi, let me ask you some details of your interesting idea (how to achieve the same functionality as with vtunerc driver): [...] The driver, as proposed, is not really a driver, as it doesn't support any hardware. The kernel driver would be used to just copy data from one userspace Please stop learning me what can be called driver and what nope. Your definition is nonsense and I don't want to follow you on it. You can stick your fingers in your ears and shout all you like but given Mauro is the maintainer I'd suggest you work with him rather than making it painful. One of the failures we routinely exclude code from the kernel for is best described as user interface of contributor You may be not read all my mails but I really tried to be very positive in them. I wanted to focus on my Subject, but Mauro has, sometimes, the demand to focus on insignificant things (like if the code is driver or not). At least it is my feeling from all those disscussions with him. It's a loopback that adds a performance hit. The right way to do this is in userspace with the userspace infrastructure. At that point you can handle all the corner cases properly, integrate things like service discovery into your model and so on - stuff you'll never get to work that well with kernel loopback hackery. Can you show me, how then can be reused most important part of dvb-core subsystem like tuning and demuxing? Or do you want me to invent wheels and to recode everything in the library? Of course You could certainly build a library from the same code. That might well be a good thing for all kinds of 'soft' DV applications. At that point the discussion to have is the best way to make that code sharable between a userspace library and the kernel and buildable for both. I can be wrong, I'm no big kernel hacker. So please show me the way for it. BTW, even if you can find the way, then data copying from userspace to the kernel and back is also necessery. I really don't see any advantage of you solution. In a properly built media subsystem you shouldn't need any copies beyond those that naturally occur as part of a processing pass and are therefore free. I may describe project goal, in few sentences: We have small box, running embedded linux with 2 satellite tuners on input and ethernet. Nothing more. We have designed the box for live sat TV/Radio reception, distributing them down to the network. One of the mode of working is vtuner, what allows reuse those tuners remotely on linux desktop. The kernel part is very simple code exposing kernel's dvb-core to the userspace. Userspace client/server tools do all resource discovery and connection management. It works nicely and guys with vdr who is using it are rather satisfied with it. So, the main goal of vtuner code is to fully virtualize remote DVB adapter. To any linux dvb api compatible applications and tools. The vtuner kernel code seems to be the simplest and straightforward way to achieve it. The company I work for also has something like this. We can attach a DVB tuner to either the Gateway or the STB we provide and use it indifferently , except that we have the following architecture: - a DVB daemon controlling the physical DVB tuner and exposing methods for tuning/scanning/zapping - a web server and web services for accessing the DVB daemon methods - a RTSP streamer with associated methods for controlling streaming The software running on both devices is the same (one compiled for ARM, the other for x86). I do not see any problem with this solution, people wanting to get the stream can still get the RTSP stream directly joining the multicast group, which is fortunately OS agnostic at the same time. Nice. Are your solution open-sourced? If so, can you give me URL? I still think the code is very similar to NBD (Network block device) what sits in the kernel and is using silently. I guess NBD also do data copying from/to user space. Is there something what I overlooked? Can you show me the way (hint please) I can initiate TCP connection from within kernel space? If I can do it, then the big disadvantage of data passing to and from kernel can be removed. Don't do this in kernel-space (remember the mechanism/policy split). Yes, that can be the issue, I understand that. You know - I'm a bit confused. Somebody are pointing on double data copying (userspace networked daemon - kernel - application) issue and another one warn me to not start network connection from the kernel. But if it works for NFS or CIFS then it should not be so weaky, isn't it? I must say that the box is primary focused to the DLNA/UpnP world, so vtuner feature is something like interesting addon only. But I
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
I doubt that scan or w_scan would support it. Even if it supports, that would mean that, for each ioctl that would be sent to the remote server, the error code would take 480 ms to return. Try to calculate how many time w_scan would work with that. The calculus is easy: see how many ioctl's are called by each frequency and multiply by the number of frequencies that it would be seek. You should then add the delay introduced over streaming the data from the demux, using the same calculus. This is the additional time over a local w_scan. A grouch calculus with scandvb: to tune into a single DVB-C frequency, it used 45 ioctls. Each taking 480 ms round trip would mean an extra delay of 21.6 seconds. There are 155 possible frequencies here. So, imagining that scan could deal with 21.6 seconds of delay for each channel (with it doesn't), the extra delay added by it is 1 hour (45 * 0.48 * 155). On the other hand, a solution like the one described by Florian would introduce a delay of 480 ms for the entire scan to happen, as only one data packet would be needed to send a scan request, and one one stream of packets traveling at 10GB/s would bring the answer back. Andreas was excited by your imaginations and calculations, but not me. Now you again manifested you are not treating me as partner for discussion. Otherwise you should try to understand how-that-ugly-hack works. But you surelly didn't try to do it at all. How do you find those 45 ioctls for DVB-C tune? I still see only one ioctl FE_SET_FRONTEND or v5+ variant FE_SET_PROPERTY. Sorry, but, for example, szap tunes very close to local variant: # time szap -c channels.conf -x Ocko reading channels from file 'channels.conf' zapping to 15 'ocko': sat 0, frequency = 12168 MHz V, symbolrate 2750, vpid = 0x00a0, apid = 0x0050 sid = 0x1451 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 1f | signal d410 | snr d380 | ber | unc | FE_HAS_LOCK 0.00user 0.00system 0:01.33elapsed 0%CPU (0avgtext+0avgdata 2000maxresident)k 0inputs+0outputs (0major+171minor)pagefaults 0swaps Honza -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi Michael 2011/12/5 Michael Krufky mkru...@linuxtv.org: On Mon, Dec 5, 2011 at 9:28 AM, HoP jpetr...@gmail.com wrote: Hi 2011/12/5 Florian Fainelli f.faine...@gmail.com: Hello, On 12/03/11 01:37, HoP wrote: Hi Alan. 2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk: On Thu, 1 Dec 2011 15:58:41 +0100 HoPjpetr...@gmail.com wrote: Hi, let me ask you some details of your interesting idea (how to achieve the same functionality as with vtunerc driver): [...] The driver, as proposed, is not really a driver, as it doesn't support any hardware. The kernel driver would be used to just copy data from one userspace Please stop learning me what can be called driver and what nope. Your definition is nonsense and I don't want to follow you on it. You can stick your fingers in your ears and shout all you like but given Mauro is the maintainer I'd suggest you work with him rather than making it painful. One of the failures we routinely exclude code from the kernel for is best described as user interface of contributor You may be not read all my mails but I really tried to be very positive in them. I wanted to focus on my Subject, but Mauro has, sometimes, the demand to focus on insignificant things (like if the code is driver or not). At least it is my feeling from all those disscussions with him. It's a loopback that adds a performance hit. The right way to do this is in userspace with the userspace infrastructure. At that point you can handle all the corner cases properly, integrate things like service discovery into your model and so on - stuff you'll never get to work that well with kernel loopback hackery. Can you show me, how then can be reused most important part of dvb-core subsystem like tuning and demuxing? Or do you want me to invent wheels and to recode everything in the library? Of course You could certainly build a library from the same code. That might well be a good thing for all kinds of 'soft' DV applications. At that point the discussion to have is the best way to make that code sharable between a userspace library and the kernel and buildable for both. I can be wrong, I'm no big kernel hacker. So please show me the way for it. BTW, even if you can find the way, then data copying from userspace to the kernel and back is also necessery. I really don't see any advantage of you solution. In a properly built media subsystem you shouldn't need any copies beyond those that naturally occur as part of a processing pass and are therefore free. I may describe project goal, in few sentences: We have small box, running embedded linux with 2 satellite tuners on input and ethernet. Nothing more. We have designed the box for live sat TV/Radio reception, distributing them down to the network. One of the mode of working is vtuner, what allows reuse those tuners remotely on linux desktop. The kernel part is very simple code exposing kernel's dvb-core to the userspace. Userspace client/server tools do all resource discovery and connection management. It works nicely and guys with vdr who is using it are rather satisfied with it. So, the main goal of vtuner code is to fully virtualize remote DVB adapter. To any linux dvb api compatible applications and tools. The vtuner kernel code seems to be the simplest and straightforward way to achieve it. The company I work for also has something like this. We can attach a DVB tuner to either the Gateway or the STB we provide and use it indifferently , except that we have the following architecture: - a DVB daemon controlling the physical DVB tuner and exposing methods for tuning/scanning/zapping - a web server and web services for accessing the DVB daemon methods - a RTSP streamer with associated methods for controlling streaming The software running on both devices is the same (one compiled for ARM, the other for x86). I do not see any problem with this solution, people wanting to get the stream can still get the RTSP stream directly joining the multicast group, which is fortunately OS agnostic at the same time. Nice. Are your solution open-sourced? If so, can you give me URL? I still think the code is very similar to NBD (Network block device) what sits in the kernel and is using silently. I guess NBD also do data copying from/to user space. Is there something what I overlooked? Can you show me the way (hint please) I can initiate TCP connection from within kernel space? If I can do it, then the big disadvantage of data passing to and from kernel can be removed. Don't do this in kernel-space (remember the mechanism/policy split). Yes, that can be the issue, I understand that. You know - I'm a bit confused. Somebody are pointing on double data copying (userspace networked daemon - kernel - application) issue and another one warn me to not start network connection from the kernel. But if it works for NFS or CIFS then it should not be so weaky, isn't it? I
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi. 2011/12/3 VDR User user@gmail.com: On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter o...@linuxtv.org wrote: You could certainly build a library to reach a different goal. The goal of vtuner is to access remote tuners with any existing program implementing the DVB API. So you could finally use VDR as a server/client setup using vtuner, right? With full OSD, timer, etc? Yes, I'm aware that streamdev exists. It was horrible when I tried it last (a long time ago) and I understand it's gotten better. But it's not a suitable replacement for a real server/client setup. It sounds like using vtuner, this would finally be possible and since Klaus has no intention of ever modernizing VDR into server/client (that I'm aware of), it's also the only suitable option as well. Or am I wrong about anything? If not, I know several users who would like to use this, myself included. Well, initial report was made on vdr-portal because of our hardware announce, but you can be sure the same is true if server is build on any linux hardware. Here is some note: http://www.vdr-portal.de/board18-vdr-hardware/board84-allgemein/106610-das-neue-netzwerk-client-der-f%C3%BCr-vdr-verwenden-k%C3%B6nnen/?highlight=vtuner Additional info you can find (or ask) on our forum: http://forum.nessiedvb.org/forum/viewforum.php?f=11 Please note, that compilation of vtunerc kernel driver (or loopback, or pigback or whatever name the code should be used) is simple - no need for any kernel real patching is required. Code can be compiled outside of the kernel tree (of course kernel headers are still needed). Some useful hints regarding userland application daemons you can find in our wiki: http://wiki.nessiedvb.org/wiki/doku.php?id=vtuner_mode When you get vtunerc and vtunerd applications connected, try simple command line tuning (szap/tzap or czap) to check if it works correctly. Only if you get zapping working switch to vdr. Honza -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Devin, I perfectly remember your opinion regarding vtuner. 2011/12/3 Devin Heitmueller dheitmuel...@kernellabs.com: On Sat, Dec 3, 2011 at 12:42 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Sat, 3 Dec 2011 09:21:23 -0800 VDR User user@gmail.com wrote: On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter o...@linuxtv.org wrote: You could certainly build a library to reach a different goal. The goal of vtuner is to access remote tuners with any existing program implementing the DVB API. So you could finally use VDR as a server/client setup using vtuner, right? With full OSD, timer, etc? Yes, I'm aware that streamdev exists. It was horrible when I tried it last (a long time ago) and I understand it's gotten better. But it's not a suitable replacement for a real server/client setup. It sounds like using vtuner, this would finally be possible and since Klaus has no intention of ever modernizing VDR into server/client (that I'm aware of), it's also the only suitable option as well. I would expect it to still suck. One of the problems you have with trying to pretend things are not networked is that you fake asynchronous events synchronously, you can't properly cover error cases and as a result you get things like ioctls that hang for two minutes or fail in bogus and bizarre ways. If you loop via userspace you've also got to deal with deadlocks and all sorts of horrible cornercases like the user space daemon dying. There is a reason properly working client/server code looks different - it's not a trivial transformation and faking it kernel side won't be any better than faking it in user space - it may well even be a worse fake. Alan This whole notion of creating fake kernel devices to represent networked tuners feels like a hack. If applications want to access networked tuners, adding support for RTP/RTSP or incorporating libhdhomerun (LGPL) is a fairly straightforward exercise. In fact, many applications already have incorporated support for one of these two approaches. The fact that app maintainers have been unwilling/uninterested to do such doesn't feel like it should be an excuse for hacking this functionality into the kernel. Still the same nonsense - why I should add 10x or even 100 times more code to achieve not the same but may be 80-90% same result? The idea is hell simple = allow to use those remote tuners by 100% of dvb api compliant applications. Not 80%, but 100%. Honza -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi, Some input from the sideline reading this discussion. As a FreeBSD'er I would very much like to see two things happen: - vtunerc goes into userspace like a client/server daemon pair using CUSE and can support _any_ /dev/dvb/adapter, also those created by CUSE itself. That means I could potentially use vtunerc in FreeBSD with drivers like cx88: Vtuner already has userland client/server pair. The server application is connecting to _any_ /dev/dvb/adapter device. Please look at small picture here: http://code.google.com/p/vtuner/wiki/BigPicture That means the server part is using totally clean linux. Nothing more. http://corona.homeunix.net/cx88wiki - DVB-X solution in Linux gets mmap support to avoid endless copying of data between kernel and userspace. Adding nmap support should be straightforward. I have it on my TODO. Honza -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Well, initial report was made on vdr-portal because of our hardware announce, but you can be sure the same is true if server is build on any linux hardware. Here is some note: http://www.vdr-portal.de/board18-vdr-hardware/board84-allgemein/106610-das-neue-netzwerk-client-der-f%C3%BCr-vdr-verwenden-k%C3%B6nnen/?highlight=vtuner Additional info you can find (or ask) on our forum: http://forum.nessiedvb.org/forum/viewforum.php?f=11 Please note, that compilation of vtunerc kernel driver (or loopback, or pigback or whatever name the code should be used) is simple - no need for any kernel real patching is required. Code can be compiled outside of the kernel tree (of course kernel headers are still needed). Some useful hints regarding userland application daemons you can find in our wiki: http://wiki.nessiedvb.org/wiki/doku.php?id=vtuner_mode When you get vtunerc and vtunerd applications connected, try simple command line tuning (szap/tzap or czap) to check if it works correctly. Only if you get zapping working switch to vdr. Thanks for the info and links. I do know many guys who would be interested in this if it can provide good server/client ability with VDR. However, a large number of us only speak english so places like vdr-portal aren't much use a lot of the time. If you have english forums somewhere, that link would be far more useful I think. No problem. Simply ignore first URL. All others are english :-) I would recommend start from how-it-works-diagram: http://code.google.com/p/vtuner/wiki/BigPicture and then have a look at wiki. where you can some step-by-step info. Anyway, don't hesitate to ask any question in our forum or write me directly. Honza -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
[...] you failed to convince people why this can't be implemented on userspace, Wrong. You failed to convince people why this must be implemented in userspace. Even Michael Krufky, who's only against merging it, likes the idea, because it's useful. Sometimes, when I'm debugging a driver, I use to add several hacks inside the kernelspace, in order to do things that are useful on my development (debug printk's, dirty hacks, etc). I even have my own set of patches that I apply on kvm, in order to sniff PCI traffic. This doesn't mean that I should send all those crap upstream. If you want to disscuss, please better use wordings. Even my Subject was not about endless discussion that your userspace aproach is better (me, Andreas and few others doesn't agree with you, it is your own POV, nobody follows you, if you not noted) don't be so offensive regarding my code. I don't thing it is so crap. Just because something can be implemented in userspace doesn't mean that it's technically superior. True, but I didn't see anything at the submitted code or at the discussions showing that implementing it in kernelspace is technically superior. What I'm seeing is what is coded there: http://code.google.com/p/vtuner/ The kernelspace part is just a piggyback driver, that just copies data from/to the dvb calls into another device, that sends the request back to userspace. A separate userspace daemon will get such results and send to the network stack: http://code.google.com/p/vtuner/source/browse/vtuner-network.c?repo=apps This is technically inferior of letting the application just talk to vtuner directly via some library call. Btw, applications like vdr, vlc, kaffeine and others already implement their own ways to remotelly access the DVB devices without requiring any kernelspace piggyback driver. This in not only about well-known fatty applications like vdr, kaffeine etc. Using vtunerc allows to use any dvb api compatible tools. Like tools from dvb-tools package (szap/dvbsnoop/...) There is no more general way of having dvb adapter virtualized. the driver adds hooks at kernelspace that would open internal API's that several developers don't agree on exposing at userspace, as would allow non GPL license compatible drivers to re-use their work in a way they are against. What's left is your unreasonable GPL blah blah. So the answer to Honza's question is: Yes, Mauro is nacking the driver because he's worrying about possible misuse. Well, yes. I feel the same what wrote Andreas. The only pity is that nobody from outside linuxm-media need to comment that. Honza -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi Alan. 2011/12/3 Alan Cox a...@lxorguk.ukuu.org.uk: On Thu, 1 Dec 2011 15:58:41 +0100 HoP jpetr...@gmail.com wrote: Hi, let me ask you some details of your interesting idea (how to achieve the same functionality as with vtunerc driver): [...] The driver, as proposed, is not really a driver, as it doesn't support any hardware. The kernel driver would be used to just copy data from one userspace Please stop learning me what can be called driver and what nope. Your definition is nonsense and I don't want to follow you on it. You can stick your fingers in your ears and shout all you like but given Mauro is the maintainer I'd suggest you work with him rather than making it painful. One of the failures we routinely exclude code from the kernel for is best described as user interface of contributor You may be not read all my mails but I really tried to be very positive in them. I wanted to focus on my Subject, but Mauro has, sometimes, the demand to focus on insignificant things (like if the code is driver or not). At least it is my feeling from all those disscussions with him. It's a loopback that adds a performance hit. The right way to do this is in userspace with the userspace infrastructure. At that point you can handle all the corner cases properly, integrate things like service discovery into your model and so on - stuff you'll never get to work that well with kernel loopback hackery. Can you show me, how then can be reused most important part of dvb-core subsystem like tuning and demuxing? Or do you want me to invent wheels and to recode everything in the library? Of course You could certainly build a library from the same code. That might well be a good thing for all kinds of 'soft' DV applications. At that point the discussion to have is the best way to make that code sharable between a userspace library and the kernel and buildable for both. I can be wrong, I'm no big kernel hacker. So please show me the way for it. BTW, even if you can find the way, then data copying from userspace to the kernel and back is also necessery. I really don't see any advantage of you solution. In a properly built media subsystem you shouldn't need any copies beyond those that naturally occur as part of a processing pass and are therefore free. I may describe project goal, in few sentences: We have small box, running embedded linux with 2 satellite tuners on input and ethernet. Nothing more. We have designed the box for live sat TV/Radio reception, distributing them down to the network. One of the mode of working is vtuner, what allows reuse those tuners remotely on linux desktop. The kernel part is very simple code exposing kernel's dvb-core to the userspace. Userspace client/server tools do all resource discovery and connection management. It works nicely and guys with vdr who is using it are rather satisfied with it. So, the main goal of vtuner code is to fully virtualize remote DVB adapter. To any linux dvb api compatible applications and tools. The vtuner kernel code seems to be the simplest and straightforward way to achieve it. I still think the code is very similar to NBD (Network block device) what sits in the kernel and is using silently. I guess NBD also do data copying from/to user space. Is there something what I overlooked? Can you show me the way (hint please) I can initiate TCP connection from within kernel space? If I can do it, then the big disadvantage of data passing to and from kernel can be removed. I must say that the box is primary focused to the DLNA/UpnP world, so vtuner feature is something like interesting addon only. But I was myself very nice surprised how good it behaves on real installations and that was reason I decided to try to get it included in kernel. I see that in present there is no willingness for code acceptation, so I will continue out of the kernel tree. Anyway, if I can find the way how to start TCP connection from the kernel part, I understand it can boost throughput very nicely up. Honza -- 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] vtunerc: virtual DVB device
Hi On Wed, 30 Nov 2011 22:38:33 +0100, HoP jpetr...@gmail.com wrote: I have one big problem with it. I can even imagine that some bad guys could abuse virtual driver to use it for distribution close-source drivers in the binary blobs. But is it that - worrying about bad boys abusing - the sufficient reason for such aggressive NACK which I did? I am not a LinuxTV developer so I am not in position to take a stand for or against this. Ultimately though, either your driver is rejected or it is accepted. This is not really a matter of being aggressive or not. It just so happens that many Linux-DVB contributors feel the same way against that class of driver. Also note the fear of GPL avoidance is not unique to Linux-DVB. If I am not mistaken there is no user-space socket API back-end for the same reasons. And there is also no _in-tree_ loopback V4L2 device driver in kernel. Well, that is why I was asking again - in some parts there are similar drivers accepted and in another parts no. Really confusing to me. I'm not kernel hacker, so I didn't know about historical cases. Sorry. [...] I can't understand that because I see very similar drivers in kernel for ages (nbd, or even more similar is usbip) and seems they don't hamper to anybody. Sure. On That said, the Network Block Device, USB-IP and TUNTAP are not really competing with real drivers because of their high perfomance impact, so they are probably not the best examples to support your argument. uinput and ALSA loopback would seem like better examples to me. Thanks for hints. It is no problem to use another arguments, if things get cleaner then :-) I would like to note that I don't want to start any flame-war, so very short answer would be enough for me. Did you try to implement this through CUSE? Then there should be no GPL problems. Also then you do not need to convince anybody to take your driver in the kernel. I did a very quick look on CUSE and if I understood it well, it was usable for drivers not need for cooperation of other kernel internal subsystems. But DVB driver usually use dvb-core subsystem (for tuning and for pid filtering/demuxing), so I don't see the way how to connect there. I think it is impossible. Honza -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
2011/12/1 Mauro Carvalho Chehab mche...@redhat.com: On 01-12-2011 12:58, HoP wrote: Hi, let me ask you some details of your interesting idea (how to achieve the same functionality as with vtunerc driver): [...] The driver, as proposed, is not really a driver, as it doesn't support any hardware. The kernel driver would be used to just copy data from one userspace Please stop learning me what can be called driver and what nope. Your definition is nonsense and I don't want to follow you on it. application to the other. The same result could be obtained in userspace, by implementing a library. Such library could even use LD_PRELOAD to support binary only applications, like what libv4l does. In terms of performance, such library would probably perform better than a kernel driver, as there's no need to do context switching for each call, and no need to talk with a device (where kernel outperforms userspace). Also, depending on how such library is implemented, double buffering might be avoided. So, from architectural POV, this code should be written as an userspace library. BTW, alsa also came with the same results, years ago, as audio remote streaming is supported via userspace tools, like pulseaudio. Can you show me, how then can be reused most important part of dvb-core subsystem like tuning and demuxing? Why do you need to implement it? Just forward the requests to the machine with the real driver. Or do you want me to invent wheels and to recode everything in the library? Kernel code is GPLv2. You can use its code on a GPLv2 licensed library. I see. So if you think it is nice to get dvb-core, make a wrapper around to get it usable in userspace and maintain totally same functionality by myself then I say it is no go. If it looks for you like good idea I must disagree. Code duplication? Two maintaners? That is crazy idea man. Of course I can be wrong, I'm no big kernel hacker. So please show me the way for it. BTW, even if you can find the way, then data copying from userspace to the kernel and back is also necessery. See libv4l, at v4l2-utils.git (at linuxtv.org). I really don't see any advantage of you solution. And I can't see any advantage on yours ;) Putting something that belongs to userspace into kernelspace just because it is easier to re-use the existing code inside the kernel is not a good argument. It is only your POV that it should be in userspace. Creating additional code which not only enlarge code size by 2 but I think by 10 is really not good idea. And it get no advantage only disadvantages. Don't get me wrong but if you want to submit a code to be merged on any existing software (being open source or not), you should be prepared to defend your code and justify the need for it to the other developers. Sure. I was prepared for technical disscussion, but was fully suprised that it was not happend (ok, to be correct, few guys are exception, like Andreas and few others. I really appreciate it). So, my question was still not answered: Can be driver NACKed only because of worrying about possible misuse? Honza -- 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
[RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi folks. I need to warn you that my mail is a bit little longer then I would like to be.But I'm not able to ask my question without some background information. On June 19th, I was sending the driver to the Linux-media mailing list. Original announcement is there: http://www.spinics.net/lists/linux-media/msg34240.html One would say that the code describes very well what it does = adds virtual DVB device. To be more clear on it I have even done some small picture: http://www.nessiedvb.org/wiki/doku.php?id=vtuner_bigpicture I was hoping to get any feedback regarding code implementation. It was my first code for the kernel and I felt very well that some part can be done better or even simpler. What really surprised me badly was that when I read all 54 responses I have counted only two real technical answers!!! All rest were about POLITICAL issues - code was NACKed w/o any technical discussion. Because of fear of possible abusing of driver. I didn't know that there existed very big movement against such code in dvb-core subsystem before. I have one big problem with it. I can even imagine that some bad guys could abuse virtual driver to use it for distribution close-source drivers in the binary blobs. But is it that - worrying about bad boys abusing - the sufficient reason for such aggressive NACK which I did? Then would be better to remove loadable module API fully from kernel. Is it the right way? Please confirm me that worrying about abusive act is enough to NACK particular driver. Then I may be definitely understand I'm doing something wrong and will stay (with such enemy driver) out of tree. I can't understand that because I see very similar drivers in kernel for ages (nbd, or even more similar is usbip) and seems they don't hamper to anybody. I would like to note that I don't want to start any flame-war, so very short answer would be enough for me. Regards Honza PS: Please be so kind and CC the answer/comment to me, I'm only on linux-media ML, not on linux-kernel ML. Thanks. BTW, if accidentally, somebody find it interesting and would like to help me doing code review, there is the code hosted now: http://code.google.com/p/vtuner/source/browse?repo=linux-driver -- 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: Smart card reader support for Anysee DVB devices
If you would like to help me then you can find out correct device name and whats needed for that. I mainly see following possibilities; * /dev/ttyAnyseeN * /dev/ttyDVBN * /dev/adapterN/serial /dev/ttyscXN or /dev/dvb/adapterX/scN where X = ordered adapter number and N = ordered smartcard number in one device /Honza -- 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
[PATH v2] cxd2820r: fix possible out-of-array lookup
When I2C_WRITE is used the msg[] array contains one element only.
Don't access msg[1] in that case. Also moved rest of msg2[1]
setting to be used only if needed.
Signed-off-by: Honza Petrous jpetr...@smartimp.cz
---
diff -r ae517614bf00 drivers/media/dvb/frontends/cxd2820r_core.c
--- a/drivers/media/dvb/frontends/cxd2820r_core.c Thu Jul 28 15:44:49
2011 +0200
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c Thu Jul 28 16:20:17
2011 +0200
@@ -747,12 +747,7 @@ static int cxd2820r_tuner_i2c_xfer(struc
.flags = 0,
.len = sizeof(obuf),
.buf = obuf,
- }, {
- .addr = priv-cfg.i2c_address,
- .flags = I2C_M_RD,
- .len = msg[1].len,
- .buf = msg[1].buf,
- }
+ },
};
obuf[0] = 0x09;
@@ -760,6 +755,11 @@ static int cxd2820r_tuner_i2c_xfer(struc
if (num == 2) { /* I2C read */
obuf[1] = (msg[0].addr 1) | I2C_M_RD; /* I2C RD flag */
msg2[0].len = sizeof(obuf) - 1; /* maybe HW bug ? */
+
+ msg2[1].addr = priv-cfg.i2c_address,
+ msg2[1].flags = I2C_M_RD,
+ msg2[1].len = msg[1].len,
+ msg2[1].buf = msg[1].buf,
}
memcpy(obuf[2], msg[0].buf, msg[0].len);
--
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] cxd2820r: fix possible out-of-array lookup
Hi Antti 2011/7/23 Antti Palosaari cr...@iki.fi: On 07/23/2011 02:01 AM, HoP wrote: 2011/7/23 Antti Palosaaricr...@iki.fi: On 07/23/2011 01:47 AM, HoP wrote: 2011/7/23 Antti Palosaaricr...@iki.fi: On 07/23/2011 01:18 AM, HoP wrote: In case of i2c write operation there is only one element in msg[] array. Don't access msg[1] in that case. NACK. I suspect you confuse now local msg2 and msg that is passed as function parameter. Could you double check and explain? Can you confirm your NACK? As I wrote before, my patch was about read access out of msg[] array parameter of function cxd2820r_tuner_i2c_xfer() in case when msg[] array has only one element (what should be case when using tda18271_write_regs() for example). Or am I still missed something? [snip] And one point more for I2C implementations, i2c_transfer() should implement repeated start sequence to messages given. But I am almost sure there is rather none I2C adapter HW which can do that really. Whole i2c_transfer() Strange enought. Or may better say that linux/i2c.h must fool if you are right, because there you can read: --- linux/i2c.h --- * An i2c_msg is the low level representation of one segment of an I2C * transaction. It is visible to drivers in the @i2c_transfer() procedure, * to userspace from i2c-dev, and to I2C adapter drivers through the * @i2c_adapter.@master_xfer() method. * * Except when I2C protocol mangling is used, all I2C adapters implement * the standard rules for I2C transactions. Each transaction begins with a * START. That is followed by the slave address, and a bit encoding read * versus write. Then follow all the data bytes, possibly including a byte * with SMBus PEC. The transfer terminates with a NAK, or when all those * bytes have been transferred and ACKed. If this is the last message in a * group, it is followed by a STOP. Otherwise it is followed by the next * @i2c_msg transaction segment, beginning with a (repeated) START. --- It says quite the reverse - all multimessage transfers have using repeated START. Very annoying. At least for kernel newbies. Regards Honza -- 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] cxd2820r: fix possible out-of-array lookup
2011/7/23 Malcolm Priestley tvbox...@gmail.com: On Sat, 2011-07-23 at 01:47 +0200, HoP wrote: 2011/7/23 Antti Palosaari cr...@iki.fi: On 07/23/2011 02:31 AM, Antti Palosaari wrote: On 07/23/2011 02:01 AM, HoP wrote: 2011/7/23 Antti Palosaaricr...@iki.fi: But now I see what you mean. msg2[1] is set as garbage fields in case of incoming msg len is 1. True, but it does not harm since it is not used in that case. In case of write, cxd2820r_tuner_i2c_xfer() gets msg[] parameter with only one element, true? If so, then my patch is correct. Yes it is true but nonsense. It is also wrong to make always msg2 as two element array too, but those are just simpler and generates most likely some code less. Could you see it can cause problem in some case? Now I thought it more, could it crash if it point out of memory area? Arrays are not fussy they will read anything, just don't poke them :-) Are you sure about not crashing? On every architecture on which linux can run? Even if it not crash kernel, I hope we can agree that it is incorrect and need to be fixed. I see you finally understood what I wanted to do :-) I'm surprised that it not crashed already. I thought I have to missed something. It does not crash because num is constant throughout, when the number of messages is one the second element isn't transferred. Sure, that is evident. My fix was about not do read access outside of input array msg[]. I still don't understand the NACK. /Honza -- 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] cxd2820r: fix possible out-of-array lookup
In case of i2c write operation there is only one element in msg[] array.
Don't access msg[1] in that case.
Signed-off-by: Honza Petrous jpetr...@smartimp.cz
--
diff -uBbp cxd2820r_core.c.orig cxd2820r_core.c
--- cxd2820r_core.c.orig2011-07-22 23:31:56.319168405 +0200
+++ cxd2820r_core.c 2011-07-22 23:35:02.508046078 +0200
@@ -750,8 +750,6 @@ static int cxd2820r_tuner_i2c_xfer(struc
}, {
.addr = priv-cfg.i2c_address,
.flags = I2C_M_RD,
- .len = msg[1].len,
- .buf = msg[1].buf,
}
};
@@ -760,6 +758,8 @@ static int cxd2820r_tuner_i2c_xfer(struc
if (num == 2) { /* I2C read */
obuf[1] = (msg[0].addr 1) | I2C_M_RD; /* I2C RD flag */
msg2[0].len = sizeof(obuf) - 1; /* maybe HW bug ? */
+ msg2[1].len = msg[1].len;
+ msg2[1].buf = msg[1].buf;
}
memcpy(obuf[2], msg[0].buf, msg[0].len);
--
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] cxd2820r: fix possible out-of-array lookup
2011/7/23 Antti Palosaari cr...@iki.fi: On 07/23/2011 01:18 AM, HoP wrote: In case of i2c write operation there is only one element in msg[] array. Don't access msg[1] in that case. NACK. I suspect you confuse now local msg2 and msg that is passed as function parameter. Could you double check and explain? Ok, may I really understand it badly. My intention was that in case of tda18271_write_regs() there is i2c_transfer() called with msg[] array of one element only. So am I wrong? Thanks Honza -- 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] cxd2820r: fix possible out-of-array lookup
2011/7/23 Antti Palosaari cr...@iki.fi: On 07/23/2011 01:47 AM, HoP wrote: 2011/7/23 Antti Palosaaricr...@iki.fi: On 07/23/2011 01:18 AM, HoP wrote: In case of i2c write operation there is only one element in msg[] array. Don't access msg[1] in that case. NACK. I suspect you confuse now local msg2 and msg that is passed as function parameter. Could you double check and explain? Ok, may I really understand it badly. My intention was that in case of tda18271_write_regs() there is i2c_transfer() called with msg[] array of one element only. So am I wrong? No. There is only one msg array in write and in case of reg read there is two elements, first one is write and second is read. But now I see what you mean. msg2[1] is set as garbage fields in case of incoming msg len is 1. True, but it does not harm since it is not used in that case. In case of write, cxd2820r_tuner_i2c_xfer() gets msg[] parameter with only one element, true? If so, then my patch is correct. The idea of whole system is just add 2 bytes to incoming msg .buf and then forward that message. Yes. I just learnt it, very clever way. What I only don't understand is why do you decrease msg2[0].len. Seems really like some hw bug. Honza -- 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] cxd2820r: fix possible out-of-array lookup
2011/7/23 Antti Palosaari cr...@iki.fi: On 07/23/2011 02:31 AM, Antti Palosaari wrote: On 07/23/2011 02:01 AM, HoP wrote: 2011/7/23 Antti Palosaaricr...@iki.fi: But now I see what you mean. msg2[1] is set as garbage fields in case of incoming msg len is 1. True, but it does not harm since it is not used in that case. In case of write, cxd2820r_tuner_i2c_xfer() gets msg[] parameter with only one element, true? If so, then my patch is correct. Yes it is true but nonsense. It is also wrong to make always msg2 as two element array too, but those are just simpler and generates most likely some code less. Could you see it can cause problem in some case? Now I thought it more, could it crash if it point out of memory area? I see you finally understood what I wanted to do :-) I'm surprised that it not crashed already. I thought I have to missed something. Honza -- 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] vtunerc - virtual DVB device driver
2011/6/22 Markus Rechberger mrechber...@gmail.com: My very little opinion is that waving GPL is way to the hell. Nobody told me why similar technologies, in different kernel parts are acceptable, but not here. since a customer was trying to use this module the only feedback I can give right now is that there are still some fundamental bugs in that work. Just running it with some intuitive parameters (without having a dvb device connected) caused it to hang. ./vtunerc.i686 -c 1 vtunerc: [5210 ../../vtunerc.c:349] debug: added frontend mode DVB-C as mode 0, searching for tuner types 2 vtunerc: [5210 ../../vtunerc.c:346] error: unknown tuner mode specified: 1 allow values are: -s -S -s2 -S2 -c -t it just never returned. Never returned? How it is possible if just next line is exit(1) call? DMESG: vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer vtunerc: [5207 ../../vtunerc.c:606] info: msg: 4096 completed vtunerc: [5207 ../../vtunerc.c:506] info: vtuner message! vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer ps fax | grep vtunerc: 5194 pts/4 S 0:00 | \_ bash 5210 pts/4 S+ 0:00 | \_ [vtunerc.i686] that way it's not good enough for inclusion yet anyway. I never wanted to get it include immediatelly. I never stated that. That is why subject of this mail starts with [RFC]. I wanted to know if such driver is even interesting by others and if so to get help from community having the code better. I was already noted that it is my first kernel driver and I understand that reviewing code by kernel hackers can help making code better. On the other hand I never thought that the code can be totally refused because of its nature. Even I all time was writing that all subsystem (kernel + userland daemons) are GPL. Marcus, tell the customer I'm just starting some howto document to guide all willing to test how it works through compilation and installation process. In parallel I'm going to address all hints gave me by Andreas, the only guy who even had a look at source. Anyway, I'm happy for any feedback, so thanks. /Honza -- 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] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter o...@linuxtv.org wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === Devin, we need to support tuner X under Linux. Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor). Ok. Well, what is the licensing for that code? Is it GPL compatible? Not currently. So can we just make our driver closed source? Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch. Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply. Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core. Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL. === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of good will. They do it because they are compelled to by licenses or because there is no economically viable alternative. Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. Anyway, I said in my last email that would be my last email on the topic. I guess I lied. Yes, and you did lie to your vendor, too, as you did not mention the possibilities to create 1.) closed source modules derived from existing vendor drivers while still being able to use other drivers (c.f. EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL). AFAIK, the legal issues
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab mche...@redhat.com: Em 22-06-2011 09:30, Andreas Oberritter escreveu: On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter o...@linuxtv.org wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === Devin, we need to support tuner X under Linux. Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor). Ok. Well, what is the licensing for that code? Is it GPL compatible? Not currently. So can we just make our driver closed source? Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch. Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply. Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core. Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL. === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of good will. They do it because they are compelled to by licenses or because there is no economically viable alternative. Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. Anyway, I said in my last email that would be my last email on the topic. I guess I lied. Yes, and you did lie to your vendor, too, as you did not mention the possibilities to create 1.) closed source modules derived from existing vendor drivers while
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab mche...@redhat.com: Em 22-06-2011 10:13, Andreas Oberritter escreveu: On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: Em 22-06-2011 09:37, HoP escreveu: 2011/6/22 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter o...@linuxtv.org wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === Devin, we need to support tuner X under Linux. Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor). Ok. Well, what is the licensing for that code? Is it GPL compatible? Not currently. So can we just make our driver closed source? Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch. Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply. Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core. Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL. === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of good will. They do it because they are compelled to by licenses or because there is no economically viable alternative. Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. Anyway, I said in my last email that would be my last email on the topic. I guess I lied. Yes, and you did lie to your vendor, too, as you did
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Preserving the open-source eco-system is something that everyone developing open source expect: basically, you're free to do whatever you want, but if you're using a code written by an open-source developer, the expected behaviour that GPL asks (and that the developer wants, when he opted for GPL) is that you should return back to the community with any changes you did, including derivative work. This is an essential rule of working with GPL. If you're not happy with that, that's fine. You can implement another stack that is not GPL-licensed. Mauro, you totally misunderstood me. If you see on my first post in that thread I was sending full GPL-ed driver to the mailinglist. You misunderstood me. Something that exposes the kernel interface to for an userspace client driver to implement DVB is not a driver, it is a wrapper. The real driver will be in userspace, using the DVB stack, and can even be closed source. Some developers already tried to do things like that and sell the userspace code. Such code submission were nacked. There is even one case where the kernelspace code were dropped due to that (and later, replaced by an opensource driver). No, you are again wrong, sorry. If you ever tried to understand my small schema and description, you would find that REAL drivers remeains in kernel. May be you understand what I want from attached picture. You can see that the driver acts as bridge (ok, you like wording wrapper so) to distribute remote driver functionality down to the client and back. /Honza attachment: vtuner-small-picture.png
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 08:04, Andreas Oberritter escreveu: On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Preserving the open-source eco-system is something that everyone developing open source expect: basically, you're free to do whatever you want, but if you're using a code written by an open-source developer, the expected behaviour that GPL asks (and that the developer wants, when he opted for GPL) is that you should return back to the community with any changes you did, including derivative work. This is an essential rule of working with GPL. If you're not happy with that, that's fine. You can implement another stack that is not GPL-licensed. Mauro, you totally misunderstood me. If you see on my first post in that thread I was sending full GPL-ed driver to the mailinglist. You misunderstood me. Something that exposes the kernel interface to for an userspace client driver to implement DVB is not a driver, it is a wrapper. The real driver will be in userspace, using the DVB stack, and can even be closed source. Some developers already tried to do things like that and sell the userspace code. Such code submission were nacked. There is even one case where the kernelspace code were dropped due to that (and later, replaced by an opensource driver). We don't want to go on this way again. Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. Yes, but we don't need to review/maintain a kernel driver meant to be used by closed source applications, and, if they're using a GPL'd code inside a closed source application, they can be sued. Well, seems you are trying to argue using wrong arguments. One more again: If you follow my picture - all on the path, INCLUDING userland application, is GPL code. If you think about Enigma, it is GPLed also, at least version 1. But my driver is not for dreamboxes! They have similar implementation already included there. My intention was different: to allow same thing like is possible with dreamboxes, on normal linux PC desktop. Using any other userland DVB application, like VDR or MythTV or vlc. Got my point? I have nothing to do with any closed source or even binary blobs! I want DVB adapter distribution across network, nothing more. Everything is clear, from GPL point of view. I didn't review the patchset, but, from the description, I understood that it were developed to use some Dreambox-specific closed source applications. With such requirement, for me it is just a wrapper to some closed source application. I understand that my English can be not crystal clear, so you missed inside my description. But I must say it again - my code has zero connection with dreamboxes. Of course other then borrowing theirs sharing possibility and reusing same network daemons (again fully GPLed!) for it. That's said, I'm not against a driver that allows using a DVB kernel driver by a DVB open source application either inside a virtual machine or on a remote machine. This seems useful for me. So, if the code could be turned
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter o...@linuxtv.org wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The vtuner interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === Devin, we need to support tuner X under Linux. Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor). Ok. Well, what is the licensing for that code? Is it GPL compatible? Not currently. So can we just make our driver closed source? Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch. Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply. Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core. Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL. === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of good will. They do it because they are compelled to by licenses or because there is no economically viable alternative. Mauro, ultimately it is your decision as the maintainer which drivers get accepted in to the kernel. I can tell you though that this will be a very bad thing for the driver ecosystem as a whole - it will essentially make it trivial for vendors (some of which who are doing GPL work now) to provide solutions that reuse the GPL'd DVB core without having to make any of their stuff open source. Anyway, I said in my last email that would be my last email on the topic. I guess I lied. Yes, and you did lie to your vendor, too, as you did not mention the possibilities to create 1.) closed source modules derived from existing vendor drivers while still being able to use other drivers (c.f. EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL). AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL are not proofed legally in any court. While
Re: [RFC] vtunerc - virtual DVB device driver
Hi Devin. 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: 2011/6/20 Rémi Denis-Courmont r...@remlab.net: Hello, Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit : get inspired by (unfortunately close-source) solution on stb Dreambox 800 I have made my own implementation of virtual DVB device, based on the same device API. Some might argue that CUSE can already do this. Then again, CUSE would not be able to reuse the kernel DVB core infrastructure: everything would need to be reinvented in userspace. Generally speaking, this is the key reason that virtual dvb drivers have been rejected in the past for upstream inclusion - it makes it Can you tell me when such disscussion was done? I did a big attempt to check if my work is not reinventing wheels, but I found only some very generic frontend template by Emard em...@softhome.net. easier for evil tuner manufacturers to leverage all the hard work done by the LinuxTV developers while providing a closed-source solution. May be I missunderstood something, but I can't see how frontend virtualization/sharing can help to leverage others work. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. I'm again not sure if you try to argument against vtunerc code or nope. Thanks /Honza -- 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] vtunerc - virtual DVB device driver
2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: 2011/6/20 Sébastien RAILLARD (COEXSI) s...@coexsi.fr: If I may put my two cents in this discussion regarding the closed source code problem: maybe it could be great to have some closed source drivers making some DVB hardware working better or even allowing more DVB hardware working under Linux. For example, there is a good support of PCI DVB devices, but not yet so much support for PCIe DVB devices (and even less if you're searching for DVB-S2 tuner with CAM support at reasonable price). Nothing prevents a third-party from writing closed source drivers. What we do *not* think is fair though is that those third parties should be able to take advantage of all the GPL code that makes up the DVB core, and the man-years spent developing that code. If somebody wants to write a closed source driver, they are welcome to (in fact, some companies actually have). But I'll be damned if they're going to reuse GPL code to accomplish it. They are welcome to reimplement the DVB core in userland if that is their goal (under whatever licensing terms suits them). Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): I have equipment, based of course on Linux and others open-source code, which is using DVB tuners sharing (the box has two DVB-S2 NIMs on inputs and ethernet on output). If I understand you well, I have to cut such box feature (which is, btw, one of very nicer usecase of such box) and stop thinking about it? Do you really think that it is a good way which should linux come? I don't like binary drivers as well. But if developers can't extend usability of linux because of worrying about blob drivers, it is not good, it is path to the hell. My 2cents. /Honza PS: I don't want to start any war, but I would like to know if it is only Devin POV or it has wider support inside linux-media hackers. Of course I will stay with my drivers outside the kernel. Ugly, I know. But I never want to enter by closed doors. Not my way. -- 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] vtunerc - virtual DVB device driver
2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. Every couple of years somebody implements such a driver, and they have all been rejected for upstream. Why same not apply to other devices? If I would be really accurate I would vote for removing nfs, smbfs and all other network sharing filesystems. original author of the patch/driver. In fact, I believe all the cases in the past were by people who were friendly to open source. I would like to know how much such bad guys stayed with kernel development. To be fair, I am not the originator of this argument. If you read the history, a variety of other Linux DVB-V4L developers have shared the same view (which I adopted after hearing the arguments). Seems DVB hackers are very specific group. Such politic rule don't wan't to have any place in the code development. Of course, it's my personal opinion only. /Honza -- 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] vtunerc - virtual DVB device driver
2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Preserving the open-source eco-system is something that everyone developing open source expect: basically, you're free to do whatever you want, but if you're using a code written by an open-source developer, the expected behaviour that GPL asks (and that the developer wants, when he opted for GPL) is that you should return back to the community with any changes you did, including derivative work. This is an essential rule of working with GPL. If you're not happy with that, that's fine. You can implement another stack that is not GPL-licensed. Mauro, you totally misunderstood me. If you see on my first post in that thread I was sending full GPL-ed driver to the mailinglist. I simply didn't expect that my source will be refused because of worrying about misuse it to the bad things(tm). Note again: I did it GPLed and opensourced, I never ever thought about binary blobs or some other closed stuffs! /Honza -- 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
[RFC] vtunerc - virtual DVB device driver
Hi, get inspired by (unfortunately close-source) solution on stb Dreambox 800 I have made my own implementation of virtual DVB device, based on the same device API. In conjunction with Dreamtuner userland project [http://code.google.com/p/dreamtuner/] by Ronald Mieslinger user can create virtual DVB device on client side and connect it to the server. When connected, user is able to use any Linux DVB API compatible application on client side (like VDR, MeTV, MythTV, etc) without any need of code modification. As server can be used any Linux DVB API compatible device. Here is the small and ugly big picture :-) CLIENTSERVER - | Favourite Linux DVB API | | Real DVB tuner HW | | compatible application| | (any S, C or T) | - - | ^ Linux DVB API layer Linux DVB API layer | | v | - | | vtunerc.ko | | | (virtual DVB device )| | - | | | /dev/vtunerX API layer | | | v | - - | vtunerc.x86|| vtuners.arm | | (dreamtuner client app) | | (dreamtuner server app) | - | ^ |TCP/IP network | -- dreamtuner network protocol Note: current code was tested on kernels from 2.6.22 up to 2.6.38 and that is the reason of codeversion preprocessor ifdefs there. I understand fully that such code must be removed for possible code submission. Signed-off-by: Honza Petrous jpetr...@smartimp.cz diff -r a43a9e31be8b drivers/media/dvb/vtunerc/Kconfig --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/drivers/media/dvb/vtunerc/Kconfig Sun Jun 19 01:55:52 2011 +0200 @@ -0,0 +1,13 @@ +config DVB_VTUNERC + tristate Virtual DVB adapters support + depends on DVB_CORE + ---help--- + Support for virtual DVB adapter. + + Choose Y here if you want to access DVB device residing on other + computers using vtuner protocol. To compile this driver as a module, + choose M here: the module will be called vtunerc. + + To connect remote DVB device, you also need to install the user space + vtunerc command which can be found in the Dreamtuner package, available + from http://code.google.com/p/dreamtuner/. diff -r a43a9e31be8b drivers/media/dvb/vtunerc/Makefile --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/drivers/media/dvb/vtunerc/MakefileSun Jun 19 01:55:52 2011 +0200 @@ -0,0 +1,14 @@ +# +# Makefile for the nGene device driver +# + +vtunerc-objs = vtunerc_main.o vtunerc_ctrldev.o vtunerc_proxyfe.o + +obj-$(CONFIG_DVB_VTUNERC) += vtunerc.o + +EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core +EXTRA_CFLAGS += -Idrivers/media/dvb/frontends +EXTRA_CFLAGS += -Idrivers/media/common/tuners +EXTRA_CFLAGS += -Iinclude/linux + +EXTRA_CFLAGS += -DHAVE_DVB_API_VERSION=5 diff -r a43a9e31be8b drivers/media/dvb/vtunerc/vtuner.h --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/drivers/media/dvb/vtunerc/vtuner.hSun Jun 19 01:55:52 2011 +0200 @@ -0,0 +1,163 @@ +/* + * vtunerc: /dev/vtunerc API + * + * Copyright (C) 2010-11 Honza Petrous jpetr...@smartimp.cz + * [based on dreamtuner userland code by Roland Mieslinger] + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _VTUNER_H_ +#define _VTUNER_H_ + +#ifndef HAVE_DVB_API_VERSION +#define HAVE_DVB_API_VERSION 5 +#endif + +#if HAVE_DVB_API_VERSION 3 + #include ost/frontend.h + #include ost/dmx.h + #include ost/sec.h +#else + #include linux/dvb/version.h +
Re: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
2011/5/12 Bjørn Mork bj...@mork.no: Andreas Oberritter o...@linuxtv.org writes: Please try the patches submitted for testing: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html Ah, great! Thanks. Nothing better than a problem already solved. Not solved. Andreas did an attempt to solve it (at least as far as I know patches not get accepted yet), so please report your result of testing. Honza -- 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: stv090x vs stv0900
Hi Pascal, I was adding support for a non working version of DVBWorld HD 2104 It is listed on http://www.linuxtv.org/wiki/index.php/DVBWorld_HD_2104_FTA_USB_Box as : = for new solution : 2104B (Sharp0169 Tuner) * STV6110A tuner * ST0903 demod * Cyrix CY7C68013A USB controller = The 2104A is supposed to be working and also have ST0903 but uses stv0900, so I tried using it too but did not manage to get it working. I now have some working code by using stv090x + stv6110x (copied config from budget) but I am wondering why do we have 2 drivers for stv0900, and is stv0900 supposed to handle stv0903 devices or is either the code or the wki wrong about 2104A? Also, are they both maintained ? I wrote a patch to add get_frontend to stv090x but stv0900 also does not have it and I don't know which one should get new code. And stv6110x seems to also handle stv6110 which also exists as a separate module... Hehe, you are not only one who is fooled by current situation regarding demods stv0900/stv0903 and plls stv6110. Current status-quo is not good. Same question is asked here again and again. Interesting that it is against usual rule having only one driver for every chip in kernel, but this time that rather strong rule was not applied. Dunno why. May be someone from knowings can answer that on wiki? /Honza PS: FYI I'm also using BOTH variants in 2 projects. For me both look very similar and work w/o probs. So I can't tell you which is better :) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: zvbi-atsc-cc device node conflict
2010/4/17 Devin Heitmueller dheitmuel...@kernellabs.com: On Fri, Apr 16, 2010 at 7:19 PM, David Liontooth lionte...@cogweb.net wrote: I'm using a HVR-1850 in digital mode and get good picture and sound using mplayer -autosync 30 -cache 2048 dvb://KCAL-DT Closed captioning works flawlessly with this command: zvbi-atsc-cc -C test-cc.txt KCAL-DT However, if I try to run both at the same time, I get a device node conflict: zvbi-atsc-cc: Cannot open '/dev/dvb/adapter0/frontend0': Device or resource busy. How do I get video and closed captioning at the same time? To my knowledge, you cannot run two userland apps streaming from the frontend at the same time. Generally, when people need to do this sort of thing they write a userland daemon that multiplexes. Alternatively, you can cat the frontend to disk and then have both mplayer and your cc parser reading the resulting file. Usually there is some way, for ex. command line option, how to say to second app that frondend is already locked. Then second app simply skips tuning at all. Rest processing is made using demux and dvr devices, so there is not reason why 2 apps should tune in same time. /Honza -- 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: zvbi-atsc-cc device node conflict
2010/4/17 David Liontooth lionte...@cogweb.net: HoP wrote: 2010/4/17 Devin Heitmueller dheitmuel...@kernellabs.com: On Fri, Apr 16, 2010 at 7:19 PM, David Liontooth lionte...@cogweb.net wrote: I'm using a HVR-1850 in digital mode and get good picture and sound using mplayer -autosync 30 -cache 2048 dvb://KCAL-DT Closed captioning works flawlessly with this command: zvbi-atsc-cc -C test-cc.txt KCAL-DT However, if I try to run both at the same time, I get a device node conflict: zvbi-atsc-cc: Cannot open '/dev/dvb/adapter0/frontend0': Device or resource busy. How do I get video and closed captioning at the same time? To my knowledge, you cannot run two userland apps streaming from the frontend at the same time. Generally, when people need to do this sort of thing they write a userland daemon that multiplexes. Alternatively, you can cat the frontend to disk and then have both mplayer and your cc parser reading the resulting file. Usually there is some way, for ex. command line option, how to say to second app that frondend is already locked. Then second app simply skips tuning at all. Rest processing is made using demux and dvr devices, so there is not reason why 2 apps should tune in same time. /Honza Thanks! I'm trying to create separate recordings of the video/audio file on the one hand and the closed captioning on the other. In one console, I issue azap -r KOCE-HD In a second, I issue cat /dev/dvb/adapter0/dvr0 test-cat3.mpeg I cannot at the same time run this in a third: zvbi-atsc-cc -C test-cc.txt KOCE-HD because of resource conflict. Using cat works, but how do I get closed captioning from the resulting mpeg file? Very dump way is simply feed zvbi with resulting test-cat3.mpeg. If this page is correct: http://www.digipedia.pl/man/doc/view/zvbi-atsc-cc.1/ using -t command line option you can get CC by issuing something like cat test-cat3.mpeg zvbi-atsc-cc -ts -C test-cc.txt Of course I'm assuming that CC pid is included in recording. But dunno if azap is demuxing pids others then A/V. /Honza -- 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: zvbi-atsc-cc device node conflict
That's promising but no cigar: cat test-cat3.mpeg zvbi-atsc-cc --ts just feeds the output of the cat into a file called zvbi-atsc-cc (not surprisingly). Hehe. Sure, it was my mistake. Piping syntax what you tried later is exactly what I thought :-) cat test-cat3.mpeg | zvbi-atsc-cc --ts also doesn't work. zvbi-atsc-cc's --ts switch is designed to Decode a DVB Transport Stream on stdin, so if the file created with cat /dev/dvb/adapter0/dvr0 test-cat3.mpeg qualifies as a DVB Transport Stream, then there's a way to pipe it to zvbi-atsc-cc. How do we get the syntax for this? Of course I can be wrong as I have exactly zero experiences of using zvbi tool, but I think command line option --ts should tell that data are not comming from dvr device but from stdin. Dunno why it not works for you. May be it needs some additional options? /Honza -- 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: However, if you don't want to lose your freedom, you had better not follow him. (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hi Chicken, However I am still alone with the other problem I always stressed: When using alevt-dvb (I attached my overworked version 1.7.0 in earlier mails - please do have a look at it!) the application hangs when you decide to switch to a channel that is part of a new transponder. The program hangs then. That means the way alevt-dvb is dealing with the PMT (program map table) is highly incomplete. It needs a reset function to read the new PMT when the transponder is being changed... If you tell me which application is managing channel zaping function then we can try to find way how to signal that to alevt-dvb. I do not know how to program that simple reset function. But I know that thsi is the definite key to resolve the issue. PMT reading, PMT opening, PMT parsing... Everything is already inside of the source code of alevt-dvb. In case, if more then one DVB application is running, one is something like master (which do frontend operation, ie. channel change) and rest are slaves. So master has to signal channel/transponder change to the all slaves. Typically, it is done by some custom specific way. For example master can open some well-known unix socket where all slaves are connecting and where, in case of channel change, is sent (by master) some info about such event. Cheers /Honza -- 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: However, if you don't want to lose your freedom, you had better not follow him. (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hi Chicken 2010/2/7 Chicken Shack chicken.sh...@gmx.de: Am Sonntag, den 07.02.2010, 19:10 +0100 schrieb HoP: Hi Chicken, However I am still alone with the other problem I always stressed: When using alevt-dvb (I attached my overworked version 1.7.0 in earlier mails - please do have a look at it!) the application hangs when you decide to switch to a channel that is part of a new transponder. The program hangs then. That means the way alevt-dvb is dealing with the PMT (program map table) is highly incomplete. It needs a reset function to read the new PMT when the transponder is being changed... If you tell me which application is managing channel zaping function then we can try to find way how to signal that to alevt-dvb. Hi Hello Honza, well, every application being capable of playing back DVB-TV with in-built receiver engine could manage that. Just the examples that I know: 1. mplayer (receiver engine is good old dvbstream from D. Chapman) 2. xine-ui (receiver engine is libxine) 3. kaffeine (dito 2.) 4. mythtv (don't know which) 5. xawtv (proprietary receiver engine) Oki, seems you not understood me fully. I ment exactly your configuration. I need to know: 1, which application is tuning to transponder in your case. 2, is there only one alevt-dvb instance running? Typically, there is the only one, but, of course I can imagine you do some postprocessing of ALL teletext services on current transponder. I do not know how to program that simple reset function. But I know that this is the definite key to resolve the issue. PMT reading, PMT opening, PMT parsing... Everything is already inside of the source code of alevt-dvb. In case, if more then one DVB application is running, one is something like master (which do frontend operation, ie. channel change) and rest are slaves. So master has to signal channel/transponder change to the all slaves. Typically, it is done by some custom specific way. For example master can open some well-known unix socket where all slaves are connecting and where, in case of channel change, is sent (by master) some info about such event. Yes, exactly that's the way it is! Right! But however the master application is doing this tuning job, it's not our problem issue right here. Our problem issue right here is how to make the slave application comprehend what the master application just managed to do. When I was doing the code cleanup of the complete Flexcop driver series Patrick Boettcher taught me what a software watchdog is and how it works. The Conexant frontend / demodulator chip does not work together with the Flexcop main chip without a software watchdog performing reinitialization every 400 milliseconds. That came into my mind a couple of minutes ago. Well, we should stay outside kernel layer. Best solution should be to manage signalling (of transponder change and futher information) inside userland level. And this is why I was asking who is the master (who is doing channel change) So how about giving alevt-dvb a software watchdog function that just looks up lets say every 2 seconds whether the PMT has changed or not, performing a reinitialisation of the PMT treatment built inside, i. e. doing something like a restart of alevt-dvb? To find how to catch that PMT has changed we have to know who is doing such PMT change operation. Would that be a pratical solution? Or what would be your personal proposal, Honza? Cheers CS P. S.: The decisive case the program must learn to deal with is NOT a simple channel change, as you express it above, Honza. The proggy can already run multiple instances in parallel console sessions if the transponder is one and the same.. The decisive case the program must learn to deal with is a combination of channel change PLUS transponder change, which makes it necessary to read, work over and parse a complete new PMT (program map table) causing the UI to at least starting the main program of the new transponder (which is ZDF f. ex. if the transponder is ZDFVision. Everything clear so far? Questions? Still the only one question - how it works for you now? How do you zap to channel right now? I expect you have some favourite application. Cheers /Honza -- 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: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hi Chicken Furthermore: If it is technically possible to send and receive, demux and multiplex, play and record complete contents of a transponder (i. e. multiple TS streams) by using dvbstream or mumudvb (- 8192 command line parameter), then I myself do not see the necessity to extend the capabilities of one physical device dvr0 or demux0 into a multiplicity of devices dvr0 or demux0. The what and especially the why will remain Andreas Oberritters' secret. I can only say my 2 words regarding Andreas' patch: At least one big DVB application is using it - enigma (originally inside tuxbox project, later enhanced by Dream Multimedia for theirs well-known linux based set-top-boxes Dreambox). Those boxes are selling worlwide, so userbase is wide enough (note: I'm not in any way connected with Dream Multimedia, so it is only my personal feeling and/or investigation). Of course using full TS and remuxing only in user land is not possible way for embedded application. And if you count that there can be more then one TS input, things are getting even worst. And as Andy wrote: But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. Well, it is also possible way. But it expands dvrX from usuall dvr0 to something like dvr0 ... dvr31 or so. We definitelly need such feature. I, personally, like DMX_OUT_TSDEMUX_TAP approach. Rgds /Honza -- 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 v3] isl6421.c - added tone control and temporary diseqc overcurrent
Hi Mauro,
Not to hassle you, I'm sure you're very busy.
But I'm not yet received a response from you on mail with corrected patch.
Your attention would be appreciated
Regards
/Honza
2009/12/16 HoP jpetr...@gmail.com:
Hi Mauro,
2009/12/15 Mauro Carvalho Chehab mche...@redhat.com:
[snip]
I'm still missing a driver or a board entry that requires those
changes. Could you please send it together with this patch series?
We are using it in our project. Currently we are in very early
stage of it. We still have some serious issue, what not allows
us sending such code for mainlining.
Anyway, I don't think it can block accepting current patchset.
Isl6421 driver is already in tree, we only want to add some
features, which can be or can not be interesting for others.
I believe extending of usability of current drivers is correct
way.
Also, you forgot to send your Signed-off-By. This is required for
patch submission.
Regards
/Honza
---
isl6421.c - added tone control and temporary diseqc overcurrent
Please, always send patches in-lined. makes easier for commenting.
OK.
diff -r 79fc32bba0a0 linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c Mon Dec 14 17:43:13
2009 -0200
+++ b/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c Tue Dec 15 16:36:14
2009 +0100
@@ -302,6 +302,12 @@ static struct itd1000_config skystar2_re
.i2c_address = 0x61,
};
+static struct isl6421_config skystar2_rev2_7_isl6421_config = {
+ .i2c_address = 0x08,
+ .override_set = 0x01,
+ .override_clear = 0x01,
+};
+
static int skystar2_rev27_attach(struct flexcop_device *fc,
struct i2c_adapter *i2c)
{
@@ -325,7 +331,7 @@ static int skystar2_rev27_attach(struct
/* enable no_base_addr - no repeated start when reading */
fc-fc_i2c_adap[2].no_base_addr = 1;
if (!dvb_attach(isl6421_attach, fc-fe, fc-fc_i2c_adap[2].i2c_adap,
- 0x08, 1, 1)) {
+ skystar2_rev2_7_isl6421_config)) {
err(ISL6421 could NOT be attached);
goto fail_isl;
}
@@ -368,6 +374,12 @@ static const struct cx24113_config skyst
.xtal_khz = 10111,
};
+static struct isl6421_config skystar2_rev2_8_isl6421_config = {
+ .i2c_address = 0x08,
+ .override_set = 0x00,
+ .override_clear = 0x00,
Please, do not set any static value to zero. Kernel module support already
does that, and this will just add uneeded stuff into BSS.
Done.
+};
+
static int skystar2_rev28_attach(struct flexcop_device *fc,
struct i2c_adapter *i2c)
{
@@ -391,7 +403,7 @@ static int skystar2_rev28_attach(struct
fc-fc_i2c_adap[2].no_base_addr = 1;
if (!dvb_attach(isl6421_attach, fc-fe, fc-fc_i2c_adap[2].i2c_adap,
- 0x08, 0, 0)) {
+ skystar2_rev2_8_isl6421_config)) {
err(ISL6421 could NOT be attached);
fc-fc_i2c_adap[2].no_base_addr = 0;
return 0;
diff -r 79fc32bba0a0 linux/drivers/media/dvb/frontends/isl6421.c
--- a/linux/drivers/media/dvb/frontends/isl6421.c Mon Dec 14 17:43:13
2009 -0200
+++ b/linux/drivers/media/dvb/frontends/isl6421.c Tue Dec 15 16:36:14
2009 +0100
@@ -3,6 +3,9 @@
*
* Copyright (C) 2006 Andrew de Quincey
* Copyright (C) 2006 Oliver Endriss
+ * Copyright (C) 2009 Ales Jurik and Jan Petrous (added optional 22k tone
+ * support and temporary diseqc overcurrent enable until
+ * next command - set voltage or tone)
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -36,37 +39,88 @@
#include isl6421.h
struct isl6421 {
- u8 config;
- u8 override_or;
- u8 override_and;
- struct i2c_adapter *i2c;
- u8 i2c_addr;
+ const struct isl6421_config *config;
+ u8 reg1;
reg1 seems a very bad name. Based on the datasheet, maybe
you could call it as sys_config or sys_reg_config.
Renamed to sys_reg.
+
+ struct i2c_adapter *i2c;
+
+ int (*diseqc_send_master_cmd_orig)(struct dvb_frontend *fe,
+ struct dvb_diseqc_master_cmd *cmd);
};
static int isl6421_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t
voltage)
{
struct isl6421 *isl6421 = (struct isl6421 *) fe-sec_priv;
- struct i2c_msg msg = { .addr = isl6421-i2c_addr, .flags = 0,
- .buf = isl6421-config,
- .len = sizeof(isl6421-config) };
+ struct i2c_msg msg = { .addr = isl6421-config-i2c_addr, .flags = 0,
+ .buf = isl6421-reg1,
+ .len = sizeof(isl6421-reg1) };
- isl6421-config = ~(ISL6421_VSEL1
Re: [PATCH v3] isl6421.c - added tone control and temporary diseqc overcurrent
Hi Mauro,
2010/1/20 Mauro Carvalho Chehab mche...@redhat.com:
HoP wrote:
Hi Mauro,
Not to hassle you, I'm sure you're very busy.
But I'm not yet received a response from you on mail with corrected patch.
Your attention would be appreciated
Hi Honza,
The patch looks correct to me, but, as I previously mentioned, our policy is
to add new features at the kernel driver only together with a driver that
actually requires it. This helps to avoid increasing the kernel without need.
So, please re-submit it when you have your driver requiring the isl6421
changes ready for submission, on the same patch series.
Are you sure about such policy?
I did small google research and found out the following:
My feeling is different otherwise I don't understand why did you
accept WITHOUT any word Oliver Endriss' PULL request
from December 12th:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg13302.html
I'm pointing on Oliver's pull request only because he did very similar
thing for lnbp21 like I did for isl6421.
You very quickly added his patch to 2.6.33 on December 16th:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg13429.html
So again. If I'm not blind you have accepted same work from him
but not from me. Please show me what I have overlooked
and this is not true.
Another possible explanation is that I'm totally unknow.
I hope you have some other explanation otherwise it feels to
me like elitism.
Regards
/Honza
Cheers,
Mauro.
Regards
/Honza
2009/12/16 HoP jpetr...@gmail.com:
Hi Mauro,
2009/12/15 Mauro Carvalho Chehab mche...@redhat.com:
[snip]
I'm still missing a driver or a board entry that requires those
changes. Could you please send it together with this patch series?
We are using it in our project. Currently we are in very early
stage of it. We still have some serious issue, what not allows
us sending such code for mainlining.
Anyway, I don't think it can block accepting current patchset.
Isl6421 driver is already in tree, we only want to add some
features, which can be or can not be interesting for others.
I believe extending of usability of current drivers is correct
way.
Also, you forgot to send your Signed-off-By. This is required for
patch submission.
Regards
/Honza
---
isl6421.c - added tone control and temporary diseqc overcurrent
Please, always send patches in-lined. makes easier for commenting.
OK.
diff -r 79fc32bba0a0 linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c Mon Dec 14 17:43:13
2009 -0200
+++ b/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c Tue Dec 15 16:36:14
2009 +0100
@@ -302,6 +302,12 @@ static struct itd1000_config skystar2_re
.i2c_address = 0x61,
};
+static struct isl6421_config skystar2_rev2_7_isl6421_config = {
+ .i2c_address = 0x08,
+ .override_set = 0x01,
+ .override_clear = 0x01,
+};
+
static int skystar2_rev27_attach(struct flexcop_device *fc,
struct i2c_adapter *i2c)
{
@@ -325,7 +331,7 @@ static int skystar2_rev27_attach(struct
/* enable no_base_addr - no repeated start when reading */
fc-fc_i2c_adap[2].no_base_addr = 1;
if (!dvb_attach(isl6421_attach, fc-fe,
fc-fc_i2c_adap[2].i2c_adap,
- 0x08, 1, 1)) {
+ skystar2_rev2_7_isl6421_config)) {
err(ISL6421 could NOT be attached);
goto fail_isl;
}
@@ -368,6 +374,12 @@ static const struct cx24113_config skyst
.xtal_khz = 10111,
};
+static struct isl6421_config skystar2_rev2_8_isl6421_config = {
+ .i2c_address = 0x08,
+ .override_set = 0x00,
+ .override_clear = 0x00,
Please, do not set any static value to zero. Kernel module support already
does that, and this will just add uneeded stuff into BSS.
Done.
+};
+
static int skystar2_rev28_attach(struct flexcop_device *fc,
struct i2c_adapter *i2c)
{
@@ -391,7 +403,7 @@ static int skystar2_rev28_attach(struct
fc-fc_i2c_adap[2].no_base_addr = 1;
if (!dvb_attach(isl6421_attach, fc-fe,
fc-fc_i2c_adap[2].i2c_adap,
- 0x08, 0, 0)) {
+ skystar2_rev2_8_isl6421_config)) {
err(ISL6421 could NOT be attached);
fc-fc_i2c_adap[2].no_base_addr = 0;
return 0;
diff -r 79fc32bba0a0 linux/drivers/media/dvb/frontends/isl6421.c
--- a/linux/drivers/media/dvb/frontends/isl6421.c Mon Dec 14 17:43:13
2009 -0200
+++ b/linux/drivers/media/dvb/frontends/isl6421.c Tue Dec 15 16:36:14
2009 +0100
@@ -3,6 +3,9 @@
*
* Copyright (C) 2006 Andrew de Quincey
* Copyright (C) 2006 Oliver Endriss
+ * Copyright (C) 2009 Ales Jurik and Jan Petrous (added optional 22k tone
+ * support and temporary diseqc overcurrent enable
until
+ * next command - set voltage or tone)
*
* This program is free software; you can redistribute
Re: [PATCH v3] isl6421.c - added tone control and temporary diseqc overcurrent
2010/1/21 Mauro Carvalho Chehab mche...@redhat.com: HoP wrote: Hi Mauro, 2010/1/20 Mauro Carvalho Chehab mche...@redhat.com: HoP wrote: Hi Mauro, Not to hassle you, I'm sure you're very busy. But I'm not yet received a response from you on mail with corrected patch. Your attention would be appreciated Hi Honza, The patch looks correct to me, but, as I previously mentioned, our policy is to add new features at the kernel driver only together with a driver that actually requires it. This helps to avoid increasing the kernel without need. So, please re-submit it when you have your driver requiring the isl6421 changes ready for submission, on the same patch series. Are you sure about such policy? I did small google research and found out the following: My feeling is different otherwise I don't understand why did you accept WITHOUT any word Oliver Endriss' PULL request from December 12th: http://www.mail-archive.com/linux-media@vger.kernel.org/msg13302.html I'm pointing on Oliver's pull request only because he did very similar thing for lnbp21 like I did for isl6421. You very quickly added his patch to 2.6.33 on December 16th: http://www.mail-archive.com/linux-media@vger.kernel.org/msg13429.html So again. If I'm not blind you have accepted same work from him but not from me. Please show me what I have overlooked and this is not true. Another possible explanation is that I'm totally unknow. I hope you have some other explanation otherwise it feels to me like elitism. As far as I understood, those changes are needed by the mantis driver, that got committed on the next day, as shown at the commit logs: http://linuxtv.org/hg/v4l-dvb/rev/07c36cb88bce http://linuxtv.org/hg/v4l-dvb/rev/d644727cd528 So, on that time I had already a pull request for the mantis driver. It is fine if I receive two separate pull requests, one depending of the other. That's said, Oliver is the maintainer of isl6421 driver, so he is the one that better know what bugs are there and what fixes are needed. Due to that, when I receive a patch from a driver maintainer, I'm inclined to ack with the changes, in the belief that he is doing the better for the driver. Even so, I review the driver looking for troubles on his approach taking more care with new exported symbols added and with new userspace API's that the patch might have. OK, you beat me. Good bye /Honza -- 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: About driver architecture
Hi Manu, 2010/1/14 Manu Abraham abraham.m...@gmail.com: Well, the SAA716x is only the PCI Express interface. There is no video capture involved in there with the STi7109. It is a full fledged DVB STB SOC. OSD is handled by the STi7109 on that STB. http://www.st.com/stonline/products/literature/bd/11660/sti7109.pdf Though it is not complete, that driver, it still does handle it, through the firmware interface. These are the kind of devices that you find on a DVB STB, i must say. On a DVB STB, what happens is that you load a vendor specific firmware on the SOC. The SOC is just issued the firmware commands, that's how a STB works in principle. A DVB STB can be considered to have 2 outputs, ie if you use it as a PC card, you can output the whole thing to your PC monitor, or output it to a TV set. But in the case of the STB, you have a TV output alone. I never know about use of stb7109 in any PCI card. It is surprise to me. Interesting what firmware is loaded to stb7109. Is it STM's proprietary os21 or even linux? /Honza -- 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: About driver architecture
The STi7109 also has a frame buffer approach, currently the framebuffer is not implemented in this specific case. http://osdir.com/ml/linux.fbdev.user/2008-07/msg4.html When you use stb7109 as main cpu for system (like is done for many linux or os21-based set-top-boxes already), then you can use FB driver from stlinux, what is STM's port of linux for theirs STB7xxx SOCs. See more on www.stlinux.com. Even more, there is already flying around full source code for such SOCs, which allows you to make full-featured box. I have a dream that sometimes those drivers come to mainline similar like TI chips are comming these days. /Honza -- 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: CI USB
I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. /Honza -- 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: CI USB
Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. /Honza -- 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 v2] isl6421.c - added tone control and temporary diseqc overcurrent
Hi Mauro, I have finally found some time for reworking our patch with regards of notes I got in disscussion. BTW, I learnt that sending patch for review to original authors is right thing (tm), so I have added Oliver, as isl6421.c author, Patrick as flexcop author, Gerd as cx88/saa7134 author (I hope I found correct persons, if no please ignore posting). Regards /Honza --- isl6421.c - added tone control and temporary diseqc overcurrent Signed-off-by: Jan Petrous jpetr...@gmail.com Signed-off-by: Ales Jurik aju...@quick.cz isl6421-v2.patch Description: Binary data
[PATCH v3] isl6421.c - added tone control and temporary diseqc overcurrent
Hi Mauro,
2009/12/15 Mauro Carvalho Chehab mche...@redhat.com:
[snip]
I'm still missing a driver or a board entry that requires those
changes. Could you please send it together with this patch series?
We are using it in our project. Currently we are in very early
stage of it. We still have some serious issue, what not allows
us sending such code for mainlining.
Anyway, I don't think it can block accepting current patchset.
Isl6421 driver is already in tree, we only want to add some
features, which can be or can not be interesting for others.
I believe extending of usability of current drivers is correct
way.
Also, you forgot to send your Signed-off-By. This is required for
patch submission.
Regards
/Honza
---
isl6421.c - added tone control and temporary diseqc overcurrent
Please, always send patches in-lined. makes easier for commenting.
OK.
diff -r 79fc32bba0a0 linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c Mon Dec 14 17:43:13
2009 -0200
+++ b/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c Tue Dec 15 16:36:14
2009 +0100
@@ -302,6 +302,12 @@ static struct itd1000_config skystar2_re
.i2c_address = 0x61,
};
+static struct isl6421_config skystar2_rev2_7_isl6421_config = {
+ .i2c_address = 0x08,
+ .override_set = 0x01,
+ .override_clear = 0x01,
+};
+
static int skystar2_rev27_attach(struct flexcop_device *fc,
struct i2c_adapter *i2c)
{
@@ -325,7 +331,7 @@ static int skystar2_rev27_attach(struct
/* enable no_base_addr - no repeated start when reading */
fc-fc_i2c_adap[2].no_base_addr = 1;
if (!dvb_attach(isl6421_attach, fc-fe, fc-fc_i2c_adap[2].i2c_adap,
- 0x08, 1, 1)) {
+ skystar2_rev2_7_isl6421_config)) {
err(ISL6421 could NOT be attached);
goto fail_isl;
}
@@ -368,6 +374,12 @@ static const struct cx24113_config skyst
.xtal_khz = 10111,
};
+static struct isl6421_config skystar2_rev2_8_isl6421_config = {
+ .i2c_address = 0x08,
+ .override_set = 0x00,
+ .override_clear = 0x00,
Please, do not set any static value to zero. Kernel module support already
does that, and this will just add uneeded stuff into BSS.
Done.
+};
+
static int skystar2_rev28_attach(struct flexcop_device *fc,
struct i2c_adapter *i2c)
{
@@ -391,7 +403,7 @@ static int skystar2_rev28_attach(struct
fc-fc_i2c_adap[2].no_base_addr = 1;
if (!dvb_attach(isl6421_attach, fc-fe, fc-fc_i2c_adap[2].i2c_adap,
- 0x08, 0, 0)) {
+ skystar2_rev2_8_isl6421_config)) {
err(ISL6421 could NOT be attached);
fc-fc_i2c_adap[2].no_base_addr = 0;
return 0;
diff -r 79fc32bba0a0 linux/drivers/media/dvb/frontends/isl6421.c
--- a/linux/drivers/media/dvb/frontends/isl6421.c Mon Dec 14 17:43:13
2009 -0200
+++ b/linux/drivers/media/dvb/frontends/isl6421.c Tue Dec 15 16:36:14
2009 +0100
@@ -3,6 +3,9 @@
*
* Copyright (C) 2006 Andrew de Quincey
* Copyright (C) 2006 Oliver Endriss
+ * Copyright (C) 2009 Ales Jurik and Jan Petrous (added optional 22k tone
+ *support and temporary diseqc overcurrent enable until
+ *next command - set voltage or tone)
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -36,37 +39,88 @@
#include isl6421.h
struct isl6421 {
- u8 config;
- u8 override_or;
- u8 override_and;
- struct i2c_adapter *i2c;
- u8 i2c_addr;
+ const struct isl6421_config *config;
+ u8 reg1;
reg1 seems a very bad name. Based on the datasheet, maybe
you could call it as sys_config or sys_reg_config.
Renamed to sys_reg.
+
+ struct i2c_adapter *i2c;
+
+ int (*diseqc_send_master_cmd_orig)(struct dvb_frontend *fe,
+ struct dvb_diseqc_master_cmd *cmd);
};
static int isl6421_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t
voltage)
{
struct isl6421 *isl6421 = (struct isl6421 *) fe-sec_priv;
- struct i2c_msg msg = { .addr = isl6421-i2c_addr, .flags = 0,
- .buf = isl6421-config,
- .len = sizeof(isl6421-config) };
+ struct i2c_msg msg = { .addr = isl6421-config-i2c_addr, .flags = 0,
+ .buf = isl6421-reg1,
+ .len = sizeof(isl6421-reg1) };
- isl6421-config = ~(ISL6421_VSEL1 | ISL6421_EN1);
+ isl6421-reg1 = ~(ISL6421_VSEL1 | ISL6421_EN1);
switch(voltage) {
case SEC_VOLTAGE_OFF:
break;
case SEC_VOLTAGE_13:
- isl6421-config |= ISL6421_EN1;
+
Re: [linux-dvb] Is there somobody dealing with DVB cards here ?!?
Hi, 2009/12/13 dvblinux dvbli...@free.fr: I first have to learn what is and how to create a patch since I only used my vi to modify the source of the driver and then recompiled it... Start from here: http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches /Honza -- 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: Latest stack that can be merged on top of linux-next tree
Hi 2009/12/11 Karicheri, Muralidharan m-kariche...@ti.com: Hi, Thanks for the response. One more question that I have is if the devices on the two buses can use the same i2c address. That is the case for my board. So wondering if this works as well. That is IMHO exactly reason of existence such expanders. We, for example have two DVB-S2 tuners, using totally same i2c addresses (for demod pll). If you are carefull and access such devices only using those virtual i2c buses, then you not need to manage switching between them at all. It is job for pca954x driver. Simple and easy :) /Honza -- 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: Latest stack that can be merged on top of linux-next tree
Hi, 2009/12/10 Karicheri, Muralidharan m-kariche...@ti.com: Guennadi, I am not sure if your MT9T031 changes are part of linux-next tree at v4l-dvb. If not, can you point me to the latest stack that I can apply on top of linux-next tree to get your latest changes for MT9T031 sensor driver? I plan to do integrate sensor driver with vpfe capture driver this week. BTW, Is there a driver for the PCA9543 i2c switch that is part of MT9T031 headboard? I would like to know answer also :) I had to add support for pca9542 (what is 2 port switch) for our project. After some googling I found some patches for similar kernel I was working on (2.6.22). You can find original patches for example there: http://www.mail-archive.com/i...@lm-sensors.org/msg00315.html FYI, the driver pca954x.c seems to be driver for full family of i2c muxes/switches. Such code works fine for me. The only thing I didn't find was why the code was never merged. I hope it can helps you. /Honza -- 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: Latest stack that can be merged on top of linux-next tree
Hi, 2009/12/10 Karicheri, Muralidharan m-kariche...@ti.com: Hi, Thanks for the email. Any idea how i2c drivers can work with this? Currently in my board, I have adapter id = 1 for main i2c bus. So when this mux driver is built into the kernel, I guess I can access it using a different adapter id, right? If so, what is the adapter id? Yes, exactly that is way of using - additional i2c buses were born when pca954x started. Daniel already described this in his mail: With these patches the bus segments beyond the i2c multiplexer will be registered as separate i2c busses. Access to a device on those busses will then automatically reconfigure the multiplexer. Additional i2c buses (adapters) were counted from number +1 higher then highest i2c bus number. If you main i2c bus is i2c-1, then you you should find i2c-2,i2c-3,i2c-4,i2c-5 new buses after pca954x loading. You can check that with i2cdetect tools. How do I use this with MT9T031 driver? Any idea to share? I never had a look inside mt9t031 driver, but in general - you simply point to some of that additional adaper by i2c_get_adapter(x) Idea is very smart. You don't need to manage pca954x on your own. Driver do it itself :) /Honza -- 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: [resend] radio-sf16fmi: fix mute, add SF16-FMP to texts
Hi Ondrej, 2009/12/2 Ondrej Zary li...@rainbow-software.org: On Tuesday 01 December 2009, Petr Vandrovec wrote: Ondrej Zary wrote: Fix completely broken mute handling radio-sf16fmi. The sound was muted immediately after tuning in KRadio. Also fix typos and add SF16-FMP to the texts. I do not have device anymore. Looks OK to me. Signed-off-by: Ondrej Zary li...@rainbow-software.org Acked-by: Petr Vandrovec p...@vandrovec.name To whom should I forward this (and your second patch), I did not do any SF16 work for 10 years (and no LKML for 3). No one seems to care here on linux-media :( I recommend to wait a bit more. You seems jumped directly to time when maintainers are busy with 2.6.32 release. Mauro usually answers asap. /Honza -- 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] isl6421.c - added optional features: tone control and temporary diseqc overcurrent
Hi Mauro,
thank you for your valued hints. I'm commenting inside
message:
First of all, please check all your patches with checkpatch, to be sure
that they don't have any CodingStyle troubles. There are some on your
patch (the better is to read README.patches for more info useful
for developers).
Did checkpatch testing and has fixed all errors/warnings except
of 3 warning regarding longer line (all 3 lines has exactly
one char over 80, so I guess it should not bother much).
Of course if this rule is a must, then I can fix that also).
Attached patch adds two optional (so, disabled by default
and therefore could not break any compatibility) features:
1, tone_control=1
When enabled, ISL6421 overrides frontend's tone control
function (fe-ops.set_tone) by its own one.
On your comments, the better is to describe why someone would need
to use such option. You should also add a quick hint about that at the
option description.
Well, I'm not sure I can make some good hint why such option can
be useful by someone. I can only say that isl6121 has possibility
to drive 22k tone, so why not enable usage of it?
Of course, we made such code because we were using exactly
this way of 22k control in our device.
2, overcurrent_enable=1
When enabled, overcurrent protection is disabled during
sending diseqc command. Such option is usable when ISL6421
catch overcurrent threshold and starts limiting output.
Note: protection is disabled only during sending
of diseqc command, until next set_tone() usage.
What typically means only max up to few hundreds of ms.
WARNING: overcurrent_enable=1 is dangerous
and can damage your device. Use with care
and only if you really know what you do.
I'm not sure if it is a good idea to have this... Why/when someone would
need this?
I know that it is a bit dangerous option, so I can understand you can
don't like it :)
But I would like to note again - such way of using is permitted
by datasheet (otherwise it would not be even possible to enable it)
and we learnt when used correctly (it is enabled only within diseqc
sequence), it boost rotor moving or fixes using some power-eating
diseqc switches.
If you still feel it is better to not support bit strange mode, then
I can live with #if 0 commented out blocks or adding some
kernel config option with something like ISL6421_ENABLE_OVERCURRENT
or so.
If we go ahead and add this one, you should add a notice about it at the
parameter.
I would also print a big WARNING message at the dmesg if the module were
loaded
with this option turned on.
Added some WARNING printing to dmesg when option is enabled.
Regards
/Honza
---
Signed-off-by: Jan Petrous jpetr...@gmail.com
Signed-off-by: Ales Jurik aju...@quick.cz
diff -r 9d9bc92d7c33 drivers/media/dvb/frontends/isl6421.c
--- a/drivers/media/dvb/frontends/isl6421.c Sat Sep 19 12:48:44 2009 +0200
+++ b/drivers/media/dvb/frontends/isl6421.c Tue Nov 03 23:23:05 2009 +0100
@@ -3,6 +3,9 @@
*
* Copyright (C) 2006 Andrew de Quincey
* Copyright (C) 2006 Oliver Endriss
+ * Copyright (C) 2009 Ales Jurik and Jan Petrous (added optional 22k tone
+ *support and temporary diseqc overcurrent enable until
+ *next command - set voltage or tone)
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -35,12 +38,23 @@
#include dvb_frontend.h
#include isl6421.h
+static int tone_control;
+module_param(tone_control, int, S_IRUGO);
+MODULE_PARM_DESC(tone_control, Set ISL6421 to control 22kHz tone);
+
+static int overcurrent_enable;
+module_param(overcurrent_enable, int, S_IRUGO);
+MODULE_PARM_DESC(overcurrent_enable, Set ISL6421 to temporary enable
+ overcurrent when diseqc command is active);
+
struct isl6421 {
u8 config;
u8 override_or;
u8 override_and;
struct i2c_adapter *i2c;
u8 i2c_addr;
+ int (*diseqc_send_master_cmd_orig)(struct dvb_frontend *fe,
+ struct dvb_diseqc_master_cmd *cmd);
};
static int isl6421_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
@@ -60,6 +74,55 @@ static int isl6421_set_voltage(struct dv
break;
case SEC_VOLTAGE_18:
isl6421-config |= (ISL6421_EN1 | ISL6421_VSEL1);
+ break;
+ default:
+ return -EINVAL;
+ };
+
+ isl6421-config |= isl6421-override_or;
+ isl6421-config = isl6421-override_and;
+
+ return (i2c_transfer(isl6421-i2c, msg, 1) == 1) ? 0 : -EIO;
+}
+
+static int isl6421_send_diseqc(struct dvb_frontend *fe,
+struct dvb_diseqc_master_cmd *cmd)
+{
+ struct isl6421 *isl6421 = (struct isl6421 *) fe-sec_priv;
+ struct i2c_msg msg = { .addr = isl6421-i2c_addr, .flags = 0,
+.buf = isl6421-config,
+.len = sizeof(isl6421-config) };
+
+ isl6421-config |= ISL6421_DCL;
+
+ isl6421-config |= isl6421-override_or;
+ isl6421-config = isl6421-override_and;
+
+ if (i2c_transfer(isl6421-i2c, msg, 1) != 1)
+ return -EIO;
+
+ isl6421-config = ~ISL6421_DCL;
+
+ return
Re: [PATCH] isl6421.c - added optional features: tone control and temporary diseqc overcurrent
Hi Hermann, Attached patch adds two optional (so, disabled by default and therefore could not break any compatibility) features: 1, tone_control=1 When enabled, ISL6421 overrides frontend's tone control function (fe-ops.set_tone) by its own one. On your comments, the better is to describe why someone would need to use such option. You should also add a quick hint about that at the option description. Well, I'm not sure I can make some good hint why such option can be useful by someone. I can only say that isl6121 has possibility to drive 22k tone, so why not enable usage of it? well, we have much more experienced guys than me here on that, but it should be device specific then. Of course, we made such code because we were using exactly this way of 22k control in our device. So the demod can't do it or just free choice? Well, more detailed Ales can speak about it, he is hw guy here :) Anyway, regardless reason of choice important is that isl6421 can be used this way and, may be even more important, it is used (and works correctly) in our hardware. I understand it can be a bit non-usual way of usage, but as I said, it works for us :) 2, overcurrent_enable=1 When enabled, overcurrent protection is disabled during sending diseqc command. Such option is usable when ISL6421 catch overcurrent threshold and starts limiting output. Note: protection is disabled only during sending of diseqc command, until next set_tone() usage. What typically means only max up to few hundreds of ms. WARNING: overcurrent_enable=1 is dangerous and can damage your device. Use with care and only if you really know what you do. I'm not sure if it is a good idea to have this... Why/when someone would need this? I know that it is a bit dangerous option, so I can understand you can don't like it :) But I would like to note again - such way of using is permitted by datasheet (otherwise it would not be even possible to enable it) and we learnt when used correctly (it is enabled only within diseqc sequence), it boost rotor moving or fixes using some power-eating diseqc switches. If you still feel it is better to not support bit strange mode, then I can live with #if 0 commented out blocks or adding some kernel config option with something like ISL6421_ENABLE_OVERCURRENT or so. Question is, can you melt down some chip with it or not? If you can, stay away, since this was not in the scope earlier. We have tested it with few devices (both rotor and diseqc switches) and have not ran in any damage yet. TBH, I'm writing about possibility of damage only because of understanding that if I disable overcurrent safeguard I can imagine it can end up bad way. But not tested on our side. Regards /Honza -- 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] isl6421.c - added optional features: tone control and temporary diseqc overcurrent
Hi,
this is my first kernel patch, so all comments are welcome.
Attached patch adds two optional (so, disabled by default
and therefore could not break any compatibility) features:
1, tone_control=1
When enabled, ISL6421 overrides frontend's tone control
function (fe-ops.set_tone) by its own one.
2, overcurrent_enable=1
When enabled, overcurrent protection is disabled during
sending diseqc command. Such option is usable when ISL6421
catch overcurrent threshold and starts limiting output.
Note: protection is disabled only during sending
of diseqc command, until next set_tone() usage.
What typically means only max up to few hundreds of ms.
WARNING: overcurrent_enable=1 is dangerous
and can damage your device. Use with care
and only if you really know what you do.
/Honza
Signed-off-by: Jan Petrous jpetr...@gmail.com
---
diff -r f6680fa8e7ec linux/drivers/media/dvb/frontends/isl6421.c
--- a/linux/drivers/media/dvb/frontends/isl6421.c Tue Oct 20 00:08:05 2009 +0900
+++ b/linux/drivers/media/dvb/frontends/isl6421.c Sun Oct 25 00:59:46 2009 +0200
@@ -3,6 +3,9 @@
*
* Copyright (C) 2006 Andrew de Quincey
* Copyright (C) 2006 Oliver Endriss
+ * Copyright (C) 2009 Ales Jurik and Jan Petrous (added optional 22k tone
+ *support and temporary diseqc overcurrent enable until
+ *next command - set voltage or tone)
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -35,12 +38,23 @@
#include dvb_frontend.h
#include isl6421.h
+static int tone_control = 0;
+module_param(tone_control, int, S_IRUGO);
+MODULE_PARM_DESC(tone_control, Set ISL6421 to control 22kHz tone);
+
+static int overcurrent_enable = 0;
+module_param(overcurrent_enable, int, S_IRUGO);
+MODULE_PARM_DESC(overcurrent_enable, Set ISL6421 to temporary enable overcurrent
+ when diseqc command is active);
+
struct isl6421 {
u8 config;
u8 override_or;
u8 override_and;
struct i2c_adapter *i2c;
u8 i2c_addr;
+ int (*diseqc_send_master_cmd_orig)(struct dvb_frontend* fe,
+ struct dvb_diseqc_master_cmd* cmd);
};
static int isl6421_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
@@ -60,6 +74,53 @@
break;
case SEC_VOLTAGE_18:
isl6421-config |= (ISL6421_EN1 | ISL6421_VSEL1);
+ break;
+ default:
+ return -EINVAL;
+ };
+
+ isl6421-config |= isl6421-override_or;
+ isl6421-config = isl6421-override_and;
+
+ return (i2c_transfer(isl6421-i2c, msg, 1) == 1) ? 0 : -EIO;
+}
+
+static int isl6421_send_diseqc(struct dvb_frontend *fe,
+struct dvb_diseqc_master_cmd *cmd)
+{
+ struct isl6421 *isl6421 = (struct isl6421 *) fe-sec_priv;
+ struct i2c_msg msg = { .addr = isl6421-i2c_addr, .flags = 0,
+.buf = isl6421-config,
+.len = sizeof(isl6421-config) };
+
+ isl6421-config |= ISL6421_DCL;
+
+ isl6421-config |= isl6421-override_or;
+ isl6421-config = isl6421-override_and;
+
+ if (i2c_transfer(isl6421-i2c, msg, 1) != 1) return -EIO;
+
+ isl6421-config = ~ISL6421_DCL;
+
+ return isl6421-diseqc_send_master_cmd_orig(fe, cmd);
+}
+
+static int isl6421_set_tone(struct dvb_frontend *fe, fe_sec_tone_mode_t tone)
+{
+ struct isl6421 *isl6421 = (struct isl6421 *) fe-sec_priv;
+ struct i2c_msg msg = { .addr = isl6421-i2c_addr, .flags = 0,
+.buf = isl6421-config,
+.len = sizeof(isl6421-config) };
+
+ isl6421-config = ~(ISL6421_ENT1);
+
+ printk(KERN_INFO %s: %s\n, __func__, ((tone == SEC_TONE_OFF) ? Off : On));
+
+ switch(tone) {
+ case SEC_TONE_ON:
+ isl6421-config |= ISL6421_ENT1;
+ break;
+ case SEC_TONE_OFF:
break;
default:
return -EINVAL;
@@ -91,18 +152,26 @@
static void isl6421_release(struct dvb_frontend *fe)
{
+ struct isl6421 *isl6421 = (struct isl6421 *) fe-sec_priv;
+
/* power off */
isl6421_set_voltage(fe, SEC_VOLTAGE_OFF);
+
+ if(overcurrent_enable)
+ fe-ops.diseqc_send_master_cmd =
+ isl6421-diseqc_send_master_cmd_orig;
/* free */
kfree(fe-sec_priv);
fe-sec_priv = NULL;
}
-struct dvb_frontend *isl6421_attach(struct dvb_frontend *fe, struct i2c_adapter *i2c, u8 i2c_addr,
- u8 override_set, u8 override_clear)
+struct dvb_frontend *isl6421_attach(struct dvb_frontend *fe,
+ struct i2c_adapter *i2c, u8 i2c_addr, u8 override_set,
+ u8 override_clear)
{
struct isl6421 *isl6421 = kmalloc(sizeof(struct isl6421), GFP_KERNEL);
+
if (!isl6421)
return NULL;
@@ -131,6 +200,31 @@
/* override frontend ops */
fe-ops.set_voltage = isl6421_set_voltage;
fe-ops.enable_high_lnb_voltage = isl6421_enable_high_lnb_voltage;
+ if(tone_control)
+ fe-ops.set_tone = isl6421_set_tone;
+ if(overcurrent_enable) {
+ if((override_set ISL6421_DCL) ||
+(override_clear ISL6421_DCL)) {
+ /* there is no sense to use overcurrent_enable with DCL bit set
+ * in any override byte */
+ if(override_set ISL6421_DCL)
+printk(KERN_WARNING ISL6421 overcurrent_enable
+ with DCL bit in override_set,
+ overcurrent_enable ignored\n);
+
Re: Viewing HD?
Seems your installed ffmpeg libavcodec library has no support for PAFF+spatial. Check if update of such library can help. Good starting point for PAFF understanging: http://forum.doom9.org/showthread.php?p=927675 and mplayer with PAFF: http://forum.doom9.org/archive/index.php/t-130797.html /Honza PS: I'm not sure if this ML is correct target for your question as it is main development ML for linux-media (v4l2+dvb) subsystem inside kernel. Your question is rather application specific. 2009/10/3 Mikhail Ramendik m...@ramendik.ru: Hello, I have an AverMedia Pro A700 DVB-S card, working well with Kaffeine; the dish is tuned to Astra 28.2E (in Ireland). However, I am unable to view HD. I tried BBC HD and nothing is shown; the terminal output mentions illegal aspect ratio. Instant recording worked. In mplayer, the result was viewed very jerkily, with many messages saying PAFF + spatial direct mode is not implemented; the codec was ffmpeg h.264. CPU load was maxed out (Pentium 3 GHz). Is there any way to view HD - live or recorded? Or if the CPU is not powerful enough, which will be? And, as a CPU workaround, is there a way to recode in non-realtime, without losing data? (With the not implemented messages, I am wary of using mencoder). -- Yours, Mikhail Ramendik -- 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
