summaryrefslogtreecommitdiffstats
path: root/video/out/w32_common.c
Commit message (Collapse)AuthorAgeFilesLines
* w32_common, w32_keyboard: change license to LGPLwm42017-06-241-7/+7
| | | | All authors agreed.
* w32_common: drop TLS usageJames Ross-Gowan2017-05-161-20/+21
| | | | | | | | | | | This was added in 3f268cc4f2a4 because it wasn't clear whether WM_NCCREATE could be used to send a context pointer from CreateWindowEx to the window procedure. WM_NCCREATE isn't always the first message sent to a window, but this seems to be because of an undocumented but well-known bug where, for top-level overlapped windows, a spurious WM_GETMINMAXINFO arrives first instead. The WM_GETMINMAXINFO can be safely ignored, so it is still okay to pass the context struct in WM_NCCREATE.
* w32_common: use the proper keycodes for XBUTTON1/2James Ross-Gowan2017-05-121-2/+2
| | | | | | | 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.
* w32_common: generate MP_AXIS_* keycodes for scrollingJames Ross-Gowan2017-05-121-8/+18
| | | | | | | | | | | 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.
* w32_common: refactor mouse button handlingJames Ross-Gowan2017-04-041-39/+47
| | | | | | | 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.
* w32_common: fix undefined behaviour when toggling fullscreenJames Ross-Gowan2017-04-021-222/+214
| | | | | | | 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.
* w32_common: move the IDropTarget impl to a separate fileJames Ross-Gowan2017-03-261-201/+3
| | | | | | 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.
* win32: update the fullscreen state on restoringpavelxdd2017-02-121-1/+22
| | | | | If a maximized window restored from fullscreen, the fullscreen state needs to be updated manually.
* win32: snap to screen edgespavelxdd2017-01-271-0/+146
| | | | | | | Disabled by default. The snap sensitivity value depends on the screen DPI. The default value is 16px on a 96 DPI screen. Fixes #2248
* win32: fix for wm_syscommandpavelxdd2017-01-051-1/+1
| | | | | | | | According to MSDN, in WM_SYSCOMMAND messages, the four low-order bits of the wParam parameter are used internally by the system. To obtain the correct result when testing the value of wParam, an application must combine the value 0xFFF0 with the wParam value by using the bitwise AND operator.
* win32: change the log level of 'move window' msgpavelxdd2016-12-141-1/+1
| | | | It does more harm than good, since it spams terminal a lot
* win32: window styles improvementspavelxdd2016-12-121-4/+9
| | | | | | | Allow minimizing the borderless/fullscreen window by clicking on the taskbar button or pressing Win+Down hotkey. Also fixes #2229 and probably fixes #2451
* win32: update winapi functions namespavelxdd2016-12-121-3/+3
| | | | | | According to MSDN, GetWindowLong and SetWindowLong have been superseded by GetWindowLongPtr and SetWindowLongPtr. It's a cosmetic code change in this case.
* w32_common: implement VOCTRL_GET_DISPLAY_NAMESJames Ross-Gowan2016-09-291-0/+52
| | | | | | | | This should make display-names usable on Windows. It returns a list of GDI monitor names like "\\.\DISPLAY1". Since it may be useful to get the monitor that Windows considers associated with the window (with MonitorFromWindow,) this will always be returned as the first argument. This monitor is the one used for display-fps and icc-profile-auto.
* win32: build with -DINITGUIDJames Ross-Gowan2016-09-281-1/+0
| | | | | | | | | | | | We always want to use __declspec(selectany) to declare GUIDs, but manually including <initguid.h> in every file that used GUIDs was error-prone. Since all <initguid.h> does is define INITGUID and include <guiddef.h>, we can remove all references to <initguid.h> and just compile with -DINITGUID to get the same effect. Also, this partially reverts 622bcb0 by re-adding libuuid.a to the build, since apparently some GUIDs (such as GUID_NULL) are not declared in the source file, even when INITGUID is set.
* player: use better way to wait for input and dispatching commandswm42016-09-161-0/+2
| | | | | | | | | | | | | | | | | | | Instead of using input_ctx for waiting, use the dispatch queue directly. One big change is that the dispatch queue will just process commands that come in (e.g. from client API) without returning. This should reduce unnecessary playloop excutions (which is good since the playloop got a bit fat from rechecking a lot of conditions every iteration). Since this doesn't force a new playloop iteration on every access, this has to be enforced manually in some cases. Normal input (via terminal or VO window) still wakes up the playloop every time, though that's not too important. It makes testing this harder, though. If there are missing wakeup calls, it will be noticed only when using the client API in some form. At this point we could probably use a normal lock instead of the dispatch queue stuff.
* osdep: rename atomics.h to atomic.hwm42016-09-071-1/+1
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* w32_common: initialize playback status as soon as possiblewm42016-09-021-16/+25
| | | | | | | | On a VOCTRL_UPDATE_PLAYBACK_STATE store the state, and use it to initialize the next time the task list becomes available. This actually fixes #3482. Revert commit f2e25e9e because it's not needed anymore.
* vo: update w32_common left out by 4d75514quilloss2016-08-311-3/+0
|
* w32_common: use hooks to detect parent window resizeJames Ross-Gowan2016-08-261-35/+117
| | | | | | | | | | | | | | | | | | | | | | | Because VOCTRL_CHECK_EVENTS is processed asynchronously (as of 088a007,) the GUI thread no longer gets regular wakeups, so the old check that made sure the video window matched the parent window's size in --wid embedding mode did not run very often. This made --wid embedding not very usable. Instead of polling for window size changes, use Windows hooks to react to them when they happen. When the parent window is owned by the same process as the video window, use a WH_CALLWNDPROC hook. When the parent window is not owned by the same process, WinEvents must be used, which are not as smooth, but still work for this purpose. Since neither SetWindowsHookEx nor SetWinEventHook take a context parameter to send data to the hook function, the hook functions must find the child window by its class instead, so there are a few changes to ensure this is fast and the class is unique. This also fixes up the logic to handle window destruction. When a parent window is destroyed, its children are also destroyed, so this gives us a way to react to parent window destruction without polling.
* w32_common: update window size on resize eventswm42016-08-071-0/+6
| | | | | | Fixes a regression introduced by commit 088a0075. Fixes #3400.
* w32_common: don't wait for GUI thread when polling for eventswm42016-08-051-8/+12
| | | | | | | | | | | | | | | | | | | | VOCTRL_CHECK_EVENTS is called on every frame. This is by design, and is supposed to check the event queue of the windowing API. With the decoupled GUI thread in w32_common.c this doesn't make too much sense, and the purpose of VOCTRL_CHECK_EVENTS is really reduced to checking event flags. Even worse, waiting on the GUI thread can interfere with playback, since win32 sometimes blocks the event loop (e.g. clicking the window title bar). Change the code such that we really only query the event flags. Use atomics to avoid having to add a new mutex. (We assume we always have real atomics available. The build system doesn't check this properly, and it could fall back to dummy atomics, which are not atomic.) Should help with #3393. Doesn't help if the core happens to send a synchronous request, most commonly via VOCTRL_SET_CURSOR_VISIBILITY or VOCTRL_UPDATE_PLAYBACK_STATE.
* w32_common: make WM_NCHITTEST simpler and more accurateJames Ross-Gowan2016-07-031-15/+13
| | | | | | | | This makes the geometry of the sizing borders more like the ones in Windows 10. It also fixes an off-by-one error that made the right and bottom borders thinner than the left and top borders, which made it difficult to resize the window when using the Windows 7 classic theme (because it has pretty thin sizing borders to begin with.)
* Fix misspellingsstepshal2016-06-261-1/+1
|
* win32: use HINST_THISCOMPONENTJames Ross-Gowan2016-06-111-7/+8
| | | | | | | | | | | | | | | This is a common idiom used in MSDN docs and Raymond Chen's example programs to get a HINSTANCE for the current module, regardless of whether it's an .exe or a .dll. Using GetModuleHandle(NULL) for this is technically incorrect, since it always gets a handle to the .exe, even when the executing code (in libmpv) is running in a .dll. In this case, using the wrong HINSTANCE could cause namespace issues with window classes, since CreateWindowEx uses the HINSTANCE to search for the matching window class name. See: https://blogs.msdn.microsoft.com/oldnewthing/20050418-59/?p=35873 https://blogs.msdn.microsoft.com/oldnewthing/20041025-00/?p=37483
* w32_common: center window on original window center on video resizemaniak13492016-05-301-0/+8
| | | | | | Position the window around the original window center on video size change (when switching to the next file with different resolution, for example) instead of keeping the position of its top-left corner fixed.
* w32_common: make VOCTRL_SET_UNFS_WINDOW_SIZE resize the window around its centermaniak13492016-05-221-0/+4
| | | | | | | | | | Before that position of the window top-left corner was remaining the same when the window was scaled. Right now VOCTRL_SET_UNFS_WINDOW_SIZE is called only by window-scale. This change will not affect resizes made by the user (dragging window edge). Fixes #3164.
* w32_common: center window on original window center on resize to fit screenmaniak13492016-05-221-3/+6
| | | | | | | | | | Center the window on the original window center instead of the screen center when the window has been resized due to requested window size exceeding the size of the screen. If user moved the window, he probably did it for the reason and he probably don't want it to get back to the center of the screen when he is resizing it (with window-scale for example).
* w32_common: update stored client area size on window resizemaniak13492016-05-221-0/+10
| | | | | | | | Properly update stored client area size when the window is resized in reinit_window_state due to window size exceeding the size of the screen. This was causing wrong behavior with window-scale - when window size was becoming too big the window was resized but the video was not.
* win32: make taskbar progress indication optionalmaniak13492016-05-081-1/+1
| | | | | | | | | | | Add --taskbar-progress command line option and property which controls taskbar progress indication rendering in Windows 7+. This option is on by default and can be toggled during playback. This option does not affect the creation process of ITaskbarList3. When the option is turned off the progress bar is just hidden with TBPF_NOPROGRESS. Closes #2535
* win32: replace libuuid.a usage with initguid.hJames Ross-Gowan2016-05-011-1/+1
| | | | | | | | | | | | | | | Including initguid.h at the top of a file that uses references to GUIDs causes the GUIDs to be declared globally with __declspec(selectany). The 'selectany' attribute tells the linker to consolidate multiple definitions of each GUID, which would be great except that, in Cygwin and MinGW GCC 6.1, this method of linking makes the GUIDs conflict with the ones declared in libuuid.a. Since initguid.h obsoletes libuuid.a in modern compilers that support __declspec(selectany), add initguid.h to all files that use GUIDs and remove libuuid.a from the build. Fixes #3097
* w32_common: respect --fit-border on size checkmaniak13492016-04-301-4/+20
| | | | | | Fit whole window or just a client area in accord with value of --fit-border option. Fixes #2935.
* w32_common: fix size calculations for window resizemaniak13492016-04-301-3/+3
| | | | | | | Substraction of 1 is not necessary due to .right and .bottom values of RECT struct describing a point one pixel outside of the rectangle. Fixes #2935. (2.b)
* w32_common: switch to UniformResourceLocatorWwm42016-02-021-3/+5
| | | | | | | | This is the "unicode" version of it. It appears Firefox uses it now? I'm not sure if we still need to support the old variant, but hopefully not. Fixes #2782.
* 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
| | |