10:08pq: If I were to make a binary distribution of Weston/DRM that should be as easy to use as "download one file and run it from a VT", what tech should I look at? Arch can be limited to x86_64.
10:09pq: A statically linked binary would require significant changes that I'm not ready to do for now.
10:10emersion: AppImage maybe?
10:10pq: cool, I got the same idea after seeing my accounting software using AppImage :-)
10:12pq: another comment I heard made AppImage sound like... dead tech
10:12emersion: something like docker would be a bigger hammer
10:12emersion: maybe flatpak could work, but it has many unnecessary pieces
10:13emersion: for this use-case
10:13pq: can you access host logind and devices from inside such images?
10:13emersion: you can configure the image to bind-mount what you need
10:13emersion: i don't think sharing the GL impl would work too well though
10:14emersion: maybe that's an upside or a downside for your use-case, i don't know
10:14pq: I'm not sure I'd like to bundle Mesa. I might want to bundle Xwayland.
10:15emersion: bundling Xwayland sounds annoying from AppImage
10:16pq: why is that?
10:16pq: and why would sharing GL impl (using the host libs+drivers?) have problems?
10:17emersion: hm, maybe it's not that bad
10:18emersion: sharing the GL impl seems complicated with docker
10:18emersion: and can't be done with flatpaj
10:18emersion: flatpak*
10:18pq: because I'd have to bind-mount lots of arbitrary little bits for the docker image?
10:19emersion: yeah, and the location of these things may vary depending on the linux distro etc…
10:19emersion: and the libc might be different…
10:20pq: I'd very much don't want to bundle libc. :-)
10:20pq: ok, flatpak is out, then. Wait, do you mean that all flatpak apps will always use the Mesa hardware drivers from whatever flatpak runtime they use, never from host?
10:20emersion: yes
10:20emersion: 🙃
10:21pq: nevermind NVIDIA? :-P
10:21emersion: i have no idea how that works with NVIDIA
10:21pq: heh
10:21pq: not that I'd care about NVIDIA, just curious
10:22pq: so far sounds like AppImage would be the first thing to try
10:22emersion: it seems like there is a NVIDIA runtime for flatpak
10:22swick[m]: we generate a oci image for mutter/gnome-shell
10:23emersion: i'm annoyed that this stuff is named "freedesktop" runtime
10:23emersion: when it's flatpak-specific really
10:23swick[m]: the runtime is very much not flatpak specific
10:24swick[m]: it is literally just an ostree repo
10:24swick[m]: and the buildstream definitions
10:24emersion: hm, right
10:27emersion: nevermind then
10:28pq: the one thing I am sure of, is that I would want users to be able to run their apps from the host under that packaged Weston.
10:29pq: That's kind of the main point.
10:29pq: so Wayland and X11 sockets need to be accessible from the host
10:30pq: how would that fit with the different techs?
10:30emersion: i think it should be fine regardless of tech
10:30emersion: with containers, you can bind-mount XDG_RUNTIME_DIR and /tmp/.X11-unix
10:31emersion: X11 might be an issue because of the user ns though
10:32emersion: (heard issues from people trying to use gamescope in a container with userns)
10:33pq: hmm, I'd have to get something like a terminal run on the host, connecting to Weston, after Weston starts. Can't do that from inside the image, I suppose.
10:35swick[m]: I develop mutter inside toolbx which is essentially just a podman container with a few things bind-mounted
10:35swick[m]: and everything, including Xwayland works
10:35pq: interesting
10:36swick[m]: eh, except KMS netlink because this is bound to the user and network namespace in a weird way
10:36swick[m]: we really should get an eventfd based thing instead
10:39pq: My goal here would be to let people test Weston's color-management features easily using their own apps, without needing to build and install anything. I doubt my target audience would bother if they need to install dependencies, let alone build things.
10:39swick[m]: I even do more crazy things and use fedora silverblue OCI container as my base to develop mutter in and then boot into that via rpm-ostree
10:40swick[m]: weston doesn't require integration with other things so that should be really easy as an OCI image
10:40pq: ok, that sounds nice
10:42pq: do you know of an OCI image tutorial where I could start? I know nothing for starters.
10:48swick[m]: usually people write Containerfiles for building OCI images and then you need to figure out how to invoke docker/podman to integrate with the host system
10:54pq: I can find lots of write-ups on the topic, but it's hard to understand which ones would be good to follow.
10:56colinmarc: I think the easiest way is to start with an existing image for the OS you want (for example: https://github.com/gezp/docker-ubuntu-desktop). And then you can layer on the stuff you need, using what that dockerfile does as an example.
10:56colinmarc: I haven't tried that image, just something I found googling.
11:07pq: I guess buildah tutorials like https://github.com/containers/buildah/blob/main/docs/tutorials/01-intro.md are a good intro?
11:19emersion: swick[m]: but one wouldn't use the OS GL impl with an OCI image, right?
11:19swick[m]: no
11:20emersion: that's an explicit goal of pq
11:20swick[m]: it is also not possible
11:20emersion: what do you mean?
11:21swick[m]: it's not possible to have something independent of the host and use host libraries
11:21emersion: it's not possible with containers in general, but it's possible with other tech like AppImage
11:21swick[m]: no, it's not
11:21emersion: AppImages typically use the OS GL impl
11:21emersion: they don't run in a fully containerized env
11:22swick[m]: it allows you to mix host and bundled things but that is inherently not stable
11:22pq: I don't know actually
11:22emersion: well, that's your PoV :P
11:22emersion: AppImage folks seem to disagree, at least
11:22swick[m]: no, it is literally just how it is
11:22swick[m]: yes, but they are not exactly know for being... well.
11:23swick[m]: it's a technical question and not a matter of opinion
11:23emersion: this doesn't seem like a productive discussion
11:24emersion:goes back to work :P
11:24pq: bundling drivers seemed like a fundamentally bad idea to start with, but if everyone is doing it already...
11:25emersion: yeah, it's an issue with flatpak: sometimes the flatpak driver is older than the host…
11:25JEEB: yea, I remember looking into that when poking around snap/flatpak, and saw that being the "best practice"
11:26swick[m]: there are possible solutions, but they are not "take random crap from host" but more like "build every dependency of the driver statically"
11:27emersion: personally, i think it's fine to assume a reasonable base (libc, GL impl) from the host, and add additional libs on top
11:33q234rty: there is infracture for host provided runtime extensions so distros can in theory provide GL drivers to flatpak
11:33q234rty: no distro that I know of seems to be doing that though
11:33pq: heh
11:33mjt: next we'll talk about bundling the kernel with flatpack
11:34swick[m]: they do for nvidia
11:40wlb: wayland Issue #458 opened by Julian Orth (mahkoh) Deprecate parts of wl_output and xdg_output https://gitlab.freedesktop.org/wayland/wayland/-/issues/458
11:52colinmarc: I haven't seen an app use set_cursor with a dmabuf. should I go out of my way to handle that or just handle shm buffers for cursors?
11:53emersion: i think GTK might use a DMA-BUF?
11:53emersion: or is it for drag-and-drop icon only?
11:53emersion: can't remember details
11:53emersion: but in general i'd expect them to work
11:53pq: colinmarc, your compositor would be deemed broken if it doesn't handle dmabuf, or sub-surfaces or wp_viewport or any other generic wl_surface thing also on the cursor role surfaces.
11:54colinmarc: emersion: Ok, thanks. I can only run gtk apps via xwayland atm because I don't support drag and drop yet, and gtk apps crash on startup if you don't offer that global :)
11:55emersion: that's unfortunate
11:56colinmarc: pq: Hm, I didn't even think of subsurfaces. I think I can hook into my renderer which supports all that anyway - good that I didn't try to take a shortcut.
11:56pq: colinmarc, heh, yeah
11:57pq: Weston's renderer and backends do not even know that a surface might have a cursor role. They handle them all the same.
11:57mclasen: we don't use dmabufs for cursor in gtk, no
11:58emersion: i thought jadahl mentioned something about DMA-BUFs for DnD or something
11:59emersion: but it was a long time ago, maybe just a plan, maybe i misremeber
11:59emersion: mclasen: can you elaborate in your comment? it's not very clear to me what the issue is about
11:59emersion: and what the implications are
12:03mclasen: https://gitlab.gnome.org/GNOME/gtk/-/issues/6357#note_1985015 seems a good summary?
12:04mclasen: anybody trying to consider device pixel pixels in their sizing decisions is forced to play games
12:04mclasen: I can't say that I'm a huge fan of the use case, but want to do things like that
12:07emersion: isn't that equivalent to doing stuff at scale=1 then later the scale is updated to 1.5?
12:07emersion: GTK can scale the bounds based on that
12:07mclasen: there is no later. you need to decide the initial size when you need it
12:08emersion: the initial size is the one in configure bounds
12:08emersion: then later the scale is updated to something else
12:08emersion: and the app needs to handle the scale change as usual
12:09mclasen: it is pretty miserable to force everybody to go through a scale change every time they present a window
12:10mclasen: and even so, it is not clear what scale is even current at configure-bouinds time
12:10mclasen: we can get either logical or physical sizes, depending on circumstances
12:11emersion: configure_bounds always sends logical coords
12:11emersion: the initial scale issue is a more general issue: the compositor can't say what the scale is before it knows the size of the window
12:12emersion: it can guess, maybe, but maybe the guess is wrong
12:12mclasen: it can't know the bounds anymore either, and yet it hands them out
12:12emersion: so you'll always need to handle scale changes after initial mapping
12:12emersion: why wouldn't it know the bounds?
12:13mclasen: for the same reason it can't know scale
12:13emersion: ?
12:13mclasen: if the surface ends up on a different output, the scale changes
12:13mclasen: why else would it not know the scale?
12:13emersion: the compositor chooses the output before-hand
12:13emersion: at initial null commit time
12:13mclasen: and the bounds depends on the output just the same
12:13emersion: then sends the bounds with available space
12:13emersion: then if the window fits in the output, the scale is the output's
12:14emersion: but if it's larger, then the scale is different
12:14zamundaaa[m]: emersion: I wouldn't consider scaling dependent on the window size
12:14mclasen: I'd be perfectly happy if you give me the scale of the selected output
12:14mclasen: at configure-bounds time
12:14zamundaaa[m]: At least not the scale you tell the client
12:15emersion: zamundaaa[m]: if the window is 1000px and the output is 900px, and the output on the left has a different scale, what happens then?
12:15mclasen: a scale change
12:15emersion: s/left/right/
12:15mclasen: as you've been arguing
12:15mclasen: but that only happens if I don't respect the bounds
12:15mclasen: which is on me
12:16emersion: btw, nothing stops compositors from sending a good guess for the scale before mapping time
12:16zamundaaa[m]: Yeah, that's a client problem then
12:16mclasen: sure
12:16zamundaaa[m]: Same as the compositor not sending a good initial scale is a compositor problem
12:16mclasen: sure, it would be great if the protocols mandated that
12:17emersion: mandating for a guess is…
12:17emersion: not great
12:17zamundaaa[m]: There's no need to mandate it
12:17emersion: especially if there will always be cases in which the guess is incorrect and clients need to handle the special case
12:17mclasen: you say you don't want to guess, that forces clients to guess
12:17emersion: we could make it a "should" or something
12:18mclasen: and then people file issues like the one that started this discussion
12:18emersion: anyways
12:18zamundaaa[m]: Yeah a recommendation would be fine
12:18emersion: i don't see how all of this relates to the disucssion about dropping these wl_output props?
12:19emersion: GTK uses the wl_output.scale to take a guess?
12:19mclasen: how else would we guess ?
12:19emersion: my expectation would be no guess
12:19mclasen: I came to this discussion from this comment: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/297#note_2380277
12:21emersion: the previous discussion about first frame on HiDPI is https://gitlab.freedesktop.org/wayland/wayland/-/issues/133
12:26vyivel: can't that issue be closed now?
12:27wlb: weston/main: Pekka Paalanen * tests: replace mat2XYZ https://gitlab.freedesktop.org/wayland/weston/commit/94ccce4e3866 tests/ color-icc-output-test.c color-management-test.c lcms_util.c lcms_util.h
12:27wlb: weston/main: Pekka Paalanen * tests: fix perceptual intent in cLUT ICC profiles https://gitlab.freedesktop.org/wayland/weston/commit/9f4a9089f4c9 tests/lcms_util.c
12:27wlb: weston/main: Pekka Paalanen * color-lcms: switch default rendering intent to perceptual https://gitlab.freedesktop.org/wayland/weston/commit/abe3e20e1f82 libweston/color-lcms/color-lcms.c
12:27wlb: weston Merge request !1491 merged \o/ (Improve test ICC profiles, switch default rendering intent https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1491)
12:31emersion: vyivel: well, mclasen's point is that with today's impls, it's not possible to have a perfect first frame on HiDPI
12:31vyivel: ack
12:33ifreund: can the compositor just not display the first frame the client commits?
12:34pq: then the client would likely never display a second frame?
12:34emersion: pq, the compositor can send a configure event, and wait for an ack
12:34ifreund: the compositor would still send frame done, how would the client know?
12:34mclasen: if you never show any frames, every frame will be perfect
12:34emersion: frame done wouldn't let the compositor know when the client has handled the change
12:34emersion: so a valid client could never send a new frame
12:35ifreund: right, you need configure as well
12:35pq: heh
12:35emersion: still, sounds a bit annoying
12:35ifreund: though frame done can be used to get the client to keep rendering new frames until the ack+commit
12:35emersion: tbh i think a good guess will work in almost all cases
12:35ifreund: emersion: sway and river already have excatly this code for their transaction systems...
12:36emersion: right, frame is required to avoid stalling the client
12:36mclasen: sounds like abusing frame to extend the initial configure negotation phase
12:38ifreund: the client wouldn't even know it was happening or need to care, the compositor doesn't need to render a frame at the wrong scale
12:38ifreund: sure it would be cleaner if this was solved at the protocol level in a nice way, but that doesn't seem to be the case
12:39ifreund: also like I said, sway and river already do exactly this to make frame-perfect resize of many clients in a tiled layout work
12:40ifreund: they send a configure to all clients being resized and then drop new frames until the compositor has a buffer of the new size for all clients
12:40emersion: yeah, it's a normal thing to do
12:40emersion: still not great to have the client have one useless render at startup
12:41ifreund: for sure, it's ugly but it would work :D
12:41emersion: but if it's only in the weird edge case that it happens, shrug
12:41emersion: not sure it's worth to add more complexity to the xdg_toplevel setup just for that
12:42mclasen: just to be clear - the problem in the gtk issue is not about rendering with the wrong scale. it is about determining the size of the surface
12:42emersion: like a request for the client "i picked this initial size for my window", then wait for the compositor to send a scale
12:43emersion: mclasen: the size of the surface is in logical coords, and so is the configure_bounds
12:43zamundaaa[m]: emersion: the client making a request with a size and then having the compositor respond, instead of resizing just by doing it immediately is a thing that would be nice for other things
12:43emersion: none of that depends on the scale
12:43emersion: if the client depends on the scale internally, it can pick "1"
12:43mclasen: yet, image viewers want to configure a size that lets them show the image 1-1 in device pixels
12:44mclasen: and maximize the surface if that size is too big
12:44emersion: zamundaaa[m]: how many roundtrips will it take to show a window? :D
12:44mclasen: I did not make use case, but thats things people want to do with gtk
12:44emersion: mclasen: thanks for bringing up that use-case, it's much easier to think about this problem with a use-case in mind
12:45emersion: that would be useful stuff to add in a GitLab comment
12:48emersion: zamundaaa[m]: what other things were you thinking about?
12:58wlb: wayland Issue #459 opened by Matthias Clasen (matthiasc) stacking order is double-buffered state of the parent surface https://gitlab.freedesktop.org/wayland/wayland/-/issues/459
13:53emersion: d_ed, if it wasn't OK to workaround old APIs, wayland would have global window positioning
13:53emersion: "there exists an API that assumes X11 concepts" is not super helpful, i'd say
13:55d_ed[m]: Nor is an API that only serves hypothetical clients.
13:56d_ed[m]: Toolkits are our abstraction layer, if we don't supply what they need we haven't done our requirements analysis
13:56emersion: what they need isn't necessarily the old APIs that are carried over from X11 times
13:56emersion: hence my question about actual use-cases
13:56d_ed[m]: Not X11 times, from the common denominator of every other windowing system
13:57emersion: it is highly questionable how a regular app would use output layout info, in the context of a windowing system which doesn't let you know the position of your windows
13:57d_ed[m]: I can guarantee I will have an application out there that doesn't want to be bigger than the screen as it has a check in there already.
13:57d_ed[m]: I can guarantee I will have an application out there that defaults to 80% of the screen size.
13:57d_ed[m]: It can't be faked
13:58emersion: configure_bounds is the solution
13:58d_ed[m]: No.
13:59emersion: the screen size is not suitable anyways, if you have panels and other desktop UI elements
13:59emersion: and which screen to use
13:59emersion: it falls apart pretty quickly
14:00ifreund: +1 configure_bounds is the only robust answer
14:00d_ed[m]: Ok, tell me how to make configure_bounds work with the examples above changing only toolkit code and not the application code
14:00emersion: Qt can add new APIs
14:01ifreund: tell apps the output is the size of the configure bounds?
14:01emersion: it should also be possible to have workarounds for old apps in Qt, yeah
14:01d_ed[m]: that's not how it works IRL
14:01emersion: expose only a single screen with the size in configure_bounds
14:01emersion: well, it worked for GTK
14:01zamundaaa[m]: ifreund: it's not that simple. Apps first look at outputs, then create a window
14:03emersion: output layout API is mechanism
14:03emersion: configure_bounds is policy
14:04emersion: not the first time this happens
14:07zamundaaa[m]: emersion: about "what other things were you thinking about?", the main benefit would be to be able to cleanly constrain clients to the output bounds when they don't do it themselves
14:08zamundaaa[m]: As in, client suggests it wants a size bigger than the output, so the compositor can just say "no", and doesn't need to resort to hacks like not painting the wrongly sized frames until the client reacts to a resize request
14:09emersion: but a good client shouldn't do this?
14:09zamundaaa[m]: as you know, not every client is a good client
14:10emersion: not sure it's worth adding that new roundtrip just for this
14:10emersion: clients accept bug reports, in general
14:10zamundaaa[m]: I could also imagine it would help with tiling. You get an idea for what size the client wants before you have to decide on a tile to put it in, and set the configure bounds accordingly
14:10emersion: in tiling mode, the compositor dictates the size in configure
14:10emersion: (not in configure_bounds)
14:11emersion: but yeah, the point is still valid regardless
18:44wlb: wayland Merge request !365 closed (protocol: Require pushing upcoming state to cache on set_sync)