ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
fmuellner has quit [Ping timeout: 480 seconds]
eroc1990 has joined #wayland
Brainium has joined #wayland
columbarius has joined #wayland
<wlb> 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)
co1umbarius has quit [Ping timeout: 480 seconds]
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
SpeakerToMeat has joined #wayland
shankaru has quit [Remote host closed the connection]
shankaru has joined #wayland
SpeakerToMeat has quit [Quit: WeeChat 4.0.2]
carlos_ has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
kenny has quit [Ping timeout: 480 seconds]
eroc1990 has quit [Ping timeout: 480 seconds]
eroc1990 has joined #wayland
kts has joined #wayland
DodoGTA has quit [Ping timeout: 480 seconds]
The_Company has quit [Remote host closed the connection]
godvino has joined #wayland
kts has quit [Quit: Konversation terminated!]
kenny has joined #wayland
abeltramo589 has quit [Ping timeout: 480 seconds]
sima has joined #wayland
<wlb> weston Issue #779 opened by Tomohito Esaki (etom) Build error when xwayland is disabled. https://gitlab.freedesktop.org/wayland/weston/-/issues/779
vsyrjala has quit [Remote host closed the connection]
glennk has quit [Read error: Connection reset by peer]
rasterman has joined #wayland
glennk has joined #wayland
vsyrjala has joined #wayland
godvino has quit [Quit: WeeChat 3.6]
<ofourdan> 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?
<ofourdan> (it's a small MR, I know you choked on Xwayland not applying the configuration before)
heapify has joined #wayland
tent405 has quit [Quit: tent405]
DodoGTA has joined #wayland
DodoGTA has quit [Remote host closed the connection]
DodoGTA has joined #wayland
<jadahl> ofourdan: sure
<emersion> feel free to edit as usual
DodoGTA has quit [Quit: DodoGTA]
<jadahl> the point about hiding from screenshots/screencat/screencopy: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/95
DodoGTA has joined #wayland
<jadahl> imo makes sense as a generic protocol
<jadahl> drakulix[m]: ^
<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"
<any1> That's a neat idea
<emersion> a recent example of this concept, but on the web: https://www.stefanjudis.com/a-firefox-only-minimap/
<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.
mvlad has joined #wayland
lockywolf has quit [Quit: ZNC 1.8.2 - https://znc.in]
<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> They have this exposed, but...
<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.
<jadahl> yea
<jadahl> what is practically what is asked for in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/95 too
<kchibisov> The same wrt macOS api, but macOS api is way more weird.
<kchibisov> Such protocol is a bit tricky, because it must operate on role object.
<kchibisov> Well, for xdg-shell on toplevel.
<kchibisov> because subsurface is also a role...
jmdaemon has quit [Ping timeout: 480 seconds]
<pq> emersion, swick[m], FYI, after Wednesday I'll be off for three weeks.
fmuellner has joined #wayland
<emersion> ack
<wlb> 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]
gallo_ has quit [Quit: Lost terminal]
<wlb> 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]
nerdopolis has joined #wayland
gallo has joined #wayland
eroux has joined #wayland
eroux__ has joined #wayland
kts has joined #wayland
eroux_ has quit [Ping timeout: 480 seconds]
heapify has quit [Remote host closed the connection]
eroux has quit [Ping timeout: 480 seconds]
heapify has joined #wayland
<wlb> weston Issue #779 closed \o/ (Build error when xwayland is disabled. https://gitlab.freedesktop.org/wayland/weston/-/issues/779)
<wlb> weston Merge request !1323 merged \o/ (frontend: Fix build error when Xwayland disabled https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1323)
<wlb> weston/main: Daniel Stone * frontend: Fix build error when Xwayland disabled https://gitlab.freedesktop.org/wayland/weston/commit/4a26a2868284 compositor/main.c
kts has quit [Quit: Konversation terminated!]
<wlb> 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
<wlb> 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)
agd5f has joined #wayland
<wlb> 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
nerdopolis has quit [Ping timeout: 480 seconds]
<wlb> wayland-protocols Issue #153 opened by Colin Kinloch (ColinKinloch) Primary or audience display https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/153
Company has joined #wayland
kts has joined #wayland
heapify has quit [Quit: heapify]
heapify has joined #wayland
OpenSaned has joined #wayland
cmichael has quit [Quit: Leaving]
Company has quit [Read error: Connection reset by peer]
Company has joined #wayland
iomari891 has joined #wayland
heapify has quit [Ping timeout: 480 seconds]
iomari891 has quit [Quit: WeeChat 3.8]
iomari891 has joined #wayland
mohit815 has quit [Quit: The Lounge - https://thelounge.chat]
mohit815 has joined #wayland
junaid has joined #wayland
___nick___ has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
Guest6199 has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest6351
eroc1990 has quit [Quit: The Lounge - https://thelounge.chat]
eroc1990 has joined #wayland
kts has quit [Quit: Konversation terminated!]
___nick___ has quit []
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]
gallo has quit [Quit: Lost terminal]
rv1sr has quit []
heapify has quit [Quit: heapify]
sima has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
<wlb> wayland Issue #397 opened by NekoKitty (nekokittymiku) Wayland extremely laggy on a GTX760 + KDE https://gitlab.freedesktop.org/wayland/wayland/-/issues/397
<wlb> wayland Issue #397 closed \o/ (Wayland extremely laggy on a GTX760 + KDE https://gitlab.freedesktop.org/wayland/wayland/-/issues/397)
nerdopolis has joined #wayland
emilio[m] is now known as emilio|pst[m]
cambrian_invader has joined #wayland
<cambrian_invader> I'm trying to debug weston failing to start, but I don't see any logs from my systemd service
<cambrian_invader> I'm launching weston like `/usr/bin/weston --continue-without-input --modules=systemd-notify.so`
<cambrian_invader> however, it exits with a failure code and no output at all
<cambrian_invader> when I launch weston manually, I see output as usual
<daniels> cambrian_invader: did you set Type=notify in the service?
<cambrian_invader> yes
nerdopolis has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
glennk has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
<cambrian_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
havona has quit [Quit: leaving]
<cambrian_invader> well, I fixed my actual problem by setting use-pixman=true
<cambrian_invader> still no logs...
glennk has joined #wayland
<anarsoul|2> cambrian_invader: you'll get software rendering with use-pixmap=true
<cambrian_invader> ah
<anarsoul|2> *pixman
<cambrian_invader> well, I'm having trouble debugging the drm backend
<cambrian_invader> I tried running it under apitrace, but it didn't have the same behavior
<daniels> which driver are you using?
nerdopolis has quit [Ping timeout: 481 seconds]