[vlc-devel] Using VLC 4.0.0 on WSL2 Ubuntu 25.04 with wayland

[Alexandre Janniaux]

Hi Jean-Yves, I'm sorry for your feeling with the exchanges.

Regarding your issues, you might want to just revert the patches from this MR:
https://code.videolan.org/videolan/vlc/-/merge_requests/5721/commits

It added wp_viewporter usage on the surface provided to wl_shm, which is why it
breaks in your tests.

Without those patches, you'll still get 100% of the features from wl_shm.
Note that I still need to sort out this merge request for the Qt
integration to work
correctly (without transparent background) with wl_shm.

https://code.videolan.org/videolan/vlc/-/merge_requests/299

Regards,
--
Alexandre Janniaux
Videolabs

Le lun. 23 juin 2025 à 09:43, Jean-Yves Baudy <jy.baudy at gmail.com> a écrit :
>
> Hi,
> 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.
> A simple comment shouldn't lead to such an exchange. If this continues, I'll probably unsubscribe from my own post!!!
> 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.
> Regards
>
> Le lun. 23 juin 2025 à 09:01, Rémi Denis-Courmont <remi at remlab.net> a écrit :
>>
>>
>>
>> Le 22 juin 2025 18:59:43 GMT+03:00, "Fatih Uzunoğlu" <fuzun54 at outlook.com> a écrit :
>> >> 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.
>> >
>> >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.
>>
>> 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).
>>
>> > Note that some may argue that it should be the responsibility of the window provider.
>>
>> 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.
>>
>> 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.
>>
>> >Qt interface did not "break a display module",
>>
>> If triggering a crash in preexisting working merged code is not breaking it, then I don't know what is.
>>
>> > Iis only for window embedding case, and the interface can definitely have some additional requirements there when necessary.
>>
>> No, you just made that up. Can you even point to a precedent for that bold misleading claim?
>> _______________________________________________
>> 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