Re: [linux-dvb] [PATCH] Userspace tuner
On Tue, Sep 18, 2007 at 07:56:05PM -0300, Mauro Carvalho Chehab wrote: > proprietary format. This way, an userspace app may use the userspace > library as a "fallback method" for unknown FOURCC formats. The result > will be probably far away from an optimal result on some cases (since it > probably mean double buffering), but this will at least allow userspace > apps to work. As performance become an issue, the userspace app > developer may use the GPL code at userspace API as a reference to write > a proper optimized format driver for its apps. You can dynamically load libraries based on constructed path names which means you can write a simple library for media conversions which in turn will try and open libv4l-format-ABCD.so for any format it doesn't know - and thus is extensible - 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
> The reason why there is no single 'format conversion library' that > everybody uses is because of the large differences between requirements > for such a thing. The line between 'format conversion' and things such > as a video codec, or image processing is very vague. Agreed. What I think it should happen is that the userspace library should focus at the "weird" codecs. E. g. those which uses some sort of proprietary format. This way, an userspace app may use the userspace library as a "fallback method" for unknown FOURCC formats. The result will be probably far away from an optimal result on some cases (since it probably mean double buffering), but this will at least allow userspace apps to work. As performance become an issue, the userspace app developer may use the GPL code at userspace API as a reference to write a proper optimized format driver for its apps. Just my 2 cents. Cheers, Mauro - 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/18/07, Jelle Foks <[EMAIL PROTECTED]> wrote: > Markus Rechberger wrote: > > On 9/14/07, Alan Cox <[EMAIL PROTECTED]> wrote: > >> On Fri, Sep 14, 2007 at 01:17:05AM +0200, Markus Rechberger wrote: > >>> what stops vendors of using the current existing code to achieve that > >>> goal. They could provide binary drivers with the existing API. > >> If you feel lucky about the GPL > >> > >>> What stops companies to intercept the ioctl calls and overriding some > >>> I2C commands? > >> The GPL - derivative work is the boundary not code linkage. Possibly a > >> userspace > >> tuner hack would probably fit this too. Especially if a specific vendor > is > >> producing both bits together and trying to claim they are independant. > >> > >>> How about proprietary video formats, would you also place the decoding > >>> algorithms in kernel just to force companies to release their code > >>> for it? > >> No, I would assume they'd provide a proprietary conversion library that > >> no nobody would use (just like their hw). We keep format conversion > firmly > >> seperated from hardware I/O processing. > >> > > > > In general there are known formats available, the drawback is that every > TV > > application deals with it in a non-unified way at the moment, meaning alot > > code duplication in userspace since there's no library available at the > moment > > which does the videoconversion from one to another format. Such a library > is > > beeing developed at the moment which gets plugged infront of accessing > > the devicenodes. > > IMHO... > > The reason why there is no single 'format conversion library' that > everybody uses is because of the large differences between requirements > for such a thing. The line between 'format conversion' and things such > as a video codec, or image processing is very vague. For example: Some > apps just want compressed video format output. Would video compression > be part of such a 'format conversion library'? If so, then which > compressed video formats? Proprietary ones too? If not all formats that > exist are supported, it would not be complete for some or many apps, and > maybe not even useful at all (because integrating any necessary > pixel-format conversion into the compression routines may be more > efficient than making multiple passes over the data with separate > libraries). Will the library include resizing? If so, which resampling > algorithms? Then how about rotation? Then maybe geometrical mapping > (games could want that)? Will the library be able to adjust > brightness/contrast/saturation in software? If so, then what about noise > filtering (which algorithms?), etc... perhaps the library should go all > the way, bind to port 80 and serve-up a live video stream > 'youtube-style'? ok, now that would definitely go too far... > > The question is: Where exactly to put the boundary? > good statement, the absolute goal should be that enduser applications can handle videostreams as easy as possible. This is currently not given. For example I have devices which work with ekiga, and some devices which don't work with ekiga. Why so? Ekiga already uses a rather big library for handling videodevices. Another point is why doesn't tvtime support digital audio? People have to run sox in the background to get any sound piped from the corresponding dsp node to the soundcard, and also this is no general way. So first people have to look up what the correct audio node of their TV device is... (there are small scripts available which lets the users select) But I also think this should happen automatically. There are many devices out there which don't even include all ioctl calls which are documented in the specs. And since sometimes the API needs to be updated a library could handle this in a better way. I see the whole v4l-dvb project as half way done at the moment because of the unflexibility of the whole system. > My point is that format conversion is not a video capture driver issue. > Sure, it is convenient for apps to be able to use standard libraries > that perform certain functions with optimized code, etc, but for the > purpose of capturing video (media) it's not always necessary to convert > the output into something different before the data is useful for an app. > this is just a thought, I think a pluggable mechanism would be nice for that. The library could query the device about it's capabilities and if it returns a non standard videoformat just add a mechanism for loading the corresponding videocodec if available. > Certain format conversions can be done very efficiently inside video > cards, for example, and an app may prefer to use that. If a video card > has such functionality, access to it should be part of its driver. > yes, this would always be the optimal way > Applications needing format conversions would benefit tremendously from > a good, powerful, flexible, efficient, etc, library that removes the > necessity for each application to choose between using a
Re: [linux-dvb] [PATCH] Userspace tuner
Markus Rechberger wrote: > On 9/14/07, Alan Cox <[EMAIL PROTECTED]> wrote: >> On Fri, Sep 14, 2007 at 01:17:05AM +0200, Markus Rechberger wrote: >>> what stops vendors of using the current existing code to achieve that >>> goal. They could provide binary drivers with the existing API. >> If you feel lucky about the GPL >> >>> What stops companies to intercept the ioctl calls and overriding some >>> I2C commands? >> The GPL - derivative work is the boundary not code linkage. Possibly a >> userspace >> tuner hack would probably fit this too. Especially if a specific vendor is >> producing both bits together and trying to claim they are independant. >> >>> How about proprietary video formats, would you also place the decoding >>> algorithms in kernel just to force companies to release their code >>> for it? >> No, I would assume they'd provide a proprietary conversion library that >> no nobody would use (just like their hw). We keep format conversion firmly >> seperated from hardware I/O processing. >> > > In general there are known formats available, the drawback is that every TV > application deals with it in a non-unified way at the moment, meaning alot > code duplication in userspace since there's no library available at the moment > which does the videoconversion from one to another format. Such a library is > beeing developed at the moment which gets plugged infront of accessing > the devicenodes. IMHO... The reason why there is no single 'format conversion library' that everybody uses is because of the large differences between requirements for such a thing. The line between 'format conversion' and things such as a video codec, or image processing is very vague. For example: Some apps just want compressed video format output. Would video compression be part of such a 'format conversion library'? If so, then which compressed video formats? Proprietary ones too? If not all formats that exist are supported, it would not be complete for some or many apps, and maybe not even useful at all (because integrating any necessary pixel-format conversion into the compression routines may be more efficient than making multiple passes over the data with separate libraries). Will the library include resizing? If so, which resampling algorithms? Then how about rotation? Then maybe geometrical mapping (games could want that)? Will the library be able to adjust brightness/contrast/saturation in software? If so, then what about noise filtering (which algorithms?), etc... perhaps the library should go all the way, bind to port 80 and serve-up a live video stream 'youtube-style'? ok, now that would definitely go too far... The question is: Where exactly to put the boundary? My point is that format conversion is not a video capture driver issue. Sure, it is convenient for apps to be able to use standard libraries that perform certain functions with optimized code, etc, but for the purpose of capturing video (media) it's not always necessary to convert the output into something different before the data is useful for an app. Certain format conversions can be done very efficiently inside video cards, for example, and an app may prefer to use that. If a video card has such functionality, access to it should be part of its driver. Applications needing format conversions would benefit tremendously from a good, powerful, flexible, efficient, etc, library that removes the necessity for each application to choose between using a video-card accelerator, or MMX code, or SSE code, or another method to do the work. Maybe it should allow applications to request a 'media stream' in a given format and container, with conversion automagically happening when needed, as efficiently as possible (or at the requested quality level). But that doesn't mean that that library should be an integrated part of the video capture interface. The boundary of the 'media capture interface' driver should be on the data, as delivered by the video capture interface. The reason is that the 'best' way to do format conversions depend on the application requirements (what formats can the app use directly?), on the available hardware (is there an accelerator that can help?), and on the quality expectation or system issues (is the CPU the bottleneck or is the USB bus saturated? Do we request JPEG from the webcam and decompress into YUV, or do we request the RAW bayer from the high-quality image sensor and convert that into YUV?). Choices, choises... That means that IMHO, to prevent having runaway complexity plus chasing a moving target, format conversion should definitely not be embedded in the API to access video capture hardware, unless the hardware itself offers format conversion functions (for example, as it does now, by allowing choice of the output format, but only for formats that the hardware itself supports directly). > Although in the long run I'm looking forward to reuse the userspace tuners > with > such a library infront of everything by usi
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/15/07, Bernard Jungen <[EMAIL PROTECTED]> wrote: > On Sat, Sep 15, 2007 at 11:04:42AM -0300, Mauro Carvalho Chehab wrote: > > With respect to your kernel-userspace API for xc3028, you made something > > that seemed to be a dream: there's a consensus: not a single developer > > believed that this is the better way; nobody seems that this is the > > better approach. > > > > So, or you are the only media developer with good sense in the face of > > the Earth, or you're incapable of understand the obvious: you're wrong > > with this approach. IMO, the answer is quite obvious. > > Yes, as a newbie observer on the v4l list, the answer is obvious to me, > at last, and the reason is not entirely technical. I can't read so many > bogus arguments on so few lines without reacting. > > Rephrasing Mauro: > > "Not a single developer out of a few SEEMS to believe that it is the BETTER > approach, so since the FEW represent ALL media developers in the world, and > since there is only ONE RIGHT way to do things, and since the GROUP is > always RIGHT and always knows better than the individual, then YOU're WRONG > and I'm right. Conform to the group and do as the group says, whatever the > consequences!" > > Geeks are decidedly as prone as others to blindly accept travelling on the > slippery road of herd mentality and "obvious" conclusions based on > appearances. Is this OPEN source development or a dictatorship or what? > > So in the end Mauro will be right. And Markus will continue to develop and > defend his stuff as HE sees fit. He knows his own work better than anyone > else. It will be HIS way or nothing with his own stuff, it's his inalienable > right. > > And don't be naive, if there's no solution more viable than Markus' one, > then the latter will eventually be widely adopted somehow, sometime, > whatever the amount of grumbling from the establishment. No > dictatorship/forced consensus can decide future's direction, nor improve > its already low own viability. > I see it exactly the same way. Well I will continue to provide an alternative stack with alternative drivers. The peer review shows that it doesn't work too well without people participating fixing problems, the initial drivers were inkernel based and due some updates in modules which are used by the em28xx some devices which previously worked don't work anymore in the kernel. As for the em28xx the driver will use userspace i2c based tuners, decoders and demodulators. The userspace modules will use unaltered sample drivers which are provided by several companies, which also saves alot time in future for that project. Those drivers will also officially be provided and recommended by the manufacturing company of those devices, including the proper firmware. Personally I won't spend any time on reinventing the wheel and fixing drivers which get broken by not taking care of it. Beside that people are welcome to contribute without having to fear a political overhead of discussing requirements and other issues when changing the corresponding alternative core code. The project and how it will/should go on is documented at mcentral.de. I also see that as a good way for the community, that way the linuxtv guys have to prove that they can be open to other people without adding too much noise and overhead otherwise people will contribute to the alternative project as some already do. 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 Saturday 15 September 2007 18:58:34 Bernard Jungen wrote: > On Sat, Sep 15, 2007 at 11:04:42AM -0300, Mauro Carvalho Chehab wrote: > > With respect to your kernel-userspace API for xc3028, you made > > something that seemed to be a dream: there's a consensus: not a > > single developer believed that this is the better way; nobody seems > > that this is the better approach. > > > > So, or you are the only media developer with good sense in the face > > of the Earth, or you're incapable of understand the obvious: you're > > wrong with this approach. IMO, the answer is quite obvious. > > Yes, as a newbie observer on the v4l list, the answer is obvious to > me, at last, and the reason is not entirely technical. I can't read > so many bogus arguments on so few lines without reacting. > > Rephrasing Mauro: > > "Not a single developer out of a few SEEMS to believe that it is the > BETTER approach, so since the FEW represent ALL media developers in > the world, and since there is only ONE RIGHT way to do things, and > since the GROUP is always RIGHT and always knows better than the > individual, then YOU're WRONG and I'm right. Conform to the group and > do as the group says, whatever the consequences!" > > Geeks are decidedly as prone as others to blindly accept travelling > on the slippery road of herd mentality and "obvious" conclusions > based on appearances. Is this OPEN source development or a > dictatorship or what? It's called peer-review. It's why the linux kernel is as good as it is today. Yes, the tuner belongs in kernel-space. I'll use the user-space version from Markus in my ivtv driver as long as there is no alternative, but as soon as the same tuner is merged in the kernel I'll switch to that one. Why? Because the end-user shouldn't have to install a userspace daemon just to support a stupid little tuner. I've said this before, and I'll say it again: the sole reason for this mess is personality clashes. Technically it should have gone in two years ago. I worked two years on getting the ivtv driver (and supporting i2c drivers) merged into the kernel, in the process of which many V4L2 (and a few DVB) API additions and refinements were made, all by working with the core developers. The end result was much better than if I would have done it all by myself. It can be a difficult process (it's always hard to accept that the other person is right), and sometimes it means you have to sleep on it for a few nights before you realize that you are wrong and the other person is right. It can also go the other way, but even then it helps you because it forces you to express the technical reasons why you are right. And that gives you a better understanding of the issues at stake. > So in the end Mauro will be right. And Markus will continue to > develop and defend his stuff as HE sees fit. He knows his own work > better than anyone else. It will be HIS way or nothing with his own > stuff, it's his inalienable right. You're never alone. You work within the kernel framework and within the v4l-dvb framework. You want to get something done, then you'll have to work together. The linux project is no different there then working for a company. And no, Mauro isn't always right. But just saying 'I'm right, you're wrong' never helps. Never, ever. Arguing your case based on technical arguments is the best way to go. Always remain respectful with whomever you're arguing, always remain polite. The time for rational arguments in this situation has long since passed, unfortunately. > And don't be naive, if there's no solution more viable than Markus' > one, then the latter will eventually be widely adopted somehow, > sometime, whatever the amount of grumbling from the establishment. No > dictatorship/forced consensus can decide future's direction, nor > improve its already low own viability. Sigh. Hans - 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 Sat, Sep 15, 2007 at 11:04:42AM -0300, Mauro Carvalho Chehab wrote: > With respect to your kernel-userspace API for xc3028, you made something > that seemed to be a dream: there's a consensus: not a single developer > believed that this is the better way; nobody seems that this is the > better approach. > > So, or you are the only media developer with good sense in the face of > the Earth, or you're incapable of understand the obvious: you're wrong > with this approach. IMO, the answer is quite obvious. Yes, as a newbie observer on the v4l list, the answer is obvious to me, at last, and the reason is not entirely technical. I can't read so many bogus arguments on so few lines without reacting. Rephrasing Mauro: "Not a single developer out of a few SEEMS to believe that it is the BETTER approach, so since the FEW represent ALL media developers in the world, and since there is only ONE RIGHT way to do things, and since the GROUP is always RIGHT and always knows better than the individual, then YOU're WRONG and I'm right. Conform to the group and do as the group says, whatever the consequences!" Geeks are decidedly as prone as others to blindly accept travelling on the slippery road of herd mentality and "obvious" conclusions based on appearances. Is this OPEN source development or a dictatorship or what? So in the end Mauro will be right. And Markus will continue to develop and defend his stuff as HE sees fit. He knows his own work better than anyone else. It will be HIS way or nothing with his own stuff, it's his inalienable right. And don't be naive, if there's no solution more viable than Markus' one, then the latter will eventually be widely adopted somehow, sometime, whatever the amount of grumbling from the establishment. No dictatorship/forced consensus can decide future's direction, nor improve its already low own viability. Cheers, Bernard. - 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
Johannes Stezenbach wrote: On Sat, Sep 15, 2007, Markus Rechberger wrote: The main discussion in this thread was about drivers in userspace are bad because the API will allow binary drivers. The guy who works for Hauppauge (again I also have good contacts at Hauppauge Europe) writes it's bad - for no technical reason. lol, oh man, how to make friends and influence people. It sends a shiver down my spine that seem to imply that you use your Hauppauge Europe contact to lobby against the efforts of Hauppauge USA employees to promote support for Open Source kernel drivers within their company. Ack. - 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
Em Sáb, 2007-09-15 às 16:33 +0200, Markus Rechberger escreveu: > I'm off for the weekend now so have a nice one :-) Enjoy your weekend. I really hope that you have some time to reflect and review your positions during the weekend. -- Cheers, Mauro - 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/15/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > Everyone knows that there are some issues even some internal > > ones which I'm not part of. > > With respect to your kernel-userspace API for xc3028, you made something > that seemed to be a dream: there's a consensus: not a single developer > believed that this is the better way; nobody seems that this is the > better approach. > Not a single developer out of 3-5 people? Seems fine with me, because people didn't agree with anything else before either and tried to point me to wrong solutions. http://threebit.net/mail-archive/video4linux/msg07548.html > So, or you are the only media developer with good sense in the face of > the Earth, or you're incapable of understand the obvious: you're wrong > with this approach. IMO, the answer is quite obvious. > that for you don't have to use it. http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages I'm off for the weekend now so have a nice one :-) 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
> Everyone knows that there are some issues even some internal > ones which I'm not part of. With respect to your kernel-userspace API for xc3028, you made something that seemed to be a dream: there's a consensus: not a single developer believed that this is the better way; nobody seems that this is the better approach. So, or you are the only media developer with good sense in the face of the Earth, or you're incapable of understand the obvious: you're wrong with this approach. IMO, the answer is quite obvious. -- Cheers, Mauro - 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/15/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Sat, Sep 15, 2007, Markus Rechberger wrote: > > > > it gets me thinking. Some core developers who I met during > > the last few weeks (kernel summit, suse conference in czech) > > told me to go on with it actually because the final plan isn't that > > bad.. > > I was referring to your code you posted for merging on linux-dvb, > and which got rejected. Anyway, it's easy to agree with you if one > has just heard _your_ version -- the purpose of this thread is to > give people an alternate version of the story to complement > yours, which would allow the people you talked to to think it over > and change their mind. See if you can get of those people you > talked to to post here to support you. > Everyone knows that there are some issues even some internal ones which I'm not part of. Not sure if you met some other kernel developers recently, all you can hear is "those crazy media guys" (which just includes everyone who works with media related drivers) > > Beside that I'm just curious how much did you contribute > > during the last 2 years to the lkml/linux kernel, and how much > > do you want to contribute in future? (also from my side > > talk is cheap (even for me) but getting something done costs > > quite some time and feedback from other people) > > IOW you say if I don't write code I should shut up? > Is that also what you tell users on your em28xx list > when they dare to disagree with you? > > Nice... > This is a free world you can write whatever you want, but if you want me to change my code you need to convince me that I should acknowlidge your ideas. And by not acknowlidging my requirements don't expect that I will go back to the start and try to reinvent the wheel. After almost 2 years I'm quite into those things and I know what I want for my project and what I'll try to achieve with what I'm doing. 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 Sat, Sep 15, 2007, Markus Rechberger wrote: > The main discussion in this thread was about drivers in userspace > are bad because the API will allow binary drivers. The guy > who works for Hauppauge (again I also have good contacts > at Hauppauge Europe) writes it's bad - for no technical reason. It sends a shiver down my spine that seem to imply that you use your Hauppauge Europe contact to lobby against the efforts of Hauppauge USA employees to promote support for Open Source kernel drivers within their company. > If someone points out that it is bad (after reading the whole thread) > why don't we put X.org, bash, well everything into the kernel? > GPL is the saviour seems to be the saviour for some people in this > world, but in the end it's still if people want to go that way. > Much work has been done by other people before, my work > is also just an additional contribution and I (again) don't intend to > release binary drivers. (also keep in mind that ubuntu takes > everything which makes things work - this matters to the enduser) > > Hey I can also write I can help you to get things right with some other > people, and I can financially support people by giving away > hardware and even specs for free in some cases. Who is able > to do that from the old crufted v4l/dvb guys? > > Manu throws his drivers over the wall to the OSS community, although > I don't mind. > Mauro is copying the logic of my code and writes I told him I'm ok with > taking my code without just adding a single line of how his driver > got developed. (I still wonder why he skipped some significant parts > of the driver .. because he used the existing one as logic template) > > http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c > (not looking at the specific changeset but he copied the firmware > loading instructions without taking care about the copyright?) After you dismissed all arguments except your own as invalid, you've now moved on to the "post bullshit and personal accusations" stage. I hope this means we're now done with this "discussion". > > Now, doesn't _that_ get you thinking? > > oh yes. Yeah, right. 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 Sat, Sep 15, 2007, Markus Rechberger wrote: > > it gets me thinking. Some core developers who I met during > the last few weeks (kernel summit, suse conference in czech) > told me to go on with it actually because the final plan isn't that > bad.. I was referring to your code you posted for merging on linux-dvb, and which got rejected. Anyway, it's easy to agree with you if one has just heard _your_ version -- the purpose of this thread is to give people an alternate version of the story to complement yours, which would allow the people you talked to to think it over and change their mind. See if you can get of those people you talked to to post here to support you. > Beside that I'm just curious how much did you contribute > during the last 2 years to the lkml/linux kernel, and how much > do you want to contribute in future? (also from my side > talk is cheap (even for me) but getting something done costs > quite some time and feedback from other people) IOW you say if I don't write code I should shut up? Is that also what you tell users on your em28xx list when they dare to disagree with you? Nice... 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/15/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > The main discussion in this thread was about drivers in userspace > > are bad because the API will allow binary drivers. > > No. The focus is that userspace API is not needed at all, and the > community believe that this is a regression from all efforts that are > being done by the community to have good quality OSS software. > please have a look at: http://mcentral.de/wiki/index.php/Bugtracker > > The guy > > who works for Hauppauge (again I also have good contacts > > at Hauppauge Europe) writes it's bad - for no technical reason. > > Please stop with personal attacks. > This is no personal attack. > > I (again) don't intend to > > release binary drivers. (also keep in mind that ubuntu takes > > everything which makes things work - this matters to the enduser) > > Markus, you are thinking that all the community are fool? You're using the word "community" in a quite abstract way here. Please document how the linuxtv community behaves behind the lines, and I would even like that those people who discussed several things would start to write about their other personal issues with that project which I'm not part of. > You used to > state on your website that your intention were to release binary-only > xc5000 drivers. people talk alot, in the end only the result counts. So if you've seen any binary driver from my side point out to it. To be honest I think if I would have gone the same way as Avermedia from the beginning on to release binary drivers it would have saved months of development and the main distros could already have _full_ support for all the features. The driver as it is now is not perfect either it requires quite some more work to get all features work flawlessly around the globe for all the users. > So, please stop with childish and assume what you've said. > > > Mauro is copying the logic of my code and writes I told him I'm ok with > > taking my code without just adding a single line of how his driver > > got developed. (I still wonder why he skipped some significant parts > > of the driver .. because he used the existing one as logic template) > > > > > http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c > > The basis for tuner-xc2028 driver is tea5767. The xc2028/xc3028 drivers > is very simple: > > a) load the proper firmware; > b) send one 32 bits command to select frequency + the frequency divider. > well people see if they compare the code what you took from the existing driver. > All the rest is the common logic of a tuner driver. > > If you take a look at my driver, you will see that the implementation is > different, providing also those functionalities: > > - provides a sync during frequency setting, needed by tm6000; > - has the logic to retrieve signal status; > - part of the firmware need to be reload every time you change a freq > (tm6000 driver needs it); > - supports just the firmwares I've identified as being used by tm6000 > driver; > > The only thing I used is your usbreplay.pl, as properly stated at > README.first (properly pointing to your site). > > Again, please stop with personal attacks. This leads to nowhere. > If you look at my current implementation and even the implementation which I had a year ago many problems are solved there. I don't mind if you don't want to use the userspace tuner API, it's not a replacement for the inkernel version, it makes it just easy to implement it. The current and upcoming em28xx devices will use it, just to avoid that I have to redo all the work hundret times for no real reason. > > >From my side, I've nacked your userspace tuner. > > However, I keep open to accept your kernelspace em28xx/xc3028 drivers, > providing that they fits at the current V4L/DVB core. > I don't even want to use that existing driver in future (as I wrote earlier already). The newer module will be a dropin userspace replacement for what's available. I got around 70 devices work with it at the moment, although I don't even want to reinvent the wheel so I'll take what I've received from some companies. That way all I have to do is to use the provided API of those silicon sample drivers. > Changes at common APIs, and especially at Kernel to userspace API should > be discussed with the community. If you accept this fact, you may also > propose improvements at the APIs. > That for I wrote the RFCs which didn't get discussed properly and where 2 people of that "community" told me to use something which won't work out at all. And hey, why didn't those guys do what they told me to do in the end? Because they wanted to do it by themself only. Although it's the base of the driver without a proper base it just screams for more work in the end. > If, after all that were discussed, you're willing to do a serious work, > please send us the patches for em28xx/xc3028 kernelspace drivers. > Otherwise, I'll kindly ask you to take your own way and st
Re: [linux-dvb] [PATCH] Userspace tuner
Hello Markus, Markus Rechberger wrote: > The main discussion in this thread was about drivers in userspace > are bad because the API will allow binary drivers. The guy > who works for Hauppauge (again I also have good contacts > at Hauppauge Europe) writes it's bad - for no technical reason. AFAICS, Steven raised the same thoughts what i had. > If someone points out that it is bad (after reading the whole thread) > why don't we put X.org, bash, well everything into the kernel? I am not saying that userspace is bad. In fact i am all for userspace, _if_ there is much of a complication. For example we have had largely complex devices. You might like to read this thread a while back. This was the reason why we started up libdvbapi/mti (For those who don't know what it is, libdvbapi/mti is a userspace approach for having device support in userspace with complicated tuning algorithms with a lot of calculations) http://search.gmane.org/?query=Re%3A+%5BRFC%5D+Userspace+extensions%2C+was+Re%3A+%5Blinux-dvb%5D+%5Bpatch%5D+Add+support+for+different+tuning+algorithms&author=&group=linux.drivers.dvb&sort=relevance&DEFAULTOP=and&query= For that demodulator and a successor for the same, i had finally moved the same to in kernel with a lot of trouble. Maybe it is not as precise as it should have been. But what i mean is that we should use such approaches if there needs to be a heavy valid reason and if there are many more devices going that way, we should definitely move to userspace. Maybe the userspace idea is a bit still immature. That said, i don't see any such complexities with the XC3028 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
> The main discussion in this thread was about drivers in userspace > are bad because the API will allow binary drivers. No. The focus is that userspace API is not needed at all, and the community believe that this is a regression from all efforts that are being done by the community to have good quality OSS software. > The guy > who works for Hauppauge (again I also have good contacts > at Hauppauge Europe) writes it's bad - for no technical reason. Please stop with personal attacks. > I (again) don't intend to > release binary drivers. (also keep in mind that ubuntu takes > everything which makes things work - this matters to the enduser) Markus, you are thinking that all the community are fool? You used to state on your website that your intention were to release binary-only xc5000 drivers. So, please stop with childish and assume what you've said. > Mauro is copying the logic of my code and writes I told him I'm ok with > taking my code without just adding a single line of how his driver > got developed. (I still wonder why he skipped some significant parts > of the driver .. because he used the existing one as logic template) > > http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c The basis for tuner-xc2028 driver is tea5767. The xc2028/xc3028 drivers is very simple: a) load the proper firmware; b) send one 32 bits command to select frequency + the frequency divider. All the rest is the common logic of a tuner driver. If you take a look at my driver, you will see that the implementation is different, providing also those functionalities: - provides a sync during frequency setting, needed by tm6000; - has the logic to retrieve signal status; - part of the firmware need to be reload every time you change a freq (tm6000 driver needs it); - supports just the firmwares I've identified as being used by tm6000 driver; The only thing I used is your usbreplay.pl, as properly stated at README.first (properly pointing to your site). Again, please stop with personal attacks. This leads to nowhere. --- >From my side, I've nacked your userspace tuner. However, I keep open to accept your kernelspace em28xx/xc3028 drivers, providing that they fits at the current V4L/DVB core. Changes at common APIs, and especially at Kernel to userspace API should be discussed with the community. If you accept this fact, you may also propose improvements at the APIs. If, after all that were discussed, you're willing to do a serious work, please send us the patches for em28xx/xc3028 kernelspace drivers. Otherwise, I'll kindly ask you to take your own way and stop with those flamewars. Cheers, Mauro - 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/14/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007, Markus Rechberger wrote: > > > > people do contribute to the em28xx project. > ... > > there's also an active and even problem solving oriented ML available: > > http://mcentral.de/pipermail/em28xx/ > > > > Also if you look at the mercurial code you'll see several people > > contributing to that project. > > Of course, people who own such a device and want to use > it with Linux have no choice but to work with you. > And you do a good job for your users, you support them > well and in return they contribute info and patches > to support new devices. > > But the thing is that at mcentral.de you're the man at the top, why is it mcentral.de at the moment? I started several discussions about the whole topic. The thing which is in v4l-dvb on linuxtv does not satisfy any requirements, also further additions will be hard to achieve with it. > and your users will hardly disagree with you on core > technical questions. (Well, admittedly I'm speculating > here as I don't read your em28xx list.) > they can disagree, I even pointed out to design flaws lately when some users posted bugreports. > On for drivers/media/ OTOH you are just one developer among others, > and some of them choose to disagree with you. Even worse, > IIRC there wasn't even _a single_ other developer willing > to ACK your offending patch. > the current patch isn't offending anymore, see it as a chance I'm giving you the chance to acknowlidge what has been done now from my side. The main discussion in this thread was about drivers in userspace are bad because the API will allow binary drivers. The guy who works for Hauppauge (again I also have good contacts at Hauppauge Europe) writes it's bad - for no technical reason. If someone points out that it is bad (after reading the whole thread) why don't we put X.org, bash, well everything into the kernel? GPL is the saviour seems to be the saviour for some people in this world, but in the end it's still if people want to go that way. Much work has been done by other people before, my work is also just an additional contribution and I (again) don't intend to release binary drivers. (also keep in mind that ubuntu takes everything which makes things work - this matters to the enduser) Hey I can also write I can help you to get things right with some other people, and I can financially support people by giving away hardware and even specs for free in some cases. Who is able to do that from the old crufted v4l/dvb guys? Manu throws his drivers over the wall to the OSS community, although I don't mind. Mauro is copying the logic of my code and writes I told him I'm ok with taking my code without just adding a single line of how his driver got developed. (I still wonder why he skipped some significant parts of the driver .. because he used the existing one as logic template) http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c (not looking at the specific changeset but he copied the firmware loading instructions without taking care about the copyright?) > Now, doesn't _that_ get you thinking? > oh yes. 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
> Beside that I'm just curious how much did you contribute > during the last 2 years to the lkml/linux kernel, and how much > do you want to contribute in future? (also from my side > talk is cheap (even for me) but getting something done costs > quite some time and feedback from other people) Contributing doesn't necessarily means submitting patches. There are several good guys at the community offering very valuable contributions, like patchset reviews, good comments, userspace experiences, etc. Johannes does a very impressive work of maintaining, almost alone, LinuxTV website, upgrading the system, monitoring disk spaces, taking backups, etc. Also, he is always available to discuss the most important changes at APIs and to defend the Open Source community, providing his very clear point of view. Thank you, Johannes for all your good work! -- Cheers, Mauro - 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/14/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007, Markus Rechberger wrote: > > > > people do contribute to the em28xx project. > ... > > there's also an active and even problem solving oriented ML available: > > http://mcentral.de/pipermail/em28xx/ > > > > Also if you look at the mercurial code you'll see several people > > contributing to that project. > > Of course, people who own such a device and want to use > it with Linux have no choice but to work with you. > And you do a good job for your users, you support them > well and in return they contribute info and patches > to support new devices. > > But the thing is that at mcentral.de you're the man at the top, > and your users will hardly disagree with you on core > technical questions. (Well, admittedly I'm speculating > here as I don't read your em28xx list.) > they can. Put technical issues infront of everything also see the whole picture that userspace tv applications have to support all the codecs which are available. > On for drivers/media/ OTOH you are just one developer among others, > and some of them choose to disagree with you. Even worse, > IIRC there wasn't even _a single_ other developer willing > to ACK your offending patch. > there was not a single developer of the old crufted developers who didn't bring the project forward during the last 2 years. yes you're right. > Now, doesn't _that_ get you thinking? > it gets me thinking. Some core developers who I met during the last few weeks (kernel summit, suse conference in czech) told me to go on with it actually because the final plan isn't that bad.. I don't expect anyone of the old crufted v4l/dvb (well many of them already left the party) will join the game... (I'll leave that open here) spend some time read the whole history of this thread and it will show up what this all is targeting at. I'll answer your questions with technical reasons why I'm doing all that stuff that way if you'll just ask. Someone told me during the last 2 weeks "but v4l2 was about to solve all those problems" it didn't. (point) and I think I explained good enough why all that crap still goes on as it is. Beside that I'm just curious how much did you contribute during the last 2 years to the lkml/linux kernel, and how much do you want to contribute in future? (also from my side talk is cheap (even for me) but getting something done costs quite some time and feedback from other people) 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
Aidan Thornton wrote: > > I think this will require a rethink of either how the em2880-dvb > driver works or how frontend drivers work. The current API expects > users to initialise their frontend and then bind a tuner to it. > em2880-dvb is a sort of subdriver that attaches to the main driver, > and doesn't have any control over when or how it initialises its > tuner, so it can't delay tuner initialisation until the frontend has > been initialised. (I don't think it's the only hybrid driver that > works this way either). Of course, I could be missing something. The em28xx/xc3028 is in fact not too complex. Just for sake of demonstration, some time back i had posted a dummy driver how it can be done in a nice and clean way as an example. The patch assumes some additional standards, you can ignore them. But you get the general idea from in there. http://marc.info/?l=linux-video&m=117613833119350&w=2 > >> There is no reason why the Xceive driver cannot be merged into the >> current development tree using the hybrid tuner framework as it stands >> today. > > I'm not convinced this is entirely true. In order to avoid unnecessary > reinitialisation of the device, the driver needs to know whether the > device is in analog or digital mode, and I can't see a way of doing it > with the current API. (I think existing drivers, such as the xc2028 > driver in one branch, use the older analog API and make the digital > driver a wrapper around it.) Again, I may be missing something. You can read this post also for some additional information. http://marc.info/?l=linux-video&m=117922735929375&w=2 Use the ideas as you deem fit. ;-) 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
> > There is no reason why the Xceive driver cannot be merged into the > > current development tree using the hybrid tuner framework as it stands > > today. > > I'm not convinced this is entirely true. In order to avoid unnecessary > reinitialisation of the device, the driver needs to know whether the > device is in analog or digital mode, and I can't see a way of doing it > with the current API. (I think existing drivers, such as the xc2028 > driver in one branch, use the older analog API and make the digital > driver a wrapper around it.) Again, I may be missing something. For sure there are some ways. One dirty way would be to add an static lock at xc3028 driver. You can rise the lock when firmware is being uploaded, removing it at the end. This would prevent the troubles you've mentioned. A cleaner way would be to create a tasklet for firmware upload. This will also prevent the driver for a long load time, due to firmware initialization (a similar change were recently added at ivtv driver). For sure there are other ways of doing this. Cheers, Mauro - 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/14/07, Michael Krufky <[EMAIL PROTECTED]> wrote: > On 9/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > > > - The hybrid tuner support, that where your requirement, when all those > > > > discussions started, were already added to the subsystem. So now, an > > > > hybrid tuner can be accessed by both DVB and V4L devices; > > > > > > > > > > It's far more complex as the thing which is implemented there. > > > The only thing that has been implemented is that one moduleformat > > > can be loaded by the v4l and by the dvb framework nothing else at the > > > moment. I told you at the kernel summit about that and I think you > > > knew about that before. > > > > > > Just to quote some text: > > > "Right now, a separate instance of the driver is used for analog / > > > digital tuning. In order to use a single instance, we will have to > > > store a pointer to the dvb_frontend structure on the bridge level, but > > > there are various other prerequisites that must be dealt with before we > > > get to that point. > > > > > > We _will_ get there though, eventually." > > > > Maybe it is still not perfect. Feel free to improve it. Several people > > from the community, including me, already offered you help to add your > > driver, reworking on the 5% of the stuff that aren't compatible with the > > V4L/DVB core API design. > > For clarification, Markus is quoting me, above. > > The idea is to eventually store a pointer to the dvb_frontend > structure on the bridge level to be used as a single entry point > between the analog and digital subsystems. However, we are not yet > ready for this, as the refactoring process has a lot more to be done > beforehand. I think this will require a rethink of either how the em2880-dvb driver works or how frontend drivers work. The current API expects users to initialise their frontend and then bind a tuner to it. em2880-dvb is a sort of subdriver that attaches to the main driver, and doesn't have any control over when or how it initialises its tuner, so it can't delay tuner initialisation until the frontend has been initialised. (I don't think it's the only hybrid driver that works this way either). Of course, I could be missing something. > There is no reason why the Xceive driver cannot be merged into the > current development tree using the hybrid tuner framework as it stands > today. I'm not convinced this is entirely true. In order to avoid unnecessary reinitialisation of the device, the driver needs to know whether the device is in analog or digital mode, and I can't see a way of doing it with the current API. (I think existing drivers, such as the xc2028 driver in one branch, use the older analog API and make the digital driver a wrapper around it.) Again, I may be missing something. Aidan - 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 Fri, Sep 14, 2007, Markus Rechberger wrote: > > people do contribute to the em28xx project. ... > there's also an active and even problem solving oriented ML available: > http://mcentral.de/pipermail/em28xx/ > > Also if you look at the mercurial code you'll see several people > contributing to that project. Of course, people who own such a device and want to use it with Linux have no choice but to work with you. And you do a good job for your users, you support them well and in return they contribute info and patches to support new devices. But the thing is that at mcentral.de you're the man at the top, and your users will hardly disagree with you on core technical questions. (Well, admittedly I'm speculating here as I don't read your em28xx list.) On for drivers/media/ OTOH you are just one developer among others, and some of them choose to disagree with you. Even worse, IIRC there wasn't even _a single_ other developer willing to ACK your offending patch. Now, doesn't _that_ get you thinking? 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/14/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 9/14/07, Alex Deucher <[EMAIL PROTECTED]> wrote: > > On 9/14/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > > On 9/14/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > > > > Joerg Roedel wrote: > > > > > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote: > > > > > 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. > > > > > > > > >>> it helps to virtualize devices and introduces newer features for > > that. > > > > >>> Some interesting projects could be derrived out of that, there are > > > > >>> quite a few interesting papers floating around how drivers could be > > > > >>> handled in future. > > > > >>> > > > > >> IOMMU can be considered similar to the AGP GART, which is similar, > > > > >> remapping the Addresses, as far as i understand. > > > > > > > > > > Common new IOMMUs have only very few in common with the AGP GART. In > > > > > fact, with current modern IOMMU hardware it will be possible to > > > > > implement secure userspace device drivers that are even able to do > > DMA. > > > > > This is not possible with the GART. > > > > > > > > > >> Though you get a physical to virtual translation, what about > > interrupts, > > > > > > > > > > Modern IOMMUs are able to remap interrupts. This will solve the > > problem > > > > > with PCI interrupt sharing. > > > > > > > > What CPU's are we talking about ? > > > > > > > > > > upcoming x86-64 processors from the AMD side. I'm not into what Intel > > > is doing in that area at the moment. > > > > All AMD64 chips have an IOMMU. Only Intel's most recent chips do. > > > > It's not available yet, you can read more about it in the following article: > > http://developer.amd.com/articlex.jsp?id=101 > > If you're interested in it I can put together some more information about > it. It (the IOMMU) is available on all AMD64 chips. The newer virtualization stuff is only on the newer chips. Alex - 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/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > > - The hybrid tuner support, that where your requirement, when all those > > > discussions started, were already added to the subsystem. So now, an > > > hybrid tuner can be accessed by both DVB and V4L devices; > > > > > > > It's far more complex as the thing which is implemented there. > > The only thing that has been implemented is that one moduleformat > > can be loaded by the v4l and by the dvb framework nothing else at the > > moment. I told you at the kernel summit about that and I think you > > knew about that before. > > > > Just to quote some text: > > "Right now, a separate instance of the driver is used for analog / > > digital tuning. In order to use a single instance, we will have to > > store a pointer to the dvb_frontend structure on the bridge level, but > > there are various other prerequisites that must be dealt with before we > > get to that point. > > > > We _will_ get there though, eventually." > > Maybe it is still not perfect. Feel free to improve it. Several people > from the community, including me, already offered you help to add your > driver, reworking on the 5% of the stuff that aren't compatible with the > V4L/DVB core API design. For clarification, Markus is quoting me, above. The idea is to eventually store a pointer to the dvb_frontend structure on the bridge level to be used as a single entry point between the analog and digital subsystems. However, we are not yet ready for this, as the refactoring process has a lot more to be done beforehand. Phase 1 of the refactoring was to implement the core changes required for a single module to be used by both v4l and dvb, and to convert the existing tuner modules to the new internal API. Phase 2, a work in progress, involves the removal of duplicated code. For example, the current code in the master branch still has tda8275 / tda8275a analog code inside of tda8290.c, where the digital tuning code is in tda827x.c ... This was resolved in this changeset: Move all tda8275/8275a tuning code from tda8290 module into tda827x module http://linuxtv.org/hg/~mkrufky/philipsNXP/rev/09c2e16a8cdd This code is working fine, and I have it pushed to linuxtv.org for the sake of testing. I have not requested merge to master because I still have some cleanups to do, and I do not want this to go to 2.6.24. (side note: basic support for TDA8295 + TDA18271 has been added to my philipsNXP tree, as well) Tuner-simple and dvb-pll will have to undergo a similar treatment, and it's not going to happen overnight. But I *am* working on it. I've outlined a basic roadmap to the refactoring plans in my original RFC: http://linuxtv.org/pipermail/linux-dvb/2007-August/019950.html What I didn't mention in that RFC, however, is the method in which I plan to remove the multiple instantiations of the tuner code for a single piece of hardware, by moving the dvb_frontend pointer to the bridge level. Since this change depends on the other refactoring to be completed first, I found it unnecessary to explain this in detail at this point. When the time comes, a new RFC will be sent out to deal with that matter. There is no reason why the Xceive driver cannot be merged into the current development tree using the hybrid tuner framework as it stands today. Regards, Mike - 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/14/07, Alex Deucher <[EMAIL PROTECTED]> wrote: > On 9/14/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > On 9/14/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > > > Joerg Roedel wrote: > > > > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote: > > > > 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. > > > > > > >>> it helps to virtualize devices and introduces newer features for > that. > > > >>> Some interesting projects could be derrived out of that, there are > > > >>> quite a few interesting papers floating around how drivers could be > > > >>> handled in future. > > > >>> > > > >> IOMMU can be considered similar to the AGP GART, which is similar, > > > >> remapping the Addresses, as far as i understand. > > > > > > > > Common new IOMMUs have only very few in common with the AGP GART. In > > > > fact, with current modern IOMMU hardware it will be possible to > > > > implement secure userspace device drivers that are even able to do > DMA. > > > > This is not possible with the GART. > > > > > > > >> Though you get a physical to virtual translation, what about > interrupts, > > > > > > > > Modern IOMMUs are able to remap interrupts. This will solve the > problem > > > > with PCI interrupt sharing. > > > > > > What CPU's are we talking about ? > > > > > > > upcoming x86-64 processors from the AMD side. I'm not into what Intel > > is doing in that area at the moment. > > All AMD64 chips have an IOMMU. Only Intel's most recent chips do. > It's not available yet, you can read more about it in the following article: http://developer.amd.com/articlex.jsp?id=101 If you're interested in it I can put together some more information about it. 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 9/14/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 9/14/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > > Joerg Roedel wrote: > > > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote: > > > 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. > > > > >>> it helps to virtualize devices and introduces newer features for that. > > >>> Some interesting projects could be derrived out of that, there are > > >>> quite a few interesting papers floating around how drivers could be > > >>> handled in future. > > >>> > > >> IOMMU can be considered similar to the AGP GART, which is similar, > > >> remapping the Addresses, as far as i understand. > > > > > > Common new IOMMUs have only very few in common with the AGP GART. In > > > fact, with current modern IOMMU hardware it will be possible to > > > implement secure userspace device drivers that are even able to do DMA. > > > This is not possible with the GART. > > > > > >> Though you get a physical to virtual translation, what about interrupts, > > > > > > Modern IOMMUs are able to remap interrupts. This will solve the problem > > > with PCI interrupt sharing. > > > > What CPU's are we talking about ? > > > > upcoming x86-64 processors from the AMD side. I'm not into what Intel > is doing in that area at the moment. All AMD64 chips have an IOMMU. Only Intel's most recent chips do. Alex - 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
> > - The hybrid tuner support, that where your requirement, when all those > > discussions started, were already added to the subsystem. So now, an > > hybrid tuner can be accessed by both DVB and V4L devices; > > > > It's far more complex as the thing which is implemented there. > The only thing that has been implemented is that one moduleformat > can be loaded by the v4l and by the dvb framework nothing else at the > moment. I told you at the kernel summit about that and I think you > knew about that before. > > Just to quote some text: > "Right now, a separate instance of the driver is used for analog / > digital tuning. In order to use a single instance, we will have to > store a pointer to the dvb_frontend structure on the bridge level, but > there are various other prerequisites that must be dealt with before we > get to that point. > > We _will_ get there though, eventually." Maybe it is still not perfect. Feel free to improve it. Several people from the community, including me, already offered you help to add your driver, reworking on the 5% of the stuff that aren't compatible with the V4L/DVB core API design. > > - Audio standard selection is already possible via S_STD (it is already > > working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more > > standards should be needed, but hey, we still have 34 bits available at > > std mask. > > > > Let me quote some text where you've been in CC and which didn't get > far enough to get a solution implemented. > > (Michael Schimek) > > "> xc3028_BG_PAL_A2_A.i2c FW_78 > B/G PAL A2 > > Group delay: See RecITU-R BT.470-6 p.21 Response "A" > > xc3028_BG_PAL_A2_A_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON > > xc3028_BG_PAL_A2_B.i2c FW_78 B/G PAL A2 > > Group delay: See RecITU-R BT.470-6 p.21 Response "B" > > xc3028_BG_PAL_A2_B_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON > > > xc3028_BG_PAL_NICAM_A.i2c FW_78 B/G PAL NICAM > > Group delay: See RecITU-R BT.470-6 p.21 Response "A" > > xc3028_BG_PAL_NICAM_A_MTS.i2c FW_78_MTS B/G PAL FM > > xc3028_BG_PAL_NICAM_B.i2c FW_78 B/G PAL NICAM > > Group delay: See RecITU-R BT.470-6 p.21 Response "B" > > xc3028_BG_PAL_NICAM_B_MTS.i2c FW_78_MTS B/G PAL FM > > We cannot add new standards for each of these files because only six > bits are unassigned in the lower half of v4l2_std_id. It seems > unecessary too, please correct me if I'm wrong. We can use the full 64 bits of v4l2_std_id. We just need to take some care. Due to the lack of __ucmpdi2 on ppc32 architecture, with some gcc versions, a hack were added at v4l2-common.c, that truncates it to 32 bits, at the function v4l2_norm_to_name(): http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commit;h=412297d31d439ba56cd4faeb3a49a6f569f40702 So, using more than 32 bits is possible, providing that we change the implementation of v4l2_norm_to_name() or find a way for it to work with ppc32. Instead of just adding a standard for each possible combination, we may just add bits for the supported audio formats. For example, we can use the bitmask as: #define V4L2_STD_AUDIO_NICAM_A ((v4l2_std_id)0x0400) #define V4L2_STD_AUDIO_A2_A ((v4l2_std_id)0x0800) Since for all other chipsets but xc3028, all audio standards are supported, maybe we can, instead, use a negate bitmap logic for the non-supported audio standards. Something like: #define V4L2_STD_AUDIO_NOT_NICAM_A ((v4l2_std_id)0x0400) #define V4L2_STD_AUDIO_NOT_A2_A ((v4l2_std_id)0x0800) And define some macros for the specific standards you need. For example: #define V4L2_STD_AUDIO_NOT_ALL V4L2_STD_AUDIO_NOT_A2_A | V4L2_STD_AUDIO_NOT_NICAM_A #define V4L2_STD_PAL_BG_A2 V4L2_STD_PAL_BG | (V4L2_STD_AUDIO_NOT_ALL & !V4L2_STD_AUDIO_NOT_A2_A) This way, V4L2_STD_PAL_BG will mean that this PAL/BG accepts all possible audio standards (being binary compatible), while V4L2_STD_PAL_BG_A2_A will mean that only A2 response 'A' audio format is supported for PAL/BG. -- Cheers, Mauro - 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/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > Markus, > > > > > > > Maybe you still don't realize how tiresome it is to talk to you. > > > What you present as "linuxtv people block my contributions" is > > > IMHO "linuxtv people got fed up talking to you". Because when > > > people disagree with you, you keep rambling on and on instead > > > of just accepting it. See, working with an Open source community > > > requires that you don't piss everyone off, but instead find > > > ways to _motivate_ them to help you fix the problems which > > > prevent your code from being merged. When people are doing > > > software development _for fun_, then it should be a _pleasure_ > > > for them to work with you, and not a pain in the ass. > > > > > > > Johannes, > > > > people do contribute to the em28xx project. > > If noone keeps finding solutions for requirements I will of course > > go on to find my own way. > > Although upcoming and even the current requirements are not met > > by the existing API. > > It's worth nothing to merge what's available now since I'm not even > > ok with how several issues are solved with the driver itself at the > > moment. > > I'm going forward step by step with it now. > > > > there's also an active and even problem solving oriented ML available: > > http://mcentral.de/pipermail/em28xx/ > > > > Also if you look at the mercurial code you'll see several people > > contributing to that project. > > Solutions for your requirements can be reachable via a kernelspace > solution: > > - The hybrid tuner support, that where your requirement, when all those > discussions started, were already added to the subsystem. So now, an > hybrid tuner can be accessed by both DVB and V4L devices; > It's far more complex as the thing which is implemented there. The only thing that has been implemented is that one moduleformat can be loaded by the v4l and by the dvb framework nothing else at the moment. I told you at the kernel summit about that and I think you knew about that before. Just to quote some text: "Right now, a separate instance of the driver is used for analog / digital tuning. In order to use a single instance, we will have to store a pointer to the dvb_frontend structure on the bridge level, but there are various other prerequisites that must be dealt with before we get to that point. We _will_ get there though, eventually." > - Audio standard selection is already possible via S_STD (it is already > working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more > standards should be needed, but hey, we still have 34 bits available at > std mask. > Let me quote some text where you've been in CC and which didn't get far enough to get a solution implemented. (Michael Schimek) "> xc3028_BG_PAL_A2_A.i2c FW_78 > B/G PAL A2 > Group delay: See RecITU-R BT.470-6 p.21 Response "A" > xc3028_BG_PAL_A2_A_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON > xc3028_BG_PAL_A2_B.i2c FW_78 B/G PAL A2 > Group delay: See RecITU-R BT.470-6 p.21 Response "B" > xc3028_BG_PAL_A2_B_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON > xc3028_BG_PAL_NICAM_A.i2c FW_78 B/G PAL NICAM > Group delay: See RecITU-R BT.470-6 p.21 Response "A" > xc3028_BG_PAL_NICAM_A_MTS.i2c FW_78_MTS B/G PAL FM > xc3028_BG_PAL_NICAM_B.i2c FW_78 B/G PAL NICAM > Group delay: See RecITU-R BT.470-6 p.21 Response "B" > xc3028_BG_PAL_NICAM_B_MTS.i2c FW_78_MTS B/G PAL FM We cannot add new standards for each of these files because only six bits are unassigned in the lower half of v4l2_std_id. It seems unecessary too, please correct me if I'm wrong. (Well the driver could define its own video standards for each of the firmwares and put them into the upper 32 bits of v4l2_std_id, which were set aside for this purpose. But adding standards to the API also has its advantages. Maybe it's time to reserve bits 40-55 for future expansion.) I suppose you choose firmwares with IF or baseband sound output depending on the design of the card?" > The point is: there's no technical need for userspace. This will just > add userless complexity. > > However, you insist with your selfish idea that every other solution, > except the one you're proposing are bogus. This is not the way Open > Source development works. You should listen to people. > I pointed out a few requirements which didn't get commented at all, and I explained why things where done in a particular way. 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 Fri, Sep 14, 2007 at 08:56:40PM +0400, Manu Abraham wrote: > > I do understand that (an earlier reply from Grant Grundler on the same > [1], while working on something else), but that wasn't exactly what i > was getting at. The bridges are in fact tied up with a certain CPU class. > > Though your argument holds true: "secure userpsace device drivers can be > implemented with modern hardware" There is a large flaw in it. (From an > academic POV, you are correct) > > Now, if all the drivers were to depend on that certain feature, what > happens to all other CPU class users ? Looking at a pile of CPU's being > used, also not to forget that devices such as STB's use even very small > embedded CPU's such as the PPC405 Vulcan based [2] to mobile devices > such as mobile phones using ARM, Xtensa [3], OMAP CPU's/platforms, which > do not in any way use the bridges nor the CPU class which you however > mention. This is true. These platforms do not (and afaik will not) have an IOMMU and thus its impossible to implement a secure userspace driver interface that supports DMA. In general, IOMMUs are only expected on platforms which implement virtualization, have a processor address space larger than the io address space or both. > So .. we are looking at a small segment, ie. a subset of the PC users > even, even if the larger segments like STB's can be ignored. This would > mean that only a small subset of users using a certain CPU class can use > those drivers (eventhough the devices themselves don't have that > limitation, the limitation being the implementation of the driver > alone), which is absurd. This is also true. But looking at the current development of virtualization in hardware on the PC market (and also the increasing amount of main memory) makes me sure that in a few years every new sold _PC_ will haven an IOMMU inside. But the problems with the other platforms or older hardware will certainly remain. Joerg - 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, > > > > Maybe you still don't realize how tiresome it is to talk to you. > > What you present as "linuxtv people block my contributions" is > > IMHO "linuxtv people got fed up talking to you". Because when > > people disagree with you, you keep rambling on and on instead > > of just accepting it. See, working with an Open source community > > requires that you don't piss everyone off, but instead find > > ways to _motivate_ them to help you fix the problems which > > prevent your code from being merged. When people are doing > > software development _for fun_, then it should be a _pleasure_ > > for them to work with you, and not a pain in the ass. > > > > Johannes, > > people do contribute to the em28xx project. > If noone keeps finding solutions for requirements I will of course > go on to find my own way. > Although upcoming and even the current requirements are not met > by the existing API. > It's worth nothing to merge what's available now since I'm not even > ok with how several issues are solved with the driver itself at the > moment. > I'm going forward step by step with it now. > > there's also an active and even problem solving oriented ML available: > http://mcentral.de/pipermail/em28xx/ > > Also if you look at the mercurial code you'll see several people > contributing to that project. Solutions for your requirements can be reachable via a kernelspace solution: - The hybrid tuner support, that where your requirement, when all those discussions started, were already added to the subsystem. So now, an hybrid tuner can be accessed by both DVB and V4L devices; - Audio standard selection is already possible via S_STD (it is already working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more standards should be needed, but hey, we still have 34 bits available at std mask. The point is: there's no technical need for userspace. This will just add userless complexity. However, you insist with your selfish idea that every other solution, except the one you're proposing are bogus. This is not the way Open Source development works. You should listen to people. Cheers, Mauro - 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
Joerg Roedel wrote: >>> Common new IOMMUs have only very few in common with the AGP GART. In >>> fact, with current modern IOMMU hardware it will be possible to >>> implement secure userspace device drivers that are even able to do DMA. >>> This is not possible with the GART. >>> Though you get a physical to virtual translation, what about interrupts, >>> Modern IOMMUs are able to remap interrupts. This will solve the problem >>> with PCI interrupt sharing. >> What CPU's are we talking about ? > > IOMMUs are not necessarily a CPU feature. These IOMMUS will be found in > the South/North Bridge or even on PCI devices itself (uncommon). The > Calgary IOMMU is such an example of an IOMMU not implemented on the CPU > itself. > I do understand that (an earlier reply from Grant Grundler on the same [1], while working on something else), but that wasn't exactly what i was getting at. The bridges are in fact tied up with a certain CPU class. Though your argument holds true: "secure userpsace device drivers can be implemented with modern hardware" There is a large flaw in it. (From an academic POV, you are correct) Now, if all the drivers were to depend on that certain feature, what happens to all other CPU class users ? Looking at a pile of CPU's being used, also not to forget that devices such as STB's use even very small embedded CPU's such as the PPC405 Vulcan based [2] to mobile devices such as mobile phones using ARM, Xtensa [3], OMAP CPU's/platforms, which do not in any way use the bridges nor the CPU class which you however mention. So .. we are looking at a small segment, ie. a subset of the PC users even, even if the larger segments like STB's can be ignored. This would mean that only a small subset of users using a certain CPU class can use those drivers (eventhough the devices themselves don't have that limitation, the limitation being the implementation of the driver alone), which is absurd. Manu [1] http://lkml.org/lkml/2007/5/26/217 [2] http://abraham.manu.googlepages.com/p3160033.jpg [3] http://tensilica.com/ - 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/14/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007, Markus Rechberger wrote: > > On 9/14/07, Steven Toth <[EMAIL PROTECTED]> wrote: > > > > > > If you care about LinuxTV you'll work with the core subsystem developers > > > to bring your em28xx tree inline. If you don't care then why are you > here? > > > > It doesn't really work out to work with those 3-5 "core" people who are > active > > there. > > It starts at the point where RFCs are submitted and not answered, > > discussions are avoided and finally some people start to complain. > > In case of pointing people to wrong or bad solutions, one "Maintainer" > > pointed out it would be like manipulating others work ... this exactly > > happened with the em28xx project. It's not only about the current > > implementation, as from my side I also take upcoming products into > > account and how long it would take to get something which isn't > > supported by the API fixed.. it's just something that is too hard and > > I don't want to debate about things where I know that the outcome > > is that I have to wait till someone of those 3-5 "core" people come up > > with an own idea. > > Maybe you still don't realize how tiresome it is to talk to you. > What you present as "linuxtv people block my contributions" is > IMHO "linuxtv people got fed up talking to you". Because when > people disagree with you, you keep rambling on and on instead > of just accepting it. See, working with an Open source community > requires that you don't piss everyone off, but instead find > ways to _motivate_ them to help you fix the problems which > prevent your code from being merged. When people are doing > software development _for fun_, then it should be a _pleasure_ > for them to work with you, and not a pain in the ass. > Johannes, people do contribute to the em28xx project. If noone keeps finding solutions for requirements I will of course go on to find my own way. Although upcoming and even the current requirements are not met by the existing API. It's worth nothing to merge what's available now since I'm not even ok with how several issues are solved with the driver itself at the moment. I'm going forward step by step with it now. there's also an active and even problem solving oriented ML available: http://mcentral.de/pipermail/em28xx/ Also if you look at the mercurial code you'll see several people contributing to that project. 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 9/14/07, Alan Cox <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007 at 01:17:05AM +0200, Markus Rechberger wrote: > > what stops vendors of using the current existing code to achieve that > > goal. They could provide binary drivers with the existing API. > > If you feel lucky about the GPL > > > What stops companies to intercept the ioctl calls and overriding some > > I2C commands? > > The GPL - derivative work is the boundary not code linkage. Possibly a > userspace > tuner hack would probably fit this too. Especially if a specific vendor is > producing both bits together and trying to claim they are independant. > > > How about proprietary video formats, would you also place the decoding > > algorithms in kernel just to force companies to release their code > > for it? > > No, I would assume they'd provide a proprietary conversion library that > no nobody would use (just like their hw). We keep format conversion firmly > seperated from hardware I/O processing. > In general there are known formats available, the drawback is that every TV application deals with it in a non-unified way at the moment, meaning alot code duplication in userspace since there's no library available at the moment which does the videoconversion from one to another format. Such a library is beeing developed at the moment which gets plugged infront of accessing the devicenodes. Although in the long run I'm looking forward to reuse the userspace tuners with such a library infront of everything by using i2c-dev. This would also make it easy to reuse the sample code of several companies, without having to cut out several features of the drivers and to rewrite them to an inkernel format. 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 Fri, Sep 14, 2007 at 04:00:30PM +0400, Manu Abraham wrote: > Joerg Roedel wrote: > > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote: > > 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. > > >>> it helps to virtualize devices and introduces newer features for that. > >>> Some interesting projects could be derrived out of that, there are > >>> quite a few interesting papers floating around how drivers could be > >>> handled in future. > >>> > >> IOMMU can be considered similar to the AGP GART, which is similar, > >> remapping the Addresses, as far as i understand. > > > > Common new IOMMUs have only very few in common with the AGP GART. In > > fact, with current modern IOMMU hardware it will be possible to > > implement secure userspace device drivers that are even able to do DMA. > > This is not possible with the GART. > > > >> Though you get a physical to virtual translation, what about interrupts, > > > > Modern IOMMUs are able to remap interrupts. This will solve the problem > > with PCI interrupt sharing. > > What CPU's are we talking about ? IOMMUs are not necessarily a CPU feature. These IOMMUS will be found in the South/North Bridge or even on PCI devices itself (uncommon). The Calgary IOMMU is such an example of an IOMMU not implemented on the CPU itself. Joerg - 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/14/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > Joerg Roedel wrote: > > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote: > > 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. > > >>> it helps to virtualize devices and introduces newer features for that. > >>> Some interesting projects could be derrived out of that, there are > >>> quite a few interesting papers floating around how drivers could be > >>> handled in future. > >>> > >> IOMMU can be considered similar to the AGP GART, which is similar, > >> remapping the Addresses, as far as i understand. > > > > Common new IOMMUs have only very few in common with the AGP GART. In > > fact, with current modern IOMMU hardware it will be possible to > > implement secure userspace device drivers that are even able to do DMA. > > This is not possible with the GART. > > > >> Though you get a physical to virtual translation, what about interrupts, > > > > Modern IOMMUs are able to remap interrupts. This will solve the problem > > with PCI interrupt sharing. > > What CPU's are we talking about ? > upcoming x86-64 processors from the AMD side. I'm not into what Intel is doing in that area at the moment. 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 Fri, Sep 14, 2007 at 01:17:05AM +0200, Markus Rechberger wrote: > what stops vendors of using the current existing code to achieve that > goal. They could provide binary drivers with the existing API. If you feel lucky about the GPL > What stops companies to intercept the ioctl calls and overriding some > I2C commands? The GPL - derivative work is the boundary not code linkage. Possibly a userspace tuner hack would probably fit this too. Especially if a specific vendor is producing both bits together and trying to claim they are independant. > How about proprietary video formats, would you also place the decoding > algorithms in kernel just to force companies to release their code > for it? No, I would assume they'd provide a proprietary conversion library that no nobody would use (just like their hw). We keep format conversion firmly seperated from hardware I/O processing. Alan - 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
> > * Why did someone duallicense videodev2 with BSD/GPL? Originally the BSD people wanted to share the interface for user space compatibility. The kernel however is GPL so the BSD licence on some bits of the code isn't really relevant as the combination of bits you depend upon is GPL, will remain GPL and the only way to do a binary module would be to show it is not in any way a derivative work in law. > 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. Agreed entirely - 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
Joerg Roedel wrote: > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote: > 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. >>> it helps to virtualize devices and introduces newer features for that. >>> Some interesting projects could be derrived out of that, there are >>> quite a few interesting papers floating around how drivers could be >>> handled in future. >>> >> IOMMU can be considered similar to the AGP GART, which is similar, >> remapping the Addresses, as far as i understand. > > Common new IOMMUs have only very few in common with the AGP GART. In > fact, with current modern IOMMU hardware it will be possible to > implement secure userspace device drivers that are even able to do DMA. > This is not possible with the GART. > >> Though you get a physical to virtual translation, what about interrupts, > > Modern IOMMUs are able to remap interrupts. This will solve the problem > with PCI interrupt sharing. What CPU's are we talking about ? Thanks for the explanation. 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 Fri, Sep 14, 2007, Markus Rechberger wrote: > On 9/14/07, Steven Toth <[EMAIL PROTECTED]> wrote: > > > > If you care about LinuxTV you'll work with the core subsystem developers > > to bring your em28xx tree inline. If you don't care then why are you here? > > It doesn't really work out to work with those 3-5 "core" people who are active > there. > It starts at the point where RFCs are submitted and not answered, > discussions are avoided and finally some people start to complain. > In case of pointing people to wrong or bad solutions, one "Maintainer" > pointed out it would be like manipulating others work ... this exactly > happened with the em28xx project. It's not only about the current > implementation, as from my side I also take upcoming products into > account and how long it would take to get something which isn't > supported by the API fixed.. it's just something that is too hard and > I don't want to debate about things where I know that the outcome > is that I have to wait till someone of those 3-5 "core" people come up > with an own idea. Maybe you still don't realize how tiresome it is to talk to you. What you present as "linuxtv people block my contributions" is IMHO "linuxtv people got fed up talking to you". Because when people disagree with you, you keep rambling on and on instead of just accepting it. See, working with an Open source community requires that you don't piss everyone off, but instead find ways to _motivate_ them to help you fix the problems which prevent your code from being merged. When people are doing software development _for fun_, then it should be a _pleasure_ for them to work with you, and not a pain in the ass. You code and your arguments in this discussion may be different than before, but the thread follows a familiar pattern and will likely go nowhere, just like the many discussions before. 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 Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote: > >>> 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. > >> > > > > it helps to virtualize devices and introduces newer features for that. > > Some interesting projects could be derrived out of that, there are > > quite a few interesting papers floating around how drivers could be > > handled in future. > > > > IOMMU can be considered similar to the AGP GART, which is similar, > remapping the Addresses, as far as i understand. Common new IOMMUs have only very few in common with the AGP GART. In fact, with current modern IOMMU hardware it will be possible to implement secure userspace device drivers that are even able to do DMA. This is not possible with the GART. > Though you get a physical to virtual translation, what about interrupts, Modern IOMMUs are able to remap interrupts. This will solve the problem with PCI interrupt sharing. Joerg - 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
>>> 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. >> > > it helps to virtualize devices and introduces newer features for that. > Some interesting projects could be derrived out of that, there are > quite a few interesting papers floating around how drivers could be > handled in future. > IOMMU can be considered similar to the AGP GART, which is similar, remapping the Addresses, as far as i understand. Though you get a physical to virtual translation, what about interrupts, yet to be seen with how to do it with multipath scenarios. Something that i happened to read https://www.gelato.unsw.edu.au/archives/comp-arch/2007-March/007370.html Even Documentation/Intel-IOMMU.txt, doesn't seem to paint a very rosy picture 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/14/07, Steven Toth <[EMAIL PROTECTED]> wrote: > 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. > well you could already release binary drivers if you would be concerned about it, so again all that seems to be no reason for me. What stops Hauppauge in implementing drivers another way? For example the USB drivers completly in userspace. > 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. > For example the UIO thing, accessing MMIO through userspace, also accessing usb control messages from userspace. Because of that reason since it is already possible to provide binary drivers your reason is again not valid. The code which the userspace tuners are connected to is GPL so what. Beside that Hauppauge is not the only company out there although I also have contacts there at Hauppauge Europe. > Binary drivers (or binary components) leads Linux back in time. > > I can't believe your so passionate about protecting secrets. > Please point me to the part where I am passionated about protecting any of my opensource code which is currently available. I have other arguments why to put that part into userspace. > > 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. > just to achieve what you're trying to argue with that companies could use some odd constructs which could be used to publish their drivers as binary only. I don't see the problem there if they want to do so. > > 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
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
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
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
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
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
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: >>> 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: > > > 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
> 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, 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
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
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: > 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
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 dr
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 u