No effort was put into moving static variables into a priv struct. The
VO wasn't tested, because DirectFB's X11 backend didn't work for me (it
crashed, not just with mplayer, but also SDL applications).
This was disabled by default, and could be enabled with -dr. It was
disabled by default because it was buggy: there were issues with OSD
corruption.
It wasn't entirely sane for OpenGL based VOs either. OpenGL can chose
to drop mapped pixel buffer objects, requiring the application to map
and fill the buffer again. But there was no mechanism in mplayer to
fill the lost buffer again. (It seems this rarely happened in practice,
though.)
On the other side, users liked the --dr flag, because it promised them
more speed. I'm not sure if it actually helped with speed, but it's
unlikely it had any real advantages on modern systems.
In order to evade the --dr cargo culting in mplayer config files, it's
best to get rid of it.
Move the definitions of all special key codes (those not passed by
ASCII value) to input/keycodes.h. Before they were spread between
osdep/keycodes.h, input/joystick.h, input/mouse.h and input/ar.h, plus
some special values in input.h. This was especially inconvenient as
the codes had to be coordinated to not conflict between the files.
The change requires a bit of ugliness as appleir.c includes
<linux/input.h> which contains various conflicting KEY_* definitions.
Work around this by adding a special preprocessor variable which can
be used to avoid defining these in keycodes.h.
Require DirectFB version 0.9.15 instead of 0.9.13.
This simplifies the build system at the cost of requiring a library
version that was released at the end rather than the middle of 2002.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32251 b3059339-0415-0410-9bf9-f77b7e298cf2
Simplify DirectFB check.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32252 b3059339-0415-0410-9bf9-f77b7e298cf2
Require DirectFB version 0.9.22.
This allows getting rid of a lot of library version check #ifdeffery.
Release 0.9.22 is from February 2005, so the requirement is reasonable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32253 b3059339-0415-0410-9bf9-f77b7e298cf2
These were the only voctrl types with more than one argument. The
second argument was passed using variable arguments. Change them to
use a single argument (address of a struct containing both old
arguments). This makes forwarding the arguments to other functions
easier and allows simplifying code.
vo_directfb2.c:553: warning: passing argument 2 of ‘dfb->EnumVideoModes’ from incompatible pointer type
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25792 b3059339-0415-0410-9bf9-f77b7e298cf2
This is not possible for xover and anything supporting vidix
due to horrible hacks.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25248 b3059339-0415-0410-9bf9-f77b7e298cf2
We do not have policy of restoring bugs when bug is fixed by accident.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24967 b3059339-0415-0410-9bf9-f77b7e298cf2
"implicit declaration of function ‘mplayer_put_key’" warnings
Based on Attila's suggestions.
Approved by Uoti and Ivan.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@22841 b3059339-0415-0410-9bf9-f77b7e298cf2
return values can be negative (VO_ERROR, VO_NOTAVAIL and VO_NOTIMPL), so it's
changed to int now.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@16172 b3059339-0415-0410-9bf9-f77b7e298cf2
