Commit Graph

261 Commits

Author SHA1 Message Date
wm4 75e6584ab3 Prefix keycode defines with MP_
Do this to reduce conflicts with <linux/input.h>, which contains some
conflicting defines.

This changes the meaning of MP_KEY_DOWN:

  KEY_DOWN is renamed to MP_KEY_DOWN (cursor down key)
  MP_KEY_DOWN is renamed to MP_KEY_STATE_DOWN (modifier for key down state)
2013-02-12 10:27:00 +01:00
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 e4943165c1 x11_common: do not set custom error handler when calling XSelectInput
Do this because we want to remove the global variables required with the
old code. In particular, there doesn't seem any way to set a secure user
data pointer with xlib.

XSelectInput() causes a BadAccess error when some of the requested event
flags are reserved (for exclusive flags like ButtonPress). The custom
error handler caught this and set a global variable, so that the code
could retry the XSelectInput() call without the conflicting flags. Use a
different approach that doesn't need a custom error handler. (Although
we still assume that the error handler doesn't terminate the program.)
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
wm4 4c56baba40 options: move -geometry parsing to m_option.c
This also means the option is verified on program start, not when the VO
is created. The actual code becomes a bit more complex, because the
screen width/height is not available at program start.

The actual parsing code is still the same, with its unusual sscanf()
usage.
2013-01-23 10:56:11 +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 4873b32c59 Rename directories, move files (step 2 of 2)
Finish renaming directories and moving files. Adjust all include
statements to make the previous commit compile.

The two commits are separate, because git is bad at tracking renames
and content changes at the same time.

Also take this as an opportunity to remove the separation between
"common" and "mplayer" sources in the Makefile. ("common" used to be
shared between mplayer and mencoder.)
2012-11-12 20:08:18 +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