After creating a video window the common X code waited for a MapNotify
event before proceeding. This meant that if the window was opened on
another workspace the player would be stuck until the user switched to
that workspace and the window could become actually visible. Remove
this waiting code. I don't know why it was there or if it was actually
beneficial/needed for some setup (at least common uses seem to work
fine without it); it comes from the earliest MPlayer versions visible
in VCS history.
vo_x11_create_vo_window() only called vo_x11_update_geometry() if no
window position had been specified by -geometry or -xineramascreen, to
avoid overwriting the specified position with values from the existing
window. However window size should be initialized to the existing
window here, and setting new window title for -use-filename-title is
also done in vo_x11_update_geometry() (for whatever reason, it doesn't
match what else that function does). Change the code in
vo_x11_create_vo_window() to always call vo_x11_update_geometry() for
size variable and window title updates, but add a flag that tells it
not to update position variables.
Add support for binding commands to modifier+key combinations like
"Shift+Left" or "Ctrl+Alt+x", and support reading such combinations
from the output window of X VOs.
The recognized modifier names are Shift, Ctrl, Alt and Meta. Any
combination of those and then a non-modifier key name, separated by
'+', is accepted as a key name in input.conf. For non-special keys
that produce characters shift is ignored as a modifier. For example
"A" is handled as a key without modifiers even if you use shift to
write the capital letter; 'a' vs 'A' already distinguishes the
combinations with a normal keymap, and having separate 'a', 'Shift+A'
and 'A' (written with caps lock for example) would bring more
confusion than benefit.
Currently reading the modifier+key combinations is only supported in
the output window of those VOs that use x11_common.c event
handling. It's not possible to input the key combinations in other VOs
or in a terminal window.
Register the X11 connection fd in the input system so that
mp_input_get_cmd() can immediately wake up and handle keyboard or
other X events. The callback calls vo_check_events() and tells the
input system to handle any input possibly recorded during that. Before
this was done for vo_xv only; this commit generalizes it to all VOs
that call vo_x11_create_vo_window() - those are hopefully ones that
will handle all X events in check_events().
The callback is only kept registered while the vo is properly
configured. At other times calling check_events() would not clear
pending input and so could lead to a busy loop.
Add VO_EVENT_MOVE which is required for VOs that interact directly
with hardware like MGA and VIDIX.
Patch by Dirk Porezag [porezag yahoo com]
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32454 b3059339-0415-0410-9bf9-f77b7e298cf2
Found by the Debian QA tool 'lintian'
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31913 b3059339-0415-0410-9bf9-f77b7e298cf2
reintroduce typo in genres.h that was fixed fixed r31913 to match the id3v2 spec
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31920 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove some commented-out code that has no purpose and is only confusing.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31620 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove useless ()
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31621 b3059339-0415-0410-9bf9-f77b7e298cf2
It will most likely break their input processing.
If someone needs the previous behaviour, an option could be added (and
also used in the w32_common.c code).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31601 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix resizing with -wid after previous commit.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31604 b3059339-0415-0410-9bf9-f77b7e298cf2
Always request expose events, we have to handle them, the application
that created the -wid window can't.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31605 b3059339-0415-0410-9bf9-f77b7e298cf2
Now the window is only resized when video size (or size specified by
-geometry) changes; reconfiguring the window with the same size no
longer changes back to default size from possibly user-modified one.
Also fix a bug in fullscreen handling that could cause incorrect
window size when turning fullscreen off.
This in particular avoids MPlayer continuing to play when
a frontend using -wid crashed.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31179 b3059339-0415-0410-9bf9-f77b7e298cf2
This avoids the compilation failure on kFreeBSD (at least amd64):
In file included from libvo/vo_directfb2.c:44:
libvo/video_out.h:267: error: redefinition of 'struct keymap'
This is because libvo/vo_directfb2.c #includes sys/kd.h, which in turn
includes sys/kbio.h, which defines another 'struct keymap'.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31059 b3059339-0415-0410-9bf9-f77b7e298cf2
Fixes hangs if OpenGL initialization fails in vo gl preinit and we
call uninit while the window is still hidden.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30760 b3059339-0415-0410-9bf9-f77b7e298cf2
exit_player() was declared with differing parameter types in mplayer.c and
mplayer.h. Make the declaration in the .h file match the one in the .c file
and adjust all usages of exit_player() throughout the codebase. Also move
the exit_player() declaration into mp_core.h next to exit_player_with_rc().
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30558 b3059339-0415-0410-9bf9-f77b7e298cf2
because vo_x11_clearwindow works as intended also when the background is
set to None.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30497 b3059339-0415-0410-9bf9-f77b7e298cf2
Add a property to select YUV colorspace. Currently implemented only in
vo_vdpau and vo_xv. Allows switching between BT.601, BT.709 and
SMPTE-240M (vdpau only).
The xv support uses the "XV_ITURBT_709" attribute. At least my NVIDIA
card supports that; I don't know whether other xv implementations do.
Bind the colorspace switch to the 'c' key by default. 'c' is currently
used by vo_sdl for some fullscreen mode change thing, but at the moment
that does not conflict and if it will in the future then vo_sdl can
change.
VDPAU part based on a patch from Lauri Mylläri <lauri.myllari@gmail.com>
Main things added are custom frame dropping for VDPAU to work around
the display FPS limit, frame timing adjustment to avoid jitter when
video frame times keep falling near vsyncs, and use of VDPAU's timing
feature to keep one future frame queued in advance.
NVIDIA's VDPAU implementation refuses to change the displayed frame
more than once per vsync. This set a limit on how much video could be
sped up, and caused problems for nearly all videos on low-FPS video
projectors (playing 24 FPS video on a 24 FPS projector would not work
reliably as MPlayer may need to slightly speed up the video for AV
sync). This commit adds a framedrop mechanism that drops some frames
so that no more than one is sent for display per vsync. The code
tries to select the dropped frames smartly, selecting the best one to
show for each vsync. Because of the timing features needed the drop
functionality currently does not work if the correct-pts option is
disabled.
The code also adjusts frame timing slightly to avoid jitter. If you
for example play 24 FPS video content on a 72 FPS display then
normally a frame would be shown for 3 vsyncs, but if the frame times
happen to fall near vsyncs and change between just before and just
after then there could be frames alternating between 2 and 4
vsyncs. The code changes frame timing by up to one quarter vsync
interval to avoid this.
The above functionality depends on having reliable vsync timing
information available. The display refresh rate is not directly
provided by the VDPAU API. The current code uses information from the
XF86VidMode extension if available; I'm not sure how common cases
where that is inaccurate are. The refresh rate can be specified
manually if necessary.
After the changes in this commit MPlayer now always tries to keep one
frame queued for future display using VDPAU's internal timing
mechanism (however no more than 50 ms to the future). This should make
video playback somewhat more robust against timing inaccuracies caused
by system load.
In a list of enabled fstypes, "none" now clears the list rather than
disabling all fstypes and interrupting the parser. To enable only one
(or more) fstypes, list the types to enable after "none".
For example:
"-fstype none" is the same as before: all disabled
"-fstype none,fullscreen" enables only the fullscreen type
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29805 b3059339-0415-0410-9bf9-f77b7e298cf2
Fixes the warnings:
libvo/x11_common.c:1344: warning: 'h' may be used uninitialized in this function
libvo/x11_common.c:1344: warning: 'w' may be used uninitialized in this function
libvo/x11_common.c:1344: warning: 'y' may be used uninitialized in this function
libvo/x11_common.c:1344: warning: 'x' may be used uninitialized in this function
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29795 b3059339-0415-0410-9bf9-f77b7e298cf2
