08:27pioyi: Hello! I'm trying to create a simple app using nothing but wayland's C API
08:27pioyi: I'm trying to access wayland-book.com but its seems to be broken
08:27pioyi: Is there some sort of book or detailed tutorial that I can follow to get started?
08:28pioyi: I could read source code and the official docs but I'm looking for something that will guide me to the right path faster
08:28pioyi: I don't want to create a compositor, just a simple client app, a status bar
08:35vyivel: what is the expected behavior of "wl_surface.attach(buffer), buffer.destroy(), wl_surface.commit()"? mutter/kwin/weston unmap the surface (and allow to remap it without going through the initial configuration sequence…), wlroots/smithay show the contents of the destroyed buffer (which, i presume, is wrong too?)
08:35vyivel: sounds like this should be illegal tbh
08:36dubiousness: pioyi: the url was hit by the sourcehut DDoS outage, you can pull the full thing here: https://git.sr.ht/~sircmpwn/wayland-book/tree
08:37dubiousness: I'd imagine the book will be back up at some point today
08:38pioyi: Ok thank you so much!
08:38pioyi: Will that book be enough for me to create a client?
08:38pioyi: Or are there any crucial parts missing?
09:38pq: vyivel, I guess everyone thinks their behaviour is correct, because this is not explicitly spelled out.
09:39vyivel: i'm just not sure what would be correct to do here because all of those sounds bad to me
09:40pq: vyivel, you could even stretch the spec to claim that showing the destroyed buffer's contents is correct, because there is a phrase that allows the compositor using buffer contents even after its desctruction as long as the client is not re-using that storage.
09:40pq: yeah
09:40soreau: because that's a perfecet frame :P
09:40soreau: perfect*
09:41pq: soreau, for application shutdown reasons
09:41pq: clients do not generally wait for the buffers to be released by the compositor when they are quitting
09:41pq: they just quit, which automatically destroys the wl_buffer
09:42vyivel: attach+destroy is fine
09:42pq: but compositors may need the window contents for much longer, for window closing animations
09:42vyivel: attach+destroy+commit is strange
09:42pq: no, I would say attach+destroy without a replacement attach is definitely strange
09:42pq: commit or not
09:42emersion: the proto allows for things like:
09:43pq: foremost, this is a client bug to need to even ask this question
09:43soreau: clients do crazy things and the compositor should be do The Right Thing even when clients don't obey specs IMHO
09:43emersion: set_input_region(); destroy(); commit();
09:43emersion: to me not allowing attach(); destroy(); commit(); is a protocol design mistake
09:43pq: soreau, well, that's why the spec was changed to allow compositors to read the buffer even if it was destroyed.
09:44emersion: but this ship has sailed now...
09:44vyivel: well it's not "not allowed"
09:44vyivel: it's unspecified
09:44pq: emersion, I didn't understand.
09:45emersion: pq, there is an inconsistency between set_input_region() and attach() -- the former allows the region to be destroyed before commit, the latter doesn't
09:46pq: oh that
09:46pq: yes, it is. No problem.
09:46pq: we could have forbid that desctruction, but it would make no practical difference
09:47emersion: it would make clients more complicated to write
09:47pq: The protocol allows attach(B); B.destroy(); commit(), but it does not specify what that does.
09:47emersion: they'd need to wait for commit to be sent before destroying their regions
09:47pq: sure
09:48emersion: the set_XXX_region(); region.destroy(); …; commit(); pattern is widely used
09:48pq: sure
09:49soreau: but in reality, clients will just do whatever despite any new rules
09:49pq: The spec also says that the region data is saved or copied on set, which means furhter changes the the region before commit will not affect the committed data.
09:49pq: *to the region
09:50soreau: so you might as well make the compositor resilient and robust as possible instead of saying 'well it is a buggy client' only to get back 'but it works in this other compositor'
09:50pq: wl_buffer is different, because do not want to mandate compositors making a full copy on attach, or ever.
09:51soreau: barring any extreme special casing
09:51pq: soreau, I understand that way of thinking, and it leads to hell.
09:52soreau: pq: you can't win 'em all but you also can't just say 'oh I am making so if you do not follow the client rules, you will be punished!'
09:52soreau: clients always do the unexpected wrong thing
09:53pq: I don't know what you're arguing about. We do disconnect clients with protocol errors when a spec defines it.
09:55emersion: compositors can reference the buffer
09:55soreau: you can't detect every possible 'error' case, most clients gets disconnected for some low level resource error or otherwise installed incorrectly
09:55pq: vyivel, my interpretation of the spec is that destroying the wl_buffer before commit will remove that wl_buffer from the wl_surface pending state. Other people think in terms of references to the underlying storage and not the protocol object, so they disagree.
09:56vyivel: this works for me
09:58pq: We do have explicit wording saying that the compositor cannot read the buffer contents before it has been committed. This means that a compositor cannot read buffer B1 based on the sequence attach(B1); attach(B2); commit;
09:58emersion: https://gitlab.freedesktop.org/wayland/wayland/-/issues/300
09:58pq: whether one can draw any implications from that to the attach-destroy-commit case is another matter
10:00pq: In any case, the client is confused if it does attach-destroy-commit, it's a nonsense operation.
10:01pq: if it wants to undo the attach, it needs a new attach, not destroy
10:02pq: if it wants to send that buffer, then don't destroy until you've given the compositor the permission to handle it.
10:02emersion: agree on former, disagree on latter
10:03pq: because you track storage, not protocol objects?
10:05pq: btw. wl_buffer.release semantics are completely irrelevant in the attach-destroy-commit case, because the wl_buffer was not committed, therefore it's not used by the compositor, and there is no release coming.
10:05vyivel: aha https://gitlab.freedesktop.org/wayland/wayland/-/issues/387 is the relevant issue
10:06pq: maybe people are mislead by our sloppy writing, using "buffer" when we refer to "wl_buffer"
10:07pq: that's why I use "storage" when I'm specifically talking about the memory behind the handle
10:10soreau: just disconnect the client if it commits a surface with a destroyed wl_buffer attached :)
10:10soreau: that'll teach 'em
10:13vyivel: wl_resource_post_error() is the best libwayland function
10:13pq: ah, we were not sloppy, the spec is written with "wl_buffer", good.
10:15pq: I'm still agreeing with myself from half a year ago.
10:16pq: I think the only valid question that remains is whether attach-destroy-commit is equivalent to no attach or attach(NULL).
10:18vyivel: the former makes a bit more sense personally
10:19vyivel: mutter/kwin/weston do the latter fwiw
10:27vyivel: "allow to remap it without going through the initial configuration sequence" — seems like they don't care at all
10:37wlb: wayland Merge request !363 opened by Kirill Primak (vyivel) protocol: clarify pending wl_buffer destruction https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/363
10:40soreau: vyivel: s/pending/attached/ maybe?
10:40vyivel: a bunch of paragraphs above use "pending"
10:42soreau: there's also a lot of "attached" :P
10:46vyivel: not really
10:46vyivel: anyway it's clear enough
11:58wlb: weston Issue #609 closed \o/ (The kernel never declares which EOTF modes it supports in HDR_OUTPUT_METADATA https://gitlab.freedesktop.org/wayland/weston/-/issues/609)
12:00wlb: weston Issue #396 closed \o/ (Always create stable branches? https://gitlab.freedesktop.org/wayland/weston/-/issues/396)
13:45daniels: emersion: mind if I do a w-p release so we can get dmabuf v5 out?
13:45emersion: please do
13:45emersion: we have various MRs blocked on a w-p release
13:56wlb: wayland-protocols New tag: 1.33 https://gitlab.freedesktop.org/wayland/wayland-protocols/tags/1.33
13:57wlb: wayland-protocols Merge request !275 opened by Daniel Stone (daniels) build: Bump version to 1.33 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/275
14:00wlb: wayland-protocols/main: Daniel Stone * build: Bump version to 1.33 https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/54346071a5f2 meson.build
14:00wlb: wayland-protocols Merge request !275 merged \o/ (build: Bump version to 1.33 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/275)
14:00daniels: emersion: ^ :)
14:00emersion: ty!
14:01daniels: quite relieved that actually worked tbh, as it's the first time I've released anything using glab-cli :P
14:01wlb: weston Issue #860 closed \o/ (Qt app to take its own screenshot https://gitlab.freedesktop.org/wayland/weston/-/issues/860)
14:09wlb: weston Issue #859 closed \o/ (Weston 5 cross-compile issues with makefile https://gitlab.freedesktop.org/wayland/weston/-/issues/859)
14:11wlb: wayland/main: Consolatis * cursor: add aliases for cursor name spec https://gitlab.freedesktop.org/wayland/wayland/commit/6daa1b8713f0 cursor/cursor-data.h
14:11wlb: wayland Merge request !291 merged \o/ (cursor: add aliases for cursor name spec https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/291)
14:17wlb: wayland/main: Simon Ser * protocol: document wl_surface.offset for sub-surfaces https://gitlab.freedesktop.org/wayland/wayland/commit/dc1da181db06 protocol/wayland.xml
14:17wlb: wayland Merge request !345 merged \o/ (protocol: document wl_surface.offset for sub-surfaces https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/345)
14:32wlb: weston Issue #852 closed \o/ (DRM deinit with error device https://gitlab.freedesktop.org/wayland/weston/-/issues/852)
14:33wlb: wayland/main: Simon Ser * util: use C23 typeof if available https://gitlab.freedesktop.org/wayland/wayland/commit/56b9c92b9881 src/wayland-util.h
14:33wlb: wayland/main: Simon Ser * util: use C23 deprecated attribute https://gitlab.freedesktop.org/wayland/wayland/commit/647398ead44e src/wayland-util.h
14:33wlb: wayland Merge request !331 merged \o/ (util: use C23 typeof/deprecated if available https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/331)
14:33wlb: weston Issue #851 closed \o/ (update connector to wrong drm_device https://gitlab.freedesktop.org/wayland/weston/-/issues/851)
14:36wlb: weston Issue #850 closed \o/ (Multi-GPU hot plug https://gitlab.freedesktop.org/wayland/weston/-/issues/850)
14:41wlb: wayland/main: Ben Widawsky * protocol: clarify scale expecations https://gitlab.freedesktop.org/wayland/wayland/commit/8072ab0a505d protocol/wayland.xml
14:41wlb: wayland Merge request !357 merged \o/ (protocol: clarify scale expecations https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/357)
15:15wlb: wayland/main: Simon Ser * shm: fix resource versions https://gitlab.freedesktop.org/wayland/wayland/commit/9e233e31a21b src/wayland-shm.c
15:15wlb: wayland/main: Simon Ser * protocol: add wl_shm.release request https://gitlab.freedesktop.org/wayland/wayland/commit/f06736a8a088 protocol/wayland.xml
15:15wlb: wayland/main: Simon Ser * shm: implement version 2 https://gitlab.freedesktop.org/wayland/wayland/commit/fd42f70bafa2 src/wayland-shm.c
15:15wlb: wayland Merge request !335 merged \o/ (protocol: add wl_shm.release request https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/335)
15:17wlb: wayland Merge request !102 closed (Consider pkgconfig sysroot for pkgdatadir)
15:21wlb: wayland/main: Andreas Cord-Landwehr * Consider pkgconfig sysroot for pkgdatadir https://gitlab.freedesktop.org/wayland/wayland/commit/8c49ee311245 src/meson.build
15:21wlb: wayland Merge request !272 merged \o/ (Consider pkgconfig sysroot for pkgdatadir https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/272)
15:21wlb: wayland Merge request !305 closed (protocol: fix inconsistent typing of wl_output.transform)
15:23wlb: wayland Merge request !288 closed (release.sh: Require at least glab version 1.25.3)
15:38wlb: wayland/main: John Lindgren * connection: Small simplification to wl_connection_write() https://gitlab.freedesktop.org/wayland/wayland/commit/9867bdb111f8 src/connection.c
15:38wlb: wayland Merge request !275 merged \o/ (connection: Small simplification to wl_connection_write() https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/275)
15:49wlb: wayland Merge request !126 closed (Print the list of open file descriptors if exec-leak-check fails)
15:49wlb: wayland Merge request !178 closed (Draft: switch calls from assert() to wl_abort() | fixes#230)
15:53wlb: wayland/main: Erik Chen * connection: Spruce up logging for client errors. https://gitlab.freedesktop.org/wayland/wayland/commit/2f17d480e848 src/connection.c
15:53wlb: wayland Merge request !274 merged \o/ (connection: Spruce up logging for client errors. https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/274)
16:50wlb: weston Issue #840 closed \o/ (simple-dmabuf-egl: screen tearing https://gitlab.freedesktop.org/wayland/weston/-/issues/840)
17:09Eighth_Doctor: pq: I think I've made progress on getting weston to work, now I just need to get xwayland to run properly... this would be easier if weston supported launching xwayland with a specific display number
17:09Eighth_Doctor: would it be unreasonable to ask for a way to do that?
17:12soreau: yes
17:13soreau: IIRC you should have weston start whatever app you need so DISPLAY will be set already
17:13Eighth_Doctor: why?
17:13Eighth_Doctor: soreau: the problem is that the app launches the display itself
17:13Eighth_Doctor: otherwise this would be easy
17:13soreau: what do you mean by 'launches the display itself'?
17:14Eighth_Doctor: the anaconda installer starts out as non-graphical and then boots up the graphics and attaches itself to the X display
17:15soreau: so have weston start and write the DISPLAY somewhere, then have anaconda read it?
17:16soreau: I mean if you're anaconda starting weston, and you're the only xserver around, the display number should be the same every time I would imagine
17:17Eighth_Doctor: yeah I would hope so
17:17Eighth_Doctor: I need to find all the places where the hardcoded display is set and change it though :/
17:17Eighth_Doctor: s/set/used/
17:19soreau: I don't think it's hardcoded at all
17:19Eighth_Doctor: in anaconda it is
17:19Eighth_Doctor: there's a constant and everything uses that to get the display number
17:19soreau: oh, in anaconda..
17:20Eighth_Doctor: it's not hardcoded in weston, weston just does its thing just fine
17:21soreau: well you can run some stupid/non-graphical x11 app to get weston to launch Xwayland, then find it in the process tree and see what display it was started with and use that one
17:21Eighth_Doctor: yes...
17:21Eighth_Doctor: there are a few ways to do this
17:23daniels: I'd say we'd take an option to set the display number, yeah
17:24Eighth_Doctor: phew
17:24soreau: but if it's in use, you have to pick a different one anyway
17:26soreau: the other problem is that you end up with stupid scripts like startmycompositor & sleep 3; startmyx11app & yayanotherone &
17:26soreau: and then you have people complain that they can set the x11 display number but not the WAYLAND_DISPLAY number
17:29Eighth_Doctor: we can set that already
17:29Eighth_Doctor: --socket does that
17:29Eighth_Doctor: I'm already using it to have a different socket other than the default wayland-0
17:32q234rty: every time I read "anaconda" I think the python thingy
17:33Eighth_Doctor: well it is written in python 😅
17:33q234rty: yeah, but you know what I'm talking about :)
17:33Eighth_Doctor: yup
17:34Eighth_Doctor: I know
18:39ids1024: It seems that Mesa (at least for EGL) always uses the `main_device` of default feedback as the "display GPU". Would it be correct to say the "display GPU" should change based on surface feedback, and always be the same as the render GPU if there's at least one tranche for the display GPU (with a format that can be used for rendering, at least?), and otherwise use the current surface
18:39ids1024: feedback `default_gpu`?
18:40ids1024: Changes like https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/268 may be necessary, but compositors and clients could also still make better use of the protocol as it exists. Unless the protocol just isn't currently capable of supporting the things it's designed to support.
18:42ids1024: As I understand, currently with EGL_PRIME=1, if I have a full screen surface on the prime monitor, Mesa will just copy to a linear buffer on the the main GPU which the compositor has the render/copy for the prime GPU. When it should be possible to use direct scan out.
19:04Eighth_Doctor: actually it looks like i might have a (semi-convoluted) way to avoid having a fixed display name
19:04Eighth_Doctor: *number
22:36Eighth_Doctor: pq: well I figured out why weston was behaving so oddly, I forgot to close the files so they got written to disk 😅
22:36Eighth_Doctor: so weston read an empty file and just said "meh" and did everything else instead