summaryrefslogtreecommitdiffstats
path: root/video/out/w32_common.c
Commit message (Collapse)AuthorAgeFilesLines
* win32: don't request window size larger than the screenwm42014-09-101-3/+34
| | | | | | | | | | | | | | | | | An attempt at fixing #1070. Apparently something goes wrong if the video size is equal to the screen size. Since the window decorations add to the window size, it must actually be larger than the screen. Actually I don't know what exactly is going wrong, but since this commit also slightly improves the behavior otherwise, it's a win anyway. Try to keep the window size strictly below screen size, even accounting for window decorations. Size it down and center the window so that it fits (by either touching the left/right or top/bottom screen borders). I haven't found any information on what is the maximum allowed size and position of a window so that it doesn't collide with the task bar, so assume that we can use the entire screen, minus 1 pixel to avoid triggering fullscreen semantics (if that is even possible).
* win32: copy event flags after running VOCTRLswm42014-09-071-5/+2
| | | | | | | | | reinit_window_state() will set VO_EVENT_RESIZE when it runs, so we don't need to set it manually depending on the VOCTRL. Probably avoids duplicated resize events. I don't expect this actually fixes anything, but might help spotting other bugs easier (if there are any).
* video: rename VOCTRL_GET_WINDOW_SIZEwm42014-09-051-2/+2
| | | | Make it clear that this accesses the un-fullscreened window size.
* video: move display and timing to a separate threadwm42014-08-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VO is run inside its own thread. It also does most of video timing. The playloop hands the image data and a realtime timestamp to the VO, and the VO does the rest. In particular, this allows the playloop to do other things, instead of blocking for video redraw. But if anything accesses the VO during video timing, it will block. This also fixes vo_sdl.c event handling; but that is only a side-effect, since reimplementing the broken way would require more effort. Also drop --softsleep. In theory, this option helps if the kernel's sleeping mechanism is too inaccurate for video timing. In practice, I haven't ever encountered a situation where it helps, and it just burns CPU cycles. On the other hand it's probably actively harmful, because it prevents the libavcodec decoder threads from doing real work. Side note: Originally, I intended that multiple frames can be queued to the VO. But this is not done, due to problems with OSD and other certain features. OSD in particular is simply designed in a way that it can be neither timed nor copied, so you do have to render it into the video frame before you can draw the next frame. (Subtitles have no such restriction. sd_lavc was even updated to fix this.) It seems the right solution to queuing multiple VO frames is rendering on VO-backed framebuffers, like vo_vdpau.c does. This requires VO driver support, and is out of scope of this commit. As consequence, the VO has a queue size of 1. The existing video queue is just needed to compute frame duration, and will be moved out in the next commit.
* win32: never call GetClientRect(0, ...)wm42014-08-061-1/+4
| | | | | | | | | | | | | | | | | Sometimes GetClientRect() appeared to fail during init, and since we don't check GetClientRect() calls (because they're on our own window, and logically can never fail), bogus resizes were triggered. This could cause vo_direct3d to fail initialization. The reason was that w32->window was set to 0 during early window initialization: CreateWindow*() can send messages to the new window, even though it hasn't returned yet. This means w32->window is not yet set to our window handle, and functions in WndProc may accidentally pass hwnd=0 to win32 API functions. Fix it by initializing w32->window on opportunity. This also means we always strictly expect that the WndProc is used with our own window only.
* win32: create OpenGL context on the GUI threadwm42014-08-051-0/+6
| | | | | | | | | | | | | | | | This fixes the fullscreen issues on Intel for me. I'm baffled by it and don't understand why this suddenly works. Intel drivers being shit? Windows being shit? HWND or HDC being only 97% thread-safe instead of 98%? Me missing something subtle that is not documented anywhere? Who knows. Now instead of creating the HDC and OpenGL context on the renderer thread, they're created on the GUI thread. The renderer thread will then only call wglMakeCurrent, SwapBuffers, and OpenGL standard functions. Probably fixes github issue #968.
* vo: remove vo_mouse_movement() wrapperwm42014-07-271-2/+2
| | | | So that VO backends don't have to access the VO just for that.
* win32: remove minor non-sensewm42014-07-261-1/+0
| | | | This is done in the wrong thread. Was harmless and had no effect at all.
* win32: move window handling to a separate threadwm42014-07-261-60/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The windows message loop now runs in a separate thread. Rendering, such as with Direct3D or OpenGL, still happens in the main thread. In particular, this should prevent the video from freezing if the window is dragged. (The reason was that the message dispatcher won't return while the dragging is active, so mpv couldn't update the video at all.) This is pretty "rough" and just hacked in, and there's no API yet to make this easier for other backends. It will be cleaned up later once we're sure that it works, or when we know how exactly it should work. One oddity is that OpenGL is actually completely managed in the renderer thread, while e.g. Cocoa (which has its own threading code) creates the context in the GUI thread, and then lets the renderer thread access it. One strange issue is that we now have to stop WM_CLOSE from actually closing the window. Instead, we wait until the playloop handles the close command, and requests the VO to shutdown. This is done mainly because closing the window apparently destroys it, and then WM_USER can't be handled anymore - which means the playloop has no way to wakeup the GUI thread. It seems you can't really win here... maybe there's a better way to have a thread receive messages with and without a window, but I didn't find one yet. Dragging the window (by clicking into the middle of it) behaves strangely in wine, but didn't before the change. Reason unknown.
* win32: use gcc TLS instead of WM_NCCREATE tricks for window contextwm42014-07-261-10/+9
| | | | | | | | | | | | win32 does not provide a proper per-window context pointer. Although it does allow passing a user-chosen value to WM_CREATE/WM_NCCREATE, this is not enough - the first message doesn't even have to be WM_NCCREATE. This gets us in trouble later on, so go the easy route and just use a TLS variable. __thread is gcc specific, but Windows is a very "special" platform anyway. We support only MinGW and Cygwin on it, so who cares. (C11 standardizes __thread as _Thread_local; we can use that later.)
* win32: make a flag explicitwm42014-07-261-1/+1
| | | | | | | | This shouldn't change anything. But it's worth making this explicit, since it's very subtle and unintuitive: if the X parameter is the magic value CW_USEDEFAULT, then the Y parameter is used as nCmdShow parameter to ShowWindow(). And in our case, this is SW_HIDE (0), because we want to create a hidden window.
* win32: simplify some --wid embedding codewm42014-07-261-26/+9
| | | | | | | | | | | This looked a bit overcomplicated. We don't care about the window position (it should always be 0/0, unless the parent program moved it, which it shouldn't). We don't care about the global on-screen position. Also, we will just retrieve a WM_SIZE message if our window is resized, and we don't need to update it manually. The only thing we have to do is making sure our window fills the parent window completely.
* win32: don't use CS_OWNDCwm42014-07-261-26/+1
| | | | | | | | | | | | | CS_OWNDC will make GetDC() always return the same HDC. This might become a problem when OpenGL rendering and window management are on different threads. Although I'm not too sure about this; our code never requests a HDC outside of the OpenGL backend, and it depends on whether win32 will internally request DCs. But in any case, this seems to be cleaner. Move the GL pixelformat setup code to gl_w32.c, where it's actually needed. This also fixes that SetPixelFormat() should be called only once, and not every time video params change.
* win32: remove worthless doxygen commentswm42014-07-261-39/+4
| | | | | | These mostly describe self-explanatory things, and fail to explain actually tricky things. Which means you just waste your time reading this, and have to figure it out from the code anyway.
* win32: make private struct private, refactorwm42014-07-261-172/+192
| | | | | | | | | | | | | | | | Preparation for moving win32 windowing to a separate thread. The codesize is reduced a bit, because some small functions are inlined, which reduces noise. The main change is that now most functions use the private struct directly, instead of accessing it indirectly through vo->w32. Accesses to vo are minimalized. The final goal is adding some sort of new windowing backend API. It would be cleaner to use that as context pointer for all functions (like struct vo was previously used), but since this is work in progress, we just go with this commit.
* w32_common: fix typowm42014-05-101-2/+3
| | | | Also, reset rc completely, instead of assuming things.
* win32: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-061-67/+38
| | | | Not very tested. At least it compiles.
* w32_common: use ToUnicode to translate key inputJames Ross-Gowan2014-04-171-50/+181
| | | | | | | | | | | | | | | | This replaces translate_key_input with a solution that gives mpv more control over how keyboard input is converted to unicode. As a result: - Key up/down events are generated the same way for all keys. - Dead keys generate their base character instead of being combined with the following character. - Many Ctrl and Ctrl+Alt key combinations that were previously broken are fixed, since it's possible to discover the base keys. - AltGr doesn't produce special characters when mp_input_use_alt_gr is false. This also fixes some logic to do with detecting AltGr and adds proper UTF-16 decoding.
* w32_common: prevent MOUSE_BTN0 sticking after dragJames Ross-Gowan2014-03-121-0/+2
| | | | | | The window doesn't recieve a WM_LBUTTONUP message after it's dragged, probably because it's swallowed by the modal loop. To stop the button from sticking, release it manually when the drag is complete.
* w32_common: capture mouse inputJames Ross-Gowan2014-03-121-0/+5
| | | | | | Mouse buttons can get stuck down if the button is pressed inside the video window and released outside. Avoid this by capturing mouse input when a button is pressed.
* w32_common: don't set small iconJames Ross-Gowan2014-02-171-4/+1
| | | | | Windows will automatically choose the correct icon size if this field is unset.
* w32_common: Fix extended keysJames Ross-Gowan2014-01-211-1/+1
| | | | The KF_* flags work on the HIWORD of lParam. Whoops
* w32: use the w32_common keymap in terminal-win tooJames Ross-Gowan2014-01-191-58/+5
|
* w32_common: add extended keysJames Ross-Gowan2014-01-151-23/+54
| | | | Also VK_APPS/MP_KEY_MENU was missing.
* w32_common: prevent decoding certain keys twiceJames Ross-Gowan2014-01-151-12/+34
| | | | | | | | This is a bit of a hack, but in order to prevent TranslateMessage from seeing WM_KEYDOWN messages that we already know how to decode, move the decoding logic to the event loop. This should fix #476, since it stops the generation of extraneous WM_CHAR messages that were triggering more than one action on keydown.
* video/out: simplify monitor aspect handlingwm42014-01-111-2/+0
| | | | | | | | For some reason, this made all VO backends both set the screen resolution in opts->screenwidth/height, and call aspect_save_screenres(). Remove the latter. Move the code to calculate the PAR-corrected window size from aspect.c to vo.c, and make it so that the monitor PAR is recalculated when it makes sense.
* w32_common: reformat yet againMartin Herkt2014-01-061-208/+208
| | | | | I've been told mpv prefers switch/case on the same indent level. Sorry about the noise :P
* w32_common: don't force topmost on fullscreenMartin Herkt2014-01-061-1/+2
| | | | Fixes #457, #444.
* w32_common: reformat slightlyMartin Herkt2014-01-061-68/+99
| | | | This really needs more whitespace.
* w32_common: use OLE DnD for text/uri-list supportxnoreq2014-01-061-39/+203
| | | | Signed-off-by: Martin Herkt <lachs0r@srsfckn.biz>
* w32_common: support file drag and dropMartin Herkt2013-12-201-0/+38
|
* w32_common: fix mouse clicksMartin Herkt2013-12-191-12/+17
| | | | | | | | | | | | | | Apparently this has been broken for a year or so. The were three reasons for the breakage here: 1. The window dragging hack prevented any DOWN event from passing through since it always returned before we even got the button. 2. The window style had CS_DBLCLKS in its flags, so we did not get any DOWN events when the OS had detected a double click (instead expecting us to handle a DBL event). 3. We never sent any mouse buttons when mouse movement handling was disabled.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-2/+2
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-1/+1
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Move mpvcore/input/ to input/wm42013-12-171-3/+3
|
* options: add option to disable using right Alt key as Alt GrVivek Jain2013-12-021-1/+1
| | | | | | | | | mpv was hardcoded to always consider the right Alt key as Alt Gr, but there are parituclar combinations of platforms and keyboard layouts where it's more convenient to treat the right Alt as a keyboard modifier just like the left one. Fixes #388
* w32: implement functionality required for window-scalewm42013-11-021-0/+23
| | | | Same semantics with respect to fullscreen as x11.
* w32_common: mp_msg conversionAlexander Preisinger2013-09-111-14/+12
|
* options: remove --(no-)mouseinput optionwm42013-09-081-1/+1
| | | | I have no idea why it exists, as it's redundant to --(no-)mouse-movements.
* input: deal with spurious X11 LeaveNotify eventswm42013-09-011-3/+13
| | | | | | | | | | | | | | | | | | | | | If the mpv window is unfocus, clicking on the OSC should focus the window (done by the window manager) and allow interaction with the OSC. But somehow X sends a spurious LeaveNotify event, immediately followed by an EnterNotify event. This happens at least with IceWM. The result is that the OSC will disappear (due to receiving MOUSE_LEAVE). The OSC will stay invisible, because EnterNotify isn't handled, and there's nothing that could make the OSC appear again. Solve this by handling EnterNotify. We cause a redundant MOUSE_MOVE event to be sent, which triggers the code to make the OSC visible. We have to remove the code from input.c, which ignores redundant mouse move events. Since the code ignoring redundant mouse move events is still needed on Windows, move that code to w32_common.c. The need for this is documented in the code, also see commit 03fd2fe. (The original idea was to save some code by having this code in the core, but now it turns out that this didn't quite work out.)
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-6/+6
| | | | Followup commit. Fixes all the files references.
* w32_common: Don't use globals for TRACKMOUSEEVENTDiogo Franco (Kovensky)2013-07-251-11/+9
| | | | It seems working on getch2 gave me some brain damage.
* w32_common: Track when the mouse leaves the windowDiogo Franco (Kovensky)2013-07-251-0/+15
| | | | | | | | | Windows doesn't send WM_MOUSELEAVE by default unless you ask it to; request tracking for leave events when the mouse enters the window (or is moved). Tracking is automatically de-activated once the mouse leaves the window, so we have to re-request it every time the mouse re-enters the window.
* w32_common: show the cursor in the window borderJames Ross-Gowan2013-07-211-6/+21
| | | | | | | | | | | | | | | | | | When the cursor was in the window border, it could be hidden but it wouldn't appear again, since mpv doesn't process mouse input there. The code used ShowCursor, which is a horrid stateful API designed for mouseless Win16 systems that incremented or decremented a global counter to keep track of how many applications needed to display a special cursor (like a busy cursor.) Replace that with a simple flag, handle WM_SETCURSOR and use SetCursor(NULL) to hide the mouse cursor, but only when the mouse is in the client area. DefWindowProc will set the correct cursor on the border as long as it isn't hidden with ShowCursor. PowerPoint also uses SetCursor(NULL) to hide the cursor when showing a presentation, so it's probably safe. See http://blogs.msdn.com/b/oldnewthing/archive/2009/12/17/9937972.aspx
* video: remove fullscreen flags chaoswm42013-07-181-12/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a MPOpts fullscreen field, a mp_vo_opts.fs field, and VOFLAG_FULLSCREEN. Remove all these and introduce a mp_vo_opts.fullscreen flag instead. When VOs receive VOCTRL_FULLSCREEN, they are supposed to set the current fullscreen mode to the state in mp_vo_opts.fullscreen. They also should do this implicitly on config(). VOs which are capable of doing so can update the mp_vo_opts.fullscreen if the actual fullscreen mode changes (e.g. if the user uses the window manager controls). If fullscreen mode switching fails, they can also set mp_vo_opts.fullscreen to the actual state. Note that the X11 backend does almost none of this, and it has a private fs flag to store the fullscreen flag, instead of getting it from the WM. (Possibly because it has to deal with broken WMs.) The fullscreen option has to be checked on config() to deal with the -fs option, especially with something like: mpv --fs file1.mkv --{ --no-fs file2.mkv --} (It should start in fullscreen mode, but go to windowed mode when playing file2.mkv.) Wayland changes by: Alexander Preisinger <alexander.preisinger@gmail.com> Cocoa changes by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
* w32_common: don't use aspdat.asp for aspectwm42013-07-161-1/+2
| | | | | | | | aspdat.asp is a problem, because it's updated when the VO calls vo_get_src_dst_rects(). Nothing guarantees that the value has been updated when the w32 code accesses it. Instead, use the aspect vo_w32_config() was called with.
* core: cleanup more mp_fifo leftoverswm42013-07-021-6/+6
| | | | Now only the OSX and Wayland parts are using this.
* input: require VOs to send key up events, redo input key lookupwm42013-07-021-3/+4
| | | | | | | | | | | | | | Making key up events implicit was sort-of a nice idea, but it's too tricky and unreliable and makes the key lookup code (interpret_keys()) hard to reason about. See e.g. previous commit for subtle bugs and issues this caused. Make key-up events explicit instead. Add key up events to all VOs. Any time MP_KEY_STATE_DOWN is used, the matching key up event must use MP_KEY_STATE_UP. Rewrite the key lookup code. It should be simpler and more robust now. (Even though the LOC increases, because the new code is less "compact".)
* w32_common: prevent display power managementJames Ross-Gowan2013-06-301-0/+3
| | | | | | | | Handling SC_MONITORPOWER doesn't seem to prevent the screen from dimming. The recommended way to do this in Windows XP and Vista is to call SetThreadExecutionState with ES_DISPLAY_REQUIRED. Windows 7 also has the PowerCreateRequest/PowerSetRequest/PowerClearRequest APIs but they're probably too complicated for this task.
* w32_common: prevent that window dragging and mouse input interferewm42013-06-291-1/+1
|
* w32_common: refactor mouse button code, handle mouse up eventswm42013-06-291-31/+39
| | | | | Instead of sending a single event on click, send both down and up events.
* video/out: introduce VOCTRL_UPDATE_WINDOW_TITLEwm42013-06-151-4/+6
| | | | | | | | | | | Instead of implicitly changing the window title on config(), do it as part of the new VOCTRL. At first I wanted to make all VOs use the VOCTRL argument directly, but on a second thought it appears vo_get_window_title() is much more useful for some (namely, if the window is created lazily on first config()). Not all VOs are changed. Wayland and OSX have to follow.
* w32_common: remove some unneeded codewm42013-06-151-5/+3
| | | | vo_w32_init() can be called only once on a VO.
* w32_common: fix non-sensewm42013-06-151-2/+3
| | | | Seriously...
* w32: enable screensaver when pausedwm42013-06-141-2/+12
| | | | | | | This is quite similar to the previous commit. Untested. I'm not sure if this is how it's supposed to work. At least --no-stop-screensaver should work in any case.
* w32: use VOCTRL_SET_CURSOR_VISIBILITYwm42013-05-261-6/+7
| | | | | This didn't even implement --cursor-autohide. Now it does, and the behavior of the VOs under Windows change accordingly.
* w32: use vo_w32_control() for all VOswm42013-05-26