[vlc-devel] [PATCH] Send fullscreen video to specific monitor

Gabriel Luci github at luci.ca
Mon Oct 7 14:42:27 CEST 2019

The Qt option is handled by Qt, yes, but it only works when the video is
embedded in the interface, which means you can't keep the controls on the
primary monitor. (I assume that's because a non-embedded video window isn't
handled by Qt anymore)

I was chatting with Alexandre off-list about this and came to a similar
conclusion. So I agree this patch can be discarded as I wrote it, and I can
resubmit with a different approach.

First, in modules/video_output/win32/window.c, I can use the id parameter
to determine the name of the monitor. I guess that's why the parameter is

Then another patch would create a new setting with the monitor name and
pass it into that id parameter from further up the call stack. I think we
could go further up the call stack than vout_window_SetFullScreen(). When I
look at the call stack, I see this:

    libwin32_window_plugin.dll!SetFullscreen(vout_window_t * wnd, const
char * id) (c:\vlc\vlc\modules\video_output\win32\window.c:189)
    libvlccore.dll!vout_window_SetFullScreen(const char * id, vout_window_t
* window) (c:\vlc\vlc\include\vlc_vout_window.h:479)
    libvlccore.dll!vout_ChangeFullscreen(vout_thread_t * vout, const char *
id) (c:\vlc\vlc\src\video_output\video_output.c:390)
    libvlccore.dll!FullscreenCallback(vlc_object_t * p_this, const char *
psz_cmd, vlc_value_t oldval, vlc_value_t newval, void * p_data)
    libvlccore.dll!TriggerCallback(vlc_object_t * obj, variable_t * var,
const char * name, vlc_value_t prev) (c:\vlc\vlc\src\misc\variables.c:252)
    libvlccore.dll!var_SetChecked(vlc_object_t * p_this, const char *
psz_name, int expected_type, vlc_value_t val)
    libvlccore.dll!vlc_player_vout_SetVar(vlc_player_t * player, const char
* name, int type, vlc_value_t val) (c:\vlc\vlc\src\player\vout.c:161)
    libvlccore.dll!vlc_player_vout_SetFullscreen(vlc_player_t * player,
_Bool enabled) (c:\vlc\vlc\src\player\vout.c:180)

At  vout_intf.c:569 (FullscreenCallback) is where it
calls vout_ChangeFullscreen(p_vout, NULL); where id is NULL. So that is
where I'm guessing it could be reading the setting and passing it as the id
instead of NULL.

Qt has a way to get a list of display devices, and that's already how
"qt-fullscreen-screennumber" is populated in the preferences window, but we
can get the name instead of the number by using ->currentText().toUtf8()
instead of ->currentData().toInt().

Then the only missing piece is to modify the implementations of the other
OS's to use the value in the id parameter. That's where I can't really
help. I might be able to help with Linux (I have a Ubuntu machine I can
test on) but I couldn't help with MacOS.

Does all that sound reasonable?

On Mon, Oct 7, 2019 at 3:20 AM Steve Lhomme <robux4 at ycbcr.xyz> wrote:

> On 2019-10-03 21:03, Gabriel Luci wrote:
> > Can you point me to that proper API? I certainly don't mind using a
> > different method to do it if it makes more sense.
> I think Remi is talking about the vout_window_SetFullScreen() which can
> tell which output-identifier should be used. In other words that would
> be the name of the monitor.
> Right now we always pass NULL all the time, via
> vout_window_SetFullScreen(). That's probably where the
> "qt-fullscreen-screennumber" should be passed, although the name
> suggests it's Qt specific. It seems that the "screen id" would rather be
> OS/window manager specific than relying on Qt. It seems the Qt option is
> already handled fully by Qt, setting in the fullscreen window in the
> right window. But it may be broken in the current UI.
> > But the reason I went this route is because the SetFullscreen function
> > in /modules/video_output/win32/window.c already uses an OS-specific way
> > to select which monitor to put the video output window on
> > (MonitorFromWindow). So I assume that code must change if it's going to
> > put the window on a different monitor. It just needs to be told which
> > monitor somehow - I just don't know what that "somehow" would be besides
> > a new configuration setting.
> >
> >
> > On Thu, Oct 3, 2019 at 2:39 PM Rémi Denis-Courmont <remi at remlab.net
> > <mailto:remi at remlab.net>> wrote:
> >
> >     Hello,
> >
> >     There is already a proper API defined for this, so clearly adding an
> >     plugin-
> >     specific OS-specific setting on top is not the way to go.
> >
> >     --
> >     雷米‧德尼-库尔蒙
> >     http://www.remlab.net/
> >
> >
> >
> >     _______________________________________________
> >     vlc-devel mailing list
> >     To unsubscribe or modify your subscription options:
> >     https://mailman.videolan.org/listinfo/vlc-devel
> >
> >
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> >
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191007/36cbb404/attachment.html>

More information about the vlc-devel mailing list