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
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
HI has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
Lucretia has quit []
HI has quit []
astropeng has joined #wayland
Seirdy has quit [Quit: exiting 3.2]
Seirdy has joined #wayland
astropeng has quit []
mooff has quit [Remote host closed the connection]
mooff has joined #wayland
pi1234 has joined #wayland
pi123 has quit [Ping timeout: 480 seconds]
fstp_ has joined #wayland
pts33 has quit [Read error: Connection reset by peer]
zebrag has joined #wayland
pi12345 has joined #wayland
pi1234 has quit [Ping timeout: 480 seconds]
shashank1202 has quit [Quit: Connection closed for inactivity]
zebrag has quit [Quit: Konversation terminated!]
<DemiMarieObenour[m]>
How can one map legacy display server protocols and APIs (X11, Windows) onto Wayland?
<whot>
DemiMarieObenour[m]: see Xwayland for example, it does exactly that
<DemiMarieObenour[m]>
whot: it requires a modified Wayland compositor and special privileges
<DemiMarieObenour[m]>
Whereas Qubes OS and Wine need solutions that do not.
tzimmermann has joined #wayland
jgrulich has joined #wayland
SallyAhaj has left #wayland [Leaving]
hardening has joined #wayland
<emersion>
see wine-wayland
<pq>
romangg, if you do happen to use Wayland as config IPC, then maybe it should be a separate socket that does not offer any "normal" Wayland interfaces? That might dodge the "apps are going to abuse it" claim.
<pq>
DemiMarieObenour[m], such mapping is extremely painful to do, and in some cases you simply cannot do it in full without explicit support in the compositor. Even XWayland is not a full mapping.
<pq>
That's kind of the whole point of different window system protocols: they are not equivalent.
<DemiMarieObenour[m]>
pq: Acknowledged. How does it compare to the reverse direction: mapping Wayland onto X11?
danvet has joined #wayland
<pq>
DemiMarieObenour[m], X11 is "anyone can do anything to anyone's any things", so theoretically not a problem.
<DemiMarieObenour[m]>
pq: That explains why Wine has been able to map the Windows API to X11, but mapping it to Wayland is much harder.
<pq>
DemiMarieObenour[m], but it is also not a straightforward mapping but a reimplementation of all Wayland concepts.
<pq>
yes
<DemiMarieObenour[m]>
pq: indeed, which is I am discovering right now as I try to implement what is effectively such a mapping for Qubes OS.
<emersion>
pq, 2 sockets are tricky because you can't share things between the two
<emersion>
and can't sync
<pq>
emersion, that is the point, yes.
<emersion>
may be acceptable for input config, but not for layer-shell
<pq>
one of the points, at least
<emersion>
well… i guess you could have a normal socket, and a privileged socket with everything in the normal socket + more stuff
<emersion>
but it's not so fine-grained
<pq>
True, but I was thinking strictly only of compositor configuration.
<DemiMarieObenour[m]>
The X Access Control Extension was incredibly fine-grained.
<DemiMarieObenour[m]>
Probably too fine-grained.
<DemiMarieObenour[m]>
As far as compositor configuration: is the purpose of having an API to avoid each compositor having to implement its own configuration GUI?
<pq>
yes, I think sharing GUIs is a big deal.
<DemiMarieObenour[m]>
Agreed ― writing a good GUI is hard
<emersion>
big desktops don't really agree, since they each want their "native" UI
<DemiMarieObenour[m]>
they also have the resources to write one, though
<pq>
maybe also sharing persistent configuration storage and setting up the rules of which config source overrides what and how
<emersion>
i think a wayland protocol would be strictly superior to say a config file format here, because it allows for dynamic configurations
<pq>
if not sharing the actual store, then at least sharing the libs and architecture
<pq>
protocol is not good for compositor start-up configuration though, you'd want some way to the compositor to access stored configuration by itself - maybe via IPC though
<pq>
so waiting for a Wayland client to pop up may not be the best idea
<DemiMarieObenour[m]>
Perhaps incorporate it into libwayland-server?
<pq>
unless the compositor can launch that client?
<pq>
DemiMarieObenour[m], no, never. That I will definitely NAK.
<pq>
if I can
<pq>
libwayland-server does far too much already
<DemiMarieObenour[m]>
pq: good point (consider embedded systems where this is useless baggage)
<pq>
even if Wayland happens to be the IPC of choice, I also don't see why it should be tied to Wayland per se.
<DemiMarieObenour[m]>
perhaps there should be a libwayland-desktop-compositor or similar
<pq>
well, it's more the library maintainability question
<emersion>
i don't think sharing the impl is the first order of business here
<pq>
libwayland-server is stable, so any ABI added at all to it cannot be removed - and this config thing is definitely something that will need a few iterations at least
andyrtr_ has joined #wayland
<emersion>
i think sharing the standard is the baseline goal
<DemiMarieObenour[m]>
yeah
andyrtr has quit [Read error: Connection reset by peer]
andyrtr_ is now known as andyrtr
<pq>
I agree, getting enough people even on the page about what should be spec'd before it's even spec'd, let alone implemented, is going to be hard.
<emersion>
re config store: not all wayland compositors have a mutable config store…
<pq>
sure
<emersion>
sway's one is purely immutable from the compositor PoV
<emersion>
and i don't think we want multiple sources of truth
<emersion>
but it's all right if IPC sets up a per-runtime config
<pq>
Weston would probably like a mutable config store as soon as it gets any kind of runtime configurability, but of course it needs to be opt-in.
<DemiMarieObenour[m]>
On a different topic, I have noticed that there appears to be a gap in Wayland compositor libraries
<pq>
there indeed then comes the big problem of multiple config sources
<DemiMarieObenour[m]>
There are high-level libraries such as libweston and wlc, but they tend to be inflexible and at least wlc is deprecated.
<SardemFF7>
DemiMarieObenour[m]: I’ve played with a headless Weston X11 backend some time ago, never got it upstreamed but it worked quite well
<pq>
SardemFF7, what is headless X11?
<SardemFF7>
not headless… can’t remember how we call it
<pq>
or did you mean rootless?
<DemiMarieObenour[m]>
SardemFF7: Was it rootful or rootless? That is, did it use a single giant X11 window, or one window per toplevel surface?
<SardemFF7>
rootless!
<SardemFF7>
my bad
<DemiMarieObenour[m]>
SardemFF7: THANK YOU this might well be (almost) exactly what Qubes OS needs, at least conceptually if not from an implementation perspective.
<pq>
I'm not sure Weston (upstream) should have a rootless X11 backend.
shashank1202 has joined #wayland
<DemiMarieObenour[m]>
Is the backend infrastructure flexible enough to make writing one possible?
<SardemFF7>
officially, no
<pq>
it's not pleasant, but I guess you can do it if you want hard enough
<DemiMarieObenour[m]>
I believe there is already at least one rootless backend: Microsoft’s RDP backend for WSL2.
<emersion>
they forked weston
<emersion>
so they can butcher the internal architecture at will
<DemiMarieObenour[m]>
Darn 😞
<pq>
I haven't seen those modifications and it's not upstream yet.
___nick___ has joined #wayland
<DemiMarieObenour[m]>
pq: why do you believe that upstream should not have such a backend?
<DemiMarieObenour[m]>
(rootless X11)
<pq>
the upstream RFP backend only does rootful
<pq>
*RDP
<pq>
DemiMarieObenour[m], what would be the point of it? Why would anyone use it?
<pq>
Weston is part a tech demo, part reference implementation, and the X11 backend necessarily butchers both points.
<DemiMarieObenour[m]>
pq: directly it would not be very useful, but it could be useful to those (like me!) who are in similar situations
<DemiMarieObenour[m]>
also, rootless RDP has a use-case already
<pq>
if you want rootless, that could probably be served with a rootless RDP or VNC implementation, which seem to have more use than rootless X11.
<DemiMarieObenour[m]>
valid
<SardemFF7>
my use was to ditch backends in my app, having Wayland only, but still providing compat for X11 users
<DemiMarieObenour[m]>
That is a valid one
<pq>
you're free to do rootless on X11 yourself, but I don't think it belongs in Weston upstream.
<DemiMarieObenour[m]>
Another use would be adding Wayland support to desktop environments (such as XFCE) that don’t yet support it natively.
<pq>
SardemFF7, and your reason to not use a toolkit that supports both Wayland and X11 is...?
<SardemFF7>
though since layer-shell won the non-war it seemed useless trying to escape X11, as it was already slipping to Wayland thanks to Sway :-)
<emersion>
sigh
<DemiMarieObenour[m]>
sigh?
<emersion>
welcome back, i guess…
<SardemFF7>
pq: because it’s less flexible, less fun, and kind of bloatish for notification bubbles IMO :-)
<pq>
one can always find more and more use cases, but we are already struggling with Weston maintenance, so adding more maintenance burden will only make things worse over all, so there needs to be a good justification to add to that burden
<DemiMarieObenour[m]>
from my perspective, being able to maintain a rootless Weston backend out of tree would be very useful
<emersion>
DemiMarieObenour[m]: a long time ago there's been a disagreement how desktop UI components should be built
<emersion>
but i don't really want to re-hash this
<SardemFF7>
emersion: hey, at least I don’t feel depressed about it anymore :-)
Lucretia has joined #wayland
<DemiMarieObenour[m]>
emersion: that’s fine
<emersion>
so, can we just move on
<DemiMarieObenour[m]>
My situation is that I need extremely low-level control over input and drawing, but am by no means an expert on Wayland itself.
<pq>
I wonder if we can drop the fbdev backend by now... I'd propose X11 backend to go after that.
<emersion>
that'd be sweet
<DemiMarieObenour[m]>
fbdev is already deprecated in Linux IIRC, so I have no problem chucking that
<pq>
DemiMarieObenour[m], there was one person who has been keen on fbdev-backend, and only quite lately the kernel driver situation has improved enough that he seemed more willing to let it go.
<DemiMarieObenour[m]>
I don’t know much about Weston internals, but from what I can tell, if rootless backends were officially supported, they would be about the right abstraction level for Qubes OS to use.
<SardemFF7>
it’s more of a “are out-of-tree backends supported?” question
<DemiMarieObenour[m]>
yeah
<SardemFF7>
as in stable backend plugin API
<DemiMarieObenour[m]>
Ah
<pq>
out-of-tree backends are currently officually unsupported
<pq>
on Weston at least, where you can't load arbitrary backends.
<pq>
libweston is less clear on that
<DemiMarieObenour[m]>
emersion: If I use wlroots, how much more effort would it be to get a full-featured compositor than a bare-bones one?
<pq>
DemiMarieObenour[m], rootless and full featured seem mutually exclusive to me.
<emersion>
DemiMarieObenour[m]: what do you mean by "full-featured"?
<DemiMarieObenour[m]>
pq: probably because we have different definitions for “full featured”
<pq>
I guess depends on what you mean by full featured, I include things like composition, window management, a good timing control.
<DemiMarieObenour[m]>
emersion: that any “ordinary” application (as opposed to stuff that deliberately tries to modify the desktop environment, using layer-shell or similar) Just Works
<DemiMarieObenour[m]>
As opposed to getting bug reports because XYZ didn’t render correctly, which are a PITA to track down and fix.
<emersion>
would you say that tinywl is "full-featured"?
<DemiMarieObenour[m]>
Can it run the programs that users reasonably expect it to run?
<pq>
"render correctly" is an interesting topic. Wayland does not have any drawing API, so that in sense there is nothing to worry about. However, there are interfaces like wp_viewport: do you take the performace hit of always doing a copy in the compositor, or will you forward the client buffer with viewport data to the parent winsys?
<emersion>
it should run all xdg-shell wayland clients
<emersion>
notably missing: hidpi support, drag-and-drop, xwayland support
<DemiMarieObenour[m]>
pq: Currently the former, but that will be fixed once the needed Linux kernel interfaces have been implemented.
<DemiMarieObenour[m]>
this was aimed at pq btw, I forgot that quotes don’t translate to IRC
<emersion>
this was prefixed with "pq: "
<DemiMarieObenour[m]>
Ah okay
<emersion>
so was a completely normal interaction from IRC's PoV
<DemiMarieObenour[m]>
I am using the Matrix ⇔ IRC bridge so I am not sure what works and what does not.
<DemiMarieObenour[m]>
thanks for the help emersion
d_ed has joined #wayland
<DemiMarieObenour[m]>
<emersion> "notably missing: hidpi support..." <- How difficult would adding those be? drag-and-drop is… _iffy_ at best in Qubes OS: the window system in the GUI qube can’t be involved as the attack surface for complex data types would be too great, and the rootless sub-compositor can’t do a good job as it doesn’t know what is actually visible to the user. But copy-and-paste, XWayland, and HiDPI should work.
<emersion>
each of these shouldn't be too hard to implement, but is still a bit of work
<emersion>
maybe look into cage for a simple compositor with all of these features
<pq>
How is copy-and-paste different from drag-and-drop? Do you limit copy to just few text formats?
<emersion>
cage has a lot of rendering code as well, but it's getting removed with the scene-graph. but i don't think you need to care about rendering at all?
tzimmermann has quit [Ping timeout: 480 seconds]
muhomor has quit [Remote host closed the connection]
tzimmermann has joined #wayland
<pq>
DemiMarieObenour[m], btw. I'm really happy that there is interest from Qubes on Wayland and Weston, and you specifically with the security reviews. It's just that usually we don't have easy answers or even answers at all for your topics which undoubtedly makes it seem like an uphill battle on everything you touch. Sorry, but I do appreciate the effort.
<DemiMarieObenour[m]>
pq: Thank you _so much_ for this; knowing that my work is appreciated really helps. There not being easy answers is something I totally understand.
<DemiMarieObenour[m]>
<pq> "How is copy-and-paste different..." <- In Qubes OS, the inter-qube clipboard only supports UTF-8 text, and is managed explicitly by the user: one shortcut (by default Ctrl-Shift-C) copies data from the focused qube to the shared clipboard, and another (by default Ctrl-Shift-V) pastes the text from the shared clipboard to the focused qube. Standard copy-and-paste and drag-and-drop within a qube work normally.
<DemiMarieObenour[m]>
current UX is quite poor in this regard.
<DemiMarieObenour[m]>
The reason drag-and-drop is so difficult in Qubes OS is that it is implicit: the data is implicitly dropped on whatever window the in-qube window system thinks mouse is over, even if that is not the window the user thinks the mouse is over! That can cause things like accidentally dropping text from a messaging app into a shell, which is obviously not good. I am very much open to suggestions for how to improve this situation; the
<emersion>
why is the window system not able to figure out the correct destination?
<emersion>
because it's X11?
<DemiMarieObenour[m]>
emersion: It does not know where other qubes’ windows are located and stacked.
<emersion>
don't you have a window system outside of the sandboxes?
<DemiMarieObenour[m]>
emersion: It is X11 for now, but one goal of my work is to change this
<DemiMarieObenour[m]>
emersion: Yes, but it is not involved in drag and drop at all.
<DemiMarieObenour[m]>
Perhaps? In what way? I am no expert on window systems, to put it mildly.
<SardemFF7>
random poll: does anyone here feel like an expert on window systems? :-)
<emersion>
i don't really know how qubeos works, but that's how i'd expect a rootless system to do it
<DemiMarieObenour[m]>
one of the goals of Qubes OS is to minimize the attack surface exposed to the sandbox as much as possible
<DemiMarieObenour[m]>
emersion: would you mind explaining?
<emersion>
well, i'd expect each sandbox to just be a proxy to the outside world, not a window system
<zubzub>
SardemFF7: I am an expert on window systems, I recently had all of them replaced in my house
<emersion>
much like sommelier in chromeos
<emersion>
the proxy does just sanitization and relays everything through a VM side-channel
<DemiMarieObenour[m]>
emersion: That is in fact how Qubes OS works, but the protocol the proxy speaks is extremely bare-bones.
<emersion>
so a drag-and-drop started inside the sandbox would initiate a drag-and-drop outside it as well
<emersion>
by relaying the "start drag and drop" message basically
<DemiMarieObenour[m]>
That would be considered a security hole in Qubes OS. Any movement of data between qubes must be explicit.
<emersion>
"start drag and drop" doesn't mean any data is transferred
<emersion>
the outside window system could even ask the user something like
<emersion>
"your data transfer is crossing domains, are you sure"
<emersion>
just before the data transfer happens
<emersion>
(ie, after drop)
<emersion>
forbidding data transfer before the drop could make some clients unable to provide realtime drop feedback, but hopefully not a big deal
<emersion>
(drop feedback = changing the cursor icon depending on whether or not would the destination would accept the drop)
<DemiMarieObenour[m]>
emersion: That might work, but it would require substantial design work to ensure it does not harm security. A simpler approach would be to treat this as an error condition.
<DemiMarieObenour[m]>
emersion: In Qubes OS, the cursor cannot be changed to any arbitrary image, but only chosen from a set of allowed images.
<emersion>
well, yeah. drag and drop is pretty complicated, i completely understand why you wouldn't want it
<emersion>
the window system outside of the WM would change the cursor image, to be clear
<emersion>
outside of the VM*
<emersion>
speaking of cursor images
<emersion>
this design won't work well with wayland
<emersion>
but you might've seen that already?
<emersion>
clients don't set a cursor image with a well-known name, instead they always provide a pixel buffer with the cursor image
<emersion>
i forget how things work in the X11 world
<pq>
glyphs
<pq>
I don't remember more, don't ask.
<emersion>
oh eh
<emersion>
that does make me remember some… memories
<emersion>
mostly that it was a complete mess
<pq>
(really, as in font)
<DemiMarieObenour[m]>
emersion: Indeed so 😞. Are there a set of well-known images that most clients use, and which I could use `memcmp` to check for?
<emersion>
DemiMarieObenour[m]: if you want to go down that road, i'd expose a single XCursor theme to sandboxed apps, each cursor image with a single pixel in it
<emersion>
then i'd check the first pixel value when an app tries to set the cursor
___nick___ has quit []
<pq>
...and hope apps don't bring their own cursor themes
<emersion>
yeah
<dottedmag>
These "apps" are actually full VMs, so that means installing this theme into each VM.
<pq>
nor somehow fall back to the built-in one in libwayland-cursor - but I suppose you could check that too.
<DemiMarieObenour[m]>
pq: `length == 1` should handle that case, and in any case Qubes OS worked for years with no cursor feedback at all.
<emersion>
well, could have a few "magic sequence" pixels at the start
<DemiMarieObenour[m]>
pq: The built-in ones are easy to handle; just use a hash table.
<emersion>
DemiMarieObenour[m]: length == 1 would work if there's no hidpi
<DemiMarieObenour[m]>
emersion: Uggggh
<emersion>
hm, i guess in case of hidpi you can still check whether the cursor surface size is 1x1
<emersion>
because clients would send a 2x2 buffer with scale 2
<emersion>
so it'd still work fine
<pq>
DemiMarieObenour[m], what's the attack scenario being addressed with forbidding custom cursors?
<DemiMarieObenour[m]>
pq: not sure, I would need to check on that
<DemiMarieObenour[m]>
hidpi is another area where Qubes OS struggles, because rendering UHD data in software is sloooow
<emersion>
pq, maybe involves setting the cursor while another client has focus?
<DemiMarieObenour[m]>
and doing so in hardware is obscene attack surface
<DemiMarieObenour[m]>
emersion: That’s easy enough to check for, but being able to confuse the user as to where the cursor is would be bad.
<emersion>
ah, yeah, offsets
<emersion>
"hotspot"
___nick___ has joined #wayland
<emersion>
some bounds checking might be enough for this…
<dottedmag>
Kind of hard: obvious checks like "bounding box of all non-transparent pixels" is easily defeated by adding a single opaque pixel.
<pq>
mm... maybe Qubes could overwrite the hotspot pixel and make it blink? If it is a concern that hotspot inside the cursor image needs to be known. :-) Or any other additional visual cue.
<emersion>
cursor size must be < 64x64, cursor hotspot must be in cursor bounds?
<DemiMarieObenour[m]>
Perhaps?
<DemiMarieObenour[m]>
In any case this is something better discussed on the Qubes developer mailing list (<qubes-devel@googlegroups.com>)