[vlc-devel] [PATCH 1/4] libvlc: Add "fullscreen-monitor" setting

Rémi Denis-Courmont remi at remlab.net
Tue Oct 15 09:06:37 CEST 2019


Hi,

As noted in the last or previous to last video workshop, the whole point of separating open and enable in window provider was to support this - just like why I split open and start in audio outputs earlier.

And with that, I totally disagree with your proposal to essentially regress the design.

Le 14 octobre 2019 23:42:26 GMT+03:00, Alexandre Janniaux <ajanni at videolabs.io> a écrit :
>Hi,
>
>The rationale for having a per-module value is that the
>would have some meaning only for the modules that report
>it. Integer-screen name like xinerama ones could be used
>as string too by having names like xinerama-0, xinerama-1
>as they are mostly obsolete. Most systems with screens and
>virtual screens are using strings nowadays because they are
>easier to use by the end-user.
>
>Currently we have vout_window_ReportOutput to report these
>ids but I'm not sure it's even used by the core and the
>wayland module is the only producer. Maybe we should add
>more support for these reports but I see two issues related
>to their usage:
>
>When using audio devices, I tend to think that the user
>don't really care if they have to change audio output
>during the playback because the "main" audio device for the
>common normal user (meaning wasapi/pulseaudio) is already
>handled by the API of the audio multiplexer below, and
>changing audio device is an occasional task (or the user
>didn't really configured it, but that's not our UX problem
>anymore).
>
>In the situation of fullscreen devices, the dual concept is
>the primary screen one. But in this case primary screen is
>usually used for different things. For example, the UI are
>usually started on the primary screen so basically every
>time the setting "fullscreen-monitor" will have some meaning
>are the times where you want to set it on a different
>monitor, or almost, for instance because you have a TV
>screen connected to the same desktop station. And I don't
>know if a contextual menu to choose the fullscreen device
>during the playback is a good idea or not but I think
>setting it before the playback so that each file opens
>directly on the correct screen is the use case people want.
>
>In this case, you can't use the vout_window_ReportOutput
>because the window module doesn't exist yet, or for advanced
>usage you might want to configure it for another module
>which is not opened and thus reports no fullscreen devices.
>This is exactly what led us to using Qt as fullscreen
>provider with QScreen indices at the first place.
>
>I advised the added variable because it allows fixing most
>of the usability issues without having to solve the issues
>above. Either the UI is the correct provider for the screen
>name, so it solves for the 99%, or the user is and it solves
>for the 0.99% left.
>
>I really don't think we can get the ideal behaviour before a
>lot of work both on the core and all the window module, not
>to mention that there is few documentation on this, although
>what is there almost correctly specify all the API.
>
>Regards,
>--
>Alexandre Janniaux
>Videolabs
>
>On Mon, Oct 14, 2019 at 10:05:24AM +0200, Thomas Guillem wrote:
>>
>>
>> On Sun, Oct 13, 2019, at 16:22, Gabriel Luci wrote:
>> > I assume you mean because the output plugin doesn't necessarily
>have a window? So isn't this the same as all the "Window properties"
>settings, which are defined in the same place? Or would you prefer to
>see this under that "Window properties" section too?
>>
>> This option is a string for windows, but it could be an integer on
>other OSes
>> Rémi would prefer to have this option in win32/window.c
>>
>> vlc_module_begin()
>>  set_shortname(N_("Win32 window"))
>>  set_description(N_("Win32 window"))
>>  set_category(CAT_VIDEO)
>>  set_subcategory(SUBCAT_VIDEO_VOUT)
>>  set_capability("vout window", 10)
>>  set_callback(Open)
>> vlc_module_end()
>>
>> But I'm not sure about it, on Linux, this id would be something like
>"0:0", so a string too.
>> Personally, I prefer to have a global settings for all OSses (and
>maybe do some integer conversion on some implementations).
>>
>> >
>> > On Sun, Oct 13, 2019 at 3:18 AM Rémi Denis-Courmont
><remi at remlab.net> wrote:
>> >> Le sunnuntaina 13. lokakuuta 2019, 6.58.28 EEST Gabriel Luci a
>écrit :
>> >> > This will contain the name of the display device to always show
>> >> > fullscreen video on.
>> >> > ---
>> >> > src/libvlc-module.c | 6 ++++++
>> >> > 1 file changed, 6 insertions(+)
>> >> >
>> >> > diff --git a/src/libvlc-module.c b/src/libvlc-module.c
>> >> > index d3da4e5fb8..163e4deda0 100644
>> >> > --- a/src/libvlc-module.c
>> >> > +++ b/src/libvlc-module.c
>> >> > @@ -314,6 +314,11 @@ static const char *const
>ppsz_align_descriptions[] =
>> >> > #define FULLSCREEN_LONGTEXT N_( \
>> >> > "Start video in fullscreen mode" )
>> >> >
>> >> > +#define FULLSCREEN_MONITOR_TEXT N_("Display device for
>fullscreen video")
>> >> > +#define FULLSCREEN_MONITOR_LONGTEXT N_( \
>> >> > + "In a multiple monitor configuration, you can specify the
>device name "
>> >> > \ + "of the display that you want the fullscreen video window to
>open
>> >> > on." ) +
>> >> > #define VIDEO_ON_TOP_TEXT N_("Always on top")
>> >> > #define VIDEO_ON_TOP_LONGTEXT N_( \
>> >> > "Always place the video window on top of other windows." )
>> >> > @@ -1641,6 +1646,7 @@ vlc_module_begin ()
>> >> > add_bool( "fullscreen", false, FULLSCREEN_TEXT,
>FULLSCREEN_LONGTEXT,
>> >> > false ) change_short('f')
>> >> > change_safe ()
>> >> > + add_string( "fullscreen-monitor", "", FULLSCREEN_MONITOR_TEXT,
>> >> > FULLSCREEN_MONITOR_LONGTEXT, false ) add_bool( "embedded-video",
>1,
>> >> > EMBEDDED_TEXT, EMBEDDED_LONGTEXT, true )
>> >> > add_bool( "xlib", true, "", "", true )
>> >>
>> >> The values depend on the output plugin, so thus does not belong as
>a global
>> >> setting, just like the audio output device.
>> >>
>> >> --
>> >> レミ・デニ-クールモン
>> >> 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
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191015/68b459f7/attachment.html>


More information about the vlc-devel mailing list