04:02 wlb: weston Issue #871 opened by Thomas (CoderThomasB) Video playback using GStreamer very slow compared to X.Org on old computer https://gitlab.freedesktop.org/wayland/weston/-/issues/871
08:00 poke: Hi is this good to place to ask questions about implementing xdg-desktop-portal?
08:05 davidre: #xdg-desktop-portals:matrix.org is the portal channel
08:07 poke: thank you sorry for bother you guys
08:30 pq: emersion, wouldn't libwayland-client do the wrong thing for inheriting an object interface version from a third object?
08:30 emersion: pq, the version for new resources is passed explicitly
08:30 emersion: wl_resource_create() takes a version argument
08:33 pq: kchibisov, any configuration change must be met with ack_configure to allow the compositor to act the new state, and ack_configure requires a commit on the xdg-toplevel, IIRC.
08:33 kchibisov: And some compositors don't like commits without buffer attach, but you can't attach buffer for suspended if you use vsync.
08:34 kchibisov: it's just...
08:34 kchibisov: life is hard, I guess.
08:35 pq: From Wayland perspective, you can always draw at any time, or not draw. Client-side library designs like EGL are another matter.
08:35 kchibisov: yeah.
08:36 kchibisov: it's just ecosystem is kind of like that.
08:36 pq: indeed, ack without commit is not really an ack.
08:36 kchibisov: I mean, doing commit with buffer for suspend is also weird.
08:41 pq: emersion, yes, the server side is ok, but the client side?
08:41 emersion: hm
08:42 MrCooper: compositors which "don't like commits without buffer attach" are just broken, aren't they?
08:42 pq: I have a feeling it would get ugly.
08:42 wlb: weston Merge request !1450 opened by Wismill (wismill) Draft: simple-im: Fix modifiers https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1450
08:43 wlb: wayland Issue #437 opened by Simon Ser (emersion) Be more explicit about valid enum values https://gitlab.freedesktop.org/wayland/wayland/-/issues/437
08:43 pq: emersion, the only way I know that works right now for manually defining the version is to use a new_id without interface attribute in XML, and spec in the doc what the free parameters must be.
08:45 pq: MrCooper, correct. kchibisov ^
08:46 pq: in general at least, maybe kchibisov can give more details how exactly they don't like it?
08:46 MrCooper: or maybe the issue is that the ack requires new surface dimensions, which requires a new buffer
08:47 emersion: the problem is about toolkit API design, i believe
08:47 pq: just setting the xdg geometry should suffice, right?
08:47 kchibisov: Hm, I wonder what should be done when you resize and get suspended at the same time.
08:47 wlb: weston Issue #872 opened by Wismill (wismill) Memory leaks in weston-simple-im https://gitlab.freedesktop.org/wayland/weston/-/issues/872
08:48 pq: xdg configure drives xdg geometry, not wl_surface size, does it not?
08:48 pq: though having the two mismatch is not be best thing
08:48 kchibisov: yeah, you'll have a missmatch.
08:48 pq: but if you just cannot draw, then what else
08:49 kchibisov: my main issue is toolkit design, since commit is a wayland special concept.
08:49 kchibisov: And I can't really do commit on behalf of the users.
08:49 MrCooper: is there an issue with just doing the ack and waiting for whenever the next commit happens?
08:49 kchibisov: because it could break their multithreaded rendering, so I need to sync.
08:50 kchibisov: I mean, if you commit with EGL + use vsync you'll block indefinitely.
08:50 kchibisov: so suspended is kind of useless.
08:50 pq: can't you require toolkit used to do a "tookit commit" which on non-Wayland would be kind of unnecessary?
08:50 pq: *toolkit users
08:50 kchibisov: users won't ever call this method.
08:50 pq: maybe they should?
08:50 kchibisov: I know how to solve it in the future.
08:50 kchibisov: just not now.
08:52 pq: what about MrCooper's suggestion to ack now and let the net draw cammit it, whenever it might come? Since you have to sync resizes etc. anyway.
08:52 pq: *next
08:52 kchibisov: that's what I do though?
08:53 kchibisov: I ack myself and commit is done when user draws.
08:53 pq: what's the problem them?
08:53 kchibisov: drawing is not in my jurisdiction.
08:53 pq: so?
08:53 pq: what are you worried about?
08:53 kchibisov: And I don't want vsync users to block.
08:54 kchibisov: since they'll block in that case since frame callback won't ever arrive.
08:54 MrCooper: there's no need to commit ASAP, is there?
08:54 kchibisov: And if users use frame callbacks, the event is useless for them.
08:54 kchibisov: you need to commit the state though.
08:54 kchibisov: you can't just ack it, since the state won't apply.
08:54 pq: are you thinking you must get the commit out immediately?
08:54 kchibisov: I think that I won't be suspended until I commit.
08:55 pq: why do you need to get the ack acted on immediately?
08:55 pq: why would suspending be related to acking?
08:55 emersion: i thought that we talked at some point about disconnecting clients that don't ack in timely manner, because they can be seen as unresponsive
08:56 kchibisov: If I don't ack how it'll help me?
08:56 pq: emersion, sounds like that would need to be conditional to suspending the surface.
08:56 MrCooper: suspending a surface and then disconnecting the client for not doing anything would seem kind of mean
08:56 pq: kchibisov, what is the problem you have? What needs helping?
08:57 kchibisov: I mean, I know how to solve my problem.
08:57 kchibisov: I initially asked whether commit is really mandatory.
08:57 kchibisov: if it's mandatory I'll just approach it differently.
08:57 pq: commit is mandatory to have ack acted on. Having ack actent on immediately is not necessary.
08:57 kchibisov: mandatory in a way that compositor will think that my toplevel is not suspended until I ack+commit.
08:58 pq: what does suspending have to do with this?
08:58 emersion: the suspended state is not like the rest of the states
08:58 kchibisov: I mean, it's just an example.
08:58 kchibisov: but yeah, it's also different.
08:58 pq: is suspend using the same ack_configure as xdg-toplevel states?
08:58 kchibisov: I initially discovered that smithay doesn't think that my toplevel is active, until I ack + commit.
08:59 kchibisov: Once we were implementing wlr-foreign-toplevel-management.
08:59 kchibisov: The suspended is a bit special, because it means that you must commit without a buffer.
08:59 kchibisov: since you don't know what users of the toolkits are using, like they could draw with EGL + vsync and it's not desired to block them.
09:00 kchibisov: even though they can use frame callbacks...
09:00 kchibisov: Like in the future, I'll just ask the user to pause rendering and force a reply from them to tell whether they did that or not.
09:00 kchibisov: Once they pause, I commit on behalf of them, since they told me that they did so.
09:00 pq: where is the spec for the suspend we are talking about here?
09:01 kchibisov: xdg_shell v6 suspended state?
09:01 pq: v6???
09:01 kchibisov: https://wayland.app/protocols/xdg-shell#xdg_toplevel:enum:state:entry:suspended
09:01 kchibisov: v6
09:02 pq: phew, not xdg-shell-unstable-v6.xml, I'm relieved
09:02 kennylevinsen: Need one more version bump to disambiguate
09:03 pq: ok, and if a client required to ack suspension before it actually applies?
09:03 pq: *is
09:04 kchibisov: From my understanding to state to apply it must ack + commit.
09:04 pq: I see no wording saying it does not need an ack?
09:04 kchibisov: I mean, the problem is that it needs ack+commit.
09:04 pq: IOW, you are free to draw as many times as you want, your surface will not be suspended until you actually ack it with a commit.
09:04 kchibisov: I'm fine with ack, I'm not fine with commit.
09:05 kchibisov: My issue is basically what happens when I _ack+commit_, but I also wait for frame callback, like mesa's vsync does?
09:05 kchibisov: in my understanding I'll just block.
09:06 pq: IOW, Mesa "vsync" will not block your draws until you actually ack+committed. If it blocks, that's a compositor bug.
09:06 kchibisov: because the surface is _suspended_ now, thus I won't get frame callback soon.
09:06 pq: no, the surface is not suspended "no"
09:06 kchibisov: So if I draw with vsync to apply suspended state and I block it's a bug in compositor?
09:06 pq: the spec needs you to ack the suspension before it becomes suspended, because I don't see wording saying otherwise.
09:07 pq: yes
09:07 kchibisov: And so if I asked for frame callback when applying the suspended state I'll actually get it?
09:07 kchibisov: because emersion said otherwise iirc.
09:07 kennylevinsen: pq: I don't think that really aligns with the intended use though - "you're not going to get repainted anymore, deal with it"
09:07 pq: Mesa EGL blocks for *previous* frame submission, so you can freely do the draw for the commit that acks the suspended state.
09:08 kennylevinsen: I don't think compositors would keep sending frame events to an occluded/minimized/whatever surface on the basis of it not having ack'ed "suspended"
09:08 kchibisov: I mean, I'll draw, but it'll wait for a frame to arrive to unblock?
09:08 kchibisov: but with toplevel being suspended, I kind of assume that it won't arrive.
09:08 pq: kennylevinsen, then people failed to write it in the spec. They need to live with what they wrote, or try to fix the wording.
09:08 kchibisov: won't arrive soon.
09:09 pq: kennylevinsen, the spec implies they need to.
09:09 kennylevinsen: kchibisov, pq: mesa blocks on previous frame callbacks, so a new buffer swap blocks if the *last* one has not received its frame callback
09:10 kchibisov: Ah, and previous one I'll get.
09:10 kennylevinsen: pq: I see your point, but if neither authors nor implementers interpreted it that way then it won't work. Spec needs to be fixed then though, yes.
09:10 kchibisov: So if I try to draw after suspended it'll be broken.
09:10 pq: yes, because the spec of suspended state does not say that the suspended state would apply without an ack.
09:10 pq: kennylevinsen, indeed.
09:11 pq: and if the spec is fixed, kchibisov is back with the problem
09:11 kennylevinsen: frame callbacks are already not guaranteed, so I don't see how it would be valid to assume that they would be guaranteed until suspended is acked...
09:11 kchibisov: pq: if mesa blocks previous frame callback I don't have problem.
09:12 pq: if frame callbacks were not needed to be guaranteed, there would be no reason for the suspended state
09:12 kchibisov: I'll just delay the occluded state sending.
09:12 pq: kchibisov, right, unless you lose a race.
09:13 MrCooper: pq: the suspended state lets the client know no frame events will be arriving
09:13 kchibisov: The race is that suspended is send before the previous frame's frame callback?
09:13 pq: MrCooper, yes, but the spec for surface state requires states to be acked before they apply.
09:14 MrCooper: no frame events will be arriving anyway, even without ack
09:14 kennylevinsen: to be pedantic about the current wording, the only documented behavior is that on wl_surface::frame saying that it is not guaranteed. Nothing in the suspended spec mentions frame events - just that no repaint will occur
09:15 kchibisov: yeah, but wasn't the intention to solve the blocking vsync thing in cross platform toolkits?
09:15 kennylevinsen: so suspended just says that it will be repainted less than before (implying fewer callbacks), not that frame callbacks were going to arrive at any rate before...
09:15 pq: kchibisov, the race is that you are submitting a frame while the compositor is sending the suspended event. The compositor sees your frame+commit after it sent the suspended event. When you see the suspended event, the compositor is already holding the frame callback your draw+ack commit would wait on.
09:15 kchibisov: Like you don't really need this state, unless you want to minimize resource consumption.
09:16 kennylevinsen: I recall the discussion having use-cases in all directions, but resource consumption was one of them
09:16 kchibisov: pq: but I won't have ack?
09:16 pq: have?
09:16 kchibisov: I mean, I must ack for it to start counting?
09:17 pq: that's what we're debating here
09:17 pq: spec wording says yes, implementations say no, I guess
09:17 kchibisov: Like my issue is that I need commit in the first place. I'm fine with ack.
09:18 kchibisov: So I have issue only when I need commit, if I need only ack, or no ack or commit, I'm fine.
09:18 kchibisov: If you remove ack, yes, it's a race then.
09:18 emersion: only ack without commit is same as doing nothing
09:18 pq: you cannot have a separate ack request that does not need a commit for a state in xdg_toplevel.
09:19 pq: it's just not how xdg_toplevel works, though technically one could be adde
09:19 kchibisov: it's just suspended state is weird in a way that it's just a global state.
09:19 kennylevinsen: just ack + commit on suspended should be fine as long as the client hasn't staged other changes in the meantime that you would accidentally apply
09:19 kennylevinsen: yeah it's a little weird as a state
09:19 kchibisov: in a sense that no matter what you do, you already know that you likely won't get frame callbacks after seeing it.
09:20 emersion: it's there because it was easy, but multiple people objected
09:20 kchibisov: there was a separate protocol for surface itself.
09:20 kchibisov: iirc.
09:20 pq: kennylevinsen, I understood that's exactly the problem, kchibisov cannot guarantee that there would not be pending arbitrary state in flight when he would commit the ack.
09:20 kchibisov: I'll be able in future though.
09:21 kchibisov: just not _now_
09:21 pq: Do you need to solve the problem of now? What's today's failure mode?
09:21 kchibisov: I just removed the handling already.
09:22 kchibisov: Users have frame callbacks infra in-place and can use that instead.
09:22 kennylevinsen: Hmm, I wonder if the suspended wording should be made stronger to imply that it *must* be set on occlusion
09:22 kchibisov: I just wanted to improve the cross platform situation.
09:23 kchibisov: Since suspended is a common concept.
09:23 kennylevinsen: Maybe daniels has some thoughts, being the unfortunate soul with the Author: status. :P
09:24 kchibisov: in the future I'll just sychroniously ask the user with the callback to tell me that they've paused their rendering.
09:24 pq: We've seen how toolkit API designed for other window systems have problems adapting to Wayland, but is the opposite also true?
09:24 kchibisov: So I can _safely_ commit without buffer.
09:24 kchibisov: Wayland usually has things not present anywhere else.
09:25 kchibisov: And concepts like _apply scale yourself or you crash_.
09:25 kchibisov: if you control rendering/windowing/etc it's probably just fine.
09:26 pq: right, but if the toolkit API already required all that, would the toolkit have problems working on other window systems?
09:26 kchibisov: I'd just say that you don't have that _fear of crash_ with other stuff.
09:27 emersion: kennylevinsen: i don't think that's a good idea
09:27 kchibisov: only wayland can crash you if you don't behave.
09:27 emersion: it would force compositors to have some special logic they can't avoid
09:27 emersion: there are some grey areas where the surface is kind-of visible but not really
09:28 kennylevinsen: emersion: well if they have logic for occlusion to stop callbacks, it would just be an extension of that
09:28 kennylevinsen: if it doesn't affect callbacks, it doesn't matter
09:28 pq: kennylevinsen, I think you forgot to write in the spec adendum: "if the compositor stops frame callbacks on occlusion, then ..." ;-)
09:29 pq: or something like that
09:29 emersion: kennylevinsen: my condition for accepting suspended is that it would be purely optional for the compositor iirc
09:29 kennylevinsen: "This state may sometimes be set" - problem solved
09:29 pq: but simply saying "must be sent when occluded" is a straight demand that compositors need to know when something is occluded
09:30 kennylevinsen: indeed, makes sense
09:31 emersion: and of course can't find back that discussion…
09:31 emersion: oh well
09:32 emersion: a previous iteration was written with the "mechanism" approach
09:32 kchibisov: suspended on toplevel is kind of weird due to subsurfaces, etc.
09:32 emersion: where the state was named "invisible"
09:33 kchibisov: Like if you have toplevel covered by opaque subsurfaces, and that subsurface is the only thing visible I'm not sure how it'll work.
09:33 emersion: the state applies to the whole toplevel surface tree, kchibisov
09:34 kchibisov: yeah, but it's not suspended in that case?
09:34 kchibisov: But I might not ever recieve frame callback if I try to draw occluded surface.
09:34 emersion: indeed
09:34 emersion: that's a good point
09:35 kchibisov: it all sounds like I should just do something else instead of computers.
09:36 pq: If the intent is to avoid indefinite blocking with Mesa's EGL implementation of *today*, then it has to be a strict mechanism tied to frame callbacks without any leeway on policy.
09:36 kchibisov: I'd rather see mesa stop doing the frame callback thing.
09:36 pq: me too, and I think things are progressing in that direction
09:36 kennylevinsen:mumbles in anti-WSI
09:37 pq: one WSI implementation with known behaviour, or numerous WSI-likes that are different in each app with their own expectations, and some never going to be updated? :-p
09:38 kchibisov: sounds like wayland compositors, sign me up.
09:39 kennylevinsen: tbf, no WSI *in your userspace GPU driver* does not mean you can't have a convenience library :P
09:39 kchibisov: convinience library called mesa, I see.
09:40 YaLTeR[m]:looks at how everyone stopped killing clients for not honoring maximized size
09:40 kchibisov: tbf, if I would be able to not use mesa wsi, I'll be free from _libwayland or die_ situation.
09:40 emersion: they never did in the first place i think, YaLTeR[m]
09:40 kennylevinsen: kchibisov: do you have a blocker for not using the WSI?
09:41 kennylevinsen: (other than inconvenience of some more code)
09:41 YaLTeR[m]: emersion: I've heard rumors that sway used to
09:41 kchibisov: kennylevinsen: EGLSurface?
09:41 emersion: i don't think we ever did
09:42 pq: Compositor developers have some responsibility for not regressing applications, but applications cannot regress compositors. It's not a symmetric relationship.
09:42 kchibisov: Like I can't implement mesa's wsi out of tree iirc.
09:42 kchibisov: unless the vtable hooks in dri wayland can be used out of tree?
09:42 emersion: kchibisov: you can, with GBM and FBOs and responsibility for wiring up everything
09:43 emersion: like, wlroots does
09:43 kchibisov: but it's different to direct screen rendering and you lose some extensions.
09:43 kchibisov: And some of them you can't implement yourself.
09:43 emersion: you loose one extension that nobody seems to see value for
09:43 kchibisov: since it's a driver specific ioctls.
09:43 kennylevinsen: which extension?
09:43 kchibisov: partial_update.
09:44 kchibisov: I'm pretty sure it's the one that lost.
09:44 kchibisov: Like buffer age doesn't really matter.
09:44 emersion: the way to fix that is just to add a new, better ext
09:44 emersion: however, that's blocked on someone finding a real upside to the ext
09:44 emersion: it's not buffer age
09:45 kchibisov: How wsi will work with nvidia stuff though?
09:45 kchibisov: since their EGL lib is a bit special.
09:45 emersion: https://github.com/KhronosGroup/OpenGL-Registry/issues/547
09:47 kchibisov: wlroots also has its own wsi with vulkan, right?
09:48 emersion: wlroots' wsi is not tied to GL nor Vulkan
09:48 emersion: it's just DMA-BUFs and shm buffers
09:55 YaLTeR[m]: so if suspended covers the whole top-level, then you can move the window partially off-screen in such a way that only its CSD shadow subsurface is visible, then the window will not be suspended and yet the main surface won't receive frame callbacks
09:56 emersion: indeed
09:56 emersion: same for popup etc
09:57 kchibisov: The only benefit I see from the current suspended is that you can unload a bunch of resources.
09:57 kchibisov: And if you're a simple game it'll likely do just fine.
09:57 emersion: that might not even be appropriate, since the compositor might not debounce it
09:58 emersion: so if the user switches back and forth very quickly between workspoaces you see your disk usage go to 100%
09:58 pq: Would be awesome if someone could collect those shortcomings into a gitlab issue. No need to suggest solutions, just record the problems.
09:58 kchibisov: emersion: transfering from GPU to cpu memory and back :P
09:59 emersion: i was thinking reloading assets from disk
09:59 kchibisov: I was thinking about unloading textures, or something like that to free up a bit.
09:59 kchibisov: since you generally have pretty low amount of GPU memory.
09:59 emersion: do games keep textures in RAM, in addition to GPU VRAM?
10:00 emersion: well, in any case
10:00 kchibisov: Can you even load from disk to GPU?
10:00 emersion: well, sure, disk to RAM then to GPU
10:00 kchibisov: Yeah, so can probably download back from GPU.
10:01 YaLTeR[m]: there was some recent advertisement that PS5 can do it and then a windows API appeared for "direct from disk to GPU"
10:01 YaLTeR[m]: recent = 2 years
10:02 emersion: it is possible yeah, there were XDC presentations about SSD to GPU from AMD
10:13 YaLTeR[m]: Maybe we should take inspiration from JavaScript. `willFrameCallbacksArrive() -> "no" | "maybe" | "probably"`
10:14 davidre: "askagainlater"
10:14 kennylevinsen: it returns a confidence interval as a double
10:14 kchibisov: "whatisframecallbackanyway"
10:15 kchibisov: I mean compositor is the one sending them, so it's either yes or no.
10:16 kchibisov: just suspended state is _weird_.
10:17 wlb: wayland-protocols Merge request !277 opened by Simon Ser (emersion) xdg-shell: relax maximized size constraints https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/277 [xdg-shell]
10:50 wlb: wayland-protocols Issue #174 opened by Simon Ser (emersion) xdg-shell: specify relationship between maximum size and maximized configured size https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/174 [xdg-shell]
11:06 MrCooper: emersion: can you resolve https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90#note_2219580 & https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90#note_2243522 ?
11:11 zamundaaa[m]: <pq> "IOW, Mesa "vsync" will not block..." <- The suspended state was intentionally made to *not* be about frame callbacks in any way or form
11:11 pq: zamundaaa[m], ok, so it was never intended to solve the "eglSwapBuffers might block indefinitely". My bad.
11:12 zamundaaa[m]: Yeah
11:12 kchibisov: zamundaaa[m]: what should it be used for then?
11:12 kchibisov: Since the _pause rendering_ already solved via frame callback loop.
11:12 zamundaaa[m]: It's just a better hint for toolkit "window is occluded" APIs
11:13 zamundaaa[m]: As in, rendering is not just slowed down for the moment, but won't happen for a while. So you may even deallocate buffers and that stuff
11:14 kchibisov: but which buffers, since subsurface/shadow could still be visible?
11:14 kchibisov: I'd assume not related to presented content.
11:15 pq: xdg_toplevel is about the whole window and not just the one wl_surface it was created for. So.
11:15 zamundaaa[m]: The buffers that aren't currently held by the compositor
11:15 zamundaaa[m]: It's also about not doing calculations for animations, video decoding, that sort of stuff
11:16 kchibisov: yeah, but video decoding could be on its own subsurface which may be visible.
11:16 kchibisov: Or bleed a bit.
11:16 pq: it's still the same window
11:16 zamundaaa[m]: kchibisov That would be a compositor bug
11:17 kchibisov: so window is suspended if and only if all its tree is not visible.
11:17 kchibisov: So popups, etc.
11:17 zamundaaa[m]: I do agree it would've been better to just do it on wl_surface with guarantees about frame callbacks, but I don't really want to rehash that old discussion
11:18 kchibisov: Like if everything belonging to toplevel must be occluded for it to be suspended that sounds like fun to implement.
11:23 d_ed[m]: Occluded is not the best term, the spec calls it "suspended". We use it for "on another virtual dekstop" or "another client is fullscreen"
11:24 d_ed[m]: You can be occluded but not suspended
11:24 d_ed[m]: but never visible and not suspended
11:25 kchibisov: I mean, occluded means _not visible_, mostly.
11:25 kchibisov: Though, the correct term is suspended, yes.
11:51 kennylevinsen: d_ed[m]: I imagine you meant "never visible and suspended" :)
11:55 d_ed[m]: yes, that
12:16 daniels: kennylevinsen: yeah, my thought is that you should ignore suspended and commit new state when the compositor pushes you a configure event; it's the only thing that makes sense really
12:16 daniels: I mean, if you ignore the configure event and don't push anything, when you alt-tab back to your window, you'll see the old content, then as it gets unsuspended and commits, it will change state again to a different size or something, which seems very not ideal
12:17 daniels: if you ack the configure and don't commit new state, then you'll get taken out by the xdg-toplevel state mismatch
12:17 daniels: so yeah, I would stick to 'don't draw of your own accord, but if the compositor pushes you new state then update to match that'
12:25 wlb: wayland-protocols/main: David Redondo * Add xdg-toplevel-drag protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/c4f897d66029 staging/xdg-toplevel-drag/README staging/xdg-toplevel-drag/xdg-toplevel-drag-v1.xml meson.build
12:25 wlb: wayland-protocols Merge request !204 merged \o/ (Add xdg-toplevel-drag protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/204)
12:52 wlb: weston/main: Pekka Paalanen * backend-drm: store EDID data https://gitlab.freedesktop.org/wayland/weston/commit/2c0a9c064a28 libweston/backend-drm/ drm-internal.h drm.c modes.c
12:52 wlb: weston/main: Pekka Paalanen * backend-drm: skip EDID parsing if no change https://gitlab.freedesktop.org/wayland/weston/commit/fc0a74a4c973 libweston/backend-drm/modes.c
12:52 wlb: weston/main: Pekka Paalanen * backend-drm: rename eotf_list to str https://gitlab.freedesktop.org/wayland/weston/commit/f88073200414 libweston/backend-drm/drm.c
12:52 wlb: weston Merge request !1423 merged \o/ (backend-drm: store EDID data https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1423)
13:35 emersion: MrCooper: done
14:05 MrCooper: thanks
17:34 emersion: vyivel: did you forget to push !366?
17:36 vyivel: emersion: https://gitlab.freedesktop.org/vyivel/wayland/-/commit/9df5d063336db53d3fa333dbc29405a009a1b4c6
17:36 vyivel: not sure why the mr isn't updated
17:37 emersion: that's weird
17:40 daniels: it's happening slowly
17:41 daniels: that gets enqueued as a background job, and we had several thousand of those backed up from when the mail server's network was down
18:17 wlb: weston/main: Pierre Le Marre * simple-im: Fix modifiers https://gitlab.freedesktop.org/wayland/weston/commit/8aa14f0d39a3 clients/simple-im.c
18:17 wlb: weston Merge request !1450 merged \o/ (simple-im: Fix modifiers https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1450)
18:37 idl0r: hm, neither with nvidia nor nouveau wayland doesn't show my third monitor which is connected via HDMI to my AV receiver and from there to my monitor. any ideas how to get it working?
18:48 kennylevinsen: idl0r: Wayland is a protocol - a bunch of xml files - so it's not the right place ot ask. Your Wayland server is usually provided by your desktop environment, and so how to use, configure and debug goes to them.