w32_common: Implement --screen-name #16098

BreadFish64 · 2025-03-23T01:49:06Z

Previously the --screen-name and --fs-screen-name options did nothing on Windows.

It now attempts to convert a friendly monitor name to the GDI device name using the DisplayConfig API first. The friendly name is the shown in Windows settings like "Dell AW3423DW". Otherwise, assume it's already a GDI device name like "\.\DISPLAY1".

Edit: Added commit

w32_common: add display-names/friendly property

The friendly subkey return the same set of displays as display-names
but it attempts to convert the names to the human-friendly name that
DisplayConfig obtains from the EDID.

kasper93 · 2025-03-23T01:54:44Z

Nice. Could you also extend mp_property_display_names with the friendly name? It was requested feature #13743 to use in scripts instead of device name.

github-actions · 2025-03-23T02:06:36Z

Download the artifacts for this pull request:

Windows

macOS

BreadFish64 · 2025-03-23T02:16:44Z

@kasper93 Do you want to just change it from the GDI names to the friendly names completely? That seems easy enough.

kasper93 · 2025-03-23T02:29:41Z

@kasper93 Do you want to just change it from the GDI names to the friendly names completely? That seems easy enough.

Not sure, there may be users who wants GDI names. Maybe we do M_PROPERTY_KEY_ACTION with friendly key? So display-names return GDI names as it do now and new display-names/friendly would return friendly device name?

BreadFish64 · 2025-03-23T03:08:23Z

Sounds reasonable. I'll poke at it tomorrow.

BreadFish64 · 2025-03-23T20:52:46Z

Added the friendly subkey.
You can try it by dragging the window around with this script

function func(_, value)
    local display_names = mp.get_property("display-names")
    if display_names then
        print("Display names:\n" .. display_names .. "\n")
    end
    if value then
        print("Friendly display names:\n" .. value .. "\n")
    end
end

mp.observe_property("display-names/friendly", "string", func)

player/command.c

video/out/w32_common.c

video/out/win32/displayconfig.c

video/out/win32/displayconfig.h

kasper93 · 2025-03-23T21:39:19Z

video/out/win32/displayconfig.c

+end:
+    talloc_free(ctx);
+    return monitor_friendly_device_name;
+}


Could you move common part to separate function, just to avoid duplication, even if it's not that much.

Hmm, yeah it seems like there should be a way to combine these, but since they use two different query structs, DISPLAYCONFIG_SOURCE_DEVICE_NAME and DISPLAYCONFIG_TARGET_DEVICE_NAME, there's not much overlap.

You could move lines 230-248 and 190-204 to separate functions and call in common function based on flag which one name you want to get.

DOCS/man/input.rst

Previously the --screen-name and --fs-screen-name options did nothing on Windows. It now attempts to convert a friendly monitor name to the GDI device name using the DisplayConfig API first.

The `friendly` subkey return the same set of displays as `display-names` but it attempts to convert the names to the human-friendly name that DisplayConfig obtains from the EDID.

kasper93 · 2025-03-26T01:03:27Z

video/out/win32/displayconfig.c

+end:
+    talloc_free(ctx);
+    return monitor_friendly_device_name;
+}


You could move lines 230-248 and 190-204 to separate functions and call in common function based on flag which one name you want to get.

kasper93 · 2025-03-26T01:13:53Z

video/out/w32_common.c

+static BOOL CALLBACK get_monitor_by_name_proc(HMONITOR mon, HDC dc, LPRECT r,
+                                              LPARAM p)
+{
+    struct get_monitor_by_name_data *const data = (struct get_monitor_by_name_data*)p;


Suggested change

struct get_monitor_by_name_data *const data = (struct get_monitor_by_name_data*)p;

struct get_monitor_by_name_data *const data = (struct get_monitor_by_name_data *)p;

kasper93 · 2025-03-26T01:14:06Z

video/out/w32_common.c

+{
+    struct get_monitor_by_name_data *const data = (struct get_monitor_by_name_data*)p;
+
+    MONITORINFOEXW mi = { .cbSize = sizeof mi };


Suggested change

MONITORINFOEXW mi = { .cbSize = sizeof mi };

MONITORINFOEXW mi = { .cbSize = sizeof(mi) };

kasper93 · 2025-03-26T01:16:50Z

video/out/w32_common.c

+    struct get_monitor_by_name_data *const data = (struct get_monitor_by_name_data*)p;
+
+    MONITORINFOEXW mi = { .cbSize = sizeof mi };
+    if (GetMonitorInfoW(mon, (MONITORINFO*)&mi)) {


Suggested change

if (GetMonitorInfoW(mon, (MONITORINFO*)&mi)) {

if (GetMonitorInfoW(mon, (LPMONITORINFO)&mi)) {

kasper93 · 2025-03-26T01:18:50Z

video/out/w32_common.c

+    return TRUE;
+}
+
+static HMONITOR get_monitor_by_name(const wchar_t* name)


Suggested change

static HMONITOR get_monitor_by_name(const wchar_t* name)

static HMONITOR get_monitor_by_name(const wchar_t *name)

kasper93 · 2025-03-26T01:23:39Z

video/out/w32_common.c

+static void disp_names_append(HMONITOR mon, struct disp_names_data *data)
+{
+    MONITORINFOEXW mi = { .cbSize = sizeof mi };
+    if (GetMonitorInfoW(mon, (MONITORINFO*)&mi)) {


Same remarks as before.

CogentRedTester · 2025-03-26T09:02:59Z

DOCS/man/input.rst

+    ``display-names/friendly``
+        These are the human-friendly names obtained from the monitor EDID
+        (Dell AW3223DW, LC34G55T, etc.). These follow the same order as
+        ``display-names`` (Windows only)


Might it be worth making the property available on all systems, but merely act as a duplicate of display-names for non-windows systems? That way scripts, keybinds, and auto-profiles don't need to worry about the platform when grabbing useful display names, they could just grab display-names/friendly and have it work on all systems.

Edit: or would this impact adding friendlier names for other platforms later?

On linux, the display names are already friendly (i.e. like DP-1). I think macOS is similar. As opposed to "friendly" names, this seems to be more like the model name of the display. It's certainly possible to add it to other platforms.

We can handle this new VOCTRL everywhere, for now with the same impl, and extended if needed.

just as info, on macOS it's something like DELL U2723QE (12343224), name + serial number.
f7a32b5

Akemi · 2025-03-26T15:17:39Z

just wanted to mention, when i changed the display names on macOS in f7a32b5 i had the problem that those 'friendly' names are not deterministic, see the commit. eg same model displays have the same name or were numerated 'randomly'. that's the reason why i added the serial number to those names, to make them unique.

you might have the same problem here.

kasper93 · 2025-03-26T15:20:02Z

just wanted to mention, when i changed the display names on macOS in f7a32b5 i had the problem that those 'friendly' names are not deterministic, see the commit. eg same model displays have the same name or were numerated 'randomly'. that's the reason why i added the serial number to those names, to make them unique.

you might have the same problem here.

Yes, exactly, that's why I suggested to keep GDI path that and friendly name too.

Dudemanguy · 2025-03-26T15:47:07Z

Having multiple names exposed for the same display makes sense to me. How do we want to separate it? The existing display-names could be the names of the connectors (like HDMI-1, etc.) and we could have a display-names/model for the model name? I don't know if that makes sense on other platforms but at least on linux that would be the idea. --screen-name and similar options could accept either one.

kasper93 · 2025-03-26T15:51:15Z

So display-names/friendly would get renamed to display-names/model. Also following the concern from @Akemi, we can append (N) to duplicated names. Or unify and get some serial number.

Though, I once was thinking about it long time ago and wanted to do model name (GDI path) but this gets verbose and long. So for /model short index would be preferable. And for display-names it would be always unambiguous path returned from API.

And I agree, this is good opportunity to unify it little bit between macOS, Wayland and Windows.

dyphire · 2025-03-26T16:05:26Z

So display-names/friendly would get renamed to display-names/model. Also following the concern from @Akemi, we can append (N) to duplicated names. Or unify and get some serial number.

I think it would be better to append the serial number to the monitor name, while maintaining consistency with the behavior on macos.

Though, I once was thinking about it long time ago and wanted to do model name (GDI path) but this gets verbose and long. So for /model short index would be preferable. And for display-names it would be always unambiguous path returned from API.

I don't think it's a good idea to append the GDI path to the monitor name. As mentioned in #13743, the GDI path assigned to each monitor by the Windows system is not fixed, it changes for various reasons. This makes the property will remain unusable for persistent configuration. Glad to know it's an abandoned idea.

Akemi · 2025-03-26T16:53:41Z

So display-names/friendly would get renamed to display-names/model. Also following the concern from @Akemi, we can append (N) to duplicated names. Or unify and get some serial number.

for duplicate name also keep runtime in mind, eg you plug in the first display it would be ["Display"], plugging in a second one of the same model it would be ["Display (1)", "Display (2)"]. the first display would change names in that case. names would be unique but not deterministic.

kasper93 · 2025-03-26T17:03:44Z

So display-names/friendly would get renamed to display-names/model. Also following the concern from @Akemi, we can append (N) to duplicated names. Or unify and get some serial number.

for duplicate name also keep runtime in mind, eg you plug in the first display it would be ["Display"], plugging in a second one of the same model it would be ["Display (1)", "Display (2)"]. the first display would change names in that case. names would be unique but not deterministic.

It would be ["Display", "Display (1)"], but if you change order in which system sees them, they could swap. Which is similar issue that is with GDI that can change when reinstalling driver or changing configuration.

If we want to have physical label, the serial number is an option, though it's not that friendly, because you wouldn't use it anywhere else except mpv. Connector number would be good too, but not sure if either of this information is easy to extract in Windows.

Akemi · 2025-03-26T17:56:22Z

then you would also have the case that both display are plugged in already. would it be ["Display", "Display (1)"] or ["Display (1)", "Display (2)"]. anyway, my case is that it's not deterministic. also in the case that you mentioned.

i also want to mention that serial numbers aren't safe either in following cases:

displays have 'null' serial numbers or any kind of fuck up, like same serial numbers etc. both cases are not unheard of. some manufactures give a whole batch of displays the same serial number, or so i have heard
if you plug in the same display twice (on two different ports) or more

the latter case could be valid, for example when using the display's PiP/PaP features.

BreadFish64 force-pushed the windows_screenname branch from 82b9487 to f9cecec Compare March 23, 2025 02:15

BreadFish64 force-pushed the windows_screenname branch from 374f2bd to f15318a Compare March 23, 2025 20:29

kasper93 reviewed Mar 23, 2025

View reviewed changes

kasper93 added this to the Release v0.41.0 milestone Mar 23, 2025

BreadFish64 force-pushed the windows_screenname branch from f15318a to 4d9b7eb Compare March 24, 2025 02:12

BreadFish64 added 2 commits March 23, 2025 21:12

w32_common: implement --screen-name

088d99f

Previously the --screen-name and --fs-screen-name options did nothing on Windows. It now attempts to convert a friendly monitor name to the GDI device name using the DisplayConfig API first.

w32_common: add display-names/friendly property

e740125

The `friendly` subkey return the same set of displays as `display-names` but it attempts to convert the names to the human-friendly name that DisplayConfig obtains from the EDID.

BreadFish64 force-pushed the windows_screenname branch from 4d9b7eb to e740125 Compare March 24, 2025 02:12

kasper93 reviewed Mar 26, 2025

View reviewed changes

CogentRedTester mentioned this pull request Mar 26, 2025

Script isn't working CogentRedTester/mpv-changerefresh#11

Closed

CogentRedTester reviewed Mar 26, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

w32_common: Implement --screen-name #16098

w32_common: Implement --screen-name #16098

BreadFish64 commented Mar 23, 2025 •

edited

Loading

kasper93 commented Mar 23, 2025

github-actions bot commented Mar 23, 2025 •

edited

Loading

BreadFish64 commented Mar 23, 2025

kasper93 commented Mar 23, 2025

BreadFish64 commented Mar 23, 2025

BreadFish64 commented Mar 23, 2025

kasper93 Mar 23, 2025

BreadFish64 Mar 24, 2025

kasper93 Mar 26, 2025

kasper93 Mar 26, 2025

kasper93 Mar 26, 2025

kasper93 Mar 26, 2025

kasper93 Mar 26, 2025

kasper93 Mar 26, 2025

kasper93 Mar 26, 2025

CogentRedTester Mar 26, 2025 •

edited

Loading

Dudemanguy Mar 26, 2025

kasper93 Mar 26, 2025

Akemi Mar 26, 2025 •

edited

Loading

Akemi commented Mar 26, 2025

kasper93 commented Mar 26, 2025

Dudemanguy commented Mar 26, 2025

kasper93 commented Mar 26, 2025

dyphire commented Mar 26, 2025 •

edited

Loading

Akemi commented Mar 26, 2025

kasper93 commented Mar 26, 2025

Akemi commented Mar 26, 2025

	struct get_monitor_by_name_data const data = (struct get_monitor_by_name_data)p;
	struct get_monitor_by_name_data const data = (struct get_monitor_by_name_data )p;

	MONITORINFOEXW mi = { .cbSize = sizeof mi };
	MONITORINFOEXW mi = { .cbSize = sizeof(mi) };

	if (GetMonitorInfoW(mon, (MONITORINFO*)&mi)) {
	if (GetMonitorInfoW(mon, (LPMONITORINFO)&mi)) {

	static HMONITOR get_monitor_by_name(const wchar_t* name)
	static HMONITOR get_monitor_by_name(const wchar_t *name)

w32_common: Implement --screen-name #16098

Are you sure you want to change the base?

w32_common: Implement --screen-name #16098

Conversation

BreadFish64 commented Mar 23, 2025 • edited Loading

kasper93 commented Mar 23, 2025

github-actions bot commented Mar 23, 2025 • edited Loading

BreadFish64 commented Mar 23, 2025

kasper93 commented Mar 23, 2025

BreadFish64 commented Mar 23, 2025

BreadFish64 commented Mar 23, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CogentRedTester Mar 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Akemi Mar 26, 2025 • edited Loading

Choose a reason for hiding this comment

Akemi commented Mar 26, 2025

kasper93 commented Mar 26, 2025

Dudemanguy commented Mar 26, 2025

kasper93 commented Mar 26, 2025

dyphire commented Mar 26, 2025 • edited Loading

Akemi commented Mar 26, 2025

kasper93 commented Mar 26, 2025

Akemi commented Mar 26, 2025

BreadFish64 commented Mar 23, 2025 •

edited

Loading

github-actions bot commented Mar 23, 2025 •

edited

Loading

CogentRedTester Mar 26, 2025 •

edited

Loading

Akemi Mar 26, 2025 •

edited

Loading

dyphire commented Mar 26, 2025 •

edited

Loading