Am Samstag, den 06.02.2010, 00:39 +0100 schrieb Chicken Shack: > Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton: > > Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack: > > > Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab: > > > > Andreas Oberritter wrote: > > > > > Andy Walls wrote: > > > > > > > > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by > > > > >>> software running on Dream Multimedia set top boxes. > > > > >> Right, so reverting the patch is not an option. > > > > >> > > > > >> It also makes implementing multiple dvr0.n nodes for a demux0 device > > > > >> node probably a waste of time at this point. > > > > > > > > > > I think so, too. But I guess it's always worth discussing alternatives. > > > > > > > > If this discussion happened before 2.6.32 release, and provided that a different > > > > implementation were agreed, things would be easier, as a different solution like > > > > your proposal could be decided and used. > > > > > > > > > You cannot expect people reacting immediately if something is wrong. > > > There are and do exist enormous delays between publishing a new kernel > > > and the decision to use it after appropriate system or distro update. > > > So your expectation level is simply wrong. > > > > > > > > > > Now, we have already a regression on a stable kernel, and solving it by > > > > creating another regression is not something smart to do. > > > > > > > > > Yes. Trivial! > > > > > > > > > > >From what I understood, the regression appeared on an old, orphan > > > > application with a non-official patch applied on it. Other applications with > > > > similar features weren't affected. On the other hand, if the patch got reverted, > > > > we'll break a maintained application that is used on a great number of devices, > > > > and whose features depend on the new ioctls. > > > > > > > > > It's truly amazing how the filter system of your perception works, isn't > > > it? :) > > > > > > It's not just "an old, orphaned application with a non-official patch on > > > it." That's nonsense! > > > > > > a. As I stated already, there do exist several patched versions of > > > alevt-dvb. For instance the one that Herman Pitton tested here in public > > > causes a closed demux device error on my machine. That means that it > > > does not run because xine-ui is already using the demux device. > > > And this phenomenon has got nothing to do with the kernel headers! > > > I've tried all possibilities (old kernel headers and actual ones) so I > > > know better than Hermann Pitton does! > > > > > > And my version (and obviously the ones of Thomas Voegtle and Emil Meier > > > whom I helped with my tip to revert that patch) cause a kernel crash > > > with the actual kernel. > > > > > > b. As I also stated already the other teletext application called mtt > > > does officially not exist except for Novell / OpenSuSe distros (at least > > > as far as I have seen and found out). And this one > > > is, as I also stated, not affected by the kernel patch. It's part of a > > > discontinued program suite called xawtv-4.0 pre with a very complex > > > infrastructure behind. > > > > > > Please do not ask me why this one runs without noise - I do not know. > > > > > > So AFAICS alevt-dvb is the ONLY teletext application for Linux which is > > > available in almost all Gnu/Linux distros. > > > > > > "Other applications with similar features weren't affected." > > > > > > >From where do you know that the features are "similar"? > > > > > > This is a 100 % phantasy product of your mind that has got nothing to do > > > with existing reality, man! > > > > > > Just one example: alevt-dvb has got an excellent html export filter > > > which makes it possible to export teletext pages as graphical html > > > files. > > > I do not know any other teletext application offering that. > > > > > > > > > > We are too late in -rc cycle, so probably there's not enough time for > > > > writing, test, validate any new API in time for 2.6.33 and write some compat > > > > layer to emulate those two ioctls with a different implementation. > > > > > > Who says that a new API or an overworked API must be ready for 2.6.33? > > > When do you think the correct starting point must be set? > > > When the merge window for 2.6.34 opens or when? > > > Absurd argument! Not valid at all! > > > > > > > > > > So, removing those two ioctls is not an option anymore. > > > > > > Yes. Conclusion??? None! > > > > > > So if everybody wants to close down this discussion with that output > > > then you must admit (if you want it or not) that you de facto bury > > > teletext usage in the mud for the majority of Gnu/Linux DVB users. > > > > > > So the output is more than badly disappointing. > > > Bye bye Teletext. Nothing for future kernels, huh? > > > > Yes, you say it. It definitely will go away and we do have not any > > influence on that! Did you not notice the very slow update rate these > > days? > > a. NOTHING "will go away". This is empty rant, nothing else it is! > In US teletext is dead, yes. In Europe analogue television is close to > dead. Yes. > But I have found no information source that teletext will disappear in > general. At least not in Europe or Germany. > So if you keep that up then prove the assertion please. In the UK too. And after world war II we always followed BBC. Not that bad ... http://pressetext.com/news/090720037/nutzung-von-teletext-hat-den-zenit-erreicht > What slow update rate please? > What the hell are you talking about, man? Previously information available there was updated within minutes, now in best case every six hours it seems to me. > > > Regards > > > > > > CS > > > > > > P. S.: If you continue like that you make people run away. > > > Instead you better should try to win people, shouldn't you? > > > > > > Just see how many volunteers are here to help and then reflect > > > why that manpower is missing, Mauro! > > > Your gesture being expressed above does a lot, but it is definitely NOT > > > motivating to change that precarious situation. > > > > Then maybe better tell what you tried already, instead leaving others > > behind doing the same in vain again? > > Goddamn! I've investigated a lot, and I have written down everything I > did. > See, even if you are too lazy to read all that go blame yourself for > that lazyness, but not me, OK? My, I see a difficult to identify something of code around, not in any major distribution. One can link to any headers wanted, and scripts seem to be wrapped around too as liked ... > > Mauro always did try to keep backward compat as much as possible and > > others had to tell him better not to waste his time on it. > > > > You hit the wrong guy again and he can't even test anything. > > > All I want him is to immediately and forever stop spreading nonsense and > demotivate people and offer us all that propagandist style that I and > others do not appreciate at all. > > Unfortunately I am missing the American English equivalent for > "Differenziertheit". Is it "straightforwardness"? > > This is what I am missing when you start to express yourself. > > Your "test" of alevt-dvb-t may serve as an example: > > Noone knows your card type, noone knows your reception area, > transponder, channel. All we know from you is a pid. You did report all that? The pid is from ZDF DVB-T from Frankfurt/Main/Feldberg on a saa7134 Medion Quadro, should not matter at all. > And that there are versions of alevt-dvb who are incapable for parallel > tasking due to a wrong DVB patch you simply missed as a matter of fact. > So what the hell did you get at all, man? They really do exist, or only the sripts around? > Very low discussion level, isn't it? > > I'll leave it up to that - don't want no dumb flamings at all. > > Cheers > > CS Peace. Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
