ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<drakulix[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.
<drakulix[m]>
But imo that is a good idea for a protocol, I just won't use it for that specific issue.
<emersion>
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
<jadahl>
aah, ok, a bit special indeed
<emersion>
drakulix[m]: tbh i think this use-case would be better implemented with a special kind of surface contents
<jadahl>
drakulix[m]: yea, such a generic protocol doesn't make sense for your use case
<emersion>
attach_capture_source(wl_surface, capture_source) in place of wl_surface.attach for instance
<emersion>
not sure how this can look like exactly, but would avoid the compositor → client → compositor roundtrip
<emersion>
ideas from years ago would be to expose a new kind of wl_buffer
<jadahl>
a special kind of wl_buffer sounds scary
<emersion>
yeah, how it's updated is unclear
<jadahl>
think about all the layers that needs plumbing
<emersion>
i dunno, would be trivial in wlroots
<jadahl>
i mean client side
<drakulix[m]>
So the idea would be that capturing apps could hide their UI by attaching in a special way?
<emersion>
client side, it would be, wl_buffer=create_buffer_from_capture_source(capture_source), then wl_surface.attahc
<emersion>
OTOH, this restricts to very basic UI
<emersion>
no effects, displaying stuff on top of the mirrored area requires sub-surfaces etc
<drakulix[m]>
I suppose that could be useful for screenshotting tools and afaik OBS can also hide its own window from captures on some platforms.
<drakulix[m]>
But these clients probably want to hide a normal xdg-toplevel.
<emersion>
drakulix[m]: the idea would be to not use screencopy in clients providing a workspace overview, or toplevel preview, or such
<emersion>
but instead have the clients say "please mirror the screencopy source into this surface"
<drakulix[m]>
ah right. that would indeed eliminate the delay you get otherwise.
carlos_ has joined #wayland
<emersion>
there are upsides and downsides
<emersion>
anyways, just food for thought :P
<drakulix[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.
<any1>
you still have to render the image source though before composting it elsewhere.
<emersion>
yeah, sorry, i should've made that clear: it doesn't solve your issue, it's just an alternative to screencopy
<emersion>
any1: yeah, i think in Victoria's case the compositor would always need to use a separate swapchain for screen capture anyways
<emersion>
you can't filter out arbitrary surfaces if you just use the output's swapchain as usual
<drakulix[m]>
Right, so if namespace disappears from layer-shell (which I don't mind) this fits best into a private protocol.
<emersion>
yeah, "please ignore this surface" is best in a private protocol for now i think
<drakulix[m]>
I think there is still value from marking surfaces as to-be-excluded from screenshotting in general though.
<emersion>
right, but for your specific use-case of a client rendering an overview-like UI right?
<emersion>
(this would be privileged, like layer-shell)
<jadahl>
drakulix[m]: I imagine the implementation would differ for a generic protocol, e.g. showing a place holder instead of cropping/hiding
<emersion>
(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)
<drakulix[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.
<emersion>
yup, i agree this warrants two separate protocols
<jadahl>
drakulix[m]: in a way you can: if (surface.is_sensitive()) if (surface.is_dock()) crop() else surface.show_place_holder() :P
<drakulix[m]>
emersion: Right for my use-case the client needs to be integrated with the compositor anyway, so all of that is privileged anyway.
<emersion>
jadahl: what if my layer-shell surface has sensitive data, but is not an overview?
<jadahl>
emersion: end of the world
<jadahl>
as whe know it
<emersion>
i
<jadahl>
s/whe/we/
<emersion>
i'd prefer for the two cases to be explicitly split
<emersion>
:P
<drakulix[m]>
Yeah, me too.
<emersion>
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
<drakulix[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:
<drakulix[m]>
Try to get it into ext and if nobody cares, put it public into a new cosmic namespace.
<emersion>
alternatively, i could also ACK it since i think it's useful
<emersion>
even if i don't plan to use it
<drakulix[m]>
I don't mind either way.
<drakulix[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.
<emersion>
i'd like to think about other use-cases which could overlap, i wonder
<emersion>
toplevel preview will not hit this case
<emersion>
maybe screencast UI?
<drakulix[m]>
I guess OBS hiding itself doesn't want a placeholder to be shown.
<drakulix[m]>
So if we also expose this functionality in the portal, that might be interesting for some clients?
<emersion>
hm, and that's not really privileged anymore… depends how OBS shows its UI though
<drakulix[m]>
I mean a compositor could deny the portal request. Or limit it to clients, that already have privileges to do screen-capture.
<zamundaaa[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
<emersion>
right… like a VNC session
<drakulix[m]>
Right that sounds reasonable. So basically a client could only ever hide itself from its own capture session.
lockywolf has joined #wayland
<emersion>
hm, but what about "caster tools"?
<emersion>
like a timer or chat overlay for casters, which is completely separate from the capture client
<emersion>
maybe at some point it ought to be compositor configuration
<drakulix[m]>
Sounds like they would need a layer-shell surface anyway, so maybe privileged is good enough here?
<drakulix[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?
<kchibisov>
if it matters, the 'exclude from screencast' is sort of common in other windowing systems.
<kchibisov>
it's usually called 'content protection'.
<jadahl>
kchibisov: the difference is *hiding* and showing a place holder obscuring the content
<kchibisov>
I know some clients show splash screen.
<kchibisov>
So the window is present, but it shows something else.
<jadahl>
you mean the client provides its own place holder?
<jadahl>
yea, your use case got derailed into another topic :P
<jadahl>
erm, that was a reply to something in my scroll back, sorry
<drakulix[m]>
Hmm for visual consistency I feel like the compositor should render the placeholder, but maybe that's just me?
cmichael has joined #wayland
<jadahl>
drakulix[m]: that had been my assumption too
<kchibisov>
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'.
<kchibisov>
On macOS they have a flag saying how you can access a particular surface content, None, RO, RW.
<jadahl>
RW surface content? O_o
<kchibisov>
it's weird.
<kchibisov>
I don't think it really works on macOS.
<kchibisov>
Though, it's true that it's not really a security feature.
<jadahl>
it says it's about content protection
<dottedmag>
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"
<kchibisov>
I mean, you can still take a photo.
eroux_ has joined #wayland
<jadahl>
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
<kchibisov>
Well, the ms docs mention that the real use for this is overlays you might want to ignore.
<kchibisov>
Because they serve no value in the screenshot.
eroux has quit [Ping timeout: 480 seconds]
<kchibisov>
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.
<jadahl>
kchibisov: what I read was "This function and GetWindowDisplayAffinity are designed to support the window content protection feature that is new to Windows 7."
<kchibisov>
Ah, it works by not showing a window on a screenshot or capture.
Guest6351 has quit [Remote host closed the connection]
___nick___ has joined #wayland
___nick___ has quit []
cool110_ has joined #wayland
cool110_ is now known as Guest6354
___nick___ has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
Guest6354 has quit [Remote host closed the connection]
cool110- has joined #wayland
heapify has joined #wayland
OpenSaned has quit [Quit: Connection closed for inactivity]
Cyrinux94 has quit []
havona has joined #wayland
Cyrinux94 has joined #wayland
<havona>
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
<havona>
i'm just curious if that's a wayland thing or a weston thing or what's up
<jadahl>
a weston thing
<havona>
is that by design or a bug?
<jadahl>
my guess is it's an oversight
bodiccea_ has quit [Quit: Leaving]
<havona>
okay thank you
jmdaemon has joined #wayland
<havona>
sway seems to have some issues restoring focus on chvt
<havona>
it works most of the time but sometimes not
<havona>
i'm just saying
<havona>
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
<havona>
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
<havona>
oops
<havona>
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
<dottedmag>
not surprising
<vyivel>
havona: iirc changing vts removes and re-adds keyboard devices which can affect focus logic
<havona>
i just hafta get used to it i'm a new wayland person
<havona>
and i switch vts a LOT
<havona>
sway seems nice once i managed to hide the titlebars just saying
JakeSays has quit [Ping timeout: 480 seconds]
JakeSays has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
eroc1990 has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
eroc1990 has joined #wayland
junaid has quit [Remote host closed the connection]