ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Seirdy has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
Lucretia has quit []
katp32 has quit [Quit: So long, and thanks for all the fish!]
katp32 has joined #wayland
yomendieta has quit [Quit: Lost terminal]
leon-p has quit [Quit: leaving]
katp32 has quit [Quit: So long, and thanks for all the fish!]
boistordu_old has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
slattann has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
slattann has joined #wayland
danvet has joined #wayland
xexaxo_ has quit [Ping timeout: 480 seconds]
hardening has joined #wayland
floof58_ has quit [Ping timeout: 480 seconds]
floof58_ has joined #wayland
jgrulich_ has joined #wayland
jgrulich_ has quit []
sameer has joined #wayland
jgrulich_ has joined #wayland
slattann has left #wayland [#wayland]
slattann has joined #wayland
txtsd has quit [Ping timeout: 480 seconds]
immibis has joined #wayland
rasterman has joined #wayland
ppascher has joined #wayland
dcz has joined #wayland
Lucretia has joined #wayland
<alwayscurious[m]>
emersion: What do you mean by outer and inner sessions? If by outer you mean the one in the GUI qube seen by the user, then the outer one using Wayland cannot mandate the inner one using Wayland, as X11 programs must still be supported. That is the reason for this discussion.
<emersion>
then just force the X11 windows to be at 0,0
<alwayscurious[m]>
Will that cause real-world X11 programs to misbehave? Also, each qube needs to be able to share its screen and its screen only, for security reasons.
<emersion>
in any case, i'd be strongly against an "absolute position" protocol
<alwayscurious[m]>
What about a “where are my windows relative to each other” protocol?
<emersion>
especially if it's just for legacy
<alwayscurious[m]>
It isn’t; see the screensharing scenario. Without it I can’t think of a way for screensharing to work sensibly in Qubes OS.
<emersion>
i don't see how screensharing is relevant
<emersion>
don't use X11 screen capture
<alwayscurious[m]>
What is the alternative? Remember that screensharing in Qubes OS will be on a per-VM basis, so each VM needs to know what its contribution to the final image is. Otherwise the shared video will not match what the user sees, which would be very poor user experience.
<alwayscurious[m]>
That would be a problem even if X11 didn’t exist.
<emersion>
i think the answer is: wayland hasn't been designed for qubes, if you want compositor to work with qube, you'll have to fork them
<emersion>
compositors*
<emersion>
this is too much custom stuff
<emersion>
and it isn't applicable outside of qubes
st3r4g has quit [Quit: おやすみ]
<alwayscurious[m]>
What about a “restricted screensharing” idea? That is, a system based on PipeWire and xdg-portal that allowed an application to retrieve its own contribution to the display.
<alwayscurious[m]>
Consider a Flatpak that wants to share the parts of the screen it has drawn, but neither needs nor wants access to what has been drawn by other programs.
<emersion>
what's the use-case, outside of qubes?
<alwayscurious[m]>
See aforementioned Flatpak. Right now a Flatpak would need to ask permission to capture the user’s entire screen, which is a more privileged operation with more privacy concerns.
<emersion>
no, xdg-desktop-portal will ask the user "what to share"
<emersion>
it can be the entire screen, but can also be a single app or toplevel
<emersion>
or even workspace
<alwayscurious[m]>
emersion: It can do that? That solves the *entire* problem for Qubes OS.
<alwayscurious[m]>
Because from the perspective of the desktop environment, a qube is just another app.
<emersion>
gnome can do it, sway can't do it but it's planned, unsure about others
<emersion>
the xdg-desktop-portal lets the user choose in any case
<emersion>
the xdg-desktop-portal API*
<alwayscurious[m]>
nice
aleasto has joined #wayland
<emersion>
alwayscurious[m]: sorry if my tone comes out as harsh, this isn't my intention. i think qubes is pretty interesting, but i don't know how best to integrate it with the rest of the ecosystem, without deteriorating the protocol design
<emersion>
it also seems like i really don't know how qubes works :P
hendursa1 has joined #wayland
<alwayscurious[m]>
emersion: Apology accepted, thanks. And thanks for pointing out just how capable xdg-desktop-portal is; it is a sufficient workaround for my use-case. The only case I know of that it doesn’t handle is sharing a single app from within a qube, but the existing X11-based solution can’t do that either.
<alwayscurious[m]>
This has also shown just how little I know about the Linux desktop ecosystem.
<emersion>
if there is a need for compositors to provide additional info to qubes, i'd prefer to clearly label the protocol as qubes-specific, and only make it available to qubes' wayland client
aleasto has joined #wayland
<emersion>
if the protocol can be generalized to be useful for other use-cases, and has no danger of being mis-used by other clients, maybe we can find a way
<alwayscurious[m]>
Agreed. Right now I am not aware of any cases where this is needed, thanks to the xdg-desktop-portal features you described. But I will keep this in mind if it becomes necessary.
<alwayscurious[m]>
My current plan is to see how far I can go with stock Wayland, and only ask for protocol extensions if they are necessary. I thought that an absolute position protocol was necessary, but it appears I may be wrong.
hendursaga has quit [Ping timeout: 480 seconds]
<emersion>
maybe it'd be necessary for x11-inside-qubes-inside-wayland
<emersion>
also see: wine-wayland for an example of running legacy apps inside wayland
<alwayscurious[m]>
Yeah
<emersion>
at that point, maybe it's better to rely on the outer compositor's xwayland support
<emersion>
by making the qubes client use X11 instead of wayland
<alwayscurious[m]>
I also really do not want to be stuck on X11 indefinitely, even if x11-inside-wayland-inside-qubes-inside-wayland needs to work. If a special protocol is needed for this, I suspect it could probably be shared with wine, which probably has similar needs.
<romangg>
What's your expectation regading the kernel discussion? You think the protocol can stay the same or you assume a lot might change depending on what kernel decides to do?
slattann has quit []
sameer has quit [Remote host closed the connection]
<romangg>
emersion: Do you think it still is worthwhile to also implement v1?
<romangg>
Or better to directly and only go for v2?
<emersion>
i'd expect the protocol to stay more or less the same, but the type of the FD to change
<emersion>
i don't think it's worthwhile to spend some cycles doing v1
<emersion>
"i'd expect the protocol to stay more or less the same" → i mean, same as WIP v2
<romangg>
Yes, I think I got what you said. You say: don't spend time on v1. And for v2 the final protocol that will be merged to wayland-protocols will likely be pretty similar to what you currently have in your WIP MR of v2.
<emersion>
yup!
<emersion>
jekstrand has a patch which allows to grab a sync_file FD from a dmabuf
<emersion>
this should also help compositors, because with that patch they can always assume they'll have a fence, even with old clients
<romangg>
You kernel guys are doing god's work. I'll take your gifts once they dropped to userspace earth. ;D
<emersion>
all credit goes to Jason and Daniel Vetter :P
<romangg>
If nothing much changes about the v2 protocol though maybe a KWinFT contributor will do an experimental v2 implementation in KWinFT already before the kernel discussion came to a conclusion on the basis of your WIP protocol.
<romangg>
Do you have an implementation already lined up for wlroots?
<emersion>
not yet, we need to rethink our APIs
<emersion>
explicit sync requires you to pass around the fences
<emersion>
it's pretty intrusive
<romangg>
Hmm, relevant for your render/scene graph redesign?
<emersion>
also i'm not sure if we want to pass around raw FDs, or if we want abstractions
<emersion>
hopefully we can skip the abstraction if the next uAPI will be the Final One
<emersion>
not sure how scene graph fits in there
<emersion>
it'll probably manage most of the stuff for you
<romangg>
"fits in there" as in it's a totally different topic or as in we don't know how to make that work together?
<emersion>
i still haven't thought of how the two will interact
<romangg>
but you assume there will be some interaction. so just that I get a broad picture of the problem scope.
<emersion>
yeah, i think we'll want the two to interact
<emersion>
just because compositors shouldn't have to deal with it, and all of the info we need will be in the scene-graph