Re: [linux-dvb] [PATCH] Userspace tuner
On Thu, Sep 13, 2007, Markus Rechberger wrote: > Let's add the LKML to this. > > On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > > I don't see any technical reason why tuner drivers should be moved to > > > userspace. Looking at xc3028 device, the driver is very simple and > > > doesn't require any special treatment that it isn't possible to be done > > > at kernel. There are already some implementations on kernelspace that > > > works fine. > > > > As from my side to support the xceive driver properly it needs a > > rewrite and a proper API description. Since it's not possible to > > discuss any API changes Not possible? We're doing it all the time... However, your ideas were rejected in this discussion, and you can't seem to get over it. > > don't get me wrong but the existing community is rather small and > > kicking off people who are interested in changing things. IMHO there is a lack of openness caused by people being burned in past flamewars. This makes it a bit difficult to see through what happens and why, and to participate. However, I think it is completely wrong to say that the community is "kicking off people". > > I'm against how the project works out at the moment and how it worked > > out in history. Exactly this way will kick off companies to be > > interested in future like Avermedia. A driver can easily be written > > within a few weeks and I've been struggling with it for 2 years(!!!) > > now just for nothing finally telling me that some guys want to steal > > my code and move it to kernelspace although it would raise more > > complications with upcoming and current devices which have even more > > requirements. Oh dear, there we go again... more flame bait... I reality, 95% of your driver code could have been merged without problems, but you refused to take the small, objectionable part out of the picture. (For those interested: http://mcentral.de/~mrec/patches/v4l-dvb/hg_v4l-dvb-experimental_01.patch The patch changed the internal tuner API and required changes to all tuner drivers.) Your all-or-nothing approach didn't work out. Out of curiosity: How does your userspace approach solve the hybrid (analog/digital TV) tuner problem which was the only objectionable part of your work? And why are the kernel parts of your new interface now less objectionable? What changed? Johannes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On Thu, Sep 13, 2007, Markus Rechberger wrote: Let's add the LKML to this. On 9/13/07, Markus Rechberger [EMAIL PROTECTED] wrote: On 9/12/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: I don't see any technical reason why tuner drivers should be moved to userspace. Looking at xc3028 device, the driver is very simple and doesn't require any special treatment that it isn't possible to be done at kernel. There are already some implementations on kernelspace that works fine. As from my side to support the xceive driver properly it needs a rewrite and a proper API description. Since it's not possible to discuss any API changes Not possible? We're doing it all the time... However, your ideas were rejected in this discussion, and you can't seem to get over it. don't get me wrong but the existing community is rather small and kicking off people who are interested in changing things. IMHO there is a lack of openness caused by people being burned in past flamewars. This makes it a bit difficult to see through what happens and why, and to participate. However, I think it is completely wrong to say that the community is kicking off people. I'm against how the project works out at the moment and how it worked out in history. Exactly this way will kick off companies to be interested in future like Avermedia. A driver can easily be written within a few weeks and I've been struggling with it for 2 years(!!!) now just for nothing finally telling me that some guys want to steal my code and move it to kernelspace although it would raise more complications with upcoming and current devices which have even more requirements. Oh dear, there we go again... more flame bait... I reality, 95% of your driver code could have been merged without problems, but you refused to take the small, objectionable part out of the picture. (For those interested: http://mcentral.de/~mrec/patches/v4l-dvb/hg_v4l-dvb-experimental_01.patch The patch changed the internal tuner API and required changes to all tuner drivers.) Your all-or-nothing approach didn't work out. Out of curiosity: How does your userspace approach solve the hybrid (analog/digital TV) tuner problem which was the only objectionable part of your work? And why are the kernel parts of your new interface now less objectionable? What changed? Johannes - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
Hi, On 9/13/07, Johannes Stezenbach [EMAIL PROTECTED] wrote: On Thu, Sep 13, 2007, Markus Rechberger wrote: We currently have an implementation that works, although it works by downloading several firmwares for several devices or even several countries. This is not what I want to have in future since it's not needed and it's also hard to manage for distributors. All those differences could be adjusted by software even without module parameter hacks. This argument doesn't hold water. The unpleasant point for users and distributors isn't the binary-only thing, it's the no right to distribute problem. And that's the same for firmware blobs or binary-only userspace blobs. IOW, if you can get the right to redistribute a binary-only userspace blob which incudes the firmware inside, why shouldn't you be able to get the right to redistribute just the firmware? In particular xceive based drivers provide a numerous set of features which cannot be implemented into the kernel because the API (both V4L and DVB) are limited. Since to me it seriously has the impression that the project especially the core of the project is closed to the outside world (just how someone stated it out recently he licked the butts of others to get his stuff accepted) Or the other way round: Do you think your binary-only software will be important enough so distributors will go through all the trouble of trying to get a license to include it in their distribution? If so, why wouldn't they do the same for the plain firmware blobs for in-kernel drivers? I don't have any binary only software just as all the time before. I am also allowed to publish firmware for several drivers (not only the em28xx driver). Although as mentioned earlier already the current existing driver is not really manageable due the firmware mess and that driver will change completly and include templates for several other bridge drivers. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On Thu, Sep 13, 2007, Markus Rechberger wrote: We currently have an implementation that works, although it works by downloading several firmwares for several devices or even several countries. This is not what I want to have in future since it's not needed and it's also hard to manage for distributors. All those differences could be adjusted by software even without module parameter hacks. This argument doesn't hold water. The unpleasant point for users and distributors isn't the binary-only thing, it's the no right to distribute problem. And that's the same for firmware blobs or binary-only userspace blobs. IOW, if you can get the right to redistribute a binary-only userspace blob which incudes the firmware inside, why shouldn't you be able to get the right to redistribute just the firmware? Or the other way round: Do you think your binary-only software will be important enough so distributors will go through all the trouble of trying to get a license to include it in their distribution? If so, why wouldn't they do the same for the plain firmware blobs for in-kernel drivers? Johannes - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Johannes Stezenbach [EMAIL PROTECTED] wrote: On Thu, Sep 13, 2007, Markus Rechberger wrote: Let's add the LKML to this. On 9/13/07, Markus Rechberger [EMAIL PROTECTED] wrote: On 9/12/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: I don't see any technical reason why tuner drivers should be moved to userspace. Looking at xc3028 device, the driver is very simple and doesn't require any special treatment that it isn't possible to be done at kernel. There are already some implementations on kernelspace that works fine. As from my side to support the xceive driver properly it needs a rewrite and a proper API description. Since it's not possible to discuss any API changes Not possible? We're doing it all the time... Then ask Mauro about the audio standard discussion which I had with him. However, your ideas were rejected in this discussion, and you can't seem to get over it. As for future projects I see other people having the same problems if they want to join the project. If deeper requirements and/or ideas will come up some particular people will try to run their own game. If I'm doing something wrong technically then state it out show me the bugs that I can understand what I did wrong or what I am doing wrong. As for design changes if someone thinks he has to deny something he has to state out _why_ and not only some overall nontechnical statements which do not help anyone. don't get me wrong but the existing community is rather small and kicking off people who are interested in changing things. IMHO there is a lack of openness caused by people being burned in past flamewars. This makes it a bit difficult to see through what happens and why, and to participate. However, I think it is completely wrong to say that the community is kicking off people. You identified it already the right way in one mail much earlier. It's a messup caused by many people and not only by one single person. And that's also how I see it. I'm against how the project works out at the moment and how it worked out in history. Exactly this way will kick off companies to be interested in future like Avermedia. A driver can easily be written within a few weeks and I've been struggling with it for 2 years(!!!) now just for nothing finally telling me that some guys want to steal my code and move it to kernelspace although it would raise more complications with upcoming and current devices which have even more requirements. Oh dear, there we go again... more flame bait... I reality, 95% of your driver code could have been merged without problems, but you refused to take the small, objectionable part out of the picture. the driver itself still evolves, so the main point is in getting those incomplete APIs to support further requirements. Instead of acknowlidging and seriously discussing the solutions of others all that's beeing done now is to redo things hundred times and splitting development one side beeing more open (which is the userspace work) and the other part beeing more closed to a few people only (the inkernel work). It's not my task to convince myself to rewrite the base of something which I don't think that it would be valueable. The one who wants me that I spend days in changing my code should try to convince me to change my mind on that, unless he can provide patches which demonstrate that his changes are definitelly an advantage over what has been done from my side. I will for sure acknowlidge everything that will seriously improve the work which has been done. (For those interested: http://mcentral.de/~mrec/patches/v4l-dvb/hg_v4l-dvb-experimental_01.patch The patch changed the internal tuner API and required changes to all tuner drivers.) The main problem is moreover that the RFC didn't get discussed properly, afterwards people wondered what happened, even though the sources were also available all the time in a public repository. Your all-or-nothing approach didn't work out. well we got far enough that I end up to step away and preparing the sources to be able to get submitted beside linuxtv since I don't/didn't get any useful technical feedback there. Convince me that my work is welcome then I might start to submit smaller patches, I already spent days for exporting patches in history and it all end up nowhere but in unfriendly discussions - which also turned me to be unfriendly to some people (which I've been told that I should ignore them recently and also not continue to to argue on a nontechnical level .. althought as mentioned I'm not the only one who made mistakes :-) Out of curiosity: How does your userspace approach solve the hybrid (analog/digital TV) tuner problem which was the only objectionable part of your work? And why are the kernel parts of your new interface now less objectionable? What changed? It's only a step in development, I do not intend to keep
Re: [linux-dvb] [PATCH] Userspace tuner
It's only a step in development, I do not intend to keep the kernel stub in the end, but I do intend to keep and use the userspace drivers with i2c-dev in the long run, this requires a v4l/dvb library at the front of everything. Well, this was what adq and myself did with libdvbapi and mti, (much before UIO was announced at LK.) It is not tied to I2C either. But, according to your statements (with regards to i2c-dev) you can handle only some I2C based devices, which is in fact a subset of a subset. Also not to forget that hardly a few I2C devices are in fact truly I2C compatible. In fact many variables to be considered. Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. Manu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Manu Abraham [EMAIL PROTECTED] wrote: It's only a step in development, I do not intend to keep the kernel stub in the end, but I do intend to keep and use the userspace drivers with i2c-dev in the long run, this requires a v4l/dvb library at the front of everything. Well, this was what adq and myself did with libdvbapi and mti, (much before UIO was announced at LK.) It is not tied to I2C either. I2C is the main communication path for it, although there are callback mechanisms available which add the possibility for different configuration paths. But, according to your statements (with regards to i2c-dev) you can handle only some I2C based devices, which is in fact a subset of a subset. Also not to forget that hardly a few I2C devices are in fact truly I2C compatible. In fact many variables to be considered. The analogue tuner core is also only for i2c only devices which most devices rely on. Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
Markus Rechberger wrote: On 9/13/07, Manu Abraham [EMAIL PROTECTED] wrote: It's only a step in development, I do not intend to keep the kernel stub in the end, but I do intend to keep and use the userspace drivers with i2c-dev in the long run, this requires a v4l/dvb library at the front of everything. Well, this was what adq and myself did with libdvbapi and mti, (much before UIO was announced at LK.) It is not tied to I2C either. I2C is the main communication path for it, although there are callback mechanisms available which add the possibility for different configuration paths. Sorry, i must say that what you said is wrong. The example implementation in libdvbapi/mti is I2C only with a STV0299 on the TTPCI, if that was what you meant. But if you need examples for every possible interface, then probably you are out of luck. Manu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Manu Abraham [EMAIL PROTECTED] wrote: Markus Rechberger wrote: On 9/13/07, Manu Abraham [EMAIL PROTECTED] wrote: It's only a step in development, I do not intend to keep the kernel stub in the end, but I do intend to keep and use the userspace drivers with i2c-dev in the long run, this requires a v4l/dvb library at the front of everything. Well, this was what adq and myself did with libdvbapi and mti, (much before UIO was announced at LK.) It is not tied to I2C either. I2C is the main communication path for it, although there are callback mechanisms available which add the possibility for different configuration paths. Sorry, i must say that what you said is wrong. The example implementation in libdvbapi/mti is I2C only with a STV0299 on the TTPCI, if that was what you meant. But if you need examples for every possible interface, then probably you are out of luck. I didn't comment the libdvbapi/mti driver. I'm quite confident that non I2C protocols can be handled by a callback function. In the end it's either a usb control command or pci mmio writes in the current usual cases and such calls could be handled behind a callback function which is implemented in the driver. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
Markus Rechberger wrote: On 9/13/07, Manu Abraham [EMAIL PROTECTED] wrote: Markus Rechberger wrote: On 9/13/07, Manu Abraham [EMAIL PROTECTED] wrote: It's only a step in development, I do not intend to keep the kernel stub in the end, but I do intend to keep and use the userspace drivers with i2c-dev in the long run, this requires a v4l/dvb library at the front of everything. Well, this was what adq and myself did with libdvbapi and mti, (much before UIO was announced at LK.) It is not tied to I2C either. I2C is the main communication path for it, although there are callback mechanisms available which add the possibility for different configuration paths. Sorry, i must say that what you said is wrong. The example implementation in libdvbapi/mti is I2C only with a STV0299 on the TTPCI, if that was what you meant. But if you need examples for every possible interface, then probably you are out of luck. I didn't comment the libdvbapi/mti driver. I'm quite confident that non I2C protocols can be handled by a callback function. In the end it's either a usb control command or pci mmio writes There's also DTL in some cases. It's not USB msgs and or PCI MMIO alone. The actual DTL spec is unfortunately not open. Manu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. I know for certain that adding a userland API tuner/demod interface to the kernel, allowing non-caring opportunistic silicon or board vendors to developer closed source proprietary drivers, will have a negative effect on the community and we'd set back linuxtv 3-5 years. I know for certain that it would happen. Trust me. I've told you this countless times and you're not hearing me. Hauppauge have some leverage with Conexant and NXP to release public datasheets. If they just have to release a demod.so (or similar) loadable, they'll defer to the board vendors and we'll see the certain board vendors 'locking other board vendors' out of their drivers. We'll see embedded firmware, not shared between drivers. Except, it won't stop at demod.so. It will extend into unfixable bugs for VendorB's board, because VendorA doesn't want to release a new demod.so, and VendorB has no linux resources. What happens next? For financial reasons - demod.so will begin to include checks to see if specific PCI or USB devices are present in the system, and will fail to work properly (if at all) when they're not being used with the preferred products. Read my lips: For commercial reasons, this enables driver components that only work if specific boards are present. - Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Steven Toth [EMAIL PROTECTED] wrote: Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. I know for certain that adding a userland API tuner/demod interface to the kernel, allowing non-caring opportunistic silicon or board vendors to developer closed source proprietary drivers, will have a negative effect on the community and we'd set back linuxtv 3-5 years. I know for certain that it would happen. Trust me. I've told you this countless times and you're not hearing me. Hauppauge have some leverage with Conexant and NXP to release public datasheets. If they just have to release a demod.so (or similar) loadable, they'll defer to the board vendors and we'll see the certain board vendors 'locking other board vendors' out of their drivers. We'll see embedded firmware, not shared between drivers. Except, it won't stop at demod.so. It will extend into unfixable bugs for VendorB's board, because VendorA doesn't want to release a new demod.so, and VendorB has no linux resources. What happens next? For financial reasons - demod.so will begin to include checks to see if specific PCI or USB devices are present in the system, and will fail to work properly (if at all) when they're not being used with the preferred products. Steven, what stops vendors of using the current existing code to achieve that goal. They could provide binary drivers with the existing API. What stops companies to intercept the ioctl calls and overriding some I2C commands? Since you know about windows drivers (at least I think that you know about it) you might know about the limitations of the v4l/dvb API in general the reason just put as much code as possible into the kernel just for forcing companies to release code under GPL doesn't seem to be valid. How about proprietary video formats, would you also place the decoding algorithms in kernel just to force companies to release their code for it? What do you think about the existing usbfs implementation, which allows to implement usb drivers completly in userspace? What do you think about IOMMU? please answer those questions. thanks, Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
Am Donnerstag, den 13.09.2007, 16:36 -0400 schrieb Steven Toth: Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. I know for certain that adding a userland API tuner/demod interface to the kernel, allowing non-caring opportunistic silicon or board vendors to developer closed source proprietary drivers, will have a negative effect on the community and we'd set back linuxtv 3-5 years. I know for certain that it would happen. Trust me. I've told you this countless times and you're not hearing me. Hauppauge have some leverage with Conexant and NXP to release public datasheets. If they just have to release a demod.so (or similar) loadable, they'll defer to the board vendors and we'll see the certain board vendors 'locking other board vendors' out of their drivers. We'll see embedded firmware, not shared between drivers. Except, it won't stop at demod.so. It will extend into unfixable bugs for VendorB's board, because VendorA doesn't want to release a new demod.so, and VendorB has no linux resources. What happens next? For financial reasons - demod.so will begin to include checks to see if specific PCI or USB devices are present in the system, and will fail to work properly (if at all) when they're not being used with the preferred products. Read my lips: For commercial reasons, this enables driver components that only work if specific boards are present. - Steve I do confirn that I have all this, Steve mentions, really have seen already! Markus, sorry, they did abuse it and will do it again. Hermann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
Markus Rechberger wrote: On 9/13/07, Steven Toth [EMAIL PROTECTED] wrote: Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. I know for certain that adding a userland API tuner/demod interface to the kernel, allowing non-caring opportunistic silicon or board vendors to developer closed source proprietary drivers, will have a negative effect on the community and we'd set back linuxtv 3-5 years. I know for certain that it would happen. Trust me. I've told you this countless times and you're not hearing me. Hauppauge have some leverage with Conexant and NXP to release public datasheets. If they just have to release a demod.so (or similar) loadable, they'll defer to the board vendors and we'll see the certain board vendors 'locking other board vendors' out of their drivers. We'll see embedded firmware, not shared between drivers. Except, it won't stop at demod.so. It will extend into unfixable bugs for VendorB's board, because VendorA doesn't want to release a new demod.so, and VendorB has no linux resources. What happens next? For financial reasons - demod.so will begin to include checks to see if specific PCI or USB devices are present in the system, and will fail to work properly (if at all) when they're not being used with the preferred products. Steven, what stops vendors of using the current existing code to achieve that goal. They could provide binary drivers with the existing API. Because the good people in this mailing list are keeping them honest. Give any board or silicon company the ability to protect their IP, even in the smallest way and they'll do it, and for no good technical reason. It's a cut throat market and it's not clear that everyone understands just how thin sales margins really are. That means Hauppauge potentially releasing a binary driver, because it's much easier than seeking silicon vendor permission for a public diver. The net result of that would mean I'd have to leave the company and find another company that practices the one thing I truly care about open source and open development groups. I'm keeping Hauppauge honest with their Linux involvement and I'm not alone. Other devs in other linux subsystems in other companies are doing the same thing. Binary drivers (or binary components) leads Linux back in time. I can't believe your so passionate about protecting secrets. What stops companies to intercept the ioctl calls and overriding some I2C commands? Why would a company want to do that? Companies don't do that, hackers do that. Since you know about windows drivers (at least I think that you know about it) you might know about the limitations of the v4l/dvb API in general the reason just put as much code as possible into the kernel just for forcing companies to release code under GPL doesn't seem to be valid. It seems perfectly valid to me. How about proprietary video formats, would you also place the decoding algorithms in kernel just to force companies to release their code for it? The kernel has no good API for those, each new type of video device and suggested API is judged on it's own merits and discussed on the mailing lists. What do you think about the existing usbfs implementation, which allows to implement usb drivers completly in userspace? Those are not my problem and I don't use them, you should raise that with the relevant usb-dev mailing lists. I'm here because I care about linuxtv. Please stay on topic. What do you think about IOMMU? Just because AMD or INTEL want to invent some whizzy new technology it doesn't say anything about the TV card development and retail business. Intel and AMD have teams of Linux engineers helping operating system developers bring their ideas and technologies to new platforms. That's a million miles away from any of the TV board vendors I know of, who have little or NO fulltime linux developers and consider the 5% market fringe at best. Markus, senior devs in the LinuxTV group are telling you, based on their commercial experience, that userspace access is technically
Re: [linux-dvb] [PATCH] Userspace tuner
Well, I'd like to see Linus' opinion about this, because while programmers keep discussing this, users are waiting forever... so if Markus has a concrete and better solution, why don't use it? And as far as I know, Markus is the programmer who is most interested in this code. I didn't see anybody else in the world doing his work... And I always had a impression that if most of things could be done in user space, than it will be better (for example, devfs -> udev). Why do everything in kernel space? Lets put *less* code in the kernel, not more code. And besides that, code in user space can be changed easily. Code in kernel has to wait a long time for Linus to accept (*if* he accepts). Linus could put an end to this discussion, since he will say the final word. On Thu, 13 Sep 2007 01:10:55 +0200 "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > Let's add the LKML to this. > > On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > > Markus, > > > > > > Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: > > > > Following patch adds the possibility to implement tuner drivers in > > > > userspace. > > > > > > As you asked me about userspace driver, at Linux Conf Europe, let me > > > give you my feedback about it. > > > > > > On Linux, userspace-to-kernelspace APIs are meant to be forever. This > > > means that, once a newer API is created, this should remain supported > > > for all future versions. So, such APIs should be carefully analyzed and > > > accepted by the community, before going to mainstream. > > > > > > > The V4L and DVB API is stable at the moment because it's at a stage > > which is sufficient for older devices but not sufficient for newer > > devices anymore. > > To support newer device it needs a change. > > > > > I don't see any technical reason why tuner drivers should be moved to > > > userspace. Looking at xc3028 device, the driver is very simple and > > > doesn't require any special treatment that it isn't possible to be done > > > at kernel. There are already some implementations on kernelspace that > > > works fine. > > > > > > > As from my side to support the xceive driver properly it needs a > > rewrite and a proper API description. Since it's not possible to > > discuss any API changes I will work around at least for those devices > > which I can support for. > > > > > On the other hand, a TV driver without a tuner is a broken driver. With > > > parts of the driver being at userspace, this means to add undesired > > > complexity at the drivers architecture, while not bringing any benefit. > > > > > > If you look at V4L history, the first drivers started at userspace, > > > being migrated to kernelspace, where we have the proper scenario for > > > managing those devices. > > > > > > Another aspect that should be analyzed is what is desired by the > > > community: > > > > don't get me wrong but the existing community is rather small and > > kicking off people who are interested in changing things. > > I recently had a talk with someone and I've been told that I'm kicking > > off people. > > Guess why I kick off people? -> because they do not contribute in a > > productive way which also means submitting patches. Optical useless > > changes don't make any difference at the functionality in the end. And > > my requirements are ignored constantly here. > > > > > kernelspace tuners or userspace tuners. Keeping support for > > > both at long term doesn't seem reasonable. The Linux community should > > > decide what is the better way. Currently, only you are pushing for > > > userspace tuners, mainly due to non-technical reasons. > > > > read the project site and you will see the reasons. > > http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages > > Another advantage is that I have cygwin based code here which I can > > easily reuse with all that work I'm not going to reinvent the wheel > > even for newer devices which I work on. > > > > > Almost all the > > > other developers are comfortable with kernelspace tuners. So, creating > > > an userspace interface just to make you happy is not the way we should > > > go. > > > > > > > I'm afraid of giving the people which are against what I submitted the > > responsibility over the project. Initially there was an RFC which > > didn't get commented either (well there was one useless comment, I > > tried to discuss it on IRC before with the same guy) after I > > implemented exactly what I proposed there I got the first non > > technical comments - also keep in mind that working on something costs > > alot of time and talking about something unknown is rather cheap. > > > > > A final aspect is that having an userspace driver for tuner will mean > > > that the kernel driver will depend on an userspace counterpart in order > > > to work. This will allow a vendor with bad intentions to release a > > > partially broken userspace
Re: [linux-dvb] [PATCH] Userspace tuner
Let's add the LKML to this. On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > Markus, > > > > Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: > > > Following patch adds the possibility to implement tuner drivers in > > > userspace. > > > > As you asked me about userspace driver, at Linux Conf Europe, let me > > give you my feedback about it. > > > > On Linux, userspace-to-kernelspace APIs are meant to be forever. This > > means that, once a newer API is created, this should remain supported > > for all future versions. So, such APIs should be carefully analyzed and > > accepted by the community, before going to mainstream. > > > > The V4L and DVB API is stable at the moment because it's at a stage > which is sufficient for older devices but not sufficient for newer > devices anymore. > To support newer device it needs a change. > > > I don't see any technical reason why tuner drivers should be moved to > > userspace. Looking at xc3028 device, the driver is very simple and > > doesn't require any special treatment that it isn't possible to be done > > at kernel. There are already some implementations on kernelspace that > > works fine. > > > > As from my side to support the xceive driver properly it needs a > rewrite and a proper API description. Since it's not possible to > discuss any API changes I will work around at least for those devices > which I can support for. > > > On the other hand, a TV driver without a tuner is a broken driver. With > > parts of the driver being at userspace, this means to add undesired > > complexity at the drivers architecture, while not bringing any benefit. > > > > If you look at V4L history, the first drivers started at userspace, > > being migrated to kernelspace, where we have the proper scenario for > > managing those devices. > > > > Another aspect that should be analyzed is what is desired by the > > community: > > don't get me wrong but the existing community is rather small and > kicking off people who are interested in changing things. > I recently had a talk with someone and I've been told that I'm kicking > off people. > Guess why I kick off people? -> because they do not contribute in a > productive way which also means submitting patches. Optical useless > changes don't make any difference at the functionality in the end. And > my requirements are ignored constantly here. > > > kernelspace tuners or userspace tuners. Keeping support for > > both at long term doesn't seem reasonable. The Linux community should > > decide what is the better way. Currently, only you are pushing for > > userspace tuners, mainly due to non-technical reasons. > > read the project site and you will see the reasons. > http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages > Another advantage is that I have cygwin based code here which I can > easily reuse with all that work I'm not going to reinvent the wheel > even for newer devices which I work on. > > > Almost all the > > other developers are comfortable with kernelspace tuners. So, creating > > an userspace interface just to make you happy is not the way we should > > go. > > > > I'm afraid of giving the people which are against what I submitted the > responsibility over the project. Initially there was an RFC which > didn't get commented either (well there was one useless comment, I > tried to discuss it on IRC before with the same guy) after I > implemented exactly what I proposed there I got the first non > technical comments - also keep in mind that working on something costs > alot of time and talking about something unknown is rather cheap. > > > A final aspect is that having an userspace driver for tuner will mean > > that the kernel driver will depend on an userspace counterpart in order > > to work. This will allow a vendor with bad intentions to release a > > partially broken userspace driver, with limited capabilities, and a > > closed source driver for full support. This model is likely to occur, if > > you take a look at the past. For example: ATI and Nvidia closed source > > drivers, several soft modem drivers, some network drivers, ... > > > > Please go forward and discuss the UIO driver with Greg Kroah Hartmann > and the fuse driver with the other people. If companies want to > release binary drivers they can easily use the existing code put it > into an RPM or DEB package and Ubuntu will pick it up. > > > With all those issues, I'm against to add an userspace interface for > > tuners. > > > > I'm against how the project works out at the moment and how it worked > out in history. Exactly this way will kick off companies to be > interested in future like Avermedia. A driver can easily be written > within a few weeks and I've been struggling with it for 2 years(!!!) > now just for nothing finally telling me that some guys want to steal > my code and move it to kernelspace although it would raise more > complications with
Re: [linux-dvb] [PATCH] Userspace tuner
Let's add the LKML to this. On 9/13/07, Markus Rechberger [EMAIL PROTECTED] wrote: On 9/12/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: Markus, Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: Following patch adds the possibility to implement tuner drivers in userspace. As you asked me about userspace driver, at Linux Conf Europe, let me give you my feedback about it. On Linux, userspace-to-kernelspace APIs are meant to be forever. This means that, once a newer API is created, this should remain supported for all future versions. So, such APIs should be carefully analyzed and accepted by the community, before going to mainstream. The V4L and DVB API is stable at the moment because it's at a stage which is sufficient for older devices but not sufficient for newer devices anymore. To support newer device it needs a change. I don't see any technical reason why tuner drivers should be moved to userspace. Looking at xc3028 device, the driver is very simple and doesn't require any special treatment that it isn't possible to be done at kernel. There are already some implementations on kernelspace that works fine. As from my side to support the xceive driver properly it needs a rewrite and a proper API description. Since it's not possible to discuss any API changes I will work around at least for those devices which I can support for. On the other hand, a TV driver without a tuner is a broken driver. With parts of the driver being at userspace, this means to add undesired complexity at the drivers architecture, while not bringing any benefit. If you look at V4L history, the first drivers started at userspace, being migrated to kernelspace, where we have the proper scenario for managing those devices. Another aspect that should be analyzed is what is desired by the community: don't get me wrong but the existing community is rather small and kicking off people who are interested in changing things. I recently had a talk with someone and I've been told that I'm kicking off people. Guess why I kick off people? - because they do not contribute in a productive way which also means submitting patches. Optical useless changes don't make any difference at the functionality in the end. And my requirements are ignored constantly here. kernelspace tuners or userspace tuners. Keeping support for both at long term doesn't seem reasonable. The Linux community should decide what is the better way. Currently, only you are pushing for userspace tuners, mainly due to non-technical reasons. read the project site and you will see the reasons. http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages Another advantage is that I have cygwin based code here which I can easily reuse with all that work I'm not going to reinvent the wheel even for newer devices which I work on. Almost all the other developers are comfortable with kernelspace tuners. So, creating an userspace interface just to make you happy is not the way we should go. I'm afraid of giving the people which are against what I submitted the responsibility over the project. Initially there was an RFC which didn't get commented either (well there was one useless comment, I tried to discuss it on IRC before with the same guy) after I implemented exactly what I proposed there I got the first non technical comments - also keep in mind that working on something costs alot of time and talking about something unknown is rather cheap. A final aspect is that having an userspace driver for tuner will mean that the kernel driver will depend on an userspace counterpart in order to work. This will allow a vendor with bad intentions to release a partially broken userspace driver, with limited capabilities, and a closed source driver for full support. This model is likely to occur, if you take a look at the past. For example: ATI and Nvidia closed source drivers, several soft modem drivers, some network drivers, ... Please go forward and discuss the UIO driver with Greg Kroah Hartmann and the fuse driver with the other people. If companies want to release binary drivers they can easily use the existing code put it into an RPM or DEB package and Ubuntu will pick it up. With all those issues, I'm against to add an userspace interface for tuners. I'm against how the project works out at the moment and how it worked out in history. Exactly this way will kick off companies to be interested in future like Avermedia. A driver can easily be written within a few weeks and I've been struggling with it for 2 years(!!!) now just for nothing finally telling me that some guys want to steal my code and move it to kernelspace although it would raise more complications with upcoming and current devices which have even more requirements. I spent more time in rewriting and discussing everything than to get any of those
Re: [linux-dvb] [PATCH] Userspace tuner
Well, I'd like to see Linus' opinion about this, because while programmers keep discussing this, users are waiting forever... so if Markus has a concrete and better solution, why don't use it? And as far as I know, Markus is the programmer who is most interested in this code. I didn't see anybody else in the world doing his work... And I always had a impression that if most of things could be done in user space, than it will be better (for example, devfs - udev). Why do everything in kernel space? Lets put *less* code in the kernel, not more code. And besides that, code in user space can be changed easily. Code in kernel has to wait a long time for Linus to accept (*if* he accepts). Linus could put an end to this discussion, since he will say the final word. On Thu, 13 Sep 2007 01:10:55 +0200 Markus Rechberger [EMAIL PROTECTED] wrote: Let's add the LKML to this. On 9/13/07, Markus Rechberger [EMAIL PROTECTED] wrote: On 9/12/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: Markus, Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: Following patch adds the possibility to implement tuner drivers in userspace. As you asked me about userspace driver, at Linux Conf Europe, let me give you my feedback about it. On Linux, userspace-to-kernelspace APIs are meant to be forever. This means that, once a newer API is created, this should remain supported for all future versions. So, such APIs should be carefully analyzed and accepted by the community, before going to mainstream. The V4L and DVB API is stable at the moment because it's at a stage which is sufficient for older devices but not sufficient for newer devices anymore. To support newer device it needs a change. I don't see any technical reason why tuner drivers should be moved to userspace. Looking at xc3028 device, the driver is very simple and doesn't require any special treatment that it isn't possible to be done at kernel. There are already some implementations on kernelspace that works fine. As from my side to support the xceive driver properly it needs a rewrite and a proper API description. Since it's not possible to discuss any API changes I will work around at least for those devices which I can support for. On the other hand, a TV driver without a tuner is a broken driver. With parts of the driver being at userspace, this means to add undesired complexity at the drivers architecture, while not bringing any benefit. If you look at V4L history, the first drivers started at userspace, being migrated to kernelspace, where we have the proper scenario for managing those devices. Another aspect that should be analyzed is what is desired by the community: don't get me wrong but the existing community is rather small and kicking off people who are interested in changing things. I recently had a talk with someone and I've been told that I'm kicking off people. Guess why I kick off people? - because they do not contribute in a productive way which also means submitting patches. Optical useless changes don't make any difference at the functionality in the end. And my requirements are ignored constantly here. kernelspace tuners or userspace tuners. Keeping support for both at long term doesn't seem reasonable. The Linux community should decide what is the better way. Currently, only you are pushing for userspace tuners, mainly due to non-technical reasons. read the project site and you will see the reasons. http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages Another advantage is that I have cygwin based code here which I can easily reuse with all that work I'm not going to reinvent the wheel even for newer devices which I work on. Almost all the other developers are comfortable with kernelspace tuners. So, creating an userspace interface just to make you happy is not the way we should go. I'm afraid of giving the people which are against what I submitted the responsibility over the project. Initially there was an RFC which didn't get commented either (well there was one useless comment, I tried to discuss it on IRC before with the same guy) after I implemented exactly what I proposed there I got the first non technical comments - also keep in mind that working on something costs alot of time and talking about something unknown is rather cheap. A final aspect is that having an userspace driver for tuner will mean that the kernel driver will depend on an userspace counterpart in order to work. This will allow a vendor with bad intentions to release a partially broken userspace driver, with limited capabilities, and a closed source driver for full support. This model is likely to occur, if you take a look at the past. For example: ATI and Nvidia closed source drivers, several soft modem
