04:19 <hays> what is the relationship between libEGL.so and wayland-egl.so ?

04:23 <hays> its freaking weird--mali has a blob specifically for "wayland-gbm" but even with gbm only you get EGL and GLES support. so if wayland-egl.so is broken.. like what's that shared library for exactly.. very confused

09:54 <pq> hays, IIRC, libwayland-egl.so is just a little API extension to libEGL which is the actual implementation of anything significant required for the EGL Wayland platform. I don't think libwayland-egl.so implements anything, it just forwards to the EGL stack. So swapping out libwayland-egl.so doesn't change anything.

09:56 <pq> hays, of course, this is the upstream version of libwayland-egl.so I'm talking about. I have no idea if the Mali vendor version does something totally different.

09:57 <pq> but if it does, then swapping that one lib would just break things more

09:58 <pq> hays, I do know, that the EGL Wayland platform simply cannot work without a good libwayland-egl.so.

10:02 <pq> hays, know nothing about any proprietary EGL implementation, but originally EGL was meant to be built for a single platform at a time. So you'd have different binaries for X11, another set for Wayland, yet another set for running without a window system (e.g. fbdev or GBM). Obviously that doesn't really work out, so nowadays the same Mesa EGL binaries support multiple platforms, but who knows about Mali.

10:02 <pq> *I know

10:05 <pq> vanfanel, the problem with the surface flag is that how do you know to unset the flag in every case where it's needed?

10:07 <pq> vanfanel, a weston_surface may theoretically have multiple weston_views, and it's up to shell which ones of those should be allowed to trigger pointer confinement and when.

10:09 <pq> vanfanel, another thing I don't know about is how pointer confinement works with multiple seats. Theoretically each seat with a pointer could confine independently of each other. So having a weston_seat maintain a notion of the weston_view that can get confinement seems like a good option.

10:09 <pq> We can probably exclude the possibility that multiple views would be eligible for confiment at the same time on the same seat.

10:19 <hays> pq: thanks. that is exactly the situation with Mali. There are 4 libraries. one for "gbm" one for each for X11 or wayland +gbm, then one with all three, which reportedly is broken.

10:20 <hays> I was reading last night, and I think maybe what the mali vendor is doing is they have modified wayland with a patch to allow you to configure it NOT to produce that shared library with the intent they provide it themselves.

10:21 <hays> I had been manually deleting the wayland-produced .so via makefile scripting, so maybe I should try to "disable" it instead.. not sure it will make a difference

10:21 <hays> Thanks for the info. I know its a bit out of scope for this channel

11:40 <Vanfanel> pq: After the last ideas you gave me (using a surface pointer in the weston_seat, using serialization...), since they won't work using multiple seats, wouldn't be good idea to use a flag in the weston_surface instead as I initially said? Something like "bool allow_pointer_confinement", that would be set when the surface is both active and fullscreen.

11:41 <Vanfanel> Also, can someboy *please* explain me what a weston_surface and a weston_view are exactly? Looking at the code, it's not clear

11:41 <Vanfanel> And how a weston_view and a weston_surface relate to each other, too, please

11:52 <SardemFF7> Vanfanel: it’s not the full explaination but a weston_surface is the weston structure that represents the wl_surface Wayland object, I think 1:1

11:53 <SardemFF7> (weston_desktop_surface represents xdg_surface/xdg_toplevel/xdg_popup and the shell_surface is the shell-specific part of xdg_toplevel)

11:54 <SardemFF7> a weston_view is an internal implementation detail of Weston, you can see it a “a mapping of a weston_surface somewhere in the Weston scenegraph”

11:55 <SardemFF7> usually there is 1 “main” weston_view for a weston_surface, the “window” you interact with

11:57 <SardemFF7> but for some features, like a window picker, you can have another weston_view so it can be scaled down, and not interactive (so you cannot e.g. type text in a window directly from the picker)

11:58 <SardemFF7> or you can duplicate the same window twice and both being interactive (it could be an implementation detail of a shell having multiple workspaces)

12:39 <DodoGTA> Why do Wayland apps that freeze for too long crash with "error in client communication"?

13:02 <daniels> DodoGTA: if they’re still receiving e.g. mouse input events from the compositor, they’ll likely get killed when the socket buffer fills up because they’re not reading events

13:24 <DodoGTA> daniels: So how can I prevent this? Run blocking code in a separate thread?

13:25 <emersion> depends what your blocking code does

13:26 <emersion> if it's a blocking read(), for instance, it can be integrated in your event loop instead

14:29 <daniels> SardemFF7: more timeouts to eventd.org

14:32 <emersion> i can host the bot if you'd prefer

14:41 <SardemFF7> oh, found something, it hits 1024 fds, somehow the connection is not properly closed (local haproxy->webhook handler connection)

14:42 <SardemFF7> emersion: if you’re asking me, I’d love to fix the issue and continue to host it, but if others feel like it’d be better I don’t mind :-)

14:42 <wlb> wayland.freedesktop.org Merge request !51 opened by Michel Dänzer (daenzer) Spell Xwayland consistently https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/51

14:42 <wlb> wayland.freedesktop.org/main: Michel Dänzer * Spell Xwayland consistently https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/ebcb953236ca building.html faq.html xserver.html

14:42 <wlb> wayland.freedesktop.org Merge request !51 merged \o/ (Spell Xwayland consistently https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/51)

14:42 <wlb> wayland Merge request !290 opened by Jeremy Huddleston Sequoia (jeremyhu) Misc portability improvements to help bring wayland to darwin https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/290

14:45 <emersion> sure, just making sure you're not annoyed by it

14:46 <SardemFF7> not in the least, I’ll even add an auto-restart as a workaround for now, should mitigate the issue

15:17 <hays> emersion: seems like mali blob is supposed to work with wayland version of .so https://patchwork.ozlabs.org/project/buildroot/patch/20220924210221.1490924-1-thomas.petazzoni@bootlin.com/

16:00 <Vanfanel> SardemFF7: So, in another words, a weston_surface represents the internal abstract resources of a "canvas" (a place to draw images into), and a weston_view is a surface representation (because I understand a surface can be represented in different ways). Am I right? Just trying to confirm I understand your explanation

16:19 <jadahl> Vanfanel: weston_surface represents the logical representation of a wl_surface, i.e. a buffer + state about how to present it from clients. weston_view is a (possibly one of many) scene graph view of a weston_surface that describes how and where on the screen it should be shown

16:21 <jadahl> there is no "canvas" where weston can draw anything to anything, it's only ready and complete buffers that are provided by clients

16:21 <jadahl> or, well, there is one canvas, and that is the screen estate it composits to, i.e. what ends up on your monitor

16:28 <Vanfanel> jadahl: ok, I understand now. So a wl_surface can have multiple wl_view(s), and only one of them has been clicked on a given moment, right?

16:49 <jadahl> Vanfanel: more or less yes

17:32 <MooMoo> I'm not sure if the wayland (or the wlroots) protocols allow for this. With say for example pcmanfm/pcmanfm-qt it's trivial to take over the desktop and allow stuff like icons or whatever. I think what pcmanfm/pcmanfm-qt does is put a large window or something over the root window. How would that be possible under wayland? Because according to the github, pcmanfm-qt works fine under wayland.

22:34 <Vanfanel> jadahl: ok, thanks! Looking at maybe_enable_pointer_constraint() in libweston/input.c, it seems to select a view from a surface. Can a surface have more than one fullscreen view? Is there a way to know if a view is fullscreen?

22:39 <jadahl> Vanfanel: in theory you have two views fullscreen on separate monitors

22:40 <jadahl> in practice, unlikely...