Will be used for common data between X11 VOs. The main reasons for
making it a separate struct rather than extra fields in the main VO
struct are that some field definitions need X headers and that the code
keeps basic X state such as the display connection over opening and
closing of individual VOs.
Add a 'struct vo *vo' argument to the x11_common.c functions that
access the variable so it's available as vo->opts->vo_ontop. To keep
VOs using the old API working create a global vo variable that is set
to the currently used old vo. "vo_ontop" will be #defined to
"global_vo->opts->vo_ontop", and x11_common.h will add defines like
the following when it is included by old VOs:
#define vo_x11_ontop() vo_x11_ontop(global_vo)
so that they will call the function according to the new declaration.
consistent by introducing a new function that handles most of the
ugly things. Changes of behaviour with some vos is unavoidable, bug reports
welcome.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@23675 b3059339-0415-0410-9bf9-f77b7e298cf2
remove the variable itself. Convert code in x11_common.c and OSD timing
that depended on the variable to use real time instead.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18288 b3059339-0415-0410-9bf9-f77b7e298cf2
patch replaces '()' for the correct '(void)' in function
declarations/prototypes which have no parameters. The '()' syntax tell
thats there is a variable list of arguments, so that the compiler cannot
check this. The extra CFLAG '-Wstrict-declarations' shows those cases.
Comments about a similar patch applied to ffmpeg:
That in C++ these mean the same, but in ANSI C the semantics are
different; function() is an (obsolete) K&R C style forward declaration,
it basically means that the function can have any number and any types
of parameters, effectively completely preventing the compiler from doing
any sort of type checking. -- Erik Slagter
Defining functions with unspecified arguments is allowed but bad.
With arguments unspecified the compiler can't report an error/warning
if the function is called with incorrect arguments. -- Måns Rullgård
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17567 b3059339-0415-0410-9bf9-f77b7e298cf2
(using panscan makes x,y negative, so it is very bad idea they to be unsigned)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@15101 b3059339-0415-0410-9bf9-f77b7e298cf2
Made the code also more flexible.
Colorkey drawing is now by default done as
proposed by Marko Macek.
Patch also approved by iive.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@14743 b3059339-0415-0410-9bf9-f77b7e298cf2
it is not really beautiful that their are included here in the first place)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@14664 b3059339-0415-0410-9bf9-f77b7e298cf2
- help (-fstype help) also availabible
- support state BELOW (someone may want to use it...) and by -fstype none forcing of
not changing window layer (user request)
- drop icelayer option, it can be set by -fstype layer=<number>
- simplify vo_x11_fullscreen
- fs change code cleanup
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@9318 b3059339-0415-0410-9bf9-f77b7e298cf2
using the window's colormap (DirectColor).
this method is using the video card's hardware gamma ramp so it involves
no performance penalties at all.
patch by lucho <lucho@haemimont.bg>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@7965 b3059339-0415-0410-9bf9-f77b7e298cf2
function. This is useful for framebuffers on Sun hardware, where we have
multiple truecolor visuals of different depths available, and the root
window typically runs at depth 8, yet there are 24 bit true color visuals
available as well.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@7257 b3059339-0415-0410-9bf9-f77b7e298cf2
