ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
iomari892 has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
Guest3646 is now known as DemiMarie
ahartmetz has quit [Quit: Konversation terminated!]
Nokurn has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
crazybyte has quit [Quit: Ping timeout (120 seconds)]
crazybyte has joined #wayland
navi has quit [Quit: WeeChat 3.8]
pbsds7 has quit []
pbsds has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
<kchibisov>
KALT: I've fixed your issue, but ensure that you do `with_transparency(true)` when building a window, since the default is false.
mxz has quit [Quit: cya]
mxz has joined #wayland
Company has quit [Quit: Leaving]
sima has joined #wayland
Lightsword_ has joined #wayland
Lightsword has quit [Read error: Connection reset by peer]
_isinyaaa has quit [Read error: Connection reset by peer]
cath has joined #wayland
isinyaaa has joined #wayland
<KALT>
Thanks kchibisov.
rasterman has joined #wayland
tjaden has quit [Quit: leaving]
tjaden has joined #wayland
Nokurn has quit [Ping timeout: 480 seconds]
iomari892 has joined #wayland
crazybyte has quit [Ping timeout: 480 seconds]
crazybyte has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
MajorBiscuit has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
iomari892 has quit [Remote host closed the connection]
iomari891 has joined #wayland
<emersion>
jadahl: re !68: does that count as review or ack or none?
<jadahl>
emersion: i'd say review, since i've been reviewing it
<emersion>
ty
<jadahl>
raising issues that you've addressed etc
<jadahl>
so thanks for that
<emersion>
sorry the process has been so cumbersome, thank you for bearing with me
MajorBiscuit has quit [Quit: WeeChat 3.6]
<emersion>
okay, so next up is collect 2 ACKs
<emersion>
zzag, drakulix[m], RAOF: would you be interested in ACK'ing !68?
<jadahl>
i'll nag for some extra review on the flatpak mr
<emersion>
please remember that an ACK does not need the same amount of effort as a proper review :)
<jadahl>
pq: with the right amount of gif animations, it might work
<pq>
daniels, looks like all the "do this first" special wording for wl_surface.attach dx,dy was not explicitly carried over for wl_surface.offset, but wl_surface.offset does say it is semantically equivalent to attach dx,dy.
<pq>
daniels, wl_surface.commit spec has a clear answer.
<emersion>
jadahl: and btw would you also be interested in acking for mutter?
<pq>
Oh, offset on the child instead, that's a slightly different case. set_position is applied on parent commit, attach is applied on child commit, so depend on the commit order, I'd say.
<pq>
and application order
<pq>
set_pos definitely does stomp the offset if applied later
<jadahl>
emersion: isn't a review an implicit ack?
<emersion>
I'll take it :)
<pq>
no, you cannot ignore it
<pq>
it all depends on what commits were done on which surfaces with what state changes
<emersion>
pq, i'm not sure what you're replying to
<emersion>
"you cannot ignore it" → compositors cannot ignore the offset request for sub-surfaces?
manuel__ has joined #wayland
manuel_ has quit [Ping timeout: 480 seconds]
<pq>
emersion, correct. Client can issue a protocol sequence where ignoring for a sub-surface would be visibly different behavior from the spec.
<pq>
low-level mechanical protocol, boo
<emersion>
well, that's not how implementations do it
<pq>
*shrug*
<emersion>
and we were talking about changing the spec to make all compositors ignore the offset
<pq>
ok, but it's a spec change, not a clarification
<pq>
so better make sure everyone has always done the same way
<pq>
We have, for example, this statement in the spec for sync'd sub-surface: "The cached state is applied to the sub-surface immediately after the parent surface's state is applied."
<pq>
that might actually result in non-sensical behavior, given that set_position is parent state and offset is child state
<pq>
I'm happy if you can fix these things by writing a better spec, but I always worry that such change will cause a regression for someone somewhere, and the whole creditibility of Wayland depends on not breaking things randomly after we have defined how it must work.
<pq>
*credibility
<pq>
and that makes me the PI in your TA :-)
cmichael has joined #wayland
<daniels>
pq: when you speak about a 'clear answer', are you saying that 'If there is no pending wl_buffer, the coordinates [for any request other than attach] are relative to the current surface contents' suggests that a commit with damage but no attach refers to the currently-attached buffer?
bittin has joined #wayland
bittin has quit [Remote host closed the connection]
<pq>
daniels, surface contents != buffer, they are two different "objects".
<pq>
I'm not sure what the question is.
<daniels>
pq: the question is - if a client calls wl_surface_attach(surf, buf, 0, 0); wl_surface_damage(surf, ...); wl_surface_commit(surf); wl_surface_damage(surf, x, y, w, h); wl_surface_commit(surf); - should the second commit apply (x,y)->(w,h) damage to surf resulting in re-sourcing the content from buf?
cimarrrrrrrrrrrrrrrrrrrrrrrrrr has quit [Remote host closed the connection]
<pq>
I would say no, because the compositor *might* have already released the buffer from the first commit.
<daniels>
I agree with your assertion, which is why I asked what you were meaning - to me, it's clear that it implies that calling e.g. wl_surface_set_input_region() without an intermediate attach is fine, and that the co-ordinates passed apply in the way you'd think they would, and it's also clear (because, as you say, current surface contents != buffer) that the above scenario is UB at best
<daniels>
yes
<daniels>
that's where I thought we'd landed yesterday, but your question made you think you might be interpreting that sentence in wl_surface.commit differently :)
<pq>
I was talking about the sub-surface set_position vs. offset, if I guess what question you mean
<daniels>
oh, iswym
<daniels>
sorry, for some reason half the backlog was just missing when I loaded it this morning - seeing your conversation with emersion now it all makes much more sense
<pq>
heh
* emersion
TIL "FSVO"
<jadahl>
me too, but I don't know what Food Safety and Veterinary Office has to do with subsurfaces
<daniels>
ha
<daniels>
'for some value of'
<jadahl>
daniels: ambiguous, and not the top search result, but sure
<emersion>
it is first result in Urban Dictionary, at least
<emersion>
i mean, the first result for "TIL" is til-technologies.fr
<emersion>
.. and then "Transports interurbains de la Loire", i guess my locale weights a bit here
mvlad has joined #wayland
<jadahl>
emersion: tbf, the second result was correct and from wiktionary
<jadahl>
but seems google is confusing sweden and switzerland here or something, because I don't care about any swiss government agencies
fmuellner has joined #wayland
<kennylevinsen>
easy mistake to make
<kennylevinsen>
banking and falukorv, same same
jmdaemon has quit [Ping timeout: 480 seconds]
<zzag>
with wayland/wayland-protocols!68, is the compositor supposed to check whether wp_security_context_manager_v1 is bound by a sandbox?
<zzag>
if so, how?
<emersion>
i mean both are regions of the beautiful country of Europe
<emersion>
zzag: the compositor has the choice between two strategies
<emersion>
- assume no security context means no sandbox, which is incorrect on current sandbox impls but not more wrong than the status quo (sway)
<zzag>
my second question is: what problem does the protocol solve?
<zzag>
I don't quite follow the motivation behind the protocol
<zzag>
perhaps I should have asked that in the MR
<emersion>
- add racy sandbox-specific logic to check whether a client is flatpak or not, only allow the client to create a flatpak security context if that check succeeds
<emersion>
(mutter already has flatpak-specific logic, so could do that)
<drakulix[m]>
I guess the idea is giving sandboxed clients a less privileged sockets? (E.g. hide some globals?)
<zzag>
example?
<emersion>
the motivation is to be able to tell when a client is running in a sandbox in a secure and non-racy way, and provide a sandbox-agnostic way to get basic metadata about that client
<jadahl>
drakulix[m]: point is primarily to avoid the PID reuse race. mutter already knows if a client is flatpak/snap so it'd be more about the theoretical race
<drakulix[m]>
got it
<emersion>
so yeah, compositors can then take policy decisions based on the metadata provided by the protocol
<drakulix[m]>
So assuming you trust the sandbox, you could also e.g. have permissions to enable certain globals based on the app_id.
<emersion>
one example would be to hide the layer-shell global, for compositors implementing this
<emersion>
another example would be to restrict keyboard-shortcuts-inhibit
<jadahl>
emersion: keyboard shortcut inhibit is used by most remote desktop and virtual machine viewers
<emersion>
yeah, and one could only allow these apps to use it
<emersion>
and not allow other unsandboxed apps
bittin has quit [Remote host closed the connection]
<jadahl>
true
<emersion>
the reason it's opt-in, rather than opt-out, is to reflect the reality that unsandboxed clients can mess up your system without going through the trouble of using wayland (echo bad >>~/.bashrc)
bittin has joined #wayland
<zzag>
emersion: hmm, I see. although I'm not sure that hiding "privileged" globals is always the case. for example, layer-shell still makes sense for some apps that operate in overlay mode
<zzag>
e.g. your slurp app
<zzag>
or for third party screenshot tools
<zzag>
where you want to show an overlay
<emersion>
zzag: yes, so, my plan is to hide the globals as the first step
<emersion>
then as a second step, add a way to expose these globals to allow-listed sandboxed apps
<emersion>
you don't necessarily need to hide the globals, you can deny/ignore protocol requests if you prefer a more dynamic setup
<zzag>
"then as a second step, add a way to expose these globals to allow-listed sandboxed apps" that makes sense, especially if sandbox/flatpak is responsible for that
<emersion>
yeah, i've not yet looked too much into flatpak's permission store, but maybe could use that
<zzag>
"especially if sandbox/flatpak is responsible for that" i.e. flatpak reading app metadata and asking for those globals
<emersion>
yeah, i'm not that far into the Future™ yet, but that'd be nice for sure
<emersion>
my immediate goal is to remove the ability for Zoom/Teams/other proprietary sandboxed apps to have unrestricted access to our protocolsd
<drakulix[m]>
Why is the order of operations first to send the fd, then the metadata?
<emersion>
to make the metadata extensible
<qyliss>
my use cases for this protocol in a security-focused are: restricting access of (non-allow-listed / granted permission at runtime) sandboxed applications to certain compositor features (clipboard, fullscreen, screenshot, etc.), and for securely identifying different applications, so I can do e.g. Qubes-style coloured window decorations to differentiate between different sandbox
<emersion>
can add more metadata requests
<qyliss>
instances.
<emersion>
if we want to invent another mechanism which doesn't use the FD, we can add a new request on the global which creates the metadata object
<drakulix[m]>
ok, makes sense.
<drakulix[m]>
So realistically a compositor has to wait for commit on the context before it can really accept connections on the fd, right?
<drakulix[m]>
At least if it wants to take the metadata into account.
<emersion>
yes, a compositor would stash the FD somewhere and only start listening on commit
<emersion>
that's what the wlr impl does
<zzag>
emersion: I will check with d_ed on the protocol and either he or I ack it
<emersion>
ty!
<pq>
drakulix[m] said "wait for commit" - is there some strange character just before the word "commit"? It shows as reverse-video "Q" in irssi, and I've seen it occasionally, maybe from Matrix bridges?
<drakulix[m]>
I put commit in backticks, like markdown code formatting. (Which is how it is rendered in Element.)
<drakulix[m]>
Does that break when send over the bridge?
<pq>
I see no backticks at all
<emersion>
maybe it tries to convert to ANSI formatting codes
<emersion>
(my clients interprets it correctly, but maybe older clients don't)
<pq>
:facepalm:
<pq>
my terminal is already monospace, thank you irccloud
<drakulix[m]>
So do we blame clients or should I try to avoid that in the future?
<emersion>
ideally that would've been an IRCv3 cap that one needs to opt-in to
<emersion>
but was well before my time
<pq>
I guess I'll just mentally ignore it, and hope that Debian Bookworm contains a version of irssi that just strips it, or converts back to backticks.
<emersion>
i'd suggest opening an irssi issue if it's not fixed, since that ship has already sailed…
<pq>
looks like irssi 1.4.4 changelog has "support receiving monospace"
<emersion>
nice
<pq>
bookworm has 1.4.3
<pq>
well, one day
<emersion>
\o/ got an ACK
<emersion>
ty drakulix[m]
<drakulix[m]>
np. I was already looking forward to this protocol, I just had to get up-to-date. 🙂
columbarius has quit [Ping timeout: 480 seconds]
navi has joined #wayland
columbarius has joined #wayland
nerdopolis has joined #wayland
bittin has quit [Remote host closed the connection]
<kchibisov>
If compositor wan't to maximize/fullscreen my client, can I somehow indicate that I don't want/can't?
rv1sr has joined #wayland
<kchibisov>
I could ignore size change, but some still makes me fullscreen, centered around the black content.
KALT has quit [Remote host closed the connection]
<emersion>
mark as not resizable?
<kchibisov>
if you mean by that set min and max sizes to the same values, I think I've still seen fullscreen.
nerdopolis has quit [Remote host closed the connection]
<kennylevinsen>
min/max is just a hint, so while it might be silly for a compositor to allow a non-resizable client to fullscreen, a client must deal with it anyway
<pq>
I might call that a compositor bug, even if protocol allows it. It's not nice to exceed size hints.
nerdopolis has joined #wayland
<kennylevinsen>
exceeding size hints is normal, e.g. tiling
<kennylevinsen>
in both directions
<pq>
ugh
<pq>
still not nice
<kennylevinsen>
although tiling compositors also take min == max as hint for modal that become floating by default
<pq>
modal?
<pq>
is that really used to imply modal?
<vyivel>
regarding maximized state, it's an error to disobey the size received from the compositor
<pq>
yes
<kchibisov>
So a dialog menu, which sets min/max sizes to the same value, should still somehow deal with resize.
<kennylevinsen>
modal is the wrong word, but its used to deduce that this is a floating window ala file save prompts
<kennylevinsen>
("Similarly, a tiling window manager may use this information to place and resize client windows in a more effective way.")
<vyivel>
kchibisov: the client doesn't have to ack a configure
<emersion>
it has to…
<kchibisov>
The client must also acknowledge configure events using "ack_configure
<kchibisov>
¯\_(ツ)_/¯
<vyivel>
hm, i think gtk programs don't ack sizes less than min size...? unless i misremember
<kennylevinsen>
vyivel: an ack is implicitly an ack of every prior configure, so to not ack one you'd have to never ack ever again
<kennylevinsen>
wayland client tantrum
<vyivel>
you can ignore them until you get a state you support
<pq>
I would have expected to have new xdg-surface sub-roles than deducing anything from size hints.
<kennylevinsen>
pq: note: xdg_toplevel parent association is also used as hint for the same
<kennylevinsen>
it's a lot of toplevels that would have to use the new role though
<pq>
using parent association is fine
<kennylevinsen>
every file dialog, save or password prompt, etc.
<kchibisov>
well, we have wm_capabilities, could do client_capabilities.
<kchibisov>
but that's probably stupid.
<kennylevinsen>
but roll-out difficulty aside, I wouldn't mind clearer communication
<pq>
wm_capabilities?
<kchibisov>
wm_capabilities (v5 event).
<kchibisov>
Tells the client what compositors supports or not.
<pq>
aha
<kchibisov>
Could do inverse of it.
<kennylevinsen>
is your issue just that you have a dialog you'd prefer not to be fullscreen, or that you want a mechanism to block arbitrary fullscreening?
<kchibisov>
kennylevinsen: yes, some kind of.
<kennylevinsen>
"a or b" "yes"
<kchibisov>
I choose "a".
<kchibisov>
Though, the user I have want "b" for maximize.
<kchibisov>
And I was told that at least on some systems you have ways to mark window 'not maximizable'.
<kennylevinsen>
just asking, 'cause i'd prefer not to define "compositor must never" behavior here
<kchibisov>
Though, we could have a way to mark a window not resizable or user resizable only.
<kennylevinsen>
i.e., telling the compositor it is a dialog so it can do whatever it does for dialogs is good, saying "dialog cannot be tiled/fullscreen" is bad
<kennylevinsen>
for example, my compositor is strictly tiling in a plan9-esque way where toplevels are placed in user pre-defined "containers". The window has no say in the matter, and size hints are not considered.
<kennylevinsen>
dialogues just replace their parent as the sole content of the container until they are closed, but they are tiled all the same
<kennylevinsen>
weird, yes, but I'd prefer for that to not suddenly become a protocol violation
<kchibisov>
I still don't understand why users can't handle resizes.
<emersion>
i don't really understand what problem you're trying to solve, kchibisov
<emersion>
we already have "not resizable"
<kchibisov>
emersion: the user wants to prevent all ways to maximize a window.
<pq>
by users you mean apps/clients?
<pq>
not actual users
<kchibisov>
The actual users of the library, because they have something like that with Qt
<kennylevinsen>
as contrarian example, users of my compositors want all toplevels to be "maximized", full stop
<kennylevinsen>
s/compositors/compositor/
<pq>
right, so "we could do this with X11, we want it with Wayland too"
<kchibisov>
it's more like, I can do that with Win32, but you've got the point.
<kchibisov>
emersion: you mean that compositor treats min/max hints?
<kchibisov>
kennylevinsen's compositor doesn't bother for example, so…
<kennylevinsen>
exactly, which is how it should be
<kennylevinsen>
this allows the user to have the wanted behavior, rather than forcing the client developer's choice that may not fit with the intended usage
<kchibisov>
I set min/max hints as well, but I know that it's a recommendation.
<kennylevinsen>
while that could be more explicit, telling the server it is a dialogue some way is all that is needed. the server can then implement behavior that is appropriate for that environment/user choice/etc.
<kennylevinsen>
this could mean blocking fullscreen, or it could mean not caring - depends on the user/DE/whatever
<sewn>
hi, is this the correct channel for wayland development? i am currently trying to make a wayland application but i'm getting some errors i can't solve
<qyliss>
This is the channel for Wayland development.
<sewn>
ok cool um
<qyliss>
(but not for toolkit specific questions, etc.)
<sewn>
what is this weird "listener function for opcode 2 of xdg_toplevel is NULL" error? i'm pretty sure i filled out most of the listeners with their functions
manuel__ has quit [Ping timeout: 480 seconds]
<daniels>
you didn't fill out the third entry of the listener you passed to xdg_toplevel
<sewn>
my xdg_toplevel_listener only has .configure and .close
<daniels>
presumably you're passing too high a version to bind then - you need to only pass the version you actually support
<DodoGTA>
How is that different from not calling add_listener() at all?
sima has quit [Ping timeout: 480 seconds]
<emersion>
yes, that listener is dead code
cvmn has joined #wayland
___nick___ has joined #wayland
___nick___ has quit []
<DodoGTA>
emersion: Both SDL2 and GLFW have that listener code while winewayland doesn't (I'm trying to figure out mouse escape issues with winewayland)
caveman has quit [Remote host closed the connection]
___nick___ has joined #wayland
crazybyte has quit [Quit: Ping timeout (120 seconds)]
crazybyte has joined #wayland
<emersion>
it shouldn't make any different in behavior
<emersion>
difference*
<kennylevinsen>
I imagine it might just be habit in how they wrote the code - "this is what I did with all the others"
<kennylevinsen>
might not have been obvious that you don't need the listener
<DodoGTA>
I guess I should try removing it from SDL2 and see what happens then
iomari891 has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
navi has joined #wayland
kts has joined #wayland
jmdaemon has joined #wayland
rv1sr has quit []
___nick___ has quit [Ping timeout: 480 seconds]
<bwidawsk>
What is the expected behavior if you damage an attached buffer, then commit. The spec says damage effects the "pending buffer" but that's a bit ambiguous, I feel. Does damaging the attached buffer without attaching a new one do anything?
<emersion>
bwidawsk: we had this exact conversation… yesterday in this channel
<bwidawsk>
oops, I shall read the backlog
<bwidawsk>
funny timing
<emersion>
yeah :P
<emersion>
tl;dr
<emersion>
yes, you need to attach again
<emersion>
and make sure you're not damaging a buffer which hasn't been released
<bwidawsk>
RAOF: Do you agree the test is broken based on what emersion says ^^
<bwidawsk>
emersion: thanks for the tl;dr
<bwidawsk>
emersion: is there specific verbiage I should reference in a bug report on WLCS?
srobert has joined #wayland
iomari891 has joined #wayland
<kennylevinsen>
bwidawsk: damage applies to the pending buffer only. the pending buffer is explicitly cleared after commit, meaning that it is only valid between attach and commit
Mershl[m] has quit [Quit: Client limit exceeded: 20000]
<DodoGTA>
emersion: I guess it's dead code after all (I removed the listener stuff and Xonotic works fine without cursor escape)
rajveermalviya[m] has quit []
O5KV5980 has joined #wayland
lyasm[m] has quit [Quit: Client limit exceeded: 20000]
neobrain[m] has quit []
iomari891 has quit [Ping timeout: 480 seconds]
<bwidawsk>
kennylevinsen: yeah, I think "pending" in this case is a bit ambiguous, but I'm relatively new to wayland protocol.
<bwidawsk>
because even if you reuse the buffer, is it not pending?
<kennylevinsen>
bwidawsk: no, it is explicitly no longer pending after you call commit
<kennylevinsen>
bwidawsk: a pending buffer is what you assign with attach (i.e., nothing is pending beforehand), and there is explicitly no longer any pending buffer after commit (because it was made current)
<kennylevinsen>
so damage only has something to operate on immediately after attach and until just before commit
<RAOF>
bwidawsk: thanks for finding these! I'm a bit surprised that *Mir* doesn't fail these tests.
<bwidawsk>
There's nothing wrong with what it's doing
<bwidawsk>
afaict, it's not against spec
<bwidawsk>
kennylevinsen: I notice though damage without previous attach isn't mentioned as an error, but presumably it would have no effect
<bwidawsk>
RAOF: if you or someone you know is fixing, you are supposed to use damage_buffer now instead of damage, fyi
<bwidawsk>
RAOF: the only reason I noticed is because my compositor in a certain mode will only send frame callbacks if there is damage
<bwidawsk>
aiui, Firefox at least, probably others, will send frame requests without damage, so that would break
<RAOF>
Oh, yeah, that's why it passes. The test never actually submits a buffer, so we'll always send a frame event when asked 🤦♀️
<RAOF>
The damage bit is just a big noop
kts has quit [Remote host closed the connection]
kts has joined #wayland
<kennylevinsen>
bwidawsk: it is undefined and makes no sense to attach without a pending buffer, irrespective of why there is none
<kennylevinsen>
there is no current error for it, so it is undefined behavior
<kennylevinsen>
uh
<bwidawsk>
s/attach/damage... gotcha
<kennylevinsen>
I mean, damage without a pending buffer of course :)
<bwidawsk>
has there been previous discussion about clients submitting a frame request and expecting a done event without any damage occurring anywhere on the composited frame?
<kennylevinsen>
yes, it should be send irrespective of whether any damage is submitted as it is a request to be notified when to draw the *next* frame
kts has quit [Quit: Konversation terminated!]
jryans has quit [Quit: Client limit exceeded: 20000]
srobert has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
jmdaemon has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
jmdaemon has joined #wayland
d_ed has joined #wayland
d_ed has quit []
jmdaemon has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
Vanfanel has quit [Quit: Client limit exceeded: 20000]
ttancos[m] has quit [Quit: Client limit exceeded: 20000]
yshui` has quit []
O5KV5980 has quit [Remote host closed the connection]