Commit Graph

57 Commits

Author SHA1 Message Date
wm4 df80cd379a x11: simplify handling of X Visuals and Colormaps in VOs
Don't force VOs to pick an arbitrary default Visual and Colormap. They
still can override them if needed. This simplifies the X11 VO interface.

Always create a Colormap for simplicity. Using CopyFromParent fails if
the selected visual is not the same of that of the parent window, which
happens for me with vo_opengl.

vo_vdpau and vo_xv explicitly set CWBorderPixel, do that in x11_common
instead (it was already done for native windows, but not for slave mode
windows).

What gl_common did was incorrect in theory: freeing a colormap while a
window uses it will change the colormap of the window to "None", and
the color mapping for such windows is "undefined".
2013-01-27 13:32:27 +01:00
wm4 75164a0e0a x11: fix some obvious video mode switching bugs
The original video mode wasn't reliably restored, so just store the
mode separately.

For some reason, window decorations got into the picture, possibly due
to an incorrect initial window position or something like this.
Normally, the window is positioned and sized such that it covers the
screen entirely, even though the window still has decorations and is
not in fullscreen mode (fullscreen wouldn't be correct, because the
virtual desktop size is not screen size). Hack-fix by forcing window
decorations off when VM-switching.

All in all, VM switching is still buggy and useless.
2013-01-27 13:30:54 +01:00
wm4 0535a14505 x11: reduce VO mode switching code duplication
Some parts for initiating mode switches were duplicated in every VO
supporting X11 (except vo_opengl/gl_common, which didn't support mode
switching). Move this to x11_common.c.

Note that this might be slightly risky: is it really guaranteed that no
VO needed to do "special" setup that depends on X parameters changing
after a mode switch, such as bit depth, visuals etc.? From what I can
see, this shouldn't be the case (X probably can't even change depth on
the fly). Even if this should be a one-way road, VM switching is in
general very useless, and its implementation buggy, so it can just be
removed should unfixable problems arise.
2013-01-27 13:30:54 +01:00
wm4 a243acb1de x11: cleanup, refactor
Move things that are used by vo_xv only into vo_xv, same for vo_x11.

Rename some functions exported by x11_common, like vo_init to
vo_x11_common. Make functions not used outsode of x11_common.c private
to that file. Eliminate all global variables defined by x11_common
(except error handler and colormap stuff).

There shouldn't be any functional changes, and only code is moved
around. There are some minor simplifications in the X11 init code, as
we completely remove the ability to initialize X11 and X11+VO
separately (see commit b4d9647 "mplayer: do not create X11 state in player frontend"),
and the respective functions are conflated into vo_x11_init() and
vo_x11_uninit().
2013-01-27 13:30:53 +01:00
Rudolf Polzer 4044754d24 vo_x11, vo_xv: XShmCompletion event support
This fixes OSD flicker with vo_xv at high frame rates.
2013-01-13 22:36:42 +01:00
wm4 2628ff6224 options: remove --display
Was used to set the X11 display. XDisplayName(NULL) does the same,
using the DISPLAY environment variable instead.
2012-11-16 21:21:15 +01:00
wm4 d4bdd0473d Rename directories, move files (step 1 of 2) (does not compile)
Tis drops the silly lib prefixes, and attempts to organize the tree in
a more logical way. Make the top-level directory less cluttered as
well.

Renames the following directories:
    libaf -> audio/filter
    libao2 -> audio/out
    libvo -> video/out
    libmpdemux -> demux

Split libmpcodecs:
    vf* -> video/filter
    vd*, dec_video.* -> video/decode
    mp_image*, img_format*, ... -> video/
    ad*, dec_audio.* -> audio/decode

libaf/format.* is moved to audio/ - this is similar to how mp_image.*
is located in video/.

Move most top-level .c/.h files to core. (talloc.c/.h is left on top-
level, because it's external.) Park some of the more annoying files
in compat/. Some of these are relicts from the time mplayer used
ffmpeg internals.

sub/ is not split, because it's too much of a mess (subtitle code is
mixed with OSD display and rendering).

Maybe the organization of core is not ideal: it mixes playback core
(like mplayer.c) and utility helpers (like bstr.c/h). Should the need
arise, the playback core will be moved somewhere else, while core
contains all helper and common code.
2012-11-12 20:06:14 +01:00