08:55 wlb: weston Issue #807 opened by Kjeld Flarup (kfc) unable to bind rdp socket https://gitlab.freedesktop.org/wayland/weston/-/issues/807
09:11 wlb: weston Issue #808 opened by Kjeld Flarup (kfc) unknown child process exited https://gitlab.freedesktop.org/wayland/weston/-/issues/808
09:36 vyivel: in xdg_surface.get_popup, is it mandatory for the parent to have a role?
09:38 emersion: i would think so
09:39 emersion: it would be extremely weird for a protocol extension to change what happens when a bare wl_surface is used with get_popup
09:40 vyivel: emersion: well it's not really a bare wl_surface
09:41 vyivel: parent is object<xdg_surface> there
09:41 emersion: oh, sorry, i misunderstood
09:41 emersion: or did i
09:42 emersion: hm, right, get_popup is not the extensible version
09:42 emersion: or rather, it is, but then parent is null
09:43 vyivel: what i mean is
09:43 emersion: well, it would be extremely weird for an extension protocol top change what happens when a bare xdg_surface parent is passed in
09:43 emersion: to*
09:44 vyivel: a popup's parent should be a toplevel or a popup (assuming xdg-shell only), but it's possible to set an xdg_surface without a role as a popup's parent
09:44 emersion: does the current protocol allow something like:
09:44 vyivel: and then with some trickery you can create a popup loop
09:44 emersion: get_popup(parent=xdg_surface@1)
09:44 emersion: xdg_surface@1.get_toplevel()
09:45 vyivel: it's not specified, that's the problem
09:45 vyivel: mutter disallows this, for example
09:45 vyivel: weston is fine
09:45 emersion: if current compositors disallow this, it's a good case for clarifying the protocol
09:55 wlb: wayland-protocols Issue #157 opened by Kirill Primak (vyivel) xdg-shell: clarify whether an xdg_popup's parent must have a role https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/157
09:57 davidre: xdg_popup says
09:57 davidre: > The parent of an xdg_popup must be mapped (see the xdg_surface description) before the xdg_popup itself.
09:57 davidre: > For an xdg_surface to be mapped by the compositor, the following conditions must be met: (1) the client has assigned an xdg_surface-based role to the surface
09:57 davidre: So to me it seems the intention was to allow unmapped parents in the request
09:58 vyivel: mapped means ready to be displayed
09:58 vyivel: i don't see why it shouldn't be possible to create a popup tree and then map everything top-down
09:59 zamundaaa[m]: I don't see how that would be a sane thing to allow
10:00 vyivel: lol i guess that's fiar
10:00 vyivel: fair
10:01 vyivel: though, i don't think that interpretation is enforced by anyone
10:09 serjosna: because when i was lacking that subject at school, same wise i would not understood that method, cause the ones who try to rule such as the banners who force others under their tact and regulation i.e manipulate you to stay fraudulently at the top are pressurising you deep, so i know exactly without that education and the best high school graduated i would had crashed alike. IT's a fact, those dudes are so abusive, but the education came
10:09 serjosna: to rescue, and it is a long story, i remembered what teacher said about those things and what book said, and that is why i was confident.
10:32 pq: Hmm. Maybe I should move Weston's eotf_mode API from core to become DRM-backend specific. And the future colorimetry mode as well (for controlling "Colorspace").
10:33 pq: If the Wayland backend gains HDR support, all it needs is the content image description to forward to the host.
10:34 pq: Or... could I infer both KMS "HDR_OUTPUT_METADATA" and "Colorspace" from the image description that Weston frontend assigns to an output...
10:35 pq: I wouldn't be able to clearly indicate Colorspace=default though
10:37 pq: "traditional gamma HDR" eotf mode would be difficult to indicate too, and what about a future SBTM
10:38 pq: so yeah, I need the frontend to set both driving modes (eotf, colorimetry) and output image description separately, and let the frontend be responsible for them to not conflict.
10:43 pq: it would still make sense for a wayland-backend output to tell which eotf and colorimetry modes are available, so maybe there is reason to keep the getter API in the libweston core
10:44 pq: then, why not keep the setter API in core as well, all the definitions come with the getter API anyway
10:46 pq: DRM-backend would blindly do what the setter API says, wayland-backend would ignore it, and any other backend probably exposes only the single default SDR option.
11:59 wlb: weston Issue #807 closed \o/ (unable to bind rdp socket https://gitlab.freedesktop.org/wayland/weston/-/issues/807)
13:43 kursat: hi
14:30 drakulix[m]: hi! 👋
19:28 boud: I'd be happy to add further analysis to https://gitlab.freedesktop.org/wayland/wayland/-/issues/406 if someone's interested. It's presumably something related to clipboard functions.
20:14 dottedmag: boud: Wayland is not a piece of software, it's a protocol, so "managed by Wayland" makes as much sense as "managed by HTTP". If you use GNOME, please report bug to Mutter.
20:46 boud: dottedmag: Thanks for the clarification about what Wayland is :). The bug occurs for both foot and gnome-console aka kgx.
20:46 boud: By "Mutter", do you mean https://gitlab.gnome.org/GNOME/mutter ?
20:46 boud: If 'wayland' is the wrong place to file the bug, then 'phosh' would seem more likely as try #4.
22:01 ifreund: boud: indeed, phosh would be the correct project to report the bug to if that's the compositor you use
22:04 boud: More likely phoc:
22:04 boud: ii phoc 0.30.0+ds-2 arm64 Wayland compositor for mobile phones
22:04 boud: ifreund: thanks :)
22:05 ifreund: no problem!