summaryrefslogtreecommitdiffstats
path: root/video/out/w32_common.c
Commit message (Collapse)AuthorAgeFilesLines
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* win32: add option to set VO MMCSS profilewm42015-12-061-1/+5
| | | | This was requested.
* w32_common: implement icc-profile-autoJames Ross-Gowan2015-11-261-7/+50
| | | | | | | | | | | | This adds basic support for ICC profiles. Per-monitor profiles are supported. WCS profiles are not supported, but there is an API for converting WCS profiles to ICC, so they might be supported in future. I'm just not sure if anyone actually uses them. Reloading the ICC profile when it's changed in the control panel is also not supported. This might be possible by using the WCS APIs and watching the registry for changes, but there is no official API for it, and as far as I can tell, no other Windows programs can do it.
* win32: don't show progress indicator in idle modeJames Ross-Gowan2015-11-231-5/+12
|
* win32: support taskbar button progress indicatorMartin Herkt2015-11-151-0/+37
| | | | | | | | | | | This adds support for the progress indicator taskbar extension that was introduced with Windows 7 and Windows Server 2008 R2. I don’t like this solution because it keeps its own state and introduces another VOCTRL, but I couldn’t come up with anything less messy. closes #2399
* win32: avoid detection as exclusive fullscreen windowMartin Herkt2015-11-131-1/+1
| | | | | | | | | | | | | | | | | Apparently Windows treats windows that use OpenGL, cover an entire screen and have the WS_POPUP style set or are topmost windows as exclusive fullscreen windows that bypass DWM and cannot be covered by other windows. This means we can’t use dwmflush in fullscreen mode, and it also means that no other window can cover mpv, and it makes the screen flicker when switching to fullscreen mode. This can be avoided by not setting the WS_POPUP flag. Users can still access the old behavior by enabling stay-on-top (which IMO at least makes sense—now we just need to get dwmflush autodetection right to avoid nasty surprises). fixes #2177
* win32: request MMCSS "Playback" profilewm42015-11-081-0/+10
|
* w32: use DisplayConfig API to retrieve correct monitor refresh rateJames Ross-Gowan2015-11-061-18/+38
| | | | | | | | | | This is based on an older patch by James Ross-Gowan. It was rebased and cleaned up. Also, the DWM API usage present in the older patch was removed, because DWM reports nonsense rates at least on Windows 8.1 (they are rounded to integers, just like with the old GDI API - except the GDI API had a good excuse, as it could report only integers). Signed-off-by: wm4 <wm4@nowhere>
* w32: always get screenrc from an HMONITORJames Ross-Gowan2015-11-061-21/+41
| | | | | | | | | | | | | | | | This simplifies update_screen_rect a bit. Unless --fs-screen=all is used, it will always get an HMONITOR and call GetMonitorInfo to determine its dimensions. This will make it easier for the next few commits to determine the colour profile and the refresh rate from the HMONITOR. There is a slight change in behaviour. When selecting a screen that is out of range, such as --screen=9 on a machine with only two monitors, the old code would silently select the last existing monitor. The new code prints an error message and falls back to the default screen (same as the Cocoa code.) Signed-off-by: wm4 <wm4@nowhere>
* w32: remove Win95 and NT4 monitor codeJames Ross-Gowan2015-11-061-25/+4
| | | | | | | | | | | | | | The call to EnumDisplaySettings seems to be a relic from when MPlayer ran on systems that didn't have GetMonitorInfo or SM_CX/CYVIRTUALSCREEN. GetMonitorInfo was loaded dynamically, so it was possible for MPlayer to run without it and use the values returned by EnumDisplaySettings. These are always present in modern versions of Windows, so the values returned from EnumDisplaySettings are always overwritten. Remove the call to EnumDisplaySettings and assume SM_CX/CYVIRTUALSCREEN is always present. Signed-off-by: wm4 <wm4@nowhere>
* vo_direct3d: fix operationwm42015-10-311-2/+1
| | | | | | | | | Regression since commit 93db4233. I think the bit that was forgotten here was to remove the vo_w32_config() return value completely. The VO failed to init because that function always returned 0. This commit removes these bits and fixes the VO. Fixes #2434.
* w32_common: disable IMEJames Ross-Gowan2015-10-231-9/+16
| | | | | | | | | | The IME is not useful for key-bindings. Handle the base ASCII chars instead and don't show the IME window. For the sake of libmpv users, the IME should only be disabled on mpv's GUI thread and not application- wide. No IME on the GUI thread should also mean that VK_PROCESSKEY will never have to be handled, so the logic for that can be removed as well.
* win32: cleanup: remove some unneeded thingswm42015-10-021-14/+7
|
* vo_opengl: w32: switch to new internal APIwm42015-10-021-7/+1
|
* win32: allow multiple windows at the same timewm42015-09-221-6/+1
| | | | | | | | | | | | | | | | Window classes are process-wide (or at least DLL-wide), so you can't have 2 classes with the same name. Our code attempted to do this when for example 2 libmpv instances were created within the same process. This failed, because RegisterWindowEx() fails if the class already exists. Fix this by ignoring RegisterWindowEx() errors. If the class can really not be registered, we will fail on CreateWindowEx() instead. Of course we also can't unregister the class, as another thread might be using it. Windows will free the class automatically if the DLL is unloaded or the process terminates. Fixes #2319 (hopefully).
* w32: shift drag and drop appendsKevin Mitchell2015-08-301-2/+4
| | | | use the append to playlist functionality if shift is pressed while dropping
* input: add append argument to file drop eventKevin Mitchell2015-08-301-2/+3
| | | | | | This puts in place the machinery to merely append dropped file to the playlist instead of replacing the existing playlist. In this commit, all front-ends set this to false preserving the existing behaviour.
* win32: revert wchar_t changeswm42015-08-011-9/+9
| | | | | | | | | | | Revert "win32: more wchar_t -> WCHAR replacements" Revert "win32: replace wchar_t with WCHAR" Doing a "partial" port of this makes no sense anymore from my perspective. Revert the changes, as they're confusing without context, maintenance, and progress. These changes were a bit premature anyway, and might actually cause other issues (locale neutrality etc. as it was pointed out).
* win32: more wchar_t -> WCHAR replacementswm42015-07-301-2/+2
| | | | | | | | | | | | | This was essentially missing from commit 0b52ac8a. Since L"..." string literals have the type wchar_t[], we can't use them for UTF-16 strings. Use C11 u"..." string literals instead. These have the type char16_t[], but we simply assume char16_t is the same underlying type as WCHAR. In practice, they're both unsigned short. For this reason use -std=c11 on Windows. Since Windows is a "special" environment (we require either MinGW or Cygwin), we don't need to worry too much about compiler compatibility.
* win32: replace wchar_t with WCHARwm42015-07-291-8/+8
| | | | | | | | | | | | | WCHAR is more portable. While at least MinGW, Cygwin, and MSVC actually use 16 bit wchar_t, Midipix will have 32 bit wchar_t. In that context, using WCHAR instead is more portable. This affects only non-MinGW parts, so not all uses of wchar_t need to be changed. For example, terminal-win.c won't be used on Midipix at all. (Most of io.c won't either, so the search & replace here is more than necessary, but also not harmful.) (Midipix is not useable yet, so this is just preparation.)
* win32: remove a wine hackwm42015-06-201-8/+1
| | | | | | | No particular reason, but it's still possible that it causes additional corner cases, and it's not really needed to test this on wine (other than testing fullscreen stuff, which should be done on a real Windows anyway).
* win32: prefer using internal variable for fullscreenwm42015-06-201-11/+12
| | | | | | No particular reason, but since we already have an internal variable, it's better than using the option struct, which will be redone sooner or later.
* win32: use atomics for COM interface refcountwm42015-06-141-4/+5
|
* win32: fix window resize logicwm42015-05-311-2/+3
| | | | | | Reconfiguring with the same video size should never cause the window to resize back to the video size (if the user changed its size). This was broken and it resized anyway.
* w32_common: add more rounded-down frame ratesJames Ross-Gowan2015-04-251-0/+4
| | | | | Suggested by avih. This handles x/1.001 frame rates for all multiples of 24 and 30 under 144.
* w32_common: use the current monitor's refresh rateJames Ross-Gowan2015-04-251-9/+10
|
* w32_common: prevent system sleepJames Ross-Gowan2015-04-201-1/+2
| | | | | | This prevents the machine from going to sleep while a video-only stream is playing. When audio is playing, the audio stack should make this request for us.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* win32: support get display fpsAvi Halachmi (:avih)2015-03-131-0/+54
|
* w32_common: don't hide cursor when the menu is openJames Ross-Gowan2015-03-131-8/+8
| | | | | | | | | | | | Previously, mpv would hide the cursor when the autohide timer expired, even if the window menu was open. This made it difficult to use the menu with the mouse. When handling VOCTRL_SET_CURSOR_VISIBILITY, instead of determining whether to call SetCursor by checking if the cursor is in the client area, call it based on the parameters to the last WM_SETCURSOR message. When the window enters "menu mode," it gets a WM_SETCURSOR message with HIWORD(lParam) set to 0 to indicate that the cursor shouldn't be set.
* w32_common: remove redundant is_maximized functionJames Ross-Gowan2015-03-091-8/+1
| | | | This already exists as IsMaximized in the Windows API.
* w32_common: support the "window-minimized" propertyJames Ross-Gowan2015-03-091-0/+6
|
* win32: fix some more -Wparentheses warningswm42015-03-041-1/+1
| | | | | | | Stupid compiler. For decode_surrogate_pair(), I changed the order of evaluation; it shouldn't matter, but this order is more readable in my opinion.
* input: add MOUSE_ENTER keybinding.torque2015-02-181-1/+3
| | | | Signed-off-by: wm4 <wm4@nowhere>
* win32: don't resize when window is minimizedwm42015-02-021-5/+6
| | | | | | | | At least the opengl-hq VO allocates additional resources when downscaling a lot, which is just a waste. Also see #1547 (although I doubt that this is the cause; if it is, a real fix will be required).
* command: unify handling of fullscreen and other VO flagswm42015-01-161-0/+1
| | | | | | | | The "ontop" and "border" properties already used a common mp_property_vo_flag() function, and the corresponding VOCTRLs used the same conventions. "fullscreen" is pretty similar, but was handled slightly similar. Change how VOCTRL_FULLSCREEN behaves, and use the same helper function for "fullscreen" as the other flags.
* win32: minor simplificationwm42015-01-081-3/+2
| | | | The events parameter is not needed here and won't ever be.
* win32: request UTF-16 API variants, Vista+ APIs, and COM C macroswm42015-01-071-2/+0
| | | | | Put the Vista+ (_WIN32_WINNT) and the COM C (COBJMACROS) defines into the build system, instead of defining them over and over in the code.
* w32_common: allow window resizing with --no-borderJames Ross-Gowan2014-12-291-0/+58
|
* Revert "vo/w32_common: use local definition of IID_ITaskbarList2"Kevin Mitchell2014-12-161-7/+1
| | | | | | This reverts commit 17067343eb10293beb61d3811680b9c59f4db311. Embarassingly, this turned out not to be necessary.
* vo/w32_common: use local definition of IID_ITaskbarList2Kevin Mitchell2014-12-151-1/+7
| | | | It is not defined in the current cygwin release.
* w32: copy WinID optionwm42014-12-091-14/+14
| | | | See previous and next commit.
* w32_common: fix GUID linking in CygwinJames Ross-Gowan2014-12-091-0/+1
|
* w32_common: ensure taskbar is hidden when fullscreenJames Ross-Gowan2014-12-081-2/+28
| | | | | | | | | | | | | | | Windows uses a heuristic to determine if a window should appear fullscreen. If the active window's client area covers the whole screen, the taskbar should move to the bottom of the Z-order, allowing the window to show through. Unfortunately, sometimes it doesn't work and the taskbar stays on top of the "fullscreen" window. ITaskbarList2->MarkFullscreenWindow explicitly tells the shell that a window wants to be fullscreen, so the taskbar is always at the bottom of the Z-order while the marked window is active. This might help with #999. Firefox also uses this interface to fix fullscreen issues.
* win32: add screen offset when handling overlarge windowswm42014-11-281-2/+2
| | | | | | | | | | | MS Windows doesn't allow windows larger than the screen, so we include a hack to make the window smaller. This hack recenters the window (what else would it do?). It didn't account for the virtual offset of the current screen, and it was reported that it forces the window to the first screen. Should fix #1292.
* w32_common: open window menu on Alt+SpaceJames Ross-Gowan2014-11-081-0/+10
| | | | | | Since mpv doesn't call TranslateMessage, this must be done manually. Should fix #1254
* Revert "w32_common: don't override alt+space"wm42014-11-081-16/+8
| | | | | | | | This reverts commit d859549424174179768fcd0310c75823a5ff7cb1. Going to apply the alternative fix through PR #1256, which came just some seconds after pushing the reverted commit. The reverted commit was reported as not actually working.
* w32_common: don't override alt+spacewm42014-11-081-8/+16
| | | | | | Apparently, stealing this from the WM is bad form, just like with F10. Fixes #1254.
* Set thread name for debuggingwm42014-10-191-0/+3
| | | | | | | | | | Especially with other components (libavcodec, OSX stuff), the thread list can get quite populated. Setting the thread name helps when debugging. Since this is not portable, we check the OS variants in waf configure. old-configure just gets a special-case for glibc, since doing a full check here would probably be a waste of effort.
* win32: clear window handle on destructionwm42014-10-171-0/+1
| | | | | | As I understand, otherwise, the code will try to destroy the same window again in the cleanup part of the gui_thread(), which makes no sense and is potentially dangerous.
* options: add --no-keepaspect-windowwm42014-10-041-2/+2
| | | | Seems silly, but was requested.
* w32_common: quit event loop on destroyJames Ross-Gowan2014-09-301-6/+11
| | | | | | | | | | | | When embedding, if the parent window is destroyed, it will cause mpv's window to be destroyed as well. Since WM_USER wakeups are sent to the window, destroying the window will prevent wakeups and cause uninit to hang. Fix this by quitting the event loop on WM_DESTROY. Events should only be processed for the lifetime of the window, from CreateWindowEx to WM_DESTROY. After the event loop is finished, mp_dispatch_queue_process can handle any remaining requests.
* 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