Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Sun, Oct 14, 2007, Markus Rechberger wrote: > > the reason why I take the em28xx as hostage is, well I started with it > and I work with that company and I don't see a way how to implement > the latest devices without terrible hacks (and there are around 60 > devices supported only by the current available driver and it will > double that number since customers will change several chips on those > boards) ... > I pulled all my linux opensource projects offline till this is cleared > up I don't want to do 90% of all work and people taking over my > project doing 10% of hacks for getting some credits. The long time > support is not related to linux only. It is a bit naive for you to believe you can remove your GPL distributed work from the internet by deleting it from your server. If your kernel driver work would be merged into the kernel it would retain your copyrights and Signed-off-by: attributions, so it would be visible for everyone that it is your work. If you can't live with that, then why on earth did you join a project developing software released under the GPL? Why did you release your own software under the GPL? Since you seem obsessed with keeping control over your work it is funny that you mention BSD, as the BSD license is even less restrictive than the GPL. 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/14/07, Hans Verkuil <[EMAIL PROTECTED]> wrote: > On Sunday 14 October 2007 12:40:35 Markus Rechberger wrote: > > On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Thu, 11 Oct 2007 01:00:39 +0200 > > > "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > > > > > > Please don't send 900 line emails to which you have added only an > > > additional paragraph. > > > > > > > > drivers/media/video/em28xx/em28xx-core.c |1 - > > > > > drivers/media/video/em28xx/em28xx-input.c |1 - > > > > > drivers/media/video/em28xx/em28xx-video.c |6 +- > > > > > > > > not accepted > > > > > > Until your attempt to get the userspace-driver work merged into the > > > kernel is successful (and from my reading of last month's > > > discussion it is nowhere near that), we should continue to maintain > > > the present driver. > > > > > > If you choose to not participate in that maintenance then others > > > will need to do their best in this regard. > > > > > > What we should not and will not do is to permit the current driver > > > to be held hostage to your attempt to force a controversial and > > > apparently unwelcome change into the tree. > > > > (please read through it ... ) > > > > I didn't comment this one yet, so here a few further details. Note > > I'm not looking forward to annoy other developers I want to get that > > driver completly done. > > > > some background information on the further userspace idea: > > http://lists.freebsd.org/pipermail/freebsd-multimedia/2007-September/ > >007497.html > > > > short overview, this driver has moved a massive amount to userspace: > > libtuner/ > > (libtuner.so) User-mode drivers for tuners, demodulators, and > > anything else that constitutes the "frontend". > > > > So how is this related to my project? This project can reuse all the > > userspace demods and tuner code which I have as they are including > > the floating point stuff. > > > > I had a discussion with Hans Verkuil (the IVTV maintainer) about my > > requirements and his answer was: > > > > 2:06 - However, it is a fact that the relationship between > > you and the linux(tv) community are strained to put it mildly. I > > remain convinced that none of this has any technical basis but has > > all to do with personality conflicts. To be honest, right now I think > > there is no solution in sight. This is a valid reason to consider > > stopping. > > Um, please ask next time when you want to quote from a private > discussion. > > To put it in perspective: I meant here that stopping the em28xx > development using GPL is a consideration, not to take em28xx hostage. > My first point in that same discussion was this: > > "hverkuil: - It is pointless to worry about what others might do with > your GPL code. Anyone can take it at any time and who knows, they might > succeed. Then again, they might not. In any case, it shouldn't be a > reason to consider stopping." > > The only people you are hurting by taking em28xx offline are the > end-users and yourself, I'm sorry to say. > Yes, but continuing as before keeping it aside of everything also hurts. I'm convinced that the roadmap which I aim at is fine there is code which works and which is valueable for other projects. What's the idea behind a forced separation? - One and the same code is also used as it is in Windows drivers. If someone wants to commit his free time in fixing or improving that work he's welcome to do so by touching it once 3 targets are affected. The roadmap also includes OSX which would be the 4th target. What's the value of having those shareable components which have a full implementation limited to linux which only supports a limited subset of those features (and it requires a rewrite to get it fit into the kernel, so those features will very likely get stripped off - this is the current way how it's done)? 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Sunday 14 October 2007 12:40:35 Markus Rechberger wrote: > On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Thu, 11 Oct 2007 01:00:39 +0200 > > "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > > > > Please don't send 900 line emails to which you have added only an > > additional paragraph. > > > > > > drivers/media/video/em28xx/em28xx-core.c |1 - > > > > drivers/media/video/em28xx/em28xx-input.c |1 - > > > > drivers/media/video/em28xx/em28xx-video.c |6 +- > > > > > > not accepted > > > > Until your attempt to get the userspace-driver work merged into the > > kernel is successful (and from my reading of last month's > > discussion it is nowhere near that), we should continue to maintain > > the present driver. > > > > If you choose to not participate in that maintenance then others > > will need to do their best in this regard. > > > > What we should not and will not do is to permit the current driver > > to be held hostage to your attempt to force a controversial and > > apparently unwelcome change into the tree. > > (please read through it ... ) > > I didn't comment this one yet, so here a few further details. Note > I'm not looking forward to annoy other developers I want to get that > driver completly done. > > some background information on the further userspace idea: > http://lists.freebsd.org/pipermail/freebsd-multimedia/2007-September/ >007497.html > > short overview, this driver has moved a massive amount to userspace: > libtuner/ > (libtuner.so) User-mode drivers for tuners, demodulators, and > anything else that constitutes the "frontend". > > So how is this related to my project? This project can reuse all the > userspace demods and tuner code which I have as they are including > the floating point stuff. > > I had a discussion with Hans Verkuil (the IVTV maintainer) about my > requirements and his answer was: > > 2:06 - However, it is a fact that the relationship between > you and the linux(tv) community are strained to put it mildly. I > remain convinced that none of this has any technical basis but has > all to do with personality conflicts. To be honest, right now I think > there is no solution in sight. This is a valid reason to consider > stopping. Um, please ask next time when you want to quote from a private discussion. To put it in perspective: I meant here that stopping the em28xx development using GPL is a consideration, not to take em28xx hostage. My first point in that same discussion was this: "hverkuil: - It is pointless to worry about what others might do with your GPL code. Anyone can take it at any time and who knows, they might succeed. Then again, they might not. In any case, it shouldn't be a reason to consider stopping." The only people you are hurting by taking em28xx offline are the end-users and yourself, I'm sorry to say. Regards, Hans > the reason why I take the em28xx as hostage is, well I started with > it and I work with that company and I don't see a way how to > implement the latest devices without terrible hacks (and there are > around 60 devices supported only by the current available driver and > it will double that number since customers will change several chips > on those boards) > > Due those "personal" conflicts I don't see how I can discuss it with > the linuxtv people who are against me, I even tried to discuss this > with Mauro (who never worked with a company in that area actually so > he doesn't seem to understand what I try to achive, at least I > haven't heard any technical reason why that work should be bad). > > Without any help to take aside those personal issues I don't see how > this can be solved. > I pulled all my linux opensource projects offline till this is > cleared up I don't want to do 90% of all work and people taking over > my project doing 10% of hacks for getting some credits. The long time > support is not related to linux only. > > As for the BSD project, the developers who work with kaffeine and > xine are fine with another interface which can support those BSD > drivers, as for the linux world it would mean an easy abstraction to > use i2c-dev with the existing userspace drivers without having to > change a single line in those drivers. > > sorry for bothering but it seriously cost alot of my private time as > well, Markus > > ___ > v4l-dvb-maintainer mailing list > [EMAIL PROTECTED] > http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 11 Oct 2007 01:00:39 +0200 > "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > > Please don't send 900 line emails to which you have added only an additional > paragraph. > > > > drivers/media/video/em28xx/em28xx-core.c |1 - > > > drivers/media/video/em28xx/em28xx-input.c |1 - > > > drivers/media/video/em28xx/em28xx-video.c |6 +- > > > > not accepted > > Until your attempt to get the userspace-driver work merged into the kernel > is successful (and from my reading of last month's discussion it is nowhere > near that), we should continue to maintain the present driver. > > If you choose to not participate in that maintenance then others will need > to do their best in this regard. > > What we should not and will not do is to permit the current driver to be > held hostage to your attempt to force a controversial and apparently > unwelcome change into the tree. > (please read through it ... ) I didn't comment this one yet, so here a few further details. Note I'm not looking forward to annoy other developers I want to get that driver completly done. some background information on the further userspace idea: http://lists.freebsd.org/pipermail/freebsd-multimedia/2007-September/007497.html short overview, this driver has moved a massive amount to userspace: libtuner/ (libtuner.so) User-mode drivers for tuners, demodulators, and anything else that constitutes the "frontend". So how is this related to my project? This project can reuse all the userspace demods and tuner code which I have as they are including the floating point stuff. I had a discussion with Hans Verkuil (the IVTV maintainer) about my requirements and his answer was: 2:06 - However, it is a fact that the relationship between you and the linux(tv) community are strained to put it mildly. I remain convinced that none of this has any technical basis but has all to do with personality conflicts. To be honest, right now I think there is no solution in sight. This is a valid reason to consider stopping. the reason why I take the em28xx as hostage is, well I started with it and I work with that company and I don't see a way how to implement the latest devices without terrible hacks (and there are around 60 devices supported only by the current available driver and it will double that number since customers will change several chips on those boards) Due those "personal" conflicts I don't see how I can discuss it with the linuxtv people who are against me, I even tried to discuss this with Mauro (who never worked with a company in that area actually so he doesn't seem to understand what I try to achive, at least I haven't heard any technical reason why that work should be bad). Without any help to take aside those personal issues I don't see how this can be solved. I pulled all my linux opensource projects offline till this is cleared up I don't want to do 90% of all work and people taking over my project doing 10% of hacks for getting some credits. The long time support is not related to linux only. As for the BSD project, the developers who work with kaffeine and xine are fine with another interface which can support those BSD drivers, as for the linux world it would mean an easy abstraction to use i2c-dev with the existing userspace drivers without having to change a single line in those drivers. sorry for bothering but it seriously cost alot of my private time as well, 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 11 Oct 2007 01:00:39 +0200 Markus Rechberger [EMAIL PROTECTED] wrote: Please don't send 900 line emails to which you have added only an additional paragraph. drivers/media/video/em28xx/em28xx-core.c |1 - drivers/media/video/em28xx/em28xx-input.c |1 - drivers/media/video/em28xx/em28xx-video.c |6 +- not accepted Until your attempt to get the userspace-driver work merged into the kernel is successful (and from my reading of last month's discussion it is nowhere near that), we should continue to maintain the present driver. If you choose to not participate in that maintenance then others will need to do their best in this regard. What we should not and will not do is to permit the current driver to be held hostage to your attempt to force a controversial and apparently unwelcome change into the tree. (please read through it ... ) I didn't comment this one yet, so here a few further details. Note I'm not looking forward to annoy other developers I want to get that driver completly done. some background information on the further userspace idea: http://lists.freebsd.org/pipermail/freebsd-multimedia/2007-September/007497.html short overview, this driver has moved a massive amount to userspace: libtuner/ (libtuner.so) User-mode drivers for tuners, demodulators, and anything else that constitutes the frontend. So how is this related to my project? This project can reuse all the userspace demods and tuner code which I have as they are including the floating point stuff. I had a discussion with Hans Verkuil (the IVTV maintainer) about my requirements and his answer was: 2:06 hverkuil - However, it is a fact that the relationship between you and the linux(tv) community are strained to put it mildly. I remain convinced that none of this has any technical basis but has all to do with personality conflicts. To be honest, right now I think there is no solution in sight. This is a valid reason to consider stopping. the reason why I take the em28xx as hostage is, well I started with it and I work with that company and I don't see a way how to implement the latest devices without terrible hacks (and there are around 60 devices supported only by the current available driver and it will double that number since customers will change several chips on those boards) Due those personal conflicts I don't see how I can discuss it with the linuxtv people who are against me, I even tried to discuss this with Mauro (who never worked with a company in that area actually so he doesn't seem to understand what I try to achive, at least I haven't heard any technical reason why that work should be bad). Without any help to take aside those personal issues I don't see how this can be solved. I pulled all my linux opensource projects offline till this is cleared up I don't want to do 90% of all work and people taking over my project doing 10% of hacks for getting some credits. The long time support is not related to linux only. As for the BSD project, the developers who work with kaffeine and xine are fine with another interface which can support those BSD drivers, as for the linux world it would mean an easy abstraction to use i2c-dev with the existing userspace drivers without having to change a single line in those drivers. sorry for bothering but it seriously cost alot of my private time as well, 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Sunday 14 October 2007 12:40:35 Markus Rechberger wrote: On 10/11/07, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 11 Oct 2007 01:00:39 +0200 Markus Rechberger [EMAIL PROTECTED] wrote: Please don't send 900 line emails to which you have added only an additional paragraph. drivers/media/video/em28xx/em28xx-core.c |1 - drivers/media/video/em28xx/em28xx-input.c |1 - drivers/media/video/em28xx/em28xx-video.c |6 +- not accepted Until your attempt to get the userspace-driver work merged into the kernel is successful (and from my reading of last month's discussion it is nowhere near that), we should continue to maintain the present driver. If you choose to not participate in that maintenance then others will need to do their best in this regard. What we should not and will not do is to permit the current driver to be held hostage to your attempt to force a controversial and apparently unwelcome change into the tree. (please read through it ... ) I didn't comment this one yet, so here a few further details. Note I'm not looking forward to annoy other developers I want to get that driver completly done. some background information on the further userspace idea: http://lists.freebsd.org/pipermail/freebsd-multimedia/2007-September/ 007497.html short overview, this driver has moved a massive amount to userspace: libtuner/ (libtuner.so) User-mode drivers for tuners, demodulators, and anything else that constitutes the frontend. So how is this related to my project? This project can reuse all the userspace demods and tuner code which I have as they are including the floating point stuff. I had a discussion with Hans Verkuil (the IVTV maintainer) about my requirements and his answer was: 2:06 hverkuil - However, it is a fact that the relationship between you and the linux(tv) community are strained to put it mildly. I remain convinced that none of this has any technical basis but has all to do with personality conflicts. To be honest, right now I think there is no solution in sight. This is a valid reason to consider stopping. Um, please ask next time when you want to quote from a private discussion. To put it in perspective: I meant here that stopping the em28xx development using GPL is a consideration, not to take em28xx hostage. My first point in that same discussion was this: hverkuil: - It is pointless to worry about what others might do with your GPL code. Anyone can take it at any time and who knows, they might succeed. Then again, they might not. In any case, it shouldn't be a reason to consider stopping. The only people you are hurting by taking em28xx offline are the end-users and yourself, I'm sorry to say. Regards, Hans the reason why I take the em28xx as hostage is, well I started with it and I work with that company and I don't see a way how to implement the latest devices without terrible hacks (and there are around 60 devices supported only by the current available driver and it will double that number since customers will change several chips on those boards) Due those personal conflicts I don't see how I can discuss it with the linuxtv people who are against me, I even tried to discuss this with Mauro (who never worked with a company in that area actually so he doesn't seem to understand what I try to achive, at least I haven't heard any technical reason why that work should be bad). Without any help to take aside those personal issues I don't see how this can be solved. I pulled all my linux opensource projects offline till this is cleared up I don't want to do 90% of all work and people taking over my project doing 10% of hacks for getting some credits. The long time support is not related to linux only. As for the BSD project, the developers who work with kaffeine and xine are fine with another interface which can support those BSD drivers, as for the linux world it would mean an easy abstraction to use i2c-dev with the existing userspace drivers without having to change a single line in those drivers. sorry for bothering but it seriously cost alot of my private time as well, Markus ___ v4l-dvb-maintainer mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/14/07, Hans Verkuil [EMAIL PROTECTED] wrote: On Sunday 14 October 2007 12:40:35 Markus Rechberger wrote: On 10/11/07, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 11 Oct 2007 01:00:39 +0200 Markus Rechberger [EMAIL PROTECTED] wrote: Please don't send 900 line emails to which you have added only an additional paragraph. drivers/media/video/em28xx/em28xx-core.c |1 - drivers/media/video/em28xx/em28xx-input.c |1 - drivers/media/video/em28xx/em28xx-video.c |6 +- not accepted Until your attempt to get the userspace-driver work merged into the kernel is successful (and from my reading of last month's discussion it is nowhere near that), we should continue to maintain the present driver. If you choose to not participate in that maintenance then others will need to do their best in this regard. What we should not and will not do is to permit the current driver to be held hostage to your attempt to force a controversial and apparently unwelcome change into the tree. (please read through it ... ) I didn't comment this one yet, so here a few further details. Note I'm not looking forward to annoy other developers I want to get that driver completly done. some background information on the further userspace idea: http://lists.freebsd.org/pipermail/freebsd-multimedia/2007-September/ 007497.html short overview, this driver has moved a massive amount to userspace: libtuner/ (libtuner.so) User-mode drivers for tuners, demodulators, and anything else that constitutes the frontend. So how is this related to my project? This project can reuse all the userspace demods and tuner code which I have as they are including the floating point stuff. I had a discussion with Hans Verkuil (the IVTV maintainer) about my requirements and his answer was: 2:06 hverkuil - However, it is a fact that the relationship between you and the linux(tv) community are strained to put it mildly. I remain convinced that none of this has any technical basis but has all to do with personality conflicts. To be honest, right now I think there is no solution in sight. This is a valid reason to consider stopping. Um, please ask next time when you want to quote from a private discussion. To put it in perspective: I meant here that stopping the em28xx development using GPL is a consideration, not to take em28xx hostage. My first point in that same discussion was this: hverkuil: - It is pointless to worry about what others might do with your GPL code. Anyone can take it at any time and who knows, they might succeed. Then again, they might not. In any case, it shouldn't be a reason to consider stopping. The only people you are hurting by taking em28xx offline are the end-users and yourself, I'm sorry to say. Yes, but continuing as before keeping it aside of everything also hurts. I'm convinced that the roadmap which I aim at is fine there is code which works and which is valueable for other projects. What's the idea behind a forced separation? - One and the same code is also used as it is in Windows drivers. If someone wants to commit his free time in fixing or improving that work he's welcome to do so by touching it once 3 targets are affected. The roadmap also includes OSX which would be the 4th target. What's the value of having those shareable components which have a full implementation limited to linux which only supports a limited subset of those features (and it requires a rewrite to get it fit into the kernel, so those features will very likely get stripped off - this is the current way how it's done)? 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Sun, Oct 14, 2007, Markus Rechberger wrote: the reason why I take the em28xx as hostage is, well I started with it and I work with that company and I don't see a way how to implement the latest devices without terrible hacks (and there are around 60 devices supported only by the current available driver and it will double that number since customers will change several chips on those boards) ... I pulled all my linux opensource projects offline till this is cleared up I don't want to do 90% of all work and people taking over my project doing 10% of hacks for getting some credits. The long time support is not related to linux only. It is a bit naive for you to believe you can remove your GPL distributed work from the internet by deleting it from your server. If your kernel driver work would be merged into the kernel it would retain your copyrights and Signed-off-by: attributions, so it would be visible for everyone that it is your work. If you can't live with that, then why on earth did you join a project developing software released under the GPL? Why did you release your own software under the GPL? Since you seem obsessed with keeping control over your work it is funny that you mention BSD, as the BSD license is even less restrictive than the GPL. 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
Markus Rechberger a écrit : > On 10/11/07, Aurelien Jarno <[EMAIL PROTECTED]> wrote: >> Markus Rechberger a écrit : >>> On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. >>> it does not since it's broken and feature limited. On the other side >> I have a device which works perfectly with it if you add the vendor and >> product ID to the list. I don't really call that broken. And it doesn't >> need a firmware. >> > > Aurelien, > > the device you're using is around 2 years old. You're one of the lucky > ones, I have tonns of support mails in my mail account from people who > own almost a similar device but with different videodecoders which are > not fully supported in the kernel or which worked and got broken > during the time. > It took me around 4 hours to debug such an issue last years remotly > with an enduser (which includes that noone cared to ask me if I'm fine > with such an update, neither did someone ask people who own such > devices that they should test the changes). > Please also take other devices and upcoming devices into account, > since i'm willing to spend that time and since I'm in contact with > various companies who provide several components of those devices. > I agree I am lucky, but the fact is that the in-kernel driver supports *some* devices, and *works* correctly for them. On the other side, your driver supports more devices, but it is and *out-of-tree* driver. Please either work to get your change merged, or stop complaining about changes done to the in-kernel driver. Moreover if you get a closer look at v4l-dvb git, you will see that the changes proposed by Mauro are not em28xx specific, and is actually the same change done on a lot of of v4l/dvb drivers. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Marcel Siegert <[EMAIL PROTECTED]> wrote: > Markus Rechberger schrieb: > > On 10/11/07, Marcel Siegert <[EMAIL PROTECTED]> wrote: > >> Markus Rechberger schrieb: > >>> On 10/11/07, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > Markus Rechberger a écrit : > > On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > >> As such, the old and decrepit em28xx driver seems more useful to > >> people, > >> since at least it supports the limited set of hardware on its own. > > it does not since it's broken and feature limited. On the other side > I have a device which works perfectly with it if you add the vendor and > product ID to the list. I don't really call that broken. And it doesn't > need a firmware. > > >>> Aurelien, > >>> > >>> the device you're using is around 2 years old. You're one of the lucky > >>> ones, I have tonns of support mails in my mail account from people who > >>> own almost a similar device but with different videodecoders which are > >>> not fully supported in the kernel or which worked and got broken > >>> during the time. > >>> It took me around 4 hours to debug such an issue last years remotly > >>> with an enduser (which includes that noone cared to ask me if I'm fine > >>> with such an update, neither did someone ask people who own such > >>> devices that they should test the changes). > >>> Please also take other devices and upcoming devices into account, > >>> since i'm willing to spend that time and since I'm in contact with > >>> various companies who provide several components of those devices. > >>> > Please think that a lot of persons do not have enough knowledge to > compile out of tree drivers, and that a lot more do not even know about > this out of tree driver. > > >>> this is what all is about, the project does not depend on certain > >>> broken drivers anymore. And people who initially disagreed without > >>> having any solution nor contributed any code can continue to play > >>> their game without having an impact on that driver anymore. > >>> > >>> Markus > >> markus, > >> > >> its the same old story you are telling over and over again. > >> > >> of course there might be a huge community builded up the > >> last month @ mcentral, > >> of course your driver supports newer devices, > >> > >> BUT > >> > >> the same old story is - and you always miss that part > >> > >> we discussed a lot on your changes and also ACCEPTED those > >> for merging, if you would have changed your UNNECCESSARY touching > >> of dvb-core. its proven that things could work without that > >> nacked change to dvb core. but, you decided to stop discussion then, > >> and went away to perform your own tree/userspace thing. > >> > >> as linus and andrew stated within this thread they think they will not > >> merge your code like it is cause of different reasons, > >> i am wondering a bit whats your next step is. > >> > > > > I didn't read a clean statement about it. If so I won't continue to > > pull out opensource drivers from that company. > > Marcel, you haven't been and you are not into that topic otherwise > > you'd write about missing parts and address codeparts which I have > > mentioned in the past which are not ok in the kernel and how to solve > > that best. > > saving my time instead of commenting your code does not mean i am not > into it. as far as i remember i did say, that the api mixup within > dvb-core is NOT wanted and there are solutions for other devices, > that show it can be done otherwise. i must admit it would be a different > way but the only answer you said was "No, i wont do that" > > please go back through the irc logs on linuxtv.org and find the > appropiate place. > > > I remember the mail [1] where you (and Michael) tried to point me to > > something that doesn't work out. Please get into the whole topic which > > includes studying the requirements and what parts I'm complaining > > about. > as you may remember, i also offered you to ack a MERGE AS IS base for > your code in a private conversation on irc. > I didn't see that. > the main topics in there have been: > merge your stuff > wait for multiproto applied (as i still think it is a better solution) > rework your stuff to work with multiproto > > your answer was afair "i will not allow anyone to modify my code after a > merge" > I would like to see where I wrote that. I remember that I stated out merge it as it is and modify it afterwards because then you have to take care about the requirements which are implemented and which some are not aware of. (There are also heavy discussions about that ... think we shouldn't rediscuss it and if someone wants to rediscuss it please put together a wikisite about the discussions since it makes no sense to get over it again). > that showed me, others did recognise meanwhile too, that you are NOT > able to discuss different things or opinions for real, but you take > your proposals as the "one and only".
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
Markus Rechberger schrieb: On 10/11/07, Marcel Siegert <[EMAIL PROTECTED]> wrote: Markus Rechberger schrieb: On 10/11/07, Aurelien Jarno <[EMAIL PROTECTED]> wrote: Markus Rechberger a écrit : On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side I have a device which works perfectly with it if you add the vendor and product ID to the list. I don't really call that broken. And it doesn't need a firmware. Aurelien, the device you're using is around 2 years old. You're one of the lucky ones, I have tonns of support mails in my mail account from people who own almost a similar device but with different videodecoders which are not fully supported in the kernel or which worked and got broken during the time. It took me around 4 hours to debug such an issue last years remotly with an enduser (which includes that noone cared to ask me if I'm fine with such an update, neither did someone ask people who own such devices that they should test the changes). Please also take other devices and upcoming devices into account, since i'm willing to spend that time and since I'm in contact with various companies who provide several components of those devices. Please think that a lot of persons do not have enough knowledge to compile out of tree drivers, and that a lot more do not even know about this out of tree driver. this is what all is about, the project does not depend on certain broken drivers anymore. And people who initially disagreed without having any solution nor contributed any code can continue to play their game without having an impact on that driver anymore. Markus markus, its the same old story you are telling over and over again. of course there might be a huge community builded up the last month @ mcentral, of course your driver supports newer devices, BUT the same old story is - and you always miss that part we discussed a lot on your changes and also ACCEPTED those for merging, if you would have changed your UNNECCESSARY touching of dvb-core. its proven that things could work without that nacked change to dvb core. but, you decided to stop discussion then, and went away to perform your own tree/userspace thing. as linus and andrew stated within this thread they think they will not merge your code like it is cause of different reasons, i am wondering a bit whats your next step is. I didn't read a clean statement about it. If so I won't continue to pull out opensource drivers from that company. Marcel, you haven't been and you are not into that topic otherwise you'd write about missing parts and address codeparts which I have mentioned in the past which are not ok in the kernel and how to solve that best. saving my time instead of commenting your code does not mean i am not into it. as far as i remember i did say, that the api mixup within dvb-core is NOT wanted and there are solutions for other devices, that show it can be done otherwise. i must admit it would be a different way but the only answer you said was "No, i wont do that" please go back through the irc logs on linuxtv.org and find the appropiate place. I remember the mail [1] where you (and Michael) tried to point me to something that doesn't work out. Please get into the whole topic which includes studying the requirements and what parts I'm complaining about. as you may remember, i also offered you to ack a MERGE AS IS base for your code in a private conversation on irc. the main topics in there have been: merge your stuff wait for multiproto applied (as i still think it is a better solution) rework your stuff to work with multiproto your answer was afair "i will not allow anyone to modify my code after a merge" that showed me, others did recognise meanwhile too, that you are NOT able to discuss different things or opinions for real, but you take your proposals as the "one and only". this can not work, and will not work. i will leave this discussion again, as discussing with you mostly just leads into the old story of how stupid linuxtv devs are... YOU LEFT linuxtv to build up your own - proceed further with that strategy _or_ come back to a level where you are open for different suggestions than yours. HTH marcel Markus (just for the record, although it's not relevant anymore) http://threebit.net/mail-archive/video4linux/msg07548.html - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Pádraig Brady <[EMAIL PROTECTED]> wrote: > Aidan Thornton wrote: > > I looked at this recently, and I'm not sure the core em28xx code was > > really that different (at least, pre-userspace). Most of the core > > changes seemed to be related to Markus' driver having (semi-working) > > VBI support. I haven't tried this recently; I disabled it a while back > > because it had a bug that caused a kernel panic half the time when > > attempting to record something with MythTV. > > > > The in-kernel driver looks mostly sound, though I can't test it > > myself. (One other interesting thing that was added in Markus' driver > > is various v4l1 ioctls, which may be useful to some people.) > > Yes, for example VLC doesn't support v4l2 yet. > Here is a patch I back ported to 2.6.17 last year. > http://www.pixelbeat.org/patches/linux-2.6.17-em28xx-v4l1.diff > I didn't try to get it merged as I thought Markus would do it, > but looks like that's unlikely now. > > Also here is a patch to allow shared access to the video device > (so you can have a separate tuner program to VLC for example): > http://www.pixelbeat.org/patches/linux-2.6.17-em28xx-shared.diff > > > Incidentally, I notice you appear to be developing userspace drivers > > for the tvp5150 and zl10353. Is that really necessary? > > It is necessary if Markus wants to stop people merging code back from > his in-kernel driver fork. Call me a cynic, but I'm confused about Markus' > motives in all this. > The tvp5150 as well as several other drivers have some slight changes in it to get some devices work. My motivation behind it is that since I don't agree with certain linuxtv development paths and it makes it alot easier to handle prewritten code from some companies. > Markus, please do the right thing and just merge your code! > (and please don't reply this giving reasons you won't/can't do this). > Merge the bridging code and the issue is done, the other guys should go their own paths with their own drivers if they want so. Time will show what will be better in the end. There are not so many devices out there which have newer requirements, although the em28xx is a good example for at least one device which doesn't fit. If someone's looking for another disagreement between developers (which my code is not part of): http://thread.gmane.org/gmane.linux.drivers.dvb/36583 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
Aidan Thornton wrote: > I looked at this recently, and I'm not sure the core em28xx code was > really that different (at least, pre-userspace). Most of the core > changes seemed to be related to Markus' driver having (semi-working) > VBI support. I haven't tried this recently; I disabled it a while back > because it had a bug that caused a kernel panic half the time when > attempting to record something with MythTV. > > The in-kernel driver looks mostly sound, though I can't test it > myself. (One other interesting thing that was added in Markus' driver > is various v4l1 ioctls, which may be useful to some people.) Yes, for example VLC doesn't support v4l2 yet. Here is a patch I back ported to 2.6.17 last year. http://www.pixelbeat.org/patches/linux-2.6.17-em28xx-v4l1.diff I didn't try to get it merged as I thought Markus would do it, but looks like that's unlikely now. Also here is a patch to allow shared access to the video device (so you can have a separate tuner program to VLC for example): http://www.pixelbeat.org/patches/linux-2.6.17-em28xx-shared.diff > Incidentally, I notice you appear to be developing userspace drivers > for the tvp5150 and zl10353. Is that really necessary? It is necessary if Markus wants to stop people merging code back from his in-kernel driver fork. Call me a cynic, but I'm confused about Markus' motives in all this. Markus, please do the right thing and just merge your code! (and please don't reply this giving reasons you won't/can't do this). Pádraig. - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Marcel Siegert <[EMAIL PROTECTED]> wrote: > Markus Rechberger schrieb: > > On 10/11/07, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > >> Markus Rechberger a écrit : > >>> On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > As such, the old and decrepit em28xx driver seems more useful to > people, > since at least it supports the limited set of hardware on its own. > >>> it does not since it's broken and feature limited. On the other side > >> I have a device which works perfectly with it if you add the vendor and > >> product ID to the list. I don't really call that broken. And it doesn't > >> need a firmware. > >> > > > > Aurelien, > > > > the device you're using is around 2 years old. You're one of the lucky > > ones, I have tonns of support mails in my mail account from people who > > own almost a similar device but with different videodecoders which are > > not fully supported in the kernel or which worked and got broken > > during the time. > > It took me around 4 hours to debug such an issue last years remotly > > with an enduser (which includes that noone cared to ask me if I'm fine > > with such an update, neither did someone ask people who own such > > devices that they should test the changes). > > Please also take other devices and upcoming devices into account, > > since i'm willing to spend that time and since I'm in contact with > > various companies who provide several components of those devices. > > > >> Please think that a lot of persons do not have enough knowledge to > >> compile out of tree drivers, and that a lot more do not even know about > >> this out of tree driver. > >> > > > > this is what all is about, the project does not depend on certain > > broken drivers anymore. And people who initially disagreed without > > having any solution nor contributed any code can continue to play > > their game without having an impact on that driver anymore. > > > > Markus > > markus, > > its the same old story you are telling over and over again. > > of course there might be a huge community builded up the > last month @ mcentral, > of course your driver supports newer devices, > > BUT > > the same old story is - and you always miss that part > > we discussed a lot on your changes and also ACCEPTED those > for merging, if you would have changed your UNNECCESSARY touching > of dvb-core. its proven that things could work without that > nacked change to dvb core. but, you decided to stop discussion then, > and went away to perform your own tree/userspace thing. > > as linus and andrew stated within this thread they think they will not > merge your code like it is cause of different reasons, > i am wondering a bit whats your next step is. > I didn't read a clean statement about it. If so I won't continue to pull out opensource drivers from that company. Marcel, you haven't been and you are not into that topic otherwise you'd write about missing parts and address codeparts which I have mentioned in the past which are not ok in the kernel and how to solve that best. I remember the mail [1] where you (and Michael) tried to point me to something that doesn't work out. Please get into the whole topic which includes studying the requirements and what parts I'm complaining about. Markus (just for the record, although it's not relevant anymore) http://threebit.net/mail-archive/video4linux/msg07548.html - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 10/11/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote: > > On 10/10/2007 07:24 PM, Markus Rechberger wrote: > > > > > > To point to more changes within the available driver which hasn't been > > merged > > > within the last 1 1/2 years: > > > * it supports non usbaudio based video devices. > > > * has support for dvb-t/atsc > > > * allows multiple device node access in case of analogue TV > > > * has teletext/VBI support for PAL. > > > * it supports modules which are now in userspace instead of > > > kernelspace due disagreements with some developers for 1 1/2 years. > > > * I do not agree with certain developers who do not have any experience > > > with certain parts of the code for redoing it a 4th time now. My patience > > > is over, which includes the company support in my back to get those > > > devices supported. > > > > > > > Do you plan on maintaining your own private driver tree for all of eternity? > > > > I plan to tidy it up for inclusion and put everything together to get > it work properly. > The code which is in the kernel is around 5 % done, the code which is > available on mcentral.de is around 50% done. It still requires some > work to get _all_ devices supported, and keeping the development > process in an endless loop and depending on people who have no idea > and don't care about certain requirements is no option. > The upcoming devices which use other chips and which have more > features will at least also use those drivers. I expect that it will > pump up the driver to support more than 100 devices within the next > year. I looked at this recently, and I'm not sure the core em28xx code was really that different (at least, pre-userspace). Most of the core changes seemed to be related to Markus' driver having (semi-working) VBI support. I haven't tried this recently; I disabled it a while back because it had a bug that caused a kernel panic half the time when attempting to record something with MythTV. The in-kernel driver looks mostly sound, though I can't test it myself. (One other interesting thing that was added in Markus' driver is various v4l1 ioctls, which may be useful to some people.) Incidentally, I notice you appear to be developing userspace drivers for the tvp5150 and zl10353. Is that really necessary? > * I do not agree with certain developers who do not have any experience > with certain parts of the code for redoing it a 4th time now. My patience > is over, which includes the company support in my back to get those > devices supported. Are you threatening to deliberately sabotage company support for these devices by v4l/linuxtv in favour of your userspace drivers? Also, I'm not sure reworking the non-userspace version of the code to a mergable state is actually that hard. (I'm cleaning up bits of it in my spare time, because I may have to port it to newer kernels myself in the future and it's annoying to work with as-is.) Eliminating the need for changes to the core v4l/dvb code appears to be the easy bit; the main difficulty is finding and fixing the unexpected breakages due to the interesting coupling between bits of the code. (The other difficulty is keeping track of whether analog or digital firmware is currently loaded in the xc3028 in hybrid devices; I'm using an iffy solution, but I think better ones exist.) As I recall, the changes to core code were the major roadblock in the way of merging. 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
Markus Rechberger schrieb: On 10/11/07, Aurelien Jarno <[EMAIL PROTECTED]> wrote: Markus Rechberger a écrit : On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side I have a device which works perfectly with it if you add the vendor and product ID to the list. I don't really call that broken. And it doesn't need a firmware. Aurelien, the device you're using is around 2 years old. You're one of the lucky ones, I have tonns of support mails in my mail account from people who own almost a similar device but with different videodecoders which are not fully supported in the kernel or which worked and got broken during the time. It took me around 4 hours to debug such an issue last years remotly with an enduser (which includes that noone cared to ask me if I'm fine with such an update, neither did someone ask people who own such devices that they should test the changes). Please also take other devices and upcoming devices into account, since i'm willing to spend that time and since I'm in contact with various companies who provide several components of those devices. Please think that a lot of persons do not have enough knowledge to compile out of tree drivers, and that a lot more do not even know about this out of tree driver. this is what all is about, the project does not depend on certain broken drivers anymore. And people who initially disagreed without having any solution nor contributed any code can continue to play their game without having an impact on that driver anymore. Markus markus, its the same old story you are telling over and over again. of course there might be a huge community builded up the last month @ mcentral, of course your driver supports newer devices, BUT the same old story is - and you always miss that part we discussed a lot on your changes and also ACCEPTED those for merging, if you would have changed your UNNECCESSARY touching of dvb-core. its proven that things could work without that nacked change to dvb core. but, you decided to stop discussion then, and went away to perform your own tree/userspace thing. as linus and andrew stated within this thread they think they will not merge your code like it is cause of different reasons, i am wondering a bit whats your next step is. regards marcel ps. as linus tells from time to time "It's not just black and white - there's also grey" - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Thu, Oct 11, 2007 at 07:09:47AM +0200, Markus Rechberger wrote: > It makes no sense to keep the kernel driver uptodate, it would make > more sense to support the latest driver (which some people are > supporting). > I just had a look at the driver downloads it makes around 600 > downloads for september for this driver. 600 downloads a month may seem like a lot to you for one driver. But think about how many people are running distribution kernels rather than kernels they built themselves. Typically none of these people will even know your driver exists, let alone go running after it to download/build it. >From an end-user perspective, out of tree drivers are a nuisance. Time and time again, I get bug reports from users claiming some bug is in the kernel, where the problem is actually that they're running some out of tree driver that hasn't been updated to run on the latest kernels. It's really in everyones (including yours) best interests to get drivers merged into mainline. Dave -- http://www.codemonkey.org.uk - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > Markus Rechberger a écrit : > > On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > >> As such, the old and decrepit em28xx driver seems more useful to people, > >> since at least it supports the limited set of hardware on its own. > > > > it does not since it's broken and feature limited. On the other side > > I have a device which works perfectly with it if you add the vendor and > product ID to the list. I don't really call that broken. And it doesn't > need a firmware. > Aurelien, the device you're using is around 2 years old. You're one of the lucky ones, I have tonns of support mails in my mail account from people who own almost a similar device but with different videodecoders which are not fully supported in the kernel or which worked and got broken during the time. It took me around 4 hours to debug such an issue last years remotly with an enduser (which includes that noone cared to ask me if I'm fine with such an update, neither did someone ask people who own such devices that they should test the changes). Please also take other devices and upcoming devices into account, since i'm willing to spend that time and since I'm in contact with various companies who provide several components of those devices. > Please think that a lot of persons do not have enough knowledge to > compile out of tree drivers, and that a lot more do not even know about > this out of tree driver. > this is what all is about, the project does not depend on certain broken drivers anymore. And people who initially disagreed without having any solution nor contributed any code can continue to play their game without having an impact on that driver anymore. 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
Markus Rechberger a écrit : > On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: >> As such, the old and decrepit em28xx driver seems more useful to people, >> since at least it supports the limited set of hardware on its own. > > it does not since it's broken and feature limited. On the other side I have a device which works perfectly with it if you add the vendor and product ID to the list. I don't really call that broken. And it doesn't need a firmware. Please think that a lot of persons do not have enough knowledge to compile out of tree drivers, and that a lot more do not even know about this out of tree driver. > it requires a firmware from userspace too so I don't think it matters > at all if the algorithm is done in kernelspace or userspace since it > depends on such a blob (and I cannot get the source for that firmware, > if someone's interested in that he has to disassemble the firmware). > -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
Markus Rechberger a écrit : On 10/11/07, Linus Torvalds [EMAIL PROTECTED] wrote: As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side I have a device which works perfectly with it if you add the vendor and product ID to the list. I don't really call that broken. And it doesn't need a firmware. Please think that a lot of persons do not have enough knowledge to compile out of tree drivers, and that a lot more do not even know about this out of tree driver. it requires a firmware from userspace too so I don't think it matters at all if the algorithm is done in kernelspace or userspace since it depends on such a blob (and I cannot get the source for that firmware, if someone's interested in that he has to disassemble the firmware). -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Aurelien Jarno [EMAIL PROTECTED] wrote: Markus Rechberger a écrit : On 10/11/07, Linus Torvalds [EMAIL PROTECTED] wrote: As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side I have a device which works perfectly with it if you add the vendor and product ID to the list. I don't really call that broken. And it doesn't need a firmware. Aurelien, the device you're using is around 2 years old. You're one of the lucky ones, I have tonns of support mails in my mail account from people who own almost a similar device but with different videodecoders which are not fully supported in the kernel or which worked and got broken during the time. It took me around 4 hours to debug such an issue last years remotly with an enduser (which includes that noone cared to ask me if I'm fine with such an update, neither did someone ask people who own such devices that they should test the changes). Please also take other devices and upcoming devices into account, since i'm willing to spend that time and since I'm in contact with various companies who provide several components of those devices. Please think that a lot of persons do not have enough knowledge to compile out of tree drivers, and that a lot more do not even know about this out of tree driver. this is what all is about, the project does not depend on certain broken drivers anymore. And people who initially disagreed without having any solution nor contributed any code can continue to play their game without having an impact on that driver anymore. 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Thu, Oct 11, 2007 at 07:09:47AM +0200, Markus Rechberger wrote: It makes no sense to keep the kernel driver uptodate, it would make more sense to support the latest driver (which some people are supporting). I just had a look at the driver downloads it makes around 600 downloads for september for this driver. 600 downloads a month may seem like a lot to you for one driver. But think about how many people are running distribution kernels rather than kernels they built themselves. Typically none of these people will even know your driver exists, let alone go running after it to download/build it. From an end-user perspective, out of tree drivers are a nuisance. Time and time again, I get bug reports from users claiming some bug is in the kernel, where the problem is actually that they're running some out of tree driver that hasn't been updated to run on the latest kernels. It's really in everyones (including yours) best interests to get drivers merged into mainline. Dave -- http://www.codemonkey.org.uk - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
Markus Rechberger schrieb: On 10/11/07, Aurelien Jarno [EMAIL PROTECTED] wrote: Markus Rechberger a écrit : On 10/11/07, Linus Torvalds [EMAIL PROTECTED] wrote: As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side I have a device which works perfectly with it if you add the vendor and product ID to the list. I don't really call that broken. And it doesn't need a firmware. Aurelien, the device you're using is around 2 years old. You're one of the lucky ones, I have tonns of support mails in my mail account from people who own almost a similar device but with different videodecoders which are not fully supported in the kernel or which worked and got broken during the time. It took me around 4 hours to debug such an issue last years remotly with an enduser (which includes that noone cared to ask me if I'm fine with such an update, neither did someone ask people who own such devices that they should test the changes). Please also take other devices and upcoming devices into account, since i'm willing to spend that time and since I'm in contact with various companies who provide several components of those devices. Please think that a lot of persons do not have enough knowledge to compile out of tree drivers, and that a lot more do not even know about this out of tree driver. this is what all is about, the project does not depend on certain broken drivers anymore. And people who initially disagreed without having any solution nor contributed any code can continue to play their game without having an impact on that driver anymore. Markus markus, its the same old story you are telling over and over again. of course there might be a huge community builded up the last month @ mcentral, of course your driver supports newer devices, BUT the same old story is - and you always miss that part we discussed a lot on your changes and also ACCEPTED those for merging, if you would have changed your UNNECCESSARY touching of dvb-core. its proven that things could work without that nacked change to dvb core. but, you decided to stop discussion then, and went away to perform your own tree/userspace thing. as linus and andrew stated within this thread they think they will not merge your code like it is cause of different reasons, i am wondering a bit whats your next step is. regards marcel ps. as linus tells from time to time It's not just black and white - there's also grey - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Markus Rechberger [EMAIL PROTECTED] wrote: On 10/11/07, Chuck Ebbert [EMAIL PROTECTED] wrote: On 10/10/2007 07:24 PM, Markus Rechberger wrote: To point to more changes within the available driver which hasn't been merged within the last 1 1/2 years: * it supports non usbaudio based video devices. * has support for dvb-t/atsc * allows multiple device node access in case of analogue TV * has teletext/VBI support for PAL. * it supports modules which are now in userspace instead of kernelspace due disagreements with some developers for 1 1/2 years. * I do not agree with certain developers who do not have any experience with certain parts of the code for redoing it a 4th time now. My patience is over, which includes the company support in my back to get those devices supported. Do you plan on maintaining your own private driver tree for all of eternity? I plan to tidy it up for inclusion and put everything together to get it work properly. The code which is in the kernel is around 5 % done, the code which is available on mcentral.de is around 50% done. It still requires some work to get _all_ devices supported, and keeping the development process in an endless loop and depending on people who have no idea and don't care about certain requirements is no option. The upcoming devices which use other chips and which have more features will at least also use those drivers. I expect that it will pump up the driver to support more than 100 devices within the next year. I looked at this recently, and I'm not sure the core em28xx code was really that different (at least, pre-userspace). Most of the core changes seemed to be related to Markus' driver having (semi-working) VBI support. I haven't tried this recently; I disabled it a while back because it had a bug that caused a kernel panic half the time when attempting to record something with MythTV. The in-kernel driver looks mostly sound, though I can't test it myself. (One other interesting thing that was added in Markus' driver is various v4l1 ioctls, which may be useful to some people.) Incidentally, I notice you appear to be developing userspace drivers for the tvp5150 and zl10353. Is that really necessary? * I do not agree with certain developers who do not have any experience with certain parts of the code for redoing it a 4th time now. My patience is over, which includes the company support in my back to get those devices supported. Are you threatening to deliberately sabotage company support for these devices by v4l/linuxtv in favour of your userspace drivers? Also, I'm not sure reworking the non-userspace version of the code to a mergable state is actually that hard. (I'm cleaning up bits of it in my spare time, because I may have to port it to newer kernels myself in the future and it's annoying to work with as-is.) Eliminating the need for changes to the core v4l/dvb code appears to be the easy bit; the main difficulty is finding and fixing the unexpected breakages due to the interesting coupling between bits of the code. (The other difficulty is keeping track of whether analog or digital firmware is currently loaded in the xc3028 in hybrid devices; I'm using an iffy solution, but I think better ones exist.) As I recall, the changes to core code were the major roadblock in the way of merging. 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Marcel Siegert [EMAIL PROTECTED] wrote: Markus Rechberger schrieb: On 10/11/07, Aurelien Jarno [EMAIL PROTECTED] wrote: Markus Rechberger a écrit : On 10/11/07, Linus Torvalds [EMAIL PROTECTED] wrote: As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side I have a device which works perfectly with it if you add the vendor and product ID to the list. I don't really call that broken. And it doesn't need a firmware. Aurelien, the device you're using is around 2 years old. You're one of the lucky ones, I have tonns of support mails in my mail account from people who own almost a similar device but with different videodecoders which are not fully supported in the kernel or which worked and got broken during the time. It took me around 4 hours to debug such an issue last years remotly with an enduser (which includes that noone cared to ask me if I'm fine with such an update, neither did someone ask people who own such devices that they should test the changes). Please also take other devices and upcoming devices into account, since i'm willing to spend that time and since I'm in contact with various companies who provide several components of those devices. Please think that a lot of persons do not have enough knowledge to compile out of tree drivers, and that a lot more do not even know about this out of tree driver. this is what all is about, the project does not depend on certain broken drivers anymore. And people who initially disagreed without having any solution nor contributed any code can continue to play their game without having an impact on that driver anymore. Markus markus, its the same old story you are telling over and over again. of course there might be a huge community builded up the last month @ mcentral, of course your driver supports newer devices, BUT the same old story is - and you always miss that part we discussed a lot on your changes and also ACCEPTED those for merging, if you would have changed your UNNECCESSARY touching of dvb-core. its proven that things could work without that nacked change to dvb core. but, you decided to stop discussion then, and went away to perform your own tree/userspace thing. as linus and andrew stated within this thread they think they will not merge your code like it is cause of different reasons, i am wondering a bit whats your next step is. I didn't read a clean statement about it. If so I won't continue to pull out opensource drivers from that company. Marcel, you haven't been and you are not into that topic otherwise you'd write about missing parts and address codeparts which I have mentioned in the past which are not ok in the kernel and how to solve that best. I remember the mail [1] where you (and Michael) tried to point me to something that doesn't work out. Please get into the whole topic which includes studying the requirements and what parts I'm complaining about. Markus (just for the record, although it's not relevant anymore) http://threebit.net/mail-archive/video4linux/msg07548.html - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
Aidan Thornton wrote: I looked at this recently, and I'm not sure the core em28xx code was really that different (at least, pre-userspace). Most of the core changes seemed to be related to Markus' driver having (semi-working) VBI support. I haven't tried this recently; I disabled it a while back because it had a bug that caused a kernel panic half the time when attempting to record something with MythTV. The in-kernel driver looks mostly sound, though I can't test it myself. (One other interesting thing that was added in Markus' driver is various v4l1 ioctls, which may be useful to some people.) Yes, for example VLC doesn't support v4l2 yet. Here is a patch I back ported to 2.6.17 last year. http://www.pixelbeat.org/patches/linux-2.6.17-em28xx-v4l1.diff I didn't try to get it merged as I thought Markus would do it, but looks like that's unlikely now. Also here is a patch to allow shared access to the video device (so you can have a separate tuner program to VLC for example): http://www.pixelbeat.org/patches/linux-2.6.17-em28xx-shared.diff Incidentally, I notice you appear to be developing userspace drivers for the tvp5150 and zl10353. Is that really necessary? It is necessary if Markus wants to stop people merging code back from his in-kernel driver fork. Call me a cynic, but I'm confused about Markus' motives in all this. Markus, please do the right thing and just merge your code! (and please don't reply this giving reasons you won't/can't do this). Pádraig. - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Pádraig Brady [EMAIL PROTECTED] wrote: Aidan Thornton wrote: I looked at this recently, and I'm not sure the core em28xx code was really that different (at least, pre-userspace). Most of the core changes seemed to be related to Markus' driver having (semi-working) VBI support. I haven't tried this recently; I disabled it a while back because it had a bug that caused a kernel panic half the time when attempting to record something with MythTV. The in-kernel driver looks mostly sound, though I can't test it myself. (One other interesting thing that was added in Markus' driver is various v4l1 ioctls, which may be useful to some people.) Yes, for example VLC doesn't support v4l2 yet. Here is a patch I back ported to 2.6.17 last year. http://www.pixelbeat.org/patches/linux-2.6.17-em28xx-v4l1.diff I didn't try to get it merged as I thought Markus would do it, but looks like that's unlikely now. Also here is a patch to allow shared access to the video device (so you can have a separate tuner program to VLC for example): http://www.pixelbeat.org/patches/linux-2.6.17-em28xx-shared.diff Incidentally, I notice you appear to be developing userspace drivers for the tvp5150 and zl10353. Is that really necessary? It is necessary if Markus wants to stop people merging code back from his in-kernel driver fork. Call me a cynic, but I'm confused about Markus' motives in all this. The tvp5150 as well as several other drivers have some slight changes in it to get some devices work. My motivation behind it is that since I don't agree with certain linuxtv development paths and it makes it alot easier to handle prewritten code from some companies. Markus, please do the right thing and just merge your code! (and please don't reply this giving reasons you won't/can't do this). Merge the bridging code and the issue is done, the other guys should go their own paths with their own drivers if they want so. Time will show what will be better in the end. There are not so many devices out there which have newer requirements, although the em28xx is a good example for at least one device which doesn't fit. If someone's looking for another disagreement between developers (which my code is not part of): http://thread.gmane.org/gmane.linux.drivers.dvb/36583 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
Markus Rechberger schrieb: On 10/11/07, Marcel Siegert [EMAIL PROTECTED] wrote: Markus Rechberger schrieb: On 10/11/07, Aurelien Jarno [EMAIL PROTECTED] wrote: Markus Rechberger a écrit : On 10/11/07, Linus Torvalds [EMAIL PROTECTED] wrote: As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side I have a device which works perfectly with it if you add the vendor and product ID to the list. I don't really call that broken. And it doesn't need a firmware. Aurelien, the device you're using is around 2 years old. You're one of the lucky ones, I have tonns of support mails in my mail account from people who own almost a similar device but with different videodecoders which are not fully supported in the kernel or which worked and got broken during the time. It took me around 4 hours to debug such an issue last years remotly with an enduser (which includes that noone cared to ask me if I'm fine with such an update, neither did someone ask people who own such devices that they should test the changes). Please also take other devices and upcoming devices into account, since i'm willing to spend that time and since I'm in contact with various companies who provide several components of those devices. Please think that a lot of persons do not have enough knowledge to compile out of tree drivers, and that a lot more do not even know about this out of tree driver. this is what all is about, the project does not depend on certain broken drivers anymore. And people who initially disagreed without having any solution nor contributed any code can continue to play their game without having an impact on that driver anymore. Markus markus, its the same old story you are telling over and over again. of course there might be a huge community builded up the last month @ mcentral, of course your driver supports newer devices, BUT the same old story is - and you always miss that part we discussed a lot on your changes and also ACCEPTED those for merging, if you would have changed your UNNECCESSARY touching of dvb-core. its proven that things could work without that nacked change to dvb core. but, you decided to stop discussion then, and went away to perform your own tree/userspace thing. as linus and andrew stated within this thread they think they will not merge your code like it is cause of different reasons, i am wondering a bit whats your next step is. I didn't read a clean statement about it. If so I won't continue to pull out opensource drivers from that company. Marcel, you haven't been and you are not into that topic otherwise you'd write about missing parts and address codeparts which I have mentioned in the past which are not ok in the kernel and how to solve that best. saving my time instead of commenting your code does not mean i am not into it. as far as i remember i did say, that the api mixup within dvb-core is NOT wanted and there are solutions for other devices, that show it can be done otherwise. i must admit it would be a different way but the only answer you said was No, i wont do that please go back through the irc logs on linuxtv.org and find the appropiate place. I remember the mail [1] where you (and Michael) tried to point me to something that doesn't work out. Please get into the whole topic which includes studying the requirements and what parts I'm complaining about. as you may remember, i also offered you to ack a MERGE AS IS base for your code in a private conversation on irc. the main topics in there have been: merge your stuff wait for multiproto applied (as i still think it is a better solution) rework your stuff to work with multiproto your answer was afair i will not allow anyone to modify my code after a merge that showed me, others did recognise meanwhile too, that you are NOT able to discuss different things or opinions for real, but you take your proposals as the one and only. this can not work, and will not work. i will leave this discussion again, as discussing with you mostly just leads into the old story of how stupid linuxtv devs are... YOU LEFT linuxtv to build up your own - proceed further with that strategy _or_ come back to a level where you are open for different suggestions than yours. HTH marcel Markus (just for the record, although it's not relevant anymore) http://threebit.net/mail-archive/video4linux/msg07548.html - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Marcel Siegert [EMAIL PROTECTED] wrote: Markus Rechberger schrieb: On 10/11/07, Marcel Siegert [EMAIL PROTECTED] wrote: Markus Rechberger schrieb: On 10/11/07, Aurelien Jarno [EMAIL PROTECTED] wrote: Markus Rechberger a écrit : On 10/11/07, Linus Torvalds [EMAIL PROTECTED] wrote: As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side I have a device which works perfectly with it if you add the vendor and product ID to the list. I don't really call that broken. And it doesn't need a firmware. Aurelien, the device you're using is around 2 years old. You're one of the lucky ones, I have tonns of support mails in my mail account from people who own almost a similar device but with different videodecoders which are not fully supported in the kernel or which worked and got broken during the time. It took me around 4 hours to debug such an issue last years remotly with an enduser (which includes that noone cared to ask me if I'm fine with such an update, neither did someone ask people who own such devices that they should test the changes). Please also take other devices and upcoming devices into account, since i'm willing to spend that time and since I'm in contact with various companies who provide several components of those devices. Please think that a lot of persons do not have enough knowledge to compile out of tree drivers, and that a lot more do not even know about this out of tree driver. this is what all is about, the project does not depend on certain broken drivers anymore. And people who initially disagreed without having any solution nor contributed any code can continue to play their game without having an impact on that driver anymore. Markus markus, its the same old story you are telling over and over again. of course there might be a huge community builded up the last month @ mcentral, of course your driver supports newer devices, BUT the same old story is - and you always miss that part we discussed a lot on your changes and also ACCEPTED those for merging, if you would have changed your UNNECCESSARY touching of dvb-core. its proven that things could work without that nacked change to dvb core. but, you decided to stop discussion then, and went away to perform your own tree/userspace thing. as linus and andrew stated within this thread they think they will not merge your code like it is cause of different reasons, i am wondering a bit whats your next step is. I didn't read a clean statement about it. If so I won't continue to pull out opensource drivers from that company. Marcel, you haven't been and you are not into that topic otherwise you'd write about missing parts and address codeparts which I have mentioned in the past which are not ok in the kernel and how to solve that best. saving my time instead of commenting your code does not mean i am not into it. as far as i remember i did say, that the api mixup within dvb-core is NOT wanted and there are solutions for other devices, that show it can be done otherwise. i must admit it would be a different way but the only answer you said was No, i wont do that please go back through the irc logs on linuxtv.org and find the appropiate place. I remember the mail [1] where you (and Michael) tried to point me to something that doesn't work out. Please get into the whole topic which includes studying the requirements and what parts I'm complaining about. as you may remember, i also offered you to ack a MERGE AS IS base for your code in a private conversation on irc. I didn't see that. the main topics in there have been: merge your stuff wait for multiproto applied (as i still think it is a better solution) rework your stuff to work with multiproto your answer was afair i will not allow anyone to modify my code after a merge I would like to see where I wrote that. I remember that I stated out merge it as it is and modify it afterwards because then you have to take care about the requirements which are implemented and which some are not aware of. (There are also heavy discussions about that ... think we shouldn't rediscuss it and if someone wants to rediscuss it please put together a wikisite about the discussions since it makes no sense to get over it again). that showed me, others did recognise meanwhile too, that you are NOT able to discuss different things or opinions for real, but you take your proposals as the one and only. this can not work, and will not work. I am although I won't drop parts of my code in favour of someone who has different ideas which are not even more complete or don't add some extra value to it. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
Markus Rechberger a écrit : On 10/11/07, Aurelien Jarno [EMAIL PROTECTED] wrote: Markus Rechberger a écrit : On 10/11/07, Linus Torvalds [EMAIL PROTECTED] wrote: As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side I have a device which works perfectly with it if you add the vendor and product ID to the list. I don't really call that broken. And it doesn't need a firmware. Aurelien, the device you're using is around 2 years old. You're one of the lucky ones, I have tonns of support mails in my mail account from people who own almost a similar device but with different videodecoders which are not fully supported in the kernel or which worked and got broken during the time. It took me around 4 hours to debug such an issue last years remotly with an enduser (which includes that noone cared to ask me if I'm fine with such an update, neither did someone ask people who own such devices that they should test the changes). Please also take other devices and upcoming devices into account, since i'm willing to spend that time and since I'm in contact with various companies who provide several components of those devices. I agree I am lucky, but the fact is that the in-kernel driver supports *some* devices, and *works* correctly for them. On the other side, your driver supports more devices, but it is and *out-of-tree* driver. Please either work to get your change merged, or stop complaining about changes done to the in-kernel driver. Moreover if you get a closer look at v4l-dvb git, you will see that the changes proposed by Mauro are not em28xx specific, and is actually the same change done on a lot of of v4l/dvb drivers. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 11 Oct 2007 07:09:47 +0200 "Markus Rechberger" > <[EMAIL PROTECTED]> wrote: > > > On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Thu, 11 Oct 2007 01:00:39 +0200 > > > "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > > > > > > Please don't send 900 line emails to which you have added only an > additional > > > paragraph. > > > > > > > > drivers/media/video/em28xx/em28xx-core.c |1 - > > > > > drivers/media/video/em28xx/em28xx-input.c |1 - > > > > > drivers/media/video/em28xx/em28xx-video.c |6 +- > > > > > > > > not accepted > > > > > > Until your attempt to get the userspace-driver work merged into the > kernel > > > is successful (and from my reading of last month's discussion it is > nowhere > > > near that), we should continue to maintain the present driver. > > > > > > If you choose to not participate in that maintenance then others will > need > > > to do their best in this regard. > > > > > > What we should not and will not do is to permit the current driver to be > > > held hostage to your attempt to force a controversial and apparently > > > unwelcome change into the tree. > > > > > > > It makes no sense to keep the kernel driver uptodate, > > It makes heaps of sense to keep the in-tree driver up to date if the > out-of-tree driver is unmergeable, which appears to be the case. > what is unmergeable? > > it would make > > more sense to support the latest driver (which some people are > > supporting). > > But that ignores all of last month's discussion and the various > reservations which various people have expressed. > There were discussions since the beginning of 2006 which lead nowhere. It finally turned out to be a personal issue between developers and to stop those useless discussions and to not having to rely on an incomplete API and not having to strip off the sample drivers the alternative way was developed. > Please take my advise, based upon my experience in kernel development: I > don't expect that we'll be merging the mcentral.de driver in anything like > its present form. > > So we must continue to maintain and evolve the kernel.org driver. > > > I just had a look at the driver downloads it makes around 600 > > downloads for september for this driver. If someone's interested in > > those stats I can give access to it privatly. > > The current option for people who own such a device is to take the > > driver from mcentral.de. > > Well that's a shame. But we have n,000 drivers in-tree which work OK > without doing unusual and disturbing user/kernel splits. > ahm, there are more problems than you might think about... * broken drivers (eg saa7115, incomplete driver tvp5150) * limited API which is managed by a few (DVB/V4L) * having to deal with people who disagree alot I submitted the patches RFCs and didn't get proper comments back then this doesn't motivate me in any way to continue the work and spend any efforts in getting companies to release their sample drivers. As pointed out it's possible to release the complete driver in userland even as binary driver if someone wants to, unless someone kicks out usbfs. But the conversion would take a while. And regarding the plans of the other drivers I pointed out what my plans are. 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Thu, 11 Oct 2007 07:09:47 +0200 "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Thu, 11 Oct 2007 01:00:39 +0200 > > "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > > > > Please don't send 900 line emails to which you have added only an additional > > paragraph. > > > > > > drivers/media/video/em28xx/em28xx-core.c |1 - > > > > drivers/media/video/em28xx/em28xx-input.c |1 - > > > > drivers/media/video/em28xx/em28xx-video.c |6 +- > > > > > > not accepted > > > > Until your attempt to get the userspace-driver work merged into the kernel > > is successful (and from my reading of last month's discussion it is nowhere > > near that), we should continue to maintain the present driver. > > > > If you choose to not participate in that maintenance then others will need > > to do their best in this regard. > > > > What we should not and will not do is to permit the current driver to be > > held hostage to your attempt to force a controversial and apparently > > unwelcome change into the tree. > > > > It makes no sense to keep the kernel driver uptodate, It makes heaps of sense to keep the in-tree driver up to date if the out-of-tree driver is unmergeable, which appears to be the case. > it would make > more sense to support the latest driver (which some people are > supporting). But that ignores all of last month's discussion and the various reservations which various people have expressed. Please take my advise, based upon my experience in kernel development: I don't expect that we'll be merging the mcentral.de driver in anything like its present form. So we must continue to maintain and evolve the kernel.org driver. > I just had a look at the driver downloads it makes around 600 > downloads for september for this driver. If someone's interested in > those stats I can give access to it privatly. > The current option for people who own such a device is to take the > driver from mcentral.de. Well that's a shame. But we have n,000 drivers in-tree which work OK without doing unusual and disturbing user/kernel splits. - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 11 Oct 2007 01:00:39 +0200 > "Markus Rechberger" <[EMAIL PROTECTED]> wrote: > > Please don't send 900 line emails to which you have added only an additional > paragraph. > > > > drivers/media/video/em28xx/em28xx-core.c |1 - > > > drivers/media/video/em28xx/em28xx-input.c |1 - > > > drivers/media/video/em28xx/em28xx-video.c |6 +- > > > > not accepted > > Until your attempt to get the userspace-driver work merged into the kernel > is successful (and from my reading of last month's discussion it is nowhere > near that), we should continue to maintain the present driver. > > If you choose to not participate in that maintenance then others will need > to do their best in this regard. > > What we should not and will not do is to permit the current driver to be > held hostage to your attempt to force a controversial and apparently > unwelcome change into the tree. > It makes no sense to keep the kernel driver uptodate, it would make more sense to support the latest driver (which some people are supporting). I just had a look at the driver downloads it makes around 600 downloads for september for this driver. If someone's interested in those stats I can give access to it privatly. The current option for people who own such a device is to take the driver from mcentral.de. 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote: > On 10/10/2007 07:24 PM, Markus Rechberger wrote: > > > > To point to more changes within the available driver which hasn't been > merged > > within the last 1 1/2 years: > > * it supports non usbaudio based video devices. > > * has support for dvb-t/atsc > > * allows multiple device node access in case of analogue TV > > * has teletext/VBI support for PAL. > > * it supports modules which are now in userspace instead of > > kernelspace due disagreements with some developers for 1 1/2 years. > > * I do not agree with certain developers who do not have any experience > > with certain parts of the code for redoing it a 4th time now. My patience > > is over, which includes the company support in my back to get those > > devices supported. > > > > Do you plan on maintaining your own private driver tree for all of eternity? > I plan to tidy it up for inclusion and put everything together to get it work properly. The code which is in the kernel is around 5 % done, the code which is available on mcentral.de is around 50% done. It still requires some work to get _all_ devices supported, and keeping the development process in an endless loop and depending on people who have no idea and don't care about certain requirements is no option. The upcoming devices which use other chips and which have more features will at least also use those drivers. I expect that it will pump up the driver to support more than 100 devices within the next year. 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Thu, 11 Oct 2007, Markus Rechberger wrote: > > > > the chances of the em28xx are not accepted from my side since the latest > code > > which supports way more hardware is offtree for various reasons. > > Well, I've talked to various people, and none of the main kernel people > end up being at all interested in a kernel that has external dependencies > on binary blobs for tuners. > the drivers are all opensource and the code is available. > So right now it seems like while I would personally want to have more > vendors supprt their own drivers, if that in this case means that we'd > have to have user-space and unmaintainable binaries to tune the cards, > everybody seems to hate that idea. > For me the reason is that some drivers in the kernel which that driver depends on are broken now. Those drivers got broken by several people who disagree with me. My conclusion after providing patches to fix those things is that I won't run after those people anymore. I'm not going to have further discussions with those people about it since there are enough other outstanding things to do with that driver. After 1 1/2 years I'm just fed up with it now and I want to continue to improve the driver. > As such, the old and decrepit em28xx driver seems more useful to people, > since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side it requires a firmware from userspace too so I don't think it matters at all if the algorithm is done in kernelspace or userspace since it depends on such a blob (and I cannot get the source for that firmware, if someone's interested in that he has to disassemble the firmware). 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Thu, 11 Oct 2007, Markus Rechberger wrote: > > the chances of the em28xx are not accepted from my side since the latest code > which supports way more hardware is offtree for various reasons. Well, I've talked to various people, and none of the main kernel people end up being at all interested in a kernel that has external dependencies on binary blobs for tuners. So right now it seems like while I would personally want to have more vendors supprt their own drivers, if that in this case means that we'd have to have user-space and unmaintainable binaries to tune the cards, everybody seems to hate that idea. As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. Linus - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Thu, 11 Oct 2007 01:00:39 +0200 "Markus Rechberger" <[EMAIL PROTECTED]> wrote: Please don't send 900 line emails to which you have added only an additional paragraph. > > drivers/media/video/em28xx/em28xx-core.c |1 - > > drivers/media/video/em28xx/em28xx-input.c |1 - > > drivers/media/video/em28xx/em28xx-video.c |6 +- > > not accepted Until your attempt to get the userspace-driver work merged into the kernel is successful (and from my reading of last month's discussion it is nowhere near that), we should continue to maintain the present driver. If you choose to not participate in that maintenance then others will need to do their best in this regard. What we should not and will not do is to permit the current driver to be held hostage to your attempt to force a controversial and apparently unwelcome change into the tree. - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/10/2007 07:24 PM, Markus Rechberger wrote: > > To point to more changes within the available driver which hasn't been merged > within the last 1 1/2 years: > * it supports non usbaudio based video devices. > * has support for dvb-t/atsc > * allows multiple device node access in case of analogue TV > * has teletext/VBI support for PAL. > * it supports modules which are now in userspace instead of > kernelspace due disagreements with some developers for 1 1/2 years. > * I do not agree with certain developers who do not have any experience > with certain parts of the code for redoing it a 4th time now. My patience > is over, which includes the company support in my back to get those > devices supported. > Do you plan on maintaining your own private driver tree for all of eternity? - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 10/10/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > Linus, > > > > Please pull from: > > > ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git > > master > > > > We have 300+ patches this time, covering lots of drivers improvements and > > fixes. > > > > Also, there are several core changes: > > - Unified support for Hybrid tuners on both V4L and DVB core; > > - videobuf split into PCI DMA S/G specific and a generic module; > > - added a videobuf handler for drivers that need vmalloc'ed memory like > > USB devices). > > > > And some driver additions: > > - cx23885 driver; > > - ivtv framebuffer driver; > > - tcm825x driver. > > > > I still have two cx88-alsa patches pending, at devel tree. Those two are > > dependent from -ALSA merge. So, I should send you a pull request later, > > after > > being sure that you've already pulled from alsa. > > > > Cheers, > > Mauro. > > > > --- > > > > Documentation/dvb/faq.txt |2 +- > > Documentation/video4linux/CARDLIST.bttv|1 + > > Documentation/video4linux/CARDLIST.cx23885 |5 + > > Documentation/video4linux/CARDLIST.saa7134 |5 +- > > drivers/media/Kconfig | 70 +- > > drivers/media/common/Kconfig |2 +- > > drivers/media/common/ir-functions.c|1 - > > drivers/media/common/ir-keymaps.c | 62 +- > > drivers/media/common/saa7146_core.c| 34 +- > > drivers/media/common/saa7146_fops.c|5 +- > > drivers/media/common/saa7146_i2c.c | 23 +- > > drivers/media/common/saa7146_vbi.c |9 +- > > drivers/media/common/saa7146_video.c | 11 +- > > drivers/media/dvb/bt8xx/bt878.c|1 - > > drivers/media/dvb/bt8xx/bt878.h|7 +- > > drivers/media/dvb/bt8xx/dvb-bt8xx.c|1 - > > drivers/media/dvb/cinergyT2/cinergyT2.c|8 +- > > drivers/media/dvb/dvb-core/dmxdev.c|1 - > > drivers/media/dvb/dvb-core/dvb_ca_en50221.c| 93 +- > > drivers/media/dvb/dvb-core/dvb_demux.c |5 +- > > drivers/media/dvb/dvb-core/dvb_frontend.c | 125 ++- > > drivers/media/dvb/dvb-core/dvb_frontend.h | 13 +- > > drivers/media/dvb/dvb-core/dvb_net.c | 22 +- > > drivers/media/dvb/dvb-core/dvbdev.c| 41 +- > > drivers/media/dvb/dvb-usb/Kconfig |2 + > > drivers/media/dvb/dvb-usb/dib0700.h|5 +- > > drivers/media/dvb/dvb-usb/dib0700_core.c | 23 +- > > drivers/media/dvb/dvb-usb/dib0700_devices.c| 676 +- > > drivers/media/dvb/dvb-usb/dtt200u.c| 28 +- > > drivers/media/dvb/dvb-usb/dvb-usb-ids.h| 26 +- > > drivers/media/dvb/dvb-usb/dvb-usb-init.c |2 +- > > drivers/media/dvb/dvb-usb/gp8psk-fe.c | 84 +- > > drivers/media/dvb/dvb-usb/gp8psk.c | 93 +- > > drivers/media/dvb/dvb-usb/gp8psk.h | 32 +- > > drivers/media/dvb/dvb-usb/vp7045.c |2 +- > > drivers/media/dvb/frontends/Kconfig| 33 +- > > drivers/media/dvb/frontends/Makefile |4 + > > drivers/media/dvb/frontends/bcm3510.c |1 - > > drivers/media/dvb/frontends/cx22700.c |1 - > > drivers/media/dvb/frontends/cx24110.c |1 - > > drivers/media/dvb/frontends/cx24123.c |1 - > > drivers/media/dvb/frontends/dib0070.c | 580 > > drivers/media/dvb/frontends/dib0070.h | 44 + > > drivers/media/dvb/frontends/dib3000mb.c|1 - > > drivers/media/dvb/frontends/dib3000mc.c| 192 ++- > > drivers/media/dvb/frontends/dib7000m.c | 727 ++ > > drivers/media/dvb/frontends/dib7000p.c | 908 > > drivers/media/dvb/frontends/dib7000p.h | 14 +- > > drivers/media/dvb/frontends/dibx000_common.h | 57 +- > > drivers/media/dvb/frontends/dvb-pll.c | 147 ++- > > drivers/media/dvb/frontends/dvb_dummy_fe.c |1 - > > drivers/media/dvb/frontends/isl6421.c |1 - > > drivers/media/dvb/frontends/l64781.c |1 - > > drivers/media/dvb/frontends/lgdt330x.c |1 - > > drivers/media/dvb/frontends/lnbp21.c |1 - > > drivers/media/dvb/frontends/mt2060.c |1 - > > drivers/media/dvb/frontends/mt2131.c | 314 > > drivers/media/dvb/frontends/mt2131.h | 54 + > > drivers/media/dvb/frontends/mt2131_priv.h | 49 + > > drivers/media/dvb/frontends/mt2266.c | 287 > >
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/10/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > Linus, > > Please pull from: > ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git > master > > We have 300+ patches this time, covering lots of drivers improvements and > fixes. > > Also, there are several core changes: > - Unified support for Hybrid tuners on both V4L and DVB core; > - videobuf split into PCI DMA S/G specific and a generic module; > - added a videobuf handler for drivers that need vmalloc'ed memory like > USB devices). > > And some driver additions: > - cx23885 driver; > - ivtv framebuffer driver; > - tcm825x driver. > > I still have two cx88-alsa patches pending, at devel tree. Those two are > dependent from -ALSA merge. So, I should send you a pull request later, > after > being sure that you've already pulled from alsa. > > Cheers, > Mauro. > > --- > > Documentation/dvb/faq.txt |2 +- > Documentation/video4linux/CARDLIST.bttv|1 + > Documentation/video4linux/CARDLIST.cx23885 |5 + > Documentation/video4linux/CARDLIST.saa7134 |5 +- > drivers/media/Kconfig | 70 +- > drivers/media/common/Kconfig |2 +- > drivers/media/common/ir-functions.c|1 - > drivers/media/common/ir-keymaps.c | 62 +- > drivers/media/common/saa7146_core.c| 34 +- > drivers/media/common/saa7146_fops.c|5 +- > drivers/media/common/saa7146_i2c.c | 23 +- > drivers/media/common/saa7146_vbi.c |9 +- > drivers/media/common/saa7146_video.c | 11 +- > drivers/media/dvb/bt8xx/bt878.c|1 - > drivers/media/dvb/bt8xx/bt878.h|7 +- > drivers/media/dvb/bt8xx/dvb-bt8xx.c|1 - > drivers/media/dvb/cinergyT2/cinergyT2.c|8 +- > drivers/media/dvb/dvb-core/dmxdev.c|1 - > drivers/media/dvb/dvb-core/dvb_ca_en50221.c| 93 +- > drivers/media/dvb/dvb-core/dvb_demux.c |5 +- > drivers/media/dvb/dvb-core/dvb_frontend.c | 125 ++- > drivers/media/dvb/dvb-core/dvb_frontend.h | 13 +- > drivers/media/dvb/dvb-core/dvb_net.c | 22 +- > drivers/media/dvb/dvb-core/dvbdev.c| 41 +- > drivers/media/dvb/dvb-usb/Kconfig |2 + > drivers/media/dvb/dvb-usb/dib0700.h|5 +- > drivers/media/dvb/dvb-usb/dib0700_core.c | 23 +- > drivers/media/dvb/dvb-usb/dib0700_devices.c| 676 +- > drivers/media/dvb/dvb-usb/dtt200u.c| 28 +- > drivers/media/dvb/dvb-usb/dvb-usb-ids.h| 26 +- > drivers/media/dvb/dvb-usb/dvb-usb-init.c |2 +- > drivers/media/dvb/dvb-usb/gp8psk-fe.c | 84 +- > drivers/media/dvb/dvb-usb/gp8psk.c | 93 +- > drivers/media/dvb/dvb-usb/gp8psk.h | 32 +- > drivers/media/dvb/dvb-usb/vp7045.c |2 +- > drivers/media/dvb/frontends/Kconfig| 33 +- > drivers/media/dvb/frontends/Makefile |4 + > drivers/media/dvb/frontends/bcm3510.c |1 - > drivers/media/dvb/frontends/cx22700.c |1 - > drivers/media/dvb/frontends/cx24110.c |1 - > drivers/media/dvb/frontends/cx24123.c |1 - > drivers/media/dvb/frontends/dib0070.c | 580 > drivers/media/dvb/frontends/dib0070.h | 44 + > drivers/media/dvb/frontends/dib3000mb.c|1 - > drivers/media/dvb/frontends/dib3000mc.c| 192 ++- > drivers/media/dvb/frontends/dib7000m.c | 727 ++ > drivers/media/dvb/frontends/dib7000p.c | 908 > drivers/media/dvb/frontends/dib7000p.h | 14 +- > drivers/media/dvb/frontends/dibx000_common.h | 57 +- > drivers/media/dvb/frontends/dvb-pll.c | 147 ++- > drivers/media/dvb/frontends/dvb_dummy_fe.c |1 - > drivers/media/dvb/frontends/isl6421.c |1 - > drivers/media/dvb/frontends/l64781.c |1 - > drivers/media/dvb/frontends/lgdt330x.c |1 - > drivers/media/dvb/frontends/lnbp21.c |1 - > drivers/media/dvb/frontends/mt2060.c |1 - > drivers/media/dvb/frontends/mt2131.c | 314 > drivers/media/dvb/frontends/mt2131.h | 54 + > drivers/media/dvb/frontends/mt2131_priv.h | 49 + > drivers/media/dvb/frontends/mt2266.c | 287 > drivers/media/dvb/frontends/mt2266.h | 37 + > drivers/media/dvb/frontends/mt312.c|1 - > drivers/media/dvb/frontends/mt352.c|1 - >
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/10/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git master We have 300+ patches this time, covering lots of drivers improvements and fixes. Also, there are several core changes: - Unified support for Hybrid tuners on both V4L and DVB core; - videobuf split into PCI DMA S/G specific and a generic module; - added a videobuf handler for drivers that need vmalloc'ed memory like USB devices). And some driver additions: - cx23885 driver; - ivtv framebuffer driver; - tcm825x driver. I still have two cx88-alsa patches pending, at devel tree. Those two are dependent from -ALSA merge. So, I should send you a pull request later, after being sure that you've already pulled from alsa. Cheers, Mauro. --- Documentation/dvb/faq.txt |2 +- Documentation/video4linux/CARDLIST.bttv|1 + Documentation/video4linux/CARDLIST.cx23885 |5 + Documentation/video4linux/CARDLIST.saa7134 |5 +- drivers/media/Kconfig | 70 +- drivers/media/common/Kconfig |2 +- drivers/media/common/ir-functions.c|1 - drivers/media/common/ir-keymaps.c | 62 +- drivers/media/common/saa7146_core.c| 34 +- drivers/media/common/saa7146_fops.c|5 +- drivers/media/common/saa7146_i2c.c | 23 +- drivers/media/common/saa7146_vbi.c |9 +- drivers/media/common/saa7146_video.c | 11 +- drivers/media/dvb/bt8xx/bt878.c|1 - drivers/media/dvb/bt8xx/bt878.h|7 +- drivers/media/dvb/bt8xx/dvb-bt8xx.c|1 - drivers/media/dvb/cinergyT2/cinergyT2.c|8 +- drivers/media/dvb/dvb-core/dmxdev.c|1 - drivers/media/dvb/dvb-core/dvb_ca_en50221.c| 93 +- drivers/media/dvb/dvb-core/dvb_demux.c |5 +- drivers/media/dvb/dvb-core/dvb_frontend.c | 125 ++- drivers/media/dvb/dvb-core/dvb_frontend.h | 13 +- drivers/media/dvb/dvb-core/dvb_net.c | 22 +- drivers/media/dvb/dvb-core/dvbdev.c| 41 +- drivers/media/dvb/dvb-usb/Kconfig |2 + drivers/media/dvb/dvb-usb/dib0700.h|5 +- drivers/media/dvb/dvb-usb/dib0700_core.c | 23 +- drivers/media/dvb/dvb-usb/dib0700_devices.c| 676 +- drivers/media/dvb/dvb-usb/dtt200u.c| 28 +- drivers/media/dvb/dvb-usb/dvb-usb-ids.h| 26 +- drivers/media/dvb/dvb-usb/dvb-usb-init.c |2 +- drivers/media/dvb/dvb-usb/gp8psk-fe.c | 84 +- drivers/media/dvb/dvb-usb/gp8psk.c | 93 +- drivers/media/dvb/dvb-usb/gp8psk.h | 32 +- drivers/media/dvb/dvb-usb/vp7045.c |2 +- drivers/media/dvb/frontends/Kconfig| 33 +- drivers/media/dvb/frontends/Makefile |4 + drivers/media/dvb/frontends/bcm3510.c |1 - drivers/media/dvb/frontends/cx22700.c |1 - drivers/media/dvb/frontends/cx24110.c |1 - drivers/media/dvb/frontends/cx24123.c |1 - drivers/media/dvb/frontends/dib0070.c | 580 drivers/media/dvb/frontends/dib0070.h | 44 + drivers/media/dvb/frontends/dib3000mb.c|1 - drivers/media/dvb/frontends/dib3000mc.c| 192 ++- drivers/media/dvb/frontends/dib7000m.c | 727 ++ drivers/media/dvb/frontends/dib7000p.c | 908 drivers/media/dvb/frontends/dib7000p.h | 14 +- drivers/media/dvb/frontends/dibx000_common.h | 57 +- drivers/media/dvb/frontends/dvb-pll.c | 147 ++- drivers/media/dvb/frontends/dvb_dummy_fe.c |1 - drivers/media/dvb/frontends/isl6421.c |1 - drivers/media/dvb/frontends/l64781.c |1 - drivers/media/dvb/frontends/lgdt330x.c |1 - drivers/media/dvb/frontends/lnbp21.c |1 - drivers/media/dvb/frontends/mt2060.c |1 - drivers/media/dvb/frontends/mt2131.c | 314 drivers/media/dvb/frontends/mt2131.h | 54 + drivers/media/dvb/frontends/mt2131_priv.h | 49 + drivers/media/dvb/frontends/mt2266.c | 287 drivers/media/dvb/frontends/mt2266.h | 37 + drivers/media/dvb/frontends/mt312.c|1 - drivers/media/dvb/frontends/mt352.c|1 - drivers/media/dvb/frontends/nxt200x.c |1 - drivers/media/dvb/frontends/or51132.c |1 -
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/10/2007 07:24 PM, Markus Rechberger wrote: To point to more changes within the available driver which hasn't been merged within the last 1 1/2 years: * it supports non usbaudio based video devices. * has support for dvb-t/atsc * allows multiple device node access in case of analogue TV * has teletext/VBI support for PAL. * it supports modules which are now in userspace instead of kernelspace due disagreements with some developers for 1 1/2 years. * I do not agree with certain developers who do not have any experience with certain parts of the code for redoing it a 4th time now. My patience is over, which includes the company support in my back to get those devices supported. Do you plan on maintaining your own private driver tree for all of eternity? - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Thu, 11 Oct 2007 01:00:39 +0200 Markus Rechberger [EMAIL PROTECTED] wrote: Please don't send 900 line emails to which you have added only an additional paragraph. drivers/media/video/em28xx/em28xx-core.c |1 - drivers/media/video/em28xx/em28xx-input.c |1 - drivers/media/video/em28xx/em28xx-video.c |6 +- not accepted Until your attempt to get the userspace-driver work merged into the kernel is successful (and from my reading of last month's discussion it is nowhere near that), we should continue to maintain the present driver. If you choose to not participate in that maintenance then others will need to do their best in this regard. What we should not and will not do is to permit the current driver to be held hostage to your attempt to force a controversial and apparently unwelcome change into the tree. - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Thu, 11 Oct 2007, Markus Rechberger wrote: the chances of the em28xx are not accepted from my side since the latest code which supports way more hardware is offtree for various reasons. Well, I've talked to various people, and none of the main kernel people end up being at all interested in a kernel that has external dependencies on binary blobs for tuners. So right now it seems like while I would personally want to have more vendors supprt their own drivers, if that in this case means that we'd have to have user-space and unmaintainable binaries to tune the cards, everybody seems to hate that idea. As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. Linus - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Markus Rechberger [EMAIL PROTECTED] wrote: On 10/10/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git master We have 300+ patches this time, covering lots of drivers improvements and fixes. Also, there are several core changes: - Unified support for Hybrid tuners on both V4L and DVB core; - videobuf split into PCI DMA S/G specific and a generic module; - added a videobuf handler for drivers that need vmalloc'ed memory like USB devices). And some driver additions: - cx23885 driver; - ivtv framebuffer driver; - tcm825x driver. I still have two cx88-alsa patches pending, at devel tree. Those two are dependent from -ALSA merge. So, I should send you a pull request later, after being sure that you've already pulled from alsa. Cheers, Mauro. --- Documentation/dvb/faq.txt |2 +- Documentation/video4linux/CARDLIST.bttv|1 + Documentation/video4linux/CARDLIST.cx23885 |5 + Documentation/video4linux/CARDLIST.saa7134 |5 +- drivers/media/Kconfig | 70 +- drivers/media/common/Kconfig |2 +- drivers/media/common/ir-functions.c|1 - drivers/media/common/ir-keymaps.c | 62 +- drivers/media/common/saa7146_core.c| 34 +- drivers/media/common/saa7146_fops.c|5 +- drivers/media/common/saa7146_i2c.c | 23 +- drivers/media/common/saa7146_vbi.c |9 +- drivers/media/common/saa7146_video.c | 11 +- drivers/media/dvb/bt8xx/bt878.c|1 - drivers/media/dvb/bt8xx/bt878.h|7 +- drivers/media/dvb/bt8xx/dvb-bt8xx.c|1 - drivers/media/dvb/cinergyT2/cinergyT2.c|8 +- drivers/media/dvb/dvb-core/dmxdev.c|1 - drivers/media/dvb/dvb-core/dvb_ca_en50221.c| 93 +- drivers/media/dvb/dvb-core/dvb_demux.c |5 +- drivers/media/dvb/dvb-core/dvb_frontend.c | 125 ++- drivers/media/dvb/dvb-core/dvb_frontend.h | 13 +- drivers/media/dvb/dvb-core/dvb_net.c | 22 +- drivers/media/dvb/dvb-core/dvbdev.c| 41 +- drivers/media/dvb/dvb-usb/Kconfig |2 + drivers/media/dvb/dvb-usb/dib0700.h|5 +- drivers/media/dvb/dvb-usb/dib0700_core.c | 23 +- drivers/media/dvb/dvb-usb/dib0700_devices.c| 676 +- drivers/media/dvb/dvb-usb/dtt200u.c| 28 +- drivers/media/dvb/dvb-usb/dvb-usb-ids.h| 26 +- drivers/media/dvb/dvb-usb/dvb-usb-init.c |2 +- drivers/media/dvb/dvb-usb/gp8psk-fe.c | 84 +- drivers/media/dvb/dvb-usb/gp8psk.c | 93 +- drivers/media/dvb/dvb-usb/gp8psk.h | 32 +- drivers/media/dvb/dvb-usb/vp7045.c |2 +- drivers/media/dvb/frontends/Kconfig| 33 +- drivers/media/dvb/frontends/Makefile |4 + drivers/media/dvb/frontends/bcm3510.c |1 - drivers/media/dvb/frontends/cx22700.c |1 - drivers/media/dvb/frontends/cx24110.c |1 - drivers/media/dvb/frontends/cx24123.c |1 - drivers/media/dvb/frontends/dib0070.c | 580 drivers/media/dvb/frontends/dib0070.h | 44 + drivers/media/dvb/frontends/dib3000mb.c|1 - drivers/media/dvb/frontends/dib3000mc.c| 192 ++- drivers/media/dvb/frontends/dib7000m.c | 727 ++ drivers/media/dvb/frontends/dib7000p.c | 908 drivers/media/dvb/frontends/dib7000p.h | 14 +- drivers/media/dvb/frontends/dibx000_common.h | 57 +- drivers/media/dvb/frontends/dvb-pll.c | 147 ++- drivers/media/dvb/frontends/dvb_dummy_fe.c |1 - drivers/media/dvb/frontends/isl6421.c |1 - drivers/media/dvb/frontends/l64781.c |1 - drivers/media/dvb/frontends/lgdt330x.c |1 - drivers/media/dvb/frontends/lnbp21.c |1 - drivers/media/dvb/frontends/mt2060.c |1 - drivers/media/dvb/frontends/mt2131.c | 314 drivers/media/dvb/frontends/mt2131.h | 54 + drivers/media/dvb/frontends/mt2131_priv.h | 49 + drivers/media/dvb/frontends/mt2266.c | 287 drivers/media/dvb/frontends/mt2266.h | 37 + drivers/media/dvb/frontends/mt312.c|1 - drivers/media/dvb/frontends/mt352.c|1 -
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Linus Torvalds [EMAIL PROTECTED] wrote: On Thu, 11 Oct 2007, Markus Rechberger wrote: the chances of the em28xx are not accepted from my side since the latest code which supports way more hardware is offtree for various reasons. Well, I've talked to various people, and none of the main kernel people end up being at all interested in a kernel that has external dependencies on binary blobs for tuners. the drivers are all opensource and the code is available. So right now it seems like while I would personally want to have more vendors supprt their own drivers, if that in this case means that we'd have to have user-space and unmaintainable binaries to tune the cards, everybody seems to hate that idea. For me the reason is that some drivers in the kernel which that driver depends on are broken now. Those drivers got broken by several people who disagree with me. My conclusion after providing patches to fix those things is that I won't run after those people anymore. I'm not going to have further discussions with those people about it since there are enough other outstanding things to do with that driver. After 1 1/2 years I'm just fed up with it now and I want to continue to improve the driver. As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side it requires a firmware from userspace too so I don't think it matters at all if the algorithm is done in kernelspace or userspace since it depends on such a blob (and I cannot get the source for that firmware, if someone's interested in that he has to disassemble the firmware). 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Chuck Ebbert [EMAIL PROTECTED] wrote: On 10/10/2007 07:24 PM, Markus Rechberger wrote: To point to more changes within the available driver which hasn't been merged within the last 1 1/2 years: * it supports non usbaudio based video devices. * has support for dvb-t/atsc * allows multiple device node access in case of analogue TV * has teletext/VBI support for PAL. * it supports modules which are now in userspace instead of kernelspace due disagreements with some developers for 1 1/2 years. * I do not agree with certain developers who do not have any experience with certain parts of the code for redoing it a 4th time now. My patience is over, which includes the company support in my back to get those devices supported. Do you plan on maintaining your own private driver tree for all of eternity? I plan to tidy it up for inclusion and put everything together to get it work properly. The code which is in the kernel is around 5 % done, the code which is available on mcentral.de is around 50% done. It still requires some work to get _all_ devices supported, and keeping the development process in an endless loop and depending on people who have no idea and don't care about certain requirements is no option. The upcoming devices which use other chips and which have more features will at least also use those drivers. I expect that it will pump up the driver to support more than 100 devices within the next year. 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 11 Oct 2007 01:00:39 +0200 Markus Rechberger [EMAIL PROTECTED] wrote: Please don't send 900 line emails to which you have added only an additional paragraph. drivers/media/video/em28xx/em28xx-core.c |1 - drivers/media/video/em28xx/em28xx-input.c |1 - drivers/media/video/em28xx/em28xx-video.c |6 +- not accepted Until your attempt to get the userspace-driver work merged into the kernel is successful (and from my reading of last month's discussion it is nowhere near that), we should continue to maintain the present driver. If you choose to not participate in that maintenance then others will need to do their best in this regard. What we should not and will not do is to permit the current driver to be held hostage to your attempt to force a controversial and apparently unwelcome change into the tree. It makes no sense to keep the kernel driver uptodate, it would make more sense to support the latest driver (which some people are supporting). I just had a look at the driver downloads it makes around 600 downloads for september for this driver. If someone's interested in those stats I can give access to it privatly. The current option for people who own such a device is to take the driver from mcentral.de. 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On Thu, 11 Oct 2007 07:09:47 +0200 Markus Rechberger [EMAIL PROTECTED] wrote: On 10/11/07, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 11 Oct 2007 01:00:39 +0200 Markus Rechberger [EMAIL PROTECTED] wrote: Please don't send 900 line emails to which you have added only an additional paragraph. drivers/media/video/em28xx/em28xx-core.c |1 - drivers/media/video/em28xx/em28xx-input.c |1 - drivers/media/video/em28xx/em28xx-video.c |6 +- not accepted Until your attempt to get the userspace-driver work merged into the kernel is successful (and from my reading of last month's discussion it is nowhere near that), we should continue to maintain the present driver. If you choose to not participate in that maintenance then others will need to do their best in this regard. What we should not and will not do is to permit the current driver to be held hostage to your attempt to force a controversial and apparently unwelcome change into the tree. It makes no sense to keep the kernel driver uptodate, It makes heaps of sense to keep the in-tree driver up to date if the out-of-tree driver is unmergeable, which appears to be the case. it would make more sense to support the latest driver (which some people are supporting). But that ignores all of last month's discussion and the various reservations which various people have expressed. Please take my advise, based upon my experience in kernel development: I don't expect that we'll be merging the mcentral.de driver in anything like its present form. So we must continue to maintain and evolve the kernel.org driver. I just had a look at the driver downloads it makes around 600 downloads for september for this driver. If someone's interested in those stats I can give access to it privatly. The current option for people who own such a device is to take the driver from mcentral.de. Well that's a shame. But we have n,000 drivers in-tree which work OK without doing unusual and disturbing user/kernel splits. - 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: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24
On 10/11/07, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 11 Oct 2007 07:09:47 +0200 Markus Rechberger [EMAIL PROTECTED] wrote: On 10/11/07, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 11 Oct 2007 01:00:39 +0200 Markus Rechberger [EMAIL PROTECTED] wrote: Please don't send 900 line emails to which you have added only an additional paragraph. drivers/media/video/em28xx/em28xx-core.c |1 - drivers/media/video/em28xx/em28xx-input.c |1 - drivers/media/video/em28xx/em28xx-video.c |6 +- not accepted Until your attempt to get the userspace-driver work merged into the kernel is successful (and from my reading of last month's discussion it is nowhere near that), we should continue to maintain the present driver. If you choose to not participate in that maintenance then others will need to do their best in this regard. What we should not and will not do is to permit the current driver to be held hostage to your attempt to force a controversial and apparently unwelcome change into the tree. It makes no sense to keep the kernel driver uptodate, It makes heaps of sense to keep the in-tree driver up to date if the out-of-tree driver is unmergeable, which appears to be the case. what is unmergeable? it would make more sense to support the latest driver (which some people are supporting). But that ignores all of last month's discussion and the various reservations which various people have expressed. There were discussions since the beginning of 2006 which lead nowhere. It finally turned out to be a personal issue between developers and to stop those useless discussions and to not having to rely on an incomplete API and not having to strip off the sample drivers the alternative way was developed. Please take my advise, based upon my experience in kernel development: I don't expect that we'll be merging the mcentral.de driver in anything like its present form. So we must continue to maintain and evolve the kernel.org driver. I just had a look at the driver downloads it makes around 600 downloads for september for this driver. If someone's interested in those stats I can give access to it privatly. The current option for people who own such a device is to take the driver from mcentral.de. Well that's a shame. But we have n,000 drivers in-tree which work OK without doing unusual and disturbing user/kernel splits. ahm, there are more problems than you might think about... * broken drivers (eg saa7115, incomplete driver tvp5150) * limited API which is managed by a few (DVB/V4L) * having to deal with people who disagree alot I submitted the patches RFCs and didn't get proper comments back then this doesn't motivate me in any way to continue the work and spend any efforts in getting companies to release their sample drivers. As pointed out it's possible to release the complete driver in userland even as binary driver if someone wants to, unless someone kicks out usbfs. But the conversion would take a while. And regarding the plans of the other drivers I pointed out what my plans are. 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/
