08:33 wlb: wayland-protocols Merge request !190 opened by Simon Ser (emersion) xdg-output: clarify goal https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/190 [xdg-output]
09:15 wlb: wayland Issue #350 opened by Simon Ser (emersion) Clarify interactions between wl_surface.leave and wl_output destruction https://gitlab.freedesktop.org/wayland/wayland/-/issues/350 [Protocol]
12:17 zxd: Hi
12:22 zxd: is wayland development going well ?
12:26 daniels: yep!
12:27 zxd: good, I remember in the 90s Linux was taking off and I saw how slow X was I said this is terrible someone code a new Windowing system now
12:27 zxd: too bad I didnt know any c/c++
12:33 zubzub: if I launch weston with the headless backend + use-gl it's stuck on "launching '/usr/lib/x86_64-linux-gnu/weston-desktop-shell'"
12:33 zubzub: this happens with weston v10 from debian testing as well as weston from ubuntu (v9)
12:35 pq: zubzub, does it unstuck if you wait one minute?
12:35 pq: how stuck is "stuck"?
12:35 zubzub: not sure if I waited one minute let me try
12:35 zubzub: when it's stuck, I can't connect with any client kind of stuck
12:35 pq: hmm
12:36 pq: how "can't connect"?
12:36 pq: no socket found, opening socket failed, or something?
12:37 zubzub: rebooting the server, will let you know asap :p
12:38 pq: check your WAYLAND_DISPLAY is set right, just in case; it's likely wayland-1, not wayland-0
12:38 pq: for the client, that is
12:38 zubzub: "(gtk4-demo:1740): Gtk-WARNING **: 13:38:18.171: cannot open display"
12:38 zubzub: I explicitly set it to wayland-0
12:38 pq: try wayland-1
12:39 zubzub: yeah that works o_O
12:39 pq: Weston is avoiding wayland-0 socket name if it's not the "primary" compositor like with DRM-backend
12:39 zubzub: oh ok
12:39 pq: so all nested flavors and headless avoid the default socket name
12:40 pq: at least those, not sure about DRM actually
12:40 pq: the reason is, if your real desktop is X11, your real desktop apps don't suddenly start opening inside Weston
12:41 zubzub: ic
12:42 zubzub: ugh, weston on debian testing doesn't have linux dmabuf protocol?!
12:43 pq: it should, surely
12:43 zubzub: hmm, does it decide not to advertise it under certain conditions?
12:43 pq: wayland-info is saying otherwise?
12:44 pq: yeah, gl-renderer is required at least, so if you use pixman, then no dmabuf
12:44 zubzub: hmmm, ah it's fallbacking to llvm mesa
12:44 zubzub: even though I have nvidia 515 driver
12:44 zubzub: an overlooked advantage of having a standing desk is that these are way to hard to flip over
12:45 pq: I bet NVIDIA does not advertise support for the EGL surfaceless platform? So glvnd picks the one who does, which is Mesa/llvmpipe.
12:45 zubzub: quite heavy and all
12:46 zubzub: ok that might explain it
12:46 pq: Weston's headless-backend with GL-renderer relies of the EGL surfaceless platform.
12:46 pq: EGL EGLDevice platform could be an alternative I guess, but has not been implemented in Weston
12:47 pq: Might not be a bad idea to add that, Mesa supports it too, right?
12:47 pq: which would put the burden of picking the GPU device on Weston code?
12:48 zubzub: I guess so?
12:48 zubzub: I've simpy put a config option in my implementation to pick the correct render device
12:50 zubzub: man nvidia and wayland is still such an absolute PITA to get working... breaking in (clients in) all kinds of subtle ways
12:52 zubzub: qt5 be like, ooh you have linux dmabuf protocol [using nvidia driver in the compositor], let me use it and then use mesa nouveau 😭
13:32 zubzub: oh you're giving a talk at fosdem daniels
13:33 zubzub: "what do these window system people even do all day, anyway?"
13:33 zubzub: the most important question
13:59 MrCooper: thinking of new ways to break things which were working perfectly in X, obviously
14:01 zubzub: the answer will surprise you!
14:07 MrCooper: it's INSANE
14:14 daniels: zubzub: heh yep, it’s nowhere near as interesting as yours!
14:43 zubzub: I should probably do a new talk next year
14:47 zubzub: maybe nvidias driver will be good enough to run (sdl) games without them segfaulting!
17:23 vyivel: is creating multiple xdg_surface object for the same wl_surface legal? afaiu yes, but weston (and only weston) says that "xdg_surface must not have any other role"
17:37 jadahl: vyivel: it's illegal. looking at mutter it should check and deny a client trying to call get_xdg_surface if there is already an active xdg_surface instance
17:37 vyivel: got it; right now, wlroots, kwin, and smithay allow it too
17:38 vyivel: the protocol should explicitly state that, though
17:38 vyivel: "It is illegal to create an xdg_surface for a wl_surface which already has an assigned role", but creating an xdg_surface alone doesn't set a role
17:39 jadahl: sure, makes sense to tweak that wording to make it clear
17:52 i509vcb: There is the fun issue of creating an xdg_surface and then a layer surface for example. It should be theoretically illegal per the text of the protocol but I don't recall it being implemented right anywhere
17:52 i509vcb: What I recall from that is xdg_surface assigns a sort of pseudo role
18:00 jadahl: i509vcb: yea, creating an xdg_surface without also later creating a role object using xdg_surface makes no sense
18:03 vyivel: xdg_surface as an intermediate object for setting a role makes no sense either tbh
18:04 vyivel: also yeah, creating an e.g. layer surface would be illegal: "the corresponding surface may only be assigned a role extending xdg_surface, such as xdg_toplevel or xdg_popup"
18:08 jadahl: vyivel: xdg_surface is the "abstract" role the same as abstract classes work in OO
18:08 jadahl: the fact that we need to first create it then something else is just how Wayland protocols tend to work
18:08 i509vcb: OO in the protocol drives me up a wall lol
18:09 vyivel: jadahl: i understand it, i just think it would make sense for xdg_surface to be the role object itself
18:10 i509vcb: You can't turn an xdg_toplevel into a xdg_popup however
18:10 i509vcb: It seems to act more like a role group and then a concrete role
18:10 jadahl: yea, xdg_surface isn't a role because it's just a toolbox of useful things that most roles happen to need
18:11 vyivel: most roles (two)
18:11 jadahl: there are some ideas for more: xdg_splash, xdg_pip
18:12 vyivel: eh, right
18:14 vyivel: xdg_surface.get_popup taking xdg_surface as parent is a bit ugly in that case
18:14 vyivel: should probably add an error for "invalid popup parent" or something like that too
18:15 jadahl: get_popup takes a xdg_surface as a parent because the parent can be both a xdg_toplevel and xdg_popup
18:16 vyivel: yes, but if an xdg_surface is used as a base for hypothetical xdg_splash, it shouldn't be allowed
18:16 i509vcb: I could see a pip having a reason to maybe have a popup, but not splash
18:17 jadahl: yea, sure, and there already is a 'invalid_popup_parent' error
18:18 jadahl: it will now be raised if you e.g. create circular popups
18:18 jadahl: ..chains
18:18 vyivel: oh, indeed there is
18:18 vyivel: it's fine then