Re: [Mplayerxp-general] Re: VIDIX interface (all attempts in one)

[Nick K. <nic...@ma...>]

Hello, Zdenek!

On Thu, 29 Aug 2002 14:40:19 +0200 you wrote:

[snip]
It seems that all your ideas with interface chaning were born from the fact
that you are going to have copy of VIDIX within of avifile-CVS tree.
Well - I'm ready to implement VIDIX as independed project!
Hope that after this event - it will not matter for you which internal structures
has VIDIX!
Simply because in this case you project will be free from needs of compilation
and installation of VIDIX. And will test VIDIX installation only! Isn't?
> 
> > > The server was good idea - until I've realized there is real danger
> > > with concurently running XServer - for now I don't see any simple
> > > solution except using some simple kernel module for this....
> > > 
> > It seems that you are wrong here:
> > The kernel driver (aka dhahelper) doesn't provide any security for now.
> 
> It's not about security at this moment at all (somehow you always seems add
> something to my sentencies which wasn't there)
> 
> > Thus - implementing of VIDIX server is still actual hob from security reasons.
> > Simply because we can register in vidix server video and mmio memory areas
> > through driver surveys.
> 
> But when you started with security - well as far as I know linux
> kernel developers - they will never accept anything which is as dangerously
> as Vidix - so if you are dreaming about wider acceptance of vidix device
> the security will definitely have to be resolved!
> 
I have no plans to include my drivers in the kernel.
In the Linux-world exists a lots of drivers out of the kernel.
IMO it would be wrong to bloat the Linux with all existed drivers.
(And I don't like to download teens of MB when I download the next version
of linux)
> I guess at least something like access list which would mimic
> /dev  user.group  behaviour would have to be implemented.
> 
It's my default suggestion after installation of the driver.
But in case of hacker's attack on working PLAYER (that has invisible
probability) it would be much difficulty to find out some hole
in VIDIX server than in the whole player.
> > Anyway - please tell me the version of libdl.so which caused
> > memory leaks and which version we need to have to avoid them?
> > And even more - who is able to estimate how many leaks exists
> 
> Hmm any version of glibc I've tried so far leaves some memory leaks
> - they are not huge - it's in the ranger of couple hundered bytes
> but they are leaks...
> 
Did you try the glibc-2.2.5?

> Maybe you should learn to use mpatrol & valgrind...
What is it?
> 
> > > Well I'm always trying to provide hq things - and if something could be
> > > made smaller (i.e. check memory foot print of avifile :)) 
> > > and it doesn't cost much energy I'll usually do that...
> > > 
> > For many ppl it would be much better to have HQ working mga_vid.so instead of
> > not used 10KB on thier 120GB HDD. I know that any program can be descreased
> > at least on 1 byte ;) But I'm not a fun of such things.
> 
> Well you know me - I'm a bit of perfecionist and I'm moving in steps -
> and when I already seen problem even until I've started to use I'd like
> to fix it :)
> 
The using of the word 'FIX' I prefer to relate with the word 'BUG'
but not with SIZE-OPTIMIZATION.
[snip] 
> > > But it's more realistict to support Solaris users then expeting
> > > that any major company will every write vidix driver.
> > Solaris is not a marketplace. It's installed on much less number
> > of computers than any from *bsd, BeOS, ...
> 
> And are you marketing mplayerxp or vidix :) ? 
> I've though you are building it for fun just like me...
> 
First - I'm building mplayerxp for me.
Second - I'm building mplayerxp for everyone who like it.
As said Arpi, mplayerxp is "hobbied" project ;)
But it seems that VIDIX is builded for all players after
my fork and leaving mplayer by Mike Melason.
> 
> > > dynamic driver loading will be still available - and moreover
> > > companies could mangle their function names more efficintly :)
> > > (and they seem to care about this possibility!)
> > > 
> > If you means leading underscore in function names then this problem
> > was solved a long ago.
> 
> No I mean they turn names like - OpenWindow  into XY1234Az
> so you would have harder times to disclose what the function
> actually does when you check it with objdump...
> (Though it's not really a big problem - but you know the
> commercial companies and their 'great' ideas...)
> 
I have no reports that VIDIX is used on such systems.
I won't prepare VIDIX for such systems.
I don't want to have installed all systems of the world on my computer.
But if someone will want to use VIDIX there then I'm sure he
send me patch or will make fork ;)
> > > is below their resolution (i.e. automake in it's latest incarantion
> > > now nearly outtakes the space needed for it's files to the rest of
> > > my project)
> > > 
> > Btw - embedded systems is not a goal fo vidix for now and for immediate future.
> 
> You seem to alway 'transfer' my answers to somewhat unrelated
> position - I do not use embedded systems - but still 3MB isn't
> something I simply ignore...
> 
Where you have found out 3MB?
A full size of mplayerxp distribution is less than 1.44MB for now!
But 10KB of binaries is less than I need to spend my attention!
> > Nobody will do that! The configure script has too many options to keep
> > them in mind of even advanced users so it will be unused feature.
> > But it's not a problem to implement that.
> 
> In the same logic - do you think users will track installed
> files and will remove some of them at their will :)
> Using option for such thing is definitely more natural.
> 
> But the main point is - why they should do that.
> 
Anyway it's not a #1 problem of VIDIX ;)
> > > of losing the picture - I've no idea how this works in ATI -
> > > so these are just mu experiences with MGA...
> > > (also that's why I do not believe that DMA would be ever safe -
> > > as it's being used by XFree - at least for 3d graphics)
> > > 
> > 1 - using of video and 3d things simultaneously is bad thing.
> > (Even GATOS developers always ignore such bugreports)
> 
> Yep - so windows can do that and because Linux programers are
> lazy user could either work in 3d or playe video - 
> so basicaly you are telling me I can't watch video on my
> second head while I'm developing my 3d app right ? :-)
> 
I afraid that when you'll do a several jobs simultaneously
then they will disturb to get the perfect results.
But if you are Julian Cesar - sorry! ;)
Anyway - I have no idea how such behaviour could be implemented with
Matrox HW if it's not reentrant. Such driver will require to be
compiled in the kernel.
> > 2 - I've studied mga bes programming and didn't find there
> > such things at first looking.
> 
> Because it' been disabled and it's probably well masked
> as I don't have the doc at my handes - but when you
> write to certain addresses - (I think like C2DATACLT)
> then some other address expect parameter.
> 
Such behaviour of Matrox's HW requires driver implementation
on kerenl-level only on every OS - simply because it's not
ready for multitasking environments. IMHO there should be
way to avoid that!
> > 3 - VIDIX doesn't use IRQ handling since there was found much
> > better workaround of doublebuffered problems as multibuffering.
> 
> Yep - but it's still very good thing if you are waiting for wakeup
> when you have full buffers and you want to start decoding once
> the buffer is free - usleep isn't the best solution here
> (you are lossing upto 20ms of time you could already use for decoding!)
Since linux doesn't provide any asynchronous events to end-users apps
then only way to avoid that is sleeping within of the thread.
(It seems that threads are mandatory part of any app under Linux ;).
[snip]
> > IMHO - there should be workaround of such programming (simply because
> > the time of singletasking OSes is over)
> 
> Well accessing hardware should be always guarded by OS - it's
> not a problem of HW developers :) 
> 
> It's simply wrong that linux doens't have such thing - it's been
> always problem even with XServer and framebuffer console 
> (as XFree for some unexplainable reason every few second stores
> some values to MGA registers even when you are at console - so
> it's been changing screen depth - the only solution for this
> so far is to use same depth on console as with you XServer -
> try to convice XFree developers to fix this - it's there for 2 years...
> 
Still one reason not to use Xfree86 but VIDIX only ;)
> 
> > But if you really need that - implementing of Enter(Leave)Criticalregion
> > is not a problem but it's not portable solution anyway.
> 
> Well it's not a problem for vidix itself - but how do you plan to
> ensure that XFree or linux kernel want start to write there itself?
> 
It seems that everything what you need - to have working analog of
spin_lock, isn't?
Well - dhahelper will provide its fucntionality through exporting
corresponded function through ioctl!
What about other unices - I dunno what is analog of this function there!
It seems that only Win3.1-Win9x OSes provide possibility to freeze task
switching for end-user program and as I wrote their names are:
Enter(Leave)CriticalRegion
> -- 
>   .''`.    Zdenek Kabelac  kabi@{debian.org, users.sf.net, fi.muni.cz}
>  : :' :          Debian GNU/Linux maintainer - www.debian.{org,cz}
>  `. `'  Modern processors are the most advanced heating systems around.
>    `-                                     www.tomshardware.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mplayerxp-general mailing list
> Mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mplayerxp-general
> 


Best regards! Nick