mpv's mouse button numbering is based on X11, which means XBUTTON1 and 2
on Windows (the "back" and "forward" buttons) should map to MOUSE_BTN7
and 8 in mpv. MOUSE_BTN5 and 6 refer to the horizontal scroll buttons on
mouses that have them.
Windows doesn't have a way to distinguish "precise" mouse wheel events
and events from regular notched mouse wheels. A notched wheel should
always send events with a delta of 120, but a precise wheel could also
happen to send 120 if multiple scroll events are coalesced (and to make
things even harder, some buggy Microsoft drivers send deltas less than
120, even for notched wheels.) Since there is no distinction, but
MP_AXIS_* keycodes can hold more information (the delta value,) send
MP_AXIS_* events for both kinds of mouse wheel scrolling.
TLS is a headache. We should avoid it if we can.
The involved mechanism is unfortunately entangled with the unfortunate
libmpv API for returning pointers to host API objects. This has to be
kept until we change the API somehow.
Practically untested out of pure laziness. I'm sure I'll get a bunch of
reports if it's broken.
Most authors have agreed. Like with vo.c, we don't take module
declarations into consideration (see 0e09533c73).
Notable issues:
115bfb9762: the author has (probably) not agreed. The vf.c changes were
removed with the removal of filter DR, though (see c54fc507da).
7b25afd742: the same author adds VOCTRLs for deinterlacing switching at
runtime. Put them under a HAVE_GPL ifdef just to be sure. (It looks like
we could remove the VOCTRLs immediately, as they're needed only for some
compatibility things, but no need to do that yet.)
02b199e5e9: the author had a conditional agreement to LGPL, which
doesn't allow us to change it just yet, but the code added here was
completely removed anyway. (These days, the pts is passed as mp_image
field, and put_image is gone.)
3532cd532e: same author, but code removed with DR removal.
f0626e2f8d: same author, but code was moved to mp_image.c.
e5b4b495c3: agreed to LGPLv3+ only, but the code was removed in
cfa1f9e082 anyway.
086c324692: author was not asked - minor warning fix, but no mpv
includes malloc.h anymore.
e9d0a1d609: author was not asked - removed again in 33b62af947.
c260a1139d: author could not be reached - but this code was removed when
mpv changed the image allocation code to essentially use FFmpeg's
pixdesc.
Most contributors have agreed. vo.c requires a "driver" entry for each
video output - we assume that if someone who didn't agree to LGPL added
a line, it's fine for vo.c to be LGPL anyway. If the affected video
output is not disabled at compilation time, the resulting binary will be
GPL anyway.
One problem are the changes by Nick Kurshev (usually using "nick" as SVN
username). He could not be reached. I believe all changes to his files
are actually gone, but here is a detailed listing:
fa1d5742bc: nick introduces a new VO API. It was removed in 64bedd9683.
Some of this was replaced by VOCTRLs are introduced in 7c51652a1b,
obviously replacing at least some functionality by his API.
b587a3d642: nick adds a vo_tune_info_t struct. Removed in 64bedd9683
too.
9caad2c29a: nick adds some VOCTRLs, which were silently removed in
8cc5ba5ab8 (they became unused probably with the VIDIX removal).
340183b0e9: nick adds VO-based screenshots, which got removed in
2f4b840f62. Strangely the same name was introduced in 01cf896a2f again,
but this is a coincidence and worked differently (also it was removed
yet again in 2858232220).
104c125e6d: nick adds an option for "direct rendering". It was renamed
in 6403904ae9 and fully removed in e48b21dd87.
5ddd8e92a1: nick adds code to check the VO driver preinit arg to every
single VO driver. The argument itself and any possibly remaining code
associated with it was removed in 1f5ffe7d30.
f6878753fb: nick adds header inclusion guards. We assume this is not
relevant for copyright.
Some of nick's code was merely moved to other files, such as the
equalizer stuff added in 555c676683 and moved in 4db72f6a80 and
12579136ff, and don't affect copyright of these files anymore.
Other notes:
fef7b17c34: a patch by someone who wasn't asked for relicensing added a
symbol that was removed again in 1b09f4633.
4a8a46fafd: author probably didn't agree to LGPL, but the function
signature was changed later on anyway, and nothing of this is left.
7b25afd742: the same author adds a symbol to what is vo.h today, which
this relicensing commit removes, as it was unused. (It's not clear
whether the mere symbol is copyrightable, but no need to take a risk.)
3a406e94d7, 9dd8f241ac: slave mode things by someone who couldn't be
reached. This aspect of the old slave mode was completely removed.
bbeb54d80a: patch by someone who was not asked, but the added code was
completely removed again.
Until now, the texture pointer was stored in plane 1, and the texture
array index was in plane 2. Move this down to plane 0 and plane 1. This
is to align it to the new WIP D3D11 decoding API in Libav, where we
decided that there is no reason to avoid setting plane 0, and that it
would be less weird to start at plane 0.
Sigh...
The functionality is not actually needed for vdpau, but if the vdpau
hwaccel is present, the FFmpeg version is new enough that it includes
the field.
These decoders can select the decoding device with hw_device_ctx, but
don't use hw_frames_ctx (at least not in a meaningful way).
Currently unused, but intended to be used for cuvid, as soon as it hits
ffmpeg git master.
Also make the vdpau and vaapi hwaccel definition structs static, as we
have removed the old code which would have had clashing external
declarations.
This reverts commit 142b2f23d4, and replaces it with another try. The
previous attempt removed the overlay on every rendering, because the
normal rendering path actually unrefs the mp_image. Consequently,
unmap_current_image() was completely inappropriate for removing the
overlay.
This drops support for the old libavcodec APIs. Now FFmpeg 3.3 or FFmpeg
git is required. Libav has no release with the new APIs yet, so for
Libav git as of a few weeks or months ago or so is required if you want
to use Libav.
Not much actually changes in hwdec_vaegl.c - some code is removed, but
the reindentation inflates the diff.
Reduces the ifdeffery, which is good and will avoid silent breakages, or
weird behavior if a lib is omitted.
Also reorder the x11_common.c include statements.
due to the System inherent fullscreen animation the option and the
actual fullscreen state can be out of sync, leading to a wrongly
reported unfs window size in the time of the animation.
just always fall back to the window size, we keep track of, when we
either are in fullscreen or are currently switching to it.
Fixes#4323
Wayland is still too amateurish, and multiple features don't work,
including critical ones. There is no solution in sight, so prefer X11.
(Which seems to mostly work ok via xwayland.)
Once all problems are solved, the defaults can be switched back.
Mostly because of ANGLE (sadly).
The implementation became unpleasantly big, but at least it's relatively
self-contained.
I'm not sure to what degree shaders from different drivers are
compatible as in whether a driver would randomly misbehave if it's fed
a binary created by another driver. The useless binayFormat parameter
won't help it, as they can probably easily clash. As usual, OpenGL is
pretty shit here.
gl_headers.h is basically header_fixes.h done consequently. It contains
all OpenGL defines (and some typedefs) we need. We don't include GL
headers provided by the system anymore.
Some care has to be taken by certain windowing APIs including all of
gl.h anyway. Then the definitions could clash. Fortunately, redefining
preprocessor symbols to the same content is allowed and ignored. Also,
redefining typedefs to the same thing is allowed in C11. Apparently the
latter is not allowed in C99, so there is an imperfect attempt to avoid
the typedefs if required API symbols are apparently present already.
The nost risky part about this are the standard typedefs and GLAPIENTRY.
The latter is different only on win32 (and at least consistently so).
The typedefs are mostly based on stdint.h typedefs, which khrplatform.h
clumsily emulates on platforms which don't have it. The biggest
difference is that we define GLsizeiptr directly to ptrdiff_t, instead
of checking for the _WIN64 symbol and defining it to long or long long.
This also typedefs GLsync to __GLsync, just like the khronos headers.
Although symbols prefixed with __ are implementation reserved, khronos
also violates this rule, and having the same definition as khronos will
avoid problems on duplicate definitions.
We can simplify the build scripts too. The ios-gl check seems a bit
wrong now (what we really want to test for is EAGLContext), but I can't
test and thus can't improve it.
cuda_dynamic.h redefined two GL symbols; just include the new headers
directly instead.
This is pretty trivial, but also quite annoying due to details like
mismatching eglGetProcAddress() function signature (most callers just
cast the function pointer), and ARM/Linux hacks. So move them all to one
place.
With the recent GLES3 header detection, and if ANGLE is in the search
path, the ANGLE headers will be used over the desktop GL ones. It
appears the ANGLE headers do not include <windows.h>, which leads to the
dxinterop code to fail building. Oops.
Fix this by including <windows.h> is dxinterop is compiled in.
It appears we expect IOS to provide GLES 3. The IOS block contains all
symbols from the GLES block. Weirdly not all, so it's possible that some
symbols will be redefined, which is annoying, but harmless. I don't have
an iOS setup to test, otherwise it's likely that a modification of the
IOS include statements would take care of this.
If the VO doesn't support a format output by vf_lavfi, no conversion
filter was inserted, and filter chain creation failed.
This is because vf_lavfi doesn't properly follow the format negotiation
model, which means the format negotiation pass does not catch all cases
where conversion is needed. Specifically, vf_lavfi supports that all
output formats are supported for any given input format, but then does
not actually call vf_next_query_format() in reconfig() to check which
format it uses, but outputs whatever it gets from libavfilter.
I think this is ok to avoid excessive complexity in vf_lavfi.c, but it
also means adding more kludges to vf.c. I justify this (and the code
duplication) with the idea that the current filter chain code will die
anyway at some point.
The .log field additions for c->first/c->last are strictly speaking not
needed, but useful for debugging.
Previously, the shared behaviour for each mouse-button message lived at
the bottom of the WndProc. Move it into handle_mouse_down/up functions
(similar to the handle_key_down/up functions.) This makes the WndProc
slightly less complicated. There should be no change in behaviour.
Now you can for example do "--vf=hue=h=60" - there is no "hue" filter in
mpv, so libavfilter's will be used.
This has certain caveats (see manpage).
The point of this is providing a relatively smooth transition path to
removing our own filter stuff.
The plan is to nuke the custom filter chain completely. It's not clear
what will happen to the still needed builtin filters (mostly hardware
deinterlacing and vf_vapoursynth). Most likely we'll replace them with
different filter chain concept (whose main purpose will be providing
builtin things and bridging to libavfilter).
The undocumented "warn" options are there to disable deprecation
warnings when the player inserts filter automatically.
The same will be done to audio filters, at a later point.
Now taking a screenshot actually works, if libjpeg is disabled at
compile time.
In particular, the AV_PIX_FMT_YUVJ formats (with the "J") cause us
problems. They have been deprecated years ago, but the libavcodec jpg
encoder won't accept anything else. This is made worse by the fact that
mpv doesn't have J formats internally - it always uses the color levels
metadata to decide the range instead.
The old code called reinit_window_state() from the VO thread, which is
not safe. Instead of calling reinit_window_state() when
VO_EVENT_FULLSCREEN_STATE is captured, it should be called when sending
the event from the Win32 thread instead.
there are two minor bugs. mpv could try to retrieve the size when in
fullscreen and would get the fullscreen size. to fix that we keep track
of the window size before going into fullscreen.
the second small bug is when using HiDPI resolution and the
--hidpi-window-scale option. we actually want the OSD to show the proper
window scale depending on the hidpi settings. before when resizing the
window to double the size it could show "window-scale: 1.0" or
"window-scale: 0.5" when resizing to normal size. now it considers the
backing scale factor and the hidpi option to return a logical correct
window size.
this fixes a weird behaviour when a borderless window's style mask is
set to a none-borderless style mask. this can happen when cycling the
border or just toggling fullscreen. what happens is that the first
responder is reset to the NSWindow instead of being kept, the events
view in our case. this happens without the usual resignFirstResponder,
becomeFirstResponder routine.
this is a small workaround that overrides the setStyleMask method. it
keeps the first responder from before the style mask change and resets
this first responder after the new style mask was applied.
for a reason i can just assume some key events can vanish from the
event chain and mpv seems unresponsive.
after quite some testing i could confirm that the events are present at
the first entry point of the event chain, the sendEvent method of the
Application, and that they vanish at a point afterwards. now we use
that entry point to grab keyDown and keyUp events. we also stop
propagating those key events to prevent the no key input' error sound.
if we ever need the key events somewhere down the event chain we need
to start propagating them again. though this is not necessary currently.
DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL might be buggy on some hardware.
Additionaly DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL might be supported on some
Windows 7 systems with the platform update, but it might have poor
performance. In these cases, the user might want to disable the use of
DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL swap chains with --angle-flip=no.
Basically, see the example in input.rst.
This is better than the "old" vf-toggle method, because it doesn't
require the user to duplicate the filter string in mpv.conf and
input.conf.
Some aspects of this changes are untested, so enjoy your alpha testing.
This makes the code more closely match mpv's style. Specifically, it
changes some names from camelCase to snake_case, removes some Hungarian
notation, replaces direct vtbl access with COM macros, makes use of the
SAFE_RELEASE macro, moves some declarations closer to their first use,
and fixes the brace style, as well as a few other things.
This also makes the IDropTargetVtbl static and it fixes the buggy
QueryInterface implementation.
This was mostly self-contained, so its removal makes w32_common.c a bit
easier to read. Also, because it was self contained and its author has
agreed to LGPL relicencing, the new file has the LGPL licence header.
