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
cvmn has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
Moprius has quit [Quit: Konversation terminated!]
duxsco has quit [Quit: duxsco]
wroathe has joined #wayland
ecloud has quit [Ping timeout: 480 seconds]
pushqrdx has joined #wayland
ecloud has joined #wayland
<pushqrdx>
i have a question about wayland, on the archticuture page it says that X decides which client receives input and this data isn't always accurate because an X compositor might decide put things at different locations, and wayland has the advantage that because it also acts as the server it can keep track and figure out correct clients... but isn't that the same thing that an X window manager + compositor can do? or does X server automatically
<pushqrdx>
pick up event receivers bypassing the WM/Compositor?
<pushqrdx>
sorry if the question is too neive, i am still figuring out stuff
wroathe has left #wayland [#wayland]
<fluix>
I don't know about the differences in final outcome, but a Wayland server is indeed an X server + compositor
<fluix>
s/final outcome/usability/
<pushqrdx>
fluix if that's the case then the drawback that X doesn't know which clients should receive input because compositor might be standalone can be eliminated in X if both the compositor and WM were the same piece of software right?
<pushqrdx>
asking to understand the inner workings of both X and WL servers
<pushqrdx>
or more to build a mental overview
<fluix>
sorry I wouldn't be the person to ask, maybe someone else here has a better idea (or a better place to read up on this)
<danieldg>
with normal X, you have <kernel drm> -- X -- wm, clients
<danieldg>
with XWayland, you have <kernel drm> -- compositor -- X -- clients
<danieldg>
input goes through the compositor first, and never gets to X unless an X client is active
<pushqrdx>
danieldg on X who's reposible for taking input from drm and relaying it to clients?
<danieldg>
the X server itself
<danieldg>
(it uses evdev or whatever directly)
<pushqrdx>
yeah but what exactly, like the window manager? when X receives an input how does it know which client is the recepient?
<danieldg>
X has a concept of focus I think? I don't know X.
<danieldg>
without a window manager it's whatever is under the mouse
<danieldg>
with a window manager maybe it's whoever that says
<danieldg>
you can always just not use X with wayland, anyway
<fluix>
I think they're asking about X vs. Wayland internals, not about XWayland
<pushqrdx>
the link i am missing is that on wayland website it states that a drawback of X is that it doesn't know how to propagate input correctly because the compositor might have different representation, so it got me thinking, if on X the window manager and compositor were part of the same software wouldn't that solve that issue... like it looks like an issue that only applies to standalone X compositors
<pushqrdx>
fluix yeah, how data flows generally
<danieldg>
pushqrdx: correct
<danieldg>
although I don't know how data flows on X even under XWayland
<danieldg>
that is, it might still be able to mismatch
<pushqrdx>
danieldg so wayland is pretty much X without network stuff and without the different legacy functionality that was required back when X was conceieved, but the trade off is that a wayland server needs to basically implement all the current X functionality that is scattered around the parts of X + WM + compositor into one piece of software?
<danieldg>
yes. And there's always waypipe if you want network support back.
<pushqrdx>
as far as i understand X wayland is pretty much X without a compositor because wayland acts as its compositor, but also instead of X running on top of kernel, the wayland server acts as it's input/output
<pushqrdx>
Xwayland*
<danieldg>
yeah, that's how I picture it working
<pushqrdx>
but i am correct that when a window manager is running, X doesn't forward input to clients itself instead the window manager receives all input and is responsible for figuring out what client receives it, right?
<danieldg>
no
<danieldg>
because when a window manager is slow to respond input still goes to a client
<danieldg>
... I think
<pushqrdx>
ooh, that's why many WMs do all the grab input stuff?
zebrag has quit [Quit: Konversation terminated!]
<pushqrdx>
for some reason my whole understanding of differences between X and WL servers is stuck on figureing out this detail xD
<danieldg>
you may need to find someone who knows X
<pushqrdx>
for instance compiz can do all kinds of fancy compositor transofrmations and still accurately figure out what clients receive input etc, an example of that is the full screen magnifier, which makes me think that the part on wayland's comparison that says X cannot correctly know what client receives input only applies to cases where compositor is standalone entity
lsd|2 has quit [Ping timeout: 480 seconds]
<pushqrdx>
in case of combined compositor and WMs like compiz it's obviously not an issue i think
<pushqrdx>
but yeah i wish someone who knows X as well as Wayland well enough could help shed some light on this
caveman has joined #wayland
<everfree>
pushqrdx: i believe i can answer your question
<everfree>
i skimmed the scrollback but can you restate it just so i know for sure what im answering
caveman has quit [Ping timeout: 480 seconds]
<pushqrdx>
everfree so i was trying to understand the part on wayland's website page about architecture differences between wl and X, and i came across the part where it says X is responsible for sending input to clients but "The X server doesn't actually know how to do this right" which made me wonder why not, the only reasonable (for me) explanation would be that this only true in case the compositor is a standalone application, and as a compositor it
<pushqrdx>
can transform the output in ways unknown to X and so there's a disconnect there between where things actually are and what the compositor displays
<pushqrdx>
but isn't it the case that for WM+Compositors like compiz, input can be relayed correctly to clients as the window manager knows about any kind of output transformation it did and can basically do exactly what wayland can because the scenegraph is fully visible to compiz just like wayland?
<pushqrdx>
or does X bypass the WM/compositor and do some behind the scenes handling that carries input events to X clients anyways regardless of whether a window manager is running or not
naveenk2 has joined #wayland
<pushqrdx>
when using the word wayland here i mean a wayland server implementation ofc
<everfree>
pushqrdx: your read is basically correct yeah but it's a little funky and I'll give you my best shot at explaining
<everfree>
So if you start an X server with a couple applications but no window manager you'll notice that for one you cant move windows around and for two you may not be able to focus other windows than the first one that has focus. but the one that does have focus is getting input events
<everfree>
so afaik the window manager is responsible for handling app focus but then X delivers events to whatever has that focus
<everfree>
so as you say, if the compositor and window manager are split, then the compositor might apply transformations that the window manager doesnt know about
<everfree>
if they're the same program (as is the case in KDE, compiz, I think gnome?, xfce) then your assumption that this is a non-issue is correct
<everfree>
and if you run a window manager without a compositor this also is not a problem
<everfree>
now in the event that your compositor and window manager are separate standalone programs, this continues to almost never be a problem actually faced by anyone IRL
<everfree>
unless you've purposefully configured your compositor to apply these sorts of transformations
<everfree>
like I _could_ fork picom (popular standalone compositor) and make it do some weird window transformations, but, why would I want to?
<everfree>
one potential answer is, malice. Maybe i want to trick the user into typing some data in one window when in reality they're typing into a different window
<everfree>
into thinking they're typing*
<everfree>
I don't think this is a compelling answer, because there's far easier flaws in X's security model one can exploit to achieve that goal
<everfree>
so generally speaking my personal opinion is this is only ever a problem if your compositor has bugs in it
<everfree>
which can happen! and it can happen in wayland too if your WM/compositor is written incorrectly. But it changes where in the stack those bugs have to occur
<everfree>
my understanding though (and im happy to be corrected if im wrong) is that input events always pass through the window manager in wayland
<everfree>
so basically, having one central process that all the input, window placement, and composition happen in just simplifies debugging these types of issues
<everfree>
whereas in X, my understanding is input events don't go through the window manager to get to the programs
<everfree>
unless your WM takes some approach like capturing all input and relaying them to windows, which can be done, but is not likely to actually be done because it would be a pain and introduce unwanted latency
<everfree>
X's approach has some advantages. A lot of accessibility tools written for X work across every single window manager / compositor combination out there, with every X program, as a result of this. On wayland, these sorts of tools can be written, but they either require at-spi (requires app support, can be spotty) or the module that allows acting as a libinput input devices from userspace (requires
<everfree>
permissions setup), and for many advanced features they require compositor cooperation to provide information/features that do not yet have a standard. There is a lot of reinvention that has to happen for each wayland WM. So it trades one class of problems for another
<everfree>
for now. until development in those areas grows
<pushqrdx>
everfree one example of transformation that is not for malice or bugs is things like compiz's fullscreen magnifier, where you can still use your input while zoomed in, focus other windows etc, but yeah it makes a lot of sense now that you mentioned that WM handles focus while X does relay the input to its destination, that's probably why some window managers do the "input grab" thing whenever they don't want some input to propagate any
<pushqrdx>
further right?
ecloud_ has quit [Ping timeout: 480 seconds]
<everfree>
yeah
<pushqrdx>
everfree and yeah accessibility is a huge drawback for the current status of wayland imo, idk how it is handled on macOS but i think macOS has the best accessibility coverage, every UI element is accessible and can be probed for info, there's even a built-in utility for it
<pushqrdx>
also applications can register for accessibility and get access to all input events, able to filter and manipulate them etc
<everfree>
yeah macOS is pretty much the gold standard in that regard. at-spi is an API that provides the class of features like UI element introspection / direct UI element interaction, and qt and GTK both implement it, but it doesn't hold up in comparison with macOS and is more prone to just not working right
<everfree>
its especially rough trying to use it with browsers. but macOS has the same problem in chrome or firefox. the advantage macOS has there is Safari, since they make it so safari provides just as much information as a native application does
<pushqrdx>
yeah i noticed that, but when on macOS i always use safari anyways, very optimized and works great
<everfree>
although in fairness to wayland here, at-spi problems in particular transcend the X / wayland divide
<everfree>
as at-spi does not go through X / the wayland compositor at all and instead is IPC between applications and accessibility tools over dbus
<pushqrdx>
yeah i think it's more to do with gui toolkits being kinda a mess and not providing proper support for accessibility
<pushqrdx>
at least the UI introspection part i am pretty sure is handled through AppKit on macOS, but granting accessibility permission to apps gives a lot more capabilities to an application than just reading content, for instance i used it to write an app that intercepts mouse wheel events and smoothing them out mimicking a magic mouse
<everfree>
yeah, their accessibility API also allows third party apps to control window positions and stuff like that
<everfree>
Amethyst uses this to provide tiling window manager features on macOS for example
<pushqrdx>
yeah
<everfree>
it's something I think about a lot because I use an advanced cross-platform voice control tool called talon, and theres a lot of things that would make it very hard to bring to wayland fully featured in the way it is on macOS and linux with X11
<pushqrdx>
everfree it would require a wayland server implementation built with a similar API in mind, which is possible but i haven't seen any wayland implementation do that yet
<pushqrdx>
but it should be doable to make something even exactly like macOS's API, minus the gui toolkit introspection because it sucks on qt/gtk/foo
ecloud_ has joined #wayland
rv1sr has joined #wayland
hardening has joined #wayland
priner[m] has left #wayland [#wayland]
tzimmermann has joined #wayland
caveman has joined #wayland
caveman has quit [Quit: caveman]
rgallaispou has joined #wayland
danvet has joined #wayland
jgrulich has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
jmabr has joined #wayland
Azem has joined #wayland
c7s has quit [Ping timeout: 480 seconds]
Robotista has joined #wayland
dcz_ has joined #wayland
Azem has quit [Remote host closed the connection]
Azem has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
___nick___ has joined #wayland
c7s has joined #wayland
Telvana has quit []
Telvana has joined #wayland
rasterman has joined #wayland
___nick___ has quit []
lxsameer has joined #wayland
___nick___ has joined #wayland
andyrtr- has quit []
andyrtr has joined #wayland
ecloud_ has quit [Ping timeout: 480 seconds]
jgrulich has joined #wayland
anarsoul|2 has joined #wayland
anarsoul has quit [Read error: Connection reset by peer]
<pq>
pushqrdx, the "problem" with X11 architecture is that the X11 server, the X11 WM, and the X11 compositor are all three separate components. The WM and the compositor can be built into one process, but the X server doing the input routing is always its own independent actor that merely communicates with everything else.
<pq>
pushqrdx, so the X server does not know that the WM+compositor decided to show a window somewhere else than what the position in X11 protocol is.
<pq>
pushqrdx, however, any X11 client can grab all input and also fake input to any X11 client, so with that it is somewhat possible I believe to mimick input routing in WM+compositor.
<pq>
pushqrdx, but it becomes really chatty fast IPC-wise and adds (random) latency.
eroux has joined #wayland
<pq>
everfree, ^
Hi has joined #wayland
anarsoul|2 has quit [Ping timeout: 480 seconds]
anarsoul has joined #wayland
<pq>
and yes, in Wayland architecture, all of that is supposed to be implemented in the one server process so that there are no alternative truths or problems synchronising the all window information across multiple processes.
<pq>
I say "supposed to", because there are projects that have created an off-process window manager and use IPC to communicate between the server+compositor and WM.
ecloud_ has joined #wayland
* ofourdan
being curious, who does that?
Hi has quit []
<dottedmag>
river does something like this
<ofourdan>
ah, to have an external tiling process
<ofourdan>
interesting…
lsd|2 has joined #wayland
lsd|2|2 has joined #wayland
lsd|2 has quit []
lsd|2|2 has quit []
lsd|2 has joined #wayland
MajorBiscuit has joined #wayland
eroux_ has joined #wayland
eroux has quit [Ping timeout: 480 seconds]
<pq>
ofourdan, I hear it's popular with automotive
EmetSelch has joined #wayland
Azem has quit [Ping timeout: 480 seconds]
EmetSelch has quit []
Azem has joined #wayland
eroc1990 has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #wayland
Azem has quit [Read error: Connection reset by peer]
manuel1985 has joined #wayland
eroux_ has quit [Remote host closed the connection]
<LaserEyess>
question about viewporter, tl;dr trying to help get this to work https://github.com/mpv-player/mpv/pull/10115 and right now the main obstacle is resizing/rescaling
<LaserEyess>
the author is using viewporter for scaling, but the main issue is that viewporter doesn't seem to have a concept of aspect ratio, set_destination() is very coarse and when it resizes you don't necessarily get to choose aspect ratio
<LaserEyess>
this is especially important in maximized (not full screen) windows and tiled windows in e.g. sway
<LaserEyess>
I don't see a way to say "ok, take this buffer and scale it, but put it in the middle of the surface"
<emersion>
you can use subsurfaces for this
<LaserEyess>
nothing needs to be cropped, so I think set_source() is not the right thing here
<LaserEyess>
emersion: so, create a subsurface and scale it to the exact size and place it in the exact right location, basically?
<pq>
yeah, if you need a "background", you have to arrange it yourself in maximized mode.
<LaserEyess>
the "background" just needs to be black
<pq>
LaserEyess, I know. It's still a background. Only fullscreen window state has an implicit background.
<pq>
IIRC
<LaserEyess>
honestly, I'm not convinced this is the way to go vs vaapi post processing
<pq>
What do you mean?
<LaserEyess>
in this case instead of using viewporter you would just decode the vaapi frame, scale it, and then send it via dmabuf
<LaserEyess>
scale it with vaapi scaling*
<pq>
you could, and VAAPI uses either GPU or something else to essentially do a full-frame copy. If you can afford such copy, cool.
<LaserEyess>
I don't think that would be any less efficient than viewporter since both would be hardware scaling, and vaapi scaling is sort of designed for video scaling
<pq>
viewported OTOH has the opportunity to off-load that scaling to the KMS hardware, which is not a copy.
<pq>
*viewporter
<LaserEyess>
hmm
<pq>
whether that off-loading actually works, depends
<LaserEyess>
so without the solid-buffer protocol, I wonder how it is possible to make blackbars then
<LaserEyess>
I see your point about copying the buffer, I guess it is less efficient
<pq>
wl_shm 1x1 buffer, stretched with viewporter
<LaserEyess>
and then the video subsurface on top?
<LaserEyess>
hmmm
<pq>
that should work
<LaserEyess>
do you mind if I pasted some of this in that PR linked?
<pq>
I don't mind
<LaserEyess>
ok, thanks, just want to keep track of it
<pq>
it may not be the most optimal for KMS off-loading purposes, but that gets tricky
<LaserEyess>
I wonder if the vavpp copy would be worth it in that case
<LaserEyess>
in theory that also uses fixed function stuff and should be as efficient as possible
<LaserEyess>
though, still a copy I guess if the buffer needs to then be passed to the compositor
<emersion>
also vaapi doesn't support negotiating modifiers very well
<pq>
the PP step is a copy in itself, if it's a mem2mem operation
<LaserEyess>
then there would be offering both options, which sounds easy when you're not the one writing the code to do it
zebrag has joined #wayland
<pq>
passing a dmabuf buffer to a compositor is not a copy
<LaserEyess>
yes I know
<LaserEyess>
I meant there will be a copy because of the post processing, before the buffer is passed
<LaserEyess>
which is one more than 0 copies
<LaserEyess>
emersion: what do you mean? does vaapi scaling require a specific format?
<emersion>
scanning out vaapi's buffer requires specific modifiers
<emersion>
vaapi may pick one which works "by chance"
<LaserEyess>
you can't tell it which ones to use?
<LaserEyess>
I think I'm confusing modifiers and formats here, I barely know enough about this to even have this conversation to be honest
<pq>
are VAAPI PP hardware blocks actually mem2mem though? I guess that depends on what hardware and drivers you actually have at hand.
<pq>
if VAAPI PP can do the scaling + bars without a full-frame copy, that might quite good
<emersion>
with VASurfaceAttribDRMFormatModifiers, you can
<emersion>
but it's a bit shaky
<LaserEyess>
pq: I don't know, I can probably test it
<LaserEyess>
in my experience intel seems to be a lot better here
<pq>
LaserEyess, might, I would assume it depends on the hardware at hand.
agd5f has joined #wayland
<pq>
*mind
<pq>
and this work might be aimed at some embedded platforms foremost, I'm not sure
<pq>
or I wouldn't be surprised if it was, since those usually are keen on optimizations
<LaserEyess>
this is for mpv, so mostly desktop stuf, but there's definitely interest in getting low power optimizations on SoCs
<LaserEyess>
right now the goal is for it to Just Werk™, which is does outside of the resizing stuff
<LaserEyess>
well, on weston and wlroots at least, KDE/GNOME are broken and need a fallback path for multiplane formats
<LaserEyess>
though, fundamentally I have no idea if the way it's set up now prevents further optimizations...
<ifreund>
I'm using the 1x1 buffer + viewporter trick for solid color surface in my ext-session-lock client. We noticed that using a 1x3 buffer with 3 differently colored pixels and selecting a single pixel with set_source didn't give us a solid color but rather a gradient
<ifreund>
We're now using a 1x3 shm and 3 separate 1x1 buffers, I assume that the gradient is indicative of a bug/rounding issue in the wlroots viewporter implementation though...
<ifreund>
emersion: it's easy enough to work around for our use case but I can open a wlroots issue if you think it's worth looking into
<emersion>
what are we looking at here?
<ifreund>
the picture is a screenshot of two outputs each fully covered by a surface
<emersion>
sure, but how are the fullscreen surfaces set up?
<emersion>
and how are they supposed to look like?
<ifreund>
it's supposed to all be purple
<ifreund>
the shm is a blue pixel, a purple pixel, and a red pixel in that order
<ifreund>
the wl_buffer is also 1x3, and set_source the center purple pixel only
<emersion>
it looks better with a gradient IMHO
<ifreund>
heh :D
* emersion
closes issue as "not a bug"
<emersion>
yeah, feel free to open an issue, with details and ideally reproducer
<ifreund>
new use case for wl_viewport, cheap gradients! Take that solid buffer proposal
<emersion>
WAYLAND_DEBUG logs would be useful as well
<emersion>
ahah
<ifreund>
sure, I'll throw something together
<leon-p>
not sure if it's of any interest, but we also tried setting a source smaller than a buffer-pixel in the middle, which resultet in a smaller part of the gradient being displayed
<emersion>
fun stuff
<emersion>
i'm not even sure that's a bug or not tbh
<emersion>
maybe our GL params aren't quite right though
<ifreund>
set source is described as "cropping" which makes me think that the data outside of the source area shouldn't affect the result