00:43wlb: weston Issue #778 closed \o/ (The mouse button release signal is not called after moving the surface https://gitlab.freedesktop.org/wayland/weston/-/issues/778)
06:06wlb: weston Issue #779 opened by Tomohito Esaki (etom) Build error when xwayland is disabled. https://gitlab.freedesktop.org/wayland/weston/-/issues/779
07:14ofourdan: jadahl: hey jonas, may I ask you to do a review of https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1133 considering this is mostly about using libdecor?
07:15ofourdan: (it's a small MR, I know you choked on Xwayland not applying the configuration before)
07:59jadahl: ofourdan: sure
08:13emersion: added notes for the last meeting: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meetings#2023-07-12
08:13emersion: feel free to edit as usual
08:18jadahl: the point about hiding from screenshots/screencat/screencopy: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/95
08:19jadahl: imo makes sense as a generic protocol
08:19jadahl: drakulix[m]: ^
08:22drakulix[m]: That is not exactly the same issue, I want to hide layer-shell surfaces from only certain types of captures and there is nothing sensitive about the contents.
08:23drakulix[m]: But imo that is a good idea for a protocol, I just won't use it for that specific issue.
08:24emersion: jadahl: basically Victoria's problem is that the workspace overview is a layer-shell surface, and uses screen capture to render itself, but doesn't want to capture itself
08:24jadahl: aah, ok, a bit special indeed
08:24emersion: drakulix[m]: tbh i think this use-case would be better implemented with a special kind of surface contents
08:25jadahl: drakulix[m]: yea, such a generic protocol doesn't make sense for your use case
08:25emersion: attach_capture_source(wl_surface, capture_source) in place of wl_surface.attach for instance
08:26emersion: not sure how this can look like exactly, but would avoid the compositor → client → compositor roundtrip
08:27emersion: ideas from years ago would be to expose a new kind of wl_buffer
08:27jadahl: a special kind of wl_buffer sounds scary
08:27emersion: yeah, how it's updated is unclear
08:27jadahl: think about all the layers that needs plumbing
08:27emersion: i dunno, would be trivial in wlroots
08:27jadahl: i mean client side
08:28drakulix[m]: So the idea would be that capturing apps could hide their UI by attaching in a special way?
08:28emersion: client side, it would be, wl_buffer=create_buffer_from_capture_source(capture_source), then wl_surface.attahc
08:28emersion: OTOH, this restricts to very basic UI
08:29emersion: no effects, displaying stuff on top of the mirrored area requires sub-surfaces etc
08:29drakulix[m]: I suppose that could be useful for screenshotting tools and afaik OBS can also hide its own window from captures on some platforms.
08:29drakulix[m]: But these clients probably want to hide a normal xdg-toplevel.
08:30emersion: drakulix[m]: the idea would be to not use screencopy in clients providing a workspace overview, or toplevel preview, or such
08:30emersion: but instead have the clients say "please mirror the screencopy source into this surface"
08:30any1: That's a neat idea
08:31emersion: a recent example of this concept, but on the web: https://www.stefanjudis.com/a-firefox-only-minimap/
08:31drakulix[m]: ah right. that would indeed eliminate the delay you get otherwise.
08:32emersion: there are upsides and downsides
08:33emersion: anyways, just food for thought :P
08:33drakulix[m]: But that would only hide the surfaces rendering the previews right? If you render UI around that previews, that would be captured like normal.
08:33any1: you still have to render the image source though before composting it elsewhere.
08:33emersion: yeah, sorry, i should've made that clear: it doesn't solve your issue, it's just an alternative to screencopy
08:34emersion: any1: yeah, i think in Victoria's case the compositor would always need to use a separate swapchain for screen capture anyways
08:34emersion: you can't filter out arbitrary surfaces if you just use the output's swapchain as usual
08:35drakulix[m]: Right, so if namespace disappears from layer-shell (which I don't mind) this fits best into a private protocol.
08:35emersion: yeah, "please ignore this surface" is best in a private protocol for now i think
08:36drakulix[m]: I think there is still value from marking surfaces as to-be-excluded from screenshotting in general though.
08:36emersion: right, but for your specific use-case of a client rendering an overview-like UI right?
08:37emersion: (this would be privileged, like layer-shell)
08:38jadahl: drakulix[m]: I imagine the implementation would differ for a generic protocol, e.g. showing a place holder instead of cropping/hiding
08:38emersion: (this wouldn't include "this window has sensitive data", which wouldn't be privileged and would leave the effective behavior up to the compositor's policy)
08:38drakulix[m]: jadahl: Right, thats why I can't really abuse a generic protocol for that use-case. I am just saying that should exist as well.
08:39emersion: yup, i agree this warrants two separate protocols
08:39jadahl: drakulix[m]: in a way you can: if (surface.is_sensitive()) if (surface.is_dock()) crop() else surface.show_place_holder() :P
08:39drakulix[m]: emersion: Right for my use-case the client needs to be integrated with the compositor anyway, so all of that is privileged anyway.
08:39emersion: jadahl: what if my layer-shell surface has sensitive data, but is not an overview?
08:40jadahl: emersion: end of the world
08:40jadahl: as whe know it
08:40emersion: i
08:40jadahl: s/whe/we/
08:40emersion: i'd prefer for the two cases to be explicitly split
08:40emersion: :P
08:41drakulix[m]: Yeah, me too.
08:41emersion: drakulix[m]: i think there's definitely a good use-case for a standard privileged protocol, but i wonder if you're the only interested party
08:42drakulix[m]: Which is why I will do what we discussed about vendored namespace, once we switch to ext-layer-shell and I need to build said protocol:
08:42drakulix[m]: Try to get it into ext and if nobody cares, put it public into a new cosmic namespace.
08:43emersion: alternatively, i could also ACK it since i think it's useful
08:43emersion: even if i don't plan to use it
08:43drakulix[m]: I don't mind either way.
08:43drakulix[m]: Though if sway would implement the protocol, I think 99% of our shell UI would also work with it. Which might be interesting to some users.
08:43emersion: i'd like to think about other use-cases which could overlap, i wonder
08:44emersion: toplevel preview will not hit this case
08:44emersion: maybe screencast UI?
08:44drakulix[m]: I guess OBS hiding itself doesn't want a placeholder to be shown.
08:44drakulix[m]: So if we also expose this functionality in the portal, that might be interesting for some clients?
08:44emersion: hm, and that's not really privileged anymore… depends how OBS shows its UI though
08:45drakulix[m]: I mean a compositor could deny the portal request. Or limit it to clients, that already have privileges to do screen-capture.
08:59zamundaaa[m]: drakulix: I'd even tie it to the specific screen cast for obs. It should maybe be hidden in its own screencast but not in screencasts from other apps
08:59emersion: right… like a VNC session
09:00drakulix[m]: Right that sounds reasonable. So basically a client could only ever hide itself from its own capture session.
09:00emersion: hm, but what about "caster tools"?
09:01emersion: like a timer or chat overlay for casters, which is completely separate from the capture client
09:01emersion: maybe at some point it ought to be compositor configuration
09:02drakulix[m]: Sounds like they would need a layer-shell surface anyway, so maybe privileged is good enough here?
09:03drakulix[m]: This could still be a portal request though. I think the big difference here is, capture clients hiding themselves should not need user confirmation, while other surfaces might need it?
09:07kchibisov: if it matters, the 'exclude from screencast' is sort of common in other windowing systems.
09:07kchibisov: it's usually called 'content protection'.
09:07jadahl: kchibisov: the difference is *hiding* and showing a place holder obscuring the content
09:09kchibisov: I know some clients show splash screen.
09:10kchibisov: So the window is present, but it shows something else.
09:12jadahl: you mean the client provides its own place holder?
09:15jadahl: yea, your use case got derailed into another topic :P
09:15jadahl: erm, that was a reply to something in my scroll back, sorry
09:16drakulix[m]: Hmm for visual consistency I feel like the compositor should render the placeholder, but maybe that's just me?
09:17jadahl: drakulix[m]: that had been my assumption too
09:19kchibisov: jadahl: I think on mobile some hook to a screenshot service/etc to render something arbitrary when they are notified that 'it's about to take screenshot'.
09:19kchibisov: On macOS they have a flag saying how you can access a particular surface content, None, RO, RW.
09:20jadahl: RW surface content? O_o
09:20kchibisov: it's weird.
09:20kchibisov: I don't think it really works on macOS.
09:20kchibisov: They have this exposed, but...
09:21kchibisov: On Windows they have https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowdisplayaffinity
09:23kchibisov: Though, it's true that it's not really a security feature.
09:24jadahl: it says it's about content protection
09:24dottedmag: emersion: I was already thinking along the lines of a configuration dialogue "these applications (list) have sensitive surfaces. for each application select which screencast clients can actually see them"
09:24kchibisov: I mean, you can still take a photo.
09:26jadahl: kchibisov: I imagine most if not all compositors would allow the user to ignore the hint of the client to take a proper screenshot anyway
09:26kchibisov: Well, the ms docs mention that the real use for this is overlays you might want to ignore.
09:26kchibisov: Because they serve no value in the screenshot.
09:27kchibisov: Though, given that Wayland established that overlay is done via separate set of protocols, it's not like you can disable layer-shell from being captured.
09:27jadahl: kchibisov: what I read was "This function and GetWindowDisplayAffinity are designed to support the window content protection feature that is new to Windows 7."
09:28kchibisov: Ah, it works by not showing a window on a screenshot or capture.
09:28jadahl: yea
09:28jadahl: what is practically what is asked for in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/95 too
09:28kchibisov: The same wrt macOS api, but macOS api is way more weird.
09:30kchibisov: Such protocol is a bit tricky, because it must operate on role object.
09:30kchibisov: Well, for xdg-shell on toplevel.
09:30kchibisov: because subsurface is also a role...
10:08pq: emersion, swick[m], FYI, after Wednesday I'll be off for three weeks.
10:09emersion: ack
10:10wlb: weston Merge request !1322 opened by Marius Vlad (mvlad) backend-drm: Don't assume DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP is available https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1322 [Backport to weston 12], [DRM/KMS backend]
10:45wlb: weston Merge request !1323 opened by Daniel Stone (daniels) frontend: Fix build error when Xwayland disabled https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1323 [XWayland]
11:55wlb: weston Issue #779 closed \o/ (Build error when xwayland is disabled. https://gitlab.freedesktop.org/wayland/weston/-/issues/779)
11:55wlb: weston Merge request !1323 merged \o/ (frontend: Fix build error when Xwayland disabled https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1323)
11:55wlb: weston/main: Daniel Stone * frontend: Fix build error when Xwayland disabled https://gitlab.freedesktop.org/wayland/weston/commit/4a26a2868284 compositor/main.c
12:11wlb: weston/main: Marius Vlad * backend-drm: Make DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP inert https://gitlab.freedesktop.org/wayland/weston/commit/3e4aff6af4dc libweston/backend-drm/kms.c
12:11wlb: weston Merge request !1322 merged \o/ (backend-drm: Don't assume DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP is available https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1322)
12:52wlb: wayland-protocols Merge request !238 opened by Xaver Hugl (Zamundaaa) staging: add window id protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/238
13:09wlb: wayland-protocols Issue #153 opened by Colin Kinloch (ColinKinloch) Primary or audience display https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/153
18:17havona: hello i'm new to wayland and i'm using weston and if i chvt to tty and back to weston my once focused terminal in weston loses focus and i have to super+tab to focus it again every time
18:17havona: i'm just curious if that's a wayland thing or a weston thing or what's up
18:21jadahl: a weston thing
18:21havona: is that by design or a bug?
18:25jadahl: my guess is it's an oversight
18:37havona: okay thank you
19:06havona: sway seems to have some issues restoring focus on chvt
19:06havona: it works most of the time but sometimes not
19:06havona: i'm just saying
19:14havona: so in sway if i `doas chvt 3` to the sway vt my terminal is unfocused until i hit a key but that key is not sent to the terminal
19:14havona: so in sway if i `doas chvt 3` to the sway vt my terminal is unfocused until i hit a key but that key is not sent to the terminal
19:14havona: oops
19:14havona: BASICALLY seems like restoring focus on chvt in wayland is gonna be different with every compositor unlike with x11 where it wasn't ever an issue
19:16dottedmag: not surprising
19:16vyivel: havona: iirc changing vts removes and re-adds keyboard devices which can affect focus logic
19:17havona: i just hafta get used to it i'm a new wayland person
19:17havona: and i switch vts a LOT
19:18havona: sway seems nice once i managed to hide the titlebars just saying
21:30wlb: wayland Issue #397 opened by NekoKitty (nekokittymiku) Wayland extremely laggy on a GTX760 + KDE https://gitlab.freedesktop.org/wayland/wayland/-/issues/397
21:32wlb: wayland Issue #397 closed \o/ (Wayland extremely laggy on a GTX760 + KDE https://gitlab.freedesktop.org/wayland/wayland/-/issues/397)
22:30cambrian_invader: I'm trying to debug weston failing to start, but I don't see any logs from my systemd service
22:31cambrian_invader: I'm launching weston like `/usr/bin/weston --continue-without-input --modules=systemd-notify.so`
22:31cambrian_invader: however, it exits with a failure code and no output at all
22:31cambrian_invader: when I launch weston manually, I see output as usual
22:36daniels: cambrian_invader: did you set Type=notify in the service?
22:37cambrian_invader: yes
22:37cambrian_invader: https://paste.debian.net/1286279/
22:57cambrian_invader: ok, so I added --wait-for-debugger, but even though I can attach, I can't see the "waiting for debugger" message in the journal
23:16cambrian_invader: well, I fixed my actual problem by setting use-pixman=true
23:16cambrian_invader: still no logs...
23:24anarsoul|2: cambrian_invader: you'll get software rendering with use-pixmap=true
23:24cambrian_invader: ah
23:25anarsoul|2: *pixman
23:25cambrian_invader: well, I'm having trouble debugging the drm backend
23:26cambrian_invader: I tried running it under apitrace, but it didn't have the same behavior
23:44daniels: which driver are you using?