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
Uoti Urpala
reimar
Amar Takhar
diego
Uoti Urpala
aurel
ben
lucabe
reynaldo
alex
ivo
henry
rfelker
faust3