By now VIDIX is too obscure to justify the amount of code and
complexity it requires in the sources. Although there is no pressing
need to drop it just now from a code point of view, I'll rather remove
it before release than release with VIDIX support and then drop it
later.
Some of the manpage mentions of VIDIX were in "this option supported
for these VOs" lists that looked outdated and failed to mention vdpau
for example. Replace such incorrect lists with a generic "not
supported for all VOs" mention.
Remove UNUSED macros used to shut up unused function parameter warnings.
The macros are duplicated all over libvo and serve no useful purpose
nowadays. A better way to shut up the warnings is -Wno-unused-parameter.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32422 b3059339-0415-0410-9bf9-f77b7e298cf2
Mark fillMultiBuffer() as static, it is not used outside of the file; fixes:
libvo/vo_vesa.c:532: warning: no previous prototype for 'fillMultiBuffer'
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32284 b3059339-0415-0410-9bf9-f77b7e298cf2
This might avoid some issues since sws_scale in some cases assumes these
have at least 4 valid entries.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29101 b3059339-0415-0410-9bf9-f77b7e298cf2
Convert vo_x11_border (used in vo_gl/gl2 though the vo_gl_border
macro) to use a wrapper macro in old-style VOs which do not provide a
VO object argument. Before this function had an explicit global_vo
argument in vo_gl/gl2. New vo_vdpau uses it too so use the same
mechanism as most other functions.
Create new video driver API that has a per-instance context structure
and does not rely on keeping status in global or static variables.
Existing drivers are not yet converted to this API; instead there is a
wrapper which translates calls to them.
In the new API, an old API call vo_functions->xyz(args) is generally
replaced by vo_xyz(vo_instance, args).
The changes to keep the vesa, dxr2 and xover drivers compiling have
not been tested.
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_vesa.c:55: warning: redundant redeclaration of #monitor_hfreq_str#
video_out.h:252: warning: previous declaration of #monitor_hfreq_str# was here
vo_vesa.c:56: warning: redundant redeclaration of #monitor_vfreq_str#
video_out.h:253: warning: previous declaration of #monitor_vfreq_str# was here
vo_vesa.c:57: warning: redundant redeclaration of #monitor_dotclock_str#
video_out.h:254: warning: previous declaration of #monitor_dotclock_str# was here
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25551 b3059339-0415-0410-9bf9-f77b7e298cf2
Subsequent calls would fail with some video chip (including i945)
when using -fixed-vo.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@22785 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
a simple 32 bits protected mode interface to some VESA functions. This
protected mode interface is interesting because it's quicker than the
raw int 10h interface.
Unfortunatly, begining with VBE 3.0, the 0x4f0a function is optional,
and some video cards don't implement it (3dfx, intel 845/855/865...).
This protected mode interface is then only used in vbeSetWindow and
vbeSetDisplayStart :
- vbeSetWindow already implement an alternative methode if protected
mode interface is not available.
- vbeSetDisplayStart also contain an alternative implementation, but
this one is disabled with a #if 0. I don't exactly know why because
it works well !
So currently, cards which don't have the 0x4f0a function are not
supported. This patch correct this.
- vbeGetProtModeInfo failure is not fatal.
- vbeSetDisplayStart has it's alternative implementation reenabled.
it's used only with cards which don't have the 0x4f0a function
so this won't make any difference for cards which were already
working.
This patch also make the failure of vbeGetModeInfo not fatal. The
VBE 3.0 standard state that GetModeInfo can fail with some mode
which are listed as supported if the mode can't be used in the
current situation (not enough video memory for example). So a
failure of vbeGetModeInfo don't mean that other modes won't work
and should really not be fatal.
patch by Aurelien Jacobs <aurel@gnuage.org>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13569 b3059339-0415-0410-9bf9-f77b7e298cf2
