<div dir="ltr">The issue at least with Windows is that 

there is no Windows API function to get monitor details by the name, only by the handle. So if we save the name of the device ("\\.\DISPLAY2" for example), then the only way to translate the name into the handle is to enumerate the displays.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 25, 2019 at 3:14 PM Alexandre Janniaux <<a href="mailto:ajanni@videolabs.io">ajanni@videolabs.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Probably not bugs, with regards to the documentation for<br>
this which is incomplete, but I agree with Rémi that it<br>
should also work with caching when the module is<br>
initialized, because it should report new or removed<br>
outputs.<br>
<br>
When we're doing the enumeration from the UI, it doesn't<br>
matter and we shouldn't do caching as there is not enough<br>
lifetime for interesting storage anyway. As it is only for<br>
configuration it almost doesn't matter in this design.<br>
<br>
However in your scenario, the window will indeed not do the<br>
correct behaviour with the current window implementation,<br>
as the fullscreen state and information is not stored and<br>
restored during Enable. That's a very good point.<br>
<br>
The pivotal point here is that requests like SetFullscreen<br>
can be applied with the window being disabled. It's not<br>
very documented but the main motive behind is to be able to<br>
configure the video playback surface before actually making<br>
it visible to the user, while keeping the window provider<br>
module running so as to reports outputs. It's a bit<br>
confusing from a module provider implementor point of view<br>
but is far easier to use from the API user point of view<br>
and provides a better UX than in previous 3.0.<br>
<br>
We probably want something like not changing screen if the<br>
video is already started, or if it goes to the next one,<br>
but the interface might want to set the correct screen when<br>
the playback will be stopped.<br>
<br>
Regards,<br>
--<br>
Alexandre Janniaux<br>
Videolabs<br>
<br>
On Fri, Oct 25, 2019 at 08:49:03PM +0300, Rémi Denis-Courmont wrote:<br>
> Le perjantaina 25. lokakuuta 2019, 20.37.06 EEST Gabriel Luci a écrit :<br>
> > I would normally agree, but monitors can be unplugged and plugged in at any<br>
> > time (especially wireless displays). Consider this scenario:<br>
> ><br>
> > 1. A chosen monitor is selected and VLC closed.<br>
> > 2. The chosen monitor is disconnected.<br>
> > 3. The next time VLC is run, and video played, the enumeration (without the<br>
> > chosen monitor) is saved, and video plays on the primary monitor.<br>
> > 4. You realize your forgot to plug in your chosen monitor, and do so.<br>
> ><br>
> > In that case, VLC will not play video on the chosen monitor until the<br>
> > enumeration is forced to happen again (restarting VLC or opening<br>
> > preferences, for example).<br>
><br>
> Sure it will. Unless you write bugs.<br>
><br>
> --<br>
> Rémi Denis-Courmont<br>
> <a href="http://www.remlab.net/" rel="noreferrer" target="_blank">http://www.remlab.net/</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> vlc-devel mailing list<br>
> To unsubscribe or modify your subscription options:<br>
> <a href="https://mailman.videolan.org/listinfo/vlc-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/vlc-devel</a><br>
_______________________________________________<br>
vlc-devel mailing list<br>
To unsubscribe or modify your subscription options:<br>
<a href="https://mailman.videolan.org/listinfo/vlc-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/vlc-devel</a></blockquote></div>