[MPlayer-dev-eng] [PATCH] vo device for serdisplib controlled gfx displays / display modules (-vo serdisp)
mrwastl at users.sourceforge.net
Wed Apr 25 23:52:23 CEST 2007
>I just had a quick look at the patch but there are some clear issues.
>1. Don't use sws, a vo should just report the colorspaces it really support.
will have a look at that. i used it because it was used in a vo which i
took as template.
>2. Don't use CONF_TYPE_FUNC, use normal suboptions or better use the
> string passed to preinit() with the suboptions parser.
i just saw that the whole usage was changed heavily. (i took vo_aa as a
template when i started the vo code)
will adapt to the changed behaviour (if possible. because i can only
process two suboptions: '-vo serdisp:displayname:outputdevice', because
'outputdevice' may have ":" in it (eg: '-vo
serdisp:ericssont2x:SERRAW:/dev/ttyS0', where 'SERRAW:/dev/ttyS0' is the
output device passed to serdisplib ).
>3. Why use dlopen at all? There are systems (and yes linux systems too)
> that don't support dlopen. You can probably offer useing dlopen as an
> alternative (although some will say its just cruft) but static linking
> must be possible.
i will make this an option.
big advantage of dlopen:
if everyone compiles mplayer on his/her own: no need for it, ok.
but when it comes to prebuilt packages/binaries it gives a big advange:
is is not required to have the library installed (or maybe even the
the package/binary will not have any dependency on the library. if it is
found at runtime: good. functionality available. if it is not found:
still no problem.
functionality will not be available, but the binary itself (mplayer)
will still be fine.
and one further, even bigger advantage:
the library can be exchanged without the need to rebuild the binary (eg.
mplayer) that is using the library (that's why i only use a subset of
functions of serdisplib which will not change (on an API level) - and i
also do not access fields in structs and things like that - because that
would possibly break things when changing the library).
this is - of course - a big potential danger when using dlopen (if one
doesn't care about consistency of APIs).
>4. Use dioxygen compatibles comments when you document a function.
ok. will have a look at doxygen (i've never used it until --- now :)
More information about the MPlayer-dev-eng