13:03 wlb: weston Merge request !1478 merged \o/ (color-lcms: print profile id instead of pointer https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1478)
13:03 wlb: weston/main: Pekka Paalanen * color-lcms: print profile id instead of pointer https://gitlab.freedesktop.org/wayland/weston/commit/b0224c475249 libweston/color-lcms/ color-lcms.c color-profile.c color-transform.c
13:03 wlb: weston/main: Pekka Paalanen * color: generate id for color transformations https://gitlab.freedesktop.org/wayland/weston/commit/aef9404b1d71 include/libweston/libweston.h libweston/color.c libweston/color.h libweston/compositor.c
13:03 wlb: weston/main: Pekka Paalanen * color-lcms: print transformation id instead of pointer https://gitlab.freedesktop.org/wayland/weston/commit/efec55cf62f7 libweston/color-lcms/ color-lcms.c color-transform.c
13:43 Ermine: Are there Wayland compositors that can work with fbdev?
13:44 pq: there used to be
13:45 pq: not sure if anyone bothers anymore
13:45 bl4ckb0ne: you can write an allocator impl for wlroots easily to get that to work
13:47 emersion: an allocator wouldn't work, i think
13:47 kennylevinsen: you'd probably need a new output backend which memcpy's on commit...
13:48 emersion: Ermine: the best path forward would be to write a tiny, simple KMS driver for the hw you want to use
13:48 kennylevinsen: assuming one isn't already present
13:48 emersion: if you're interested, feel free to ask for directions, there are people who've done similar things and could help
13:48 pq: Ermine, any particular reason for fbdev?
13:52 bl4ckb0ne: yeah simpledrm might be best
13:52 bl4ckb0ne: you can plug whatever framebuffer you get from uefi into it
13:52 bl4ckb0ne: thats for osdev right?
13:55 Ermine: No
13:57 Ermine: I'm going to run pmOS on rk3588s chip. Hardware enablement bits for it are not released, so I want to have fallback in case drm driver fails
13:57 pq: why would there be an fbdev driver that is not a DRM driver?
13:58 Ermine: I guess this option for now is X11, so I wondered if there's something in wayland world suitable for the task
13:58 Ermine: Oh. I thought fbdev is something universal. Forgive my ignorance!
13:59 pq: no, fbdev is based on drivers too, and they are getting eliminated and replaced with DRM drivers.
13:59 bl4ckb0ne: fbdev is deprecated
13:59 Ermine: Okay... So, fallback is simpledrm?
14:00 bl4ckb0ne: https://www.kernelconfig.io/config_drm_simpledrm you probably need that in your kernel
14:00 kennylevinsen: yeah, IIRC if the platform supports it that will be available until the real drm driver loads
14:01 Ermine: Okay, thank you very much!
14:02 pq: if you want to optimize performance without a GPU, then choose a software renderer (Pixman, Skia, whatever) your choice of Wayland compositor offers. It's likely faster than GL or Vulkan without GPU support.
14:06 Ermine: Ah, I forgot abou pixman. Thank you again
14:07 tsv: I’m interested in writing a simple application that lets you select a portion of your screen and displays it in another window. This would make it easier to share portions of your screen and potentially record them too. I’m used to working at a higher level than this though, so this is new ground for me. I’m somewhat intimidated and unsure where to start! Just wondering if
14:07 tsv: anyone has any pointers?
14:08 Ermine: You'll need t go through compositor to get that
14:09 kennylevinsen: tsv: depends a little on the compositor. For compositors implementing wlroots-based protocols, slurp shows how to make a selection, and wf-recorder shows the recording aspect.
14:10 kennylevinsen: you can also record with pipewire to be compositor-agnostic, but you'd need to find equivalents for slurp
14:10 kennylevinsen: s/wlroots-based protocols/wlroots protocols/ - midway edit going wrong
14:13 Ermine: Though writing simple kms driver would be cool from educational point of view
14:14 tsv: kennylevinsen: That's super helpful, I’ll check those out thanks. Going the Pipewire route sounds sensible, what do you mean about finding the slurp alternative? A way to select a portion of the screen and pass that to Pipewire?
14:15 tsv: I’m going to do some general reading on Wayland and Pipewire first off, I definitely need to do that!
14:15 kennylevinsen: yes, creating a surface on all available monitors so the user can make a selection anywhere is considered somewhat privileged, and while wlr-layer-shell has decent support it is not universal
14:34 emersion: zamundaaa[m]: thank you 😭
14:37 zamundaaa[m]: It's really getting ridiculous with that protocol
14:38 emersion: we should make a wayland-protocols bingo card at some point
14:38 bl4ckb0ne: +1
14:50 Ermine: What are you talking about?
14:52 Ermine: ah, found
15:10 JoshuaAshton: emersion, zamundaaa[m]: What's stopping us merging?
15:10 emersion: we generally don't merge stuff when there are unaddressed comments
15:13 JoshuaAshton: emersion: I'll look at updating the gamescope side of that rn actually
15:13 JoshuaAshton: Will need to be eventfd driven now
15:16 zamundaaa[m]: emersion: that's what the "resolve thread" button is there for
15:16 zamundaaa[m]: I'm not even really joking, there's no unresolved threads about the protocol itself on the MR
15:17 JoshuaAshton: A lot of the new threads have just been people wanting to add weird non-normative stuff that just explains how sync objects work which is strange imo
15:18 JoshuaAshton: If you are smart enough to use this protocol directly, you are smart enough to know how a timeline VkSemaphore works and the pitfalls there imo :frog:
15:19 emersion: i don't think it's bad to provide guidance, though (the linux-dmabuf little document is quite nice for instance)
15:19 emersion: but yeah…
15:22 JoshuaAshton: emersion: btw, seems like I can't just get the fd + timeline point out of a wlr_render_timeline>
15:22 JoshuaAshton: ?
15:42 drakulix[m]: Reading the open discussions I wish we could just deprecate sync subsurfaces.
15:43 JoshuaAshton: I use them in Gamescope, but I also don't do anything esoteric that probably wouldn't also just work(tm) with unsync subsurfaces
15:43 emersion: we don't have a replacement yet
15:43 emersion: (the replacement being surface transactions)
15:43 drakulix[m]: I know..
15:44 drakulix[m]: (I also wish we would have surface transactions...)
15:44 feaneron: doesn't qt-wayland exclusively rely on sync subsurfaces?
15:47 emersion: JoshuaAshton: right… the issue is that generally passing syncobj handles is a footgun, because these are per DRM FD
15:47 JoshuaAshton: How does that interact with dup and friends?
15:48 emersion: per DRM file description, iirc
15:48 emersion: the lifetime of the handle is not something you can rely on as well
15:49 emersion: like, wlroots might destroy the handle under your feet, if we expose the handle in our public API
15:49 JoshuaAshton: Perhaps let me just get an eventfd from it immediately then?
15:49 emersion: i've added a function to export the syncobj as a FD FWIW
15:49 JoshuaAshton: And I can pass that around
15:49 JoshuaAshton: ah
15:49 emersion: yeah, adding a function to extract an eventfd seems perfectly reasonable to me
15:50 emersion: lemme type that
15:50 JoshuaAshton: cool
15:50 JoshuaAshton: I have one locally in gamescope just reading your internal struct rn :frog:
15:51 JoshuaAshton: It'd be nice if it knows the buffer is already done it would tell me that
15:51 JoshuaAshton: rather than giving me a syncfd to readback
15:51 JoshuaAshton: it has to check for wait for submit anyway
15:53 emersion: hrm conflicts conflicts conflicts
15:54 JoshuaAshton: alternatively split the eventfd and the "wait for present" check
15:54 JoshuaAshton: wait for submit rather
15:54 JoshuaAshton: same deal
16:14 zzag: emersion: "we generally don't merge stuff when there are unaddressed comments" those comments are irrelevant, imho it's all good for merging now
16:15 zzag: I also would like to suggest to update the rule about unaddressed comments
16:15 zzag: so only comments from members can block changes
16:16 zzag: and comments from third parties can be considered as suggestions
16:16 zzag: so things don't become so ridiculous
16:17 emersion: just to be clear, there is no written down rule
16:18 emersion: it's just a practice we've been doing in general
16:20 zzag: yeah, I mean it's a good idea in general; but when the situation becomes dire and that person doesn't contribute anything meaningful to the discussion but just drags it, let's just go with "we've considered your input, but we still think it's better to go with this approach instead"
16:20 zzag: do you want me to merge the MR?
16:21 JoshuaAshton: :raised_hands:
16:30 wlb: wayland-protocols/main: Simon Ser * linux-drm-syncobj-v1: new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/ae9ed7ac14e0 staging/linux-drm-syncobj/README staging/linux-drm-syncobj/linux-drm-syncobj-v1.xml meson.build
16:30 wlb: wayland-protocols/main: Simon Ser * linux-explicit-synchronization-v1: add linux-drm-syncobj note https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/8be7ad67fa59 unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
16:30 d_ed[m]: <feaneron> "doesn't qt-wayland exclusively..." <- no
16:30 wlb: wayland-protocols Merge request !90 merged \o/ (linux-drm-syncobj-v1: new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90)
16:30 emersion: hm, no need to rage-rush-merge either…
16:30 feaneron: d_ed[m]: hm, i seem to have memories of qt-wayland breaking when trying to use async subsurfaces
16:31 emersion: sorry it ended up this way, but oh well, thanks for merging
16:31 d_ed[m]: The current code is desync by default
16:32 d_ed[m]: not saying your memories are wrong, but they seem to be old at least
16:32 feaneron: they are definitely old!
16:32 feaneron: at least 3 years old
16:35 emersion: phew 🎉
16:36 zzag: can we have a w-p release now please? :)
16:36 d_ed[m]: rage-rush-release at least alliterates.
16:37 emersion: triple r!
16:37 emersion: should i make one?
16:37 emersion: daniels, jadahl, it's not super clear who can make a new w-p release
16:37 emersion: if you have time to do one, that'd be nice. if you want me to do it, i can
17:03 bl4ckb0ne: gz emersion
17:12 MrCooper: congrats and thanks for the cooperation on this one, everyone
17:13 Ermine: congrats!
17:26 JoshuaAshton: Got my mesa MR updated and rebased, but still need to address MrCooper's feedback
17:26 JoshuaAshton: will do today hopefully
17:54 jadahl: emersion: I have time tonight
17:56 emersion: cool!
17:57 jadahl: and congrats on landing!
19:00 daniels: emersion: fwiw I’ve always assumed that anyone who can merge to w-p can make a release
19:01 daniels: hooray for the merge indeed :) wondering if I want to actually read the MR when I’m back or just mark as read and move on
20:38 wlb: wayland-protocols Merge request !290 opened by Jonas Ådahl (jadahl) build: Bump version to 1.34 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/290
20:39 wlb: wayland-protocols/main: Jonas Ådahl * build: Bump version to 1.34 https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/c7e9c4f5d396 meson.build
20:39 wlb: wayland-protocols Merge request !290 merged \o/ (build: Bump version to 1.34 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/290)
20:41 wlb: wayland-protocols New tag: 1.34 https://gitlab.freedesktop.org/wayland/wayland-protocols/tags/1.34
20:41 vyivel: \o/
20:41 bl4ckb0ne: o/
21:03 wlb: wayland.freedesktop.org Merge request !76 opened by Jonas Ådahl (jadahl) Add wayland-protocols 1.33 and 1.34 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/76
21:05 wlb: wayland.freedesktop.org/main: Jonas Ådahl * Add wayland-protocols 1.33 and 1.34 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/ef6ff31e8715 releases.html
21:05 wlb: wayland.freedesktop.org Merge request !76 merged \o/ (Add wayland-protocols 1.33 and 1.34 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/76)
21:10 JoshuaAshton: btw https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25709