<div dir="ltr"><div>Hi,</div><div>I had no idea such a debate would arise within the VLC developer community. For me, a basic principle, having been a developer myself for many years, is to respect the work of others.<br>A simple comment shouldn't lead to such an exchange. If this continues, I'll probably unsubscribe from my own post!!!<br>VLC works very well in my WSL2 environment if I run it on a Weston instance. Or on a native Ubuntu. And, I can survive with my modification for personal use. With my post, I just wanted to draw your attention in case you have a constructive idea.</div><div>Regards</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Le lun. 23 juin 2025 à 09:01, Rémi Denis-Courmont <<a href="mailto:remi@remlab.net">remi@remlab.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
Le 22 juin 2025 18:59:43 GMT+03:00, "Fatih Uzunoğlu" <<a href="mailto:fuzun54@outlook.com" target="_blank">fuzun54@outlook.com</a>> a écrit :<br>
>> WTH are you on about?! You don't get to choose what display module is used. If you provide a Wayland type surface you have to follow the general conventions and the specific conventions for the Wayland type.<br>
><br>
>If the display module is using viewporter, it should also take care of the fractional scale (as that is the only way to support it as per the fractional scale protocol), which probably means a new entry in the window structure so that the window provider can forward the desired scale instead of handling it itself.<br>
<br>
You're gaslighting us. The SHM module was already using the viewporter in 3.0, before any of those bugs were introduced in the Qt interface. What really happened here is whoever wrote the code didn't care to test it with the reference display. That should be software development flame testing 101, so quite troubling. Alternatively they didn't have viewport support in their display server (in which case, it's very sketchy to even attempt to use it).<br>
<br>
> Note that some may argue that it should be the responsibility of the window provider.<br>
<br>
I don't care about idiotic opinions. That can't work since the window provider has, by design, no info on the size and aspect of the video being shown in it, and thus can't possibly calculate a scale.<br>
<br>
And it goes beyond that. Each display module is free to use whatever fits it for rendering. A provider cannot use *any* rendering service on the surface unless it can't conflict with *any* potential use by *any* display.<br>
<br>
>Qt interface did not "break a display module",<br>
<br>
If triggering a crash in preexisting working merged code is not breaking it, then I don't know what is.<br>
<br>
> Iis only for window embedding case, and the interface can definitely have some additional requirements there when necessary.<br>
<br>
No, you just made that up. Can you even point to a precedent for that bold misleading claim?<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>
</blockquote></div>