[MPlayer-dev-eng] [PATCH] vo device for serdisplib controlled gfx displays / display modules (-vo serdisp)

[Wolfgang Astleitner]

hi!

>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 
header files).
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 :)

/wolfgang astleitner