08:22pq: Vanfanel, I think changing maybe_enable_pointer_constraint() in an *alternative* approach.
08:23pq: Vanfanel, if you're going to add a flag, look at my past gitlab comments: it would not be "fullscreen" but "allowed to gain confinement without a click"
08:24pq: or maybe even "allowed to gain confinement", moving the click handling completely into the shells
08:25pq: but then, a flag on the surface does not seem right, because one would need to remember to unset it as well, which is prone to errors
08:26pq: so it would probably be like a surface pointer stored somewhere (weston_seat?) to indicate that this surface is allowed to gain confinement
08:27pq: I don't remember the shell internals well enough to say if set_fullscreen() is the right function. But I do think you need the surface be both active on the seat and fullscreen to be eligible for confinement without a click.
08:29pq: or, rather than a surface pointer, it could be a serial, which basically comes back to the existing design - just not exclusively about clicks
08:30pq: if surface's confinement-serial equals the seat's confinement-serial, then confinement can activate
08:31pq: seat's confinement serial is bumped whenever something might invalidate confinement ability for any surface
08:32pq: surface's confinement-serial... oh but that doesn't work with multiple seats
08:32pq: oh well
15:20MrCooper: jadahl: thanks for merging the website Xwayland spelling fix!
15:48jadahl: MrCooper: lots more places on the Internet to fix I imagine!
15:49ofourdan: mandatory xkcd reference: https://xkcd.com/386/
15:50MrCooper: sure, but I fixed the ones which apparently led to it being inconsistent in the LWN article about X byte-swapping (fixed now too :)
15:52ofourdan: lol
15:52MrCooper: ofourdan: hehe, just a little pet peeve of mine
15:52ofourdan: not just you, it hurts me every time I read XWayland L(
15:52jadahl: SystemD, XWayland. how does that feel?
15:53MrCooper: better stay away from Phoronix then
15:53ofourdan: hehe
16:06Vanfanel: pq: from what I see in maybe_enable_pointer_constraint(), isn't the view what's evaluated to grant confinement? You talk about surface.. But do you mean view?
16:06bl4ckb0ne: i yhink the worst is WL-ROOTS
16:08Vanfanel: pq: also, after what you said, it seems to be better to store a view/surface pointer stored on a weston_seat? But then.. what about multiple seats again? :(
16:10dottedmag: bl4ckb0ne: Strong Common Lisp vibes
17:51Vanfanel: pq: given our previous conversation, I think a flag in the weston_view that allows the view to gain pointer confinement is the best (= less bad) way to go: it would work with multiple seats.
17:52Vanfanel: pq: but again, if your view on this is different (or somebody else has another idea) please tell me, not trying to force anything
18:29hays: emersion: https://wayland.freedesktop.org/building.html I am not sure what is happening here special that enables the Wayland EGL platform
18:49emersion: nothing, they're enabled by default
18:49emersion: libwayland-egl is
18:49emersion: can you describe your issue?
18:51Vanfanel: emersion: where is the weston_view struct defined? I am looking hard for the struct definition so I can add a flag member for the fullscreen pointer confinement stuff...
18:51emersion: i don't know, i am not involved in weston anymore
18:52Vanfanel: Oh, sorry to bother you then
18:54Vanfanel: Ah, weston_view seems to be defined in include/libweston/libweston.h
18:55hays: emersion: I am trying to create a buildroot that has support for wayland-egl platform, because there are a lot of things depending on it. However I suspect that the Mali driver I am using has broken support for libwayland-egl.so.
18:55hays: emersion: so I am wondering--maybe I can use wayland's version
18:56hays: unfortunately this is some kind of overhaul of buildroot's dependency system of course, which doesn't really recognize that wayland can provide this shared library
18:56hays: anyways that part is not your issue to deal with
18:57hays: anyone that can confirm this is a legitimate thing to try--it would be nice because its probably a few hours of work in buildroot
18:57emersion: ah, proprietary mali probably has its own libwayland-egl
18:58hays: yes it does--and I think its broken
18:58emersion: and the one in the Wayland repo won't work with the proprietary driver I think
18:58hays: because their buildroot DISABLES wayland-egl by default
18:58hays: ugh that's good information, if disappointing
18:59emersion: although I don't know/care a lot about proprietary drivers, take this with a grain of salt
19:01hays: according to buildroot-- kodi, sway, waylandpp (at a minimum) need this wayland-egl thing
19:01bl4ckb0ne: sway?
19:01hays: bl4ckb0ne: according to buildroot
19:01hays: but yes
19:01hays: not saying its right--and this is an old version of buildroot that has been kinda bumped up over time
19:02hays: lots of greebles here
19:02hays: anyways none of that is your problem :)
19:18bl4ckb0ne: is there a protocol out there to attach 2 buffers to a surface?
19:19jadahl: no
19:21hays: damn. waylandpp-1.0.0 seems to have a real dependency on wayland-egl
19:31hays: not anymore. :)