ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
melonai5 has quit []
melonai5 has joined #wayland
melonai5 has quit []
melonai5 has joined #wayland
garnacho_ has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
garnacho_ is now known as garnacho
guru_ has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Guru_DE has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
bindu has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
garnacho has joined #wayland
ahartmetz has quit [Quit: Konversation terminated!]
garnacho has quit [Ping timeout: 480 seconds]
melonai5 is now known as melonai
Ojus1_ has joined #wayland
kts has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
silverpower has quit [Read error: Connection reset by peer]
julio7359 has joined #wayland
silverpower has joined #wayland
privacy has quit [Ping timeout: 480 seconds]
kts has joined #wayland
mxz__ has joined #wayland
kts_ has joined #wayland
mxz_ has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
mxz__ is now known as mxz
kts_ has quit []
kts has joined #wayland
nerdopolis_ has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
Company has joined #wayland
kts has quit [Quit: Konversation terminated!]
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
Ojus1_ has quit [Remote host closed the connection]
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
mxz_ has joined #wayland
Kerr has joined #wayland
leon-anavi has joined #wayland
Guru_DE has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
mclasen has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
feaneron has joined #wayland
guru__ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
Guru_DE has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
mclasen has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
rv1sr has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
sima has joined #wayland
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
mart has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
Guru_DE has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
Guru_DE has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
guru__ has joined #wayland
mvlad has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
kts has joined #wayland
garnacho has joined #wayland
iomari891 has joined #wayland
kts has quit [Quit: Konversation terminated!]
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
Ojus1_ has joined #wayland
Ojus1_ has quit []
feaneron has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru__ has quit []
Guru_DE has joined #wayland
guru_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
kts has joined #wayland
rv1sr has quit []
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
Brainium has joined #wayland
nerdopolis has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
<JEEB>
(finally remembered the correct document name)
fmuellner has joined #wayland
<vaxry>
is there a technical reason why we can't set an event loop timer's timeout to less than 1ms?
<vaxry>
what if I want 500µs?
<pq>
vaxry, just the libwayland-server API. Use your own timerfd.
<vaxry>
huh, that makes sense. Right. Thanks bae
<pq>
or, an actual event loop library
<pq>
JEEB, thanks, that looks useful.
<JEEB>
pq: and even this already has three methods for different use cases :D
<JEEB>
although that is mostly relating to whether round-trip is required tone mapping wise
narodnik has quit [Quit: WeeChat 4.2.1]
<JEEB>
(and various other details which I conveinently did not mention :) )
<JEEB>
*conveniently
<zamundaaa[m]>
Having a standardized conversion algorithm doesn't really help with the problem imo
<JEEB>
yea, this is just probably useful in telling people what various bits there are in the process
<pq>
no, but it's a starting point, better than from scratch
<Company>
it's at least better than nothing
<zamundaaa[m]>
Company: no, I'm saying it's not
<zamundaaa[m]>
It's useful to have, on its own, but it's not useful for switching between app conversion and compositor conversion
<Company>
no, for that you need actual code
<Company>
and apps and compositors to agree on things
<zamundaaa[m]>
No, I'm saying that flat out does not work
<pq>
I don't think such agreement will ever happen.
<Company>
then people will see flickering
<zamundaaa[m]>
For example, the user can configure how SDR content is mapped to HDR displays in KWin. Even if you'd communicate the parameters and algorithm to the app, moving the window between screens will have sudden changes in appearance
<zamundaaa[m]>
That configuration is per screen, to be clear
<Company>
sure, but you have to do that or stuff will flicker
<zamundaaa[m]>
You don't have to do that stuff
<zamundaaa[m]>
You either offload something, always, or you don't offload it, ever
<Company>
that's not how things work though
<pq>
You just have to not switch between app and compositor conversion.
<zamundaaa[m]>
It's the only way things can work without flicker
<Company>
so how do you imagine direct scanout is gonna work?
<pq>
bby choosing compositor conversion always
<pq>
well, you can also choose app conversion always, and still hit direct scanout, but then you do a re-rendering in the app
<Company>
that's not direct scanout then?
<pq>
yes, it is direct scanout
<pq>
The definition of direct scanout is scanning out a client buffer.
<zamundaaa[m]>
Company: direct scanout just means that the compositor doesn't do an extra copy
<zamundaaa[m]>
I think you mean "zero copy" or similar
<pq>
It may not be the same as zero-copy.
<Company>
I mean, the relevant question for me atm is the GTK graphics offload
<Company>
which dynamically switches between subsurface and GTK's compositing
<JEEB>
(for whatever reason 2023-09 H.273 is still not freely available)
<swick[m]>
I'm with Company on this one. there just isn't a way to "always" offload something from a toolkit perspective because at any point the render nodes can change so it becomes impossible to offload
<swick[m]>
there needs to be some kind of standardization in the long run
<zamundaaa[m]>
As I already wrote, that is completely impossible
<swick[m]>
you keep saying things like that like it's the absolute truth but it's really not
<zamundaaa[m]>
Like, not just not great or anything, but it's literally not doable with multi monitor and user configuration
<pq>
not the first thing that toolkits will need to re-think for Wayland
<swick[m]>
there is no re-thinking here, that's just not how any of them work and will work
<zamundaaa[m]>
swick: then please explain to me how the compositor can ensure a smooth transition between an app compositing SDR content from a display with SDR gamut wideness 0% to a display with SDR gamut wideness 50%
<pq>
or maybe changing the "render nodes" in a toolkit does warrant flicker?
mvlad has joined #wayland
<Company>
zamundaaa[m]: that's not the goal - the goal is that the app can do the same steps that the compositor does
<pq>
nothing worked how Wayland works, until things were re-written for the better
<Company>
note the order: the app can do what the compositor does, not the compositor can do whatever the app wants
<zamundaaa[m]>
Company: the app can't do the same steps as the compositor. It can't create two images for two screens
<swick[m]>
that's not the point
<pq>
Company, that literally will never happen, because it would require changing Wayland from descriptive to prescriptive.
<Company>
no, but it can create one of the two images
<Company>
pq: "can", not "is forced to"
<swick[m]>
pq: it doesn't. the compositor just has to tell the app what it is going to do
<mclasen>
the 2 monitors are a distraction here
<pq>
not a difference here, it's a spec that will tie the hands of compositors
<Company>
I mean, the compositor gets pixels from the app, then transforms the pixels somehow and then it ends up on screen
<swick[m]>
pq: the app doesn't tell the compositor what to do, the compositor tells the client what it will do, and the client can then adjust to that, or not
<pq>
would a compositor be sending SPIRV shaders to apps?
<Company>
if the app knows about that transform, it can avoid problems
<zamundaaa[m]>
mclasen: no, they're not
<zamundaaa[m]>
I don't want flicker when you move a window from one screen to the other
<swick[m]>
pq: the compositor can also say "custom stuff" at which point the client can't adjust to the compositor, and can stop offloading
<mclasen>
I don't want that either, but that is not the case that will have toolkits temporily switch from offloading to rendering
<swick[m]>
pq: there is no need to describe every possible scenario, just the common ones so that offloading might work
<Company>
zamundaaa[m]: I don't get why that is a problem - you get pixels from the app and do stuff to them
<zamundaaa[m]>
Company: if the app applies the "same" conversion steps as the compositor, but the conversion steps differ between two screens, then there will be flicker if the app does SDR conversions with compositor-given parameters
<Company>
zamundaaa[m]: and what you want to do is tell the app as much as possible to minimize the stuff you need to do
<pq>
swick[m], doesn't the option of "custom" thwart the whole idea?
<Company>
zamundaaa[m]: then the compositor would tell the app and the app could choose the best format to avoid that
<swick[m]>
no? then the apps can make an informed decision if they want to offload something
<pq>
swick[m], sounds like the KMS color pipeline UAPI is coming to Wayland here.
<swick[m]>
apps could also not support one of the strategies the compositor is using and then not offload something
<swick[m]>
I think it will be higher level
<Company>
zamundaaa[m]: the goal here isn't to force apps to behave a certain way or to force compositors to behave a certain way - the goal is to have both cooperate to get the best result
<zamundaaa[m]>
Company: I'm telling you there is no way to cooperate. Either the app does one fixed algorithm for conversion, or the compositor does the conversion. There's no switching between them
<zamundaaa[m]>
Or changing the app's algorithm to match what the compositor does
<pq>
a noble goal, pardon my pessimism
<Company>
the compositor and the app both have a bunch of buffers that need compositing - and they both use the same hardware to do that
<Company>
so as long as they cooperate, they can switch around who does which part of that
<pq>
A committee defines a few standard algorithms, then compositors decide if they implement any of them, applications decide if they implement any of them, end users decide which one the compositor uses, and the app can check if it won the lottery. Ok, it's not zero probability, if the committee happens to find generally accepted algorithms.
<zamundaaa[m]>
Company: the compositor is not doing one single algorithm with one single fixed set of parameters
<Company>
pq: yeah, and because we cooperate, the app and compositor know which ones the other implements (most likely the same ones)
<pq>
but yes, so far an app can only provide one rendering per window, so it can match only one output at a time. For any other output, the compositor will necessarily do something more.
<Company>
yeah, and that's fine
guru_ has joined #wayland
<pq>
as long as the app does not switch *outputs*, it won't flicker, though
<Company>
the compositor will decide how it prefers to handle that case and tell the app
<Company>
that's a corner case though, the main problem is that we want to offload the video stream while you watch but when you move the mouse and the app wants to composite controls on top, it can do that without any flicker
<pq>
right
<Company>
same problem when the compositor wants to display a notification or an alt-tab overlay on top of a fullscreen window
<pq>
so the client picks one output to render for, and then it sticks to that to avoid flicker when it switches between compositor and app *blending*.
<pq>
Company, I don't see how that would be the same problem at all.
<pq>
A compositor has a prescriptive rendering API (KMS and GL/Vulkan). A client has only a descriptive API (Wayland).
feaneron has joined #wayland
<swick[m]>
it's also possible to use the same processing on all monitors even when they have different capabilities
guru__ has quit [Ping timeout: 480 seconds]
<swick[m]>
all that changes are parameters of the display
<swick[m]>
and that might even work for all the weird cases
<Company>
pq: the problem is ultimately the same one - switching from 1 buffer using direct scanout to 2 buffers - in one case that 2nd buffer is provided by the same app and in the other it's provided by a different app or the compositor itself
<swick[m]>
I'm not 100% sure this will work, but I'm equally not as convinced as zamundaaa that this won't work
<mclasen>
the client renders using gl/vulkan as well
<pq>
Company, the starting point is half the same yes. The tools you have at your disposal not.
<zamundaaa[m]>
Company why would you need to switch to compositing controls yourself? Why can't it just be on a subsurface?
<davidre>
I dont see the problem if a notification appears you have to do compositing since you need to display two different buffers
<mclasen>
zamundaaa[m]: rounded corners
<davidre>
I am a bit confused tbh so ignore me
<Company>
zamundaaa[m]: it depends on the controls - but you're at least gonna switch from direct scanout to something else
<zamundaaa[m]>
direct scanout vs not doesn't matter
<davidre>
Why does gtk care if the compositor does direct scanout or not
<davidre>
If you have two different things something has two do compositing
<Company>
davidre: because it needs to provide buffer suitable for direct scanout
<zamundaaa[m]>
Company: direct scanout isn't some different way of operation, it's just a different way to show the exact same thing
<davidre>
if the client composits video and controls the compositor can do direct scanout maybe
<zamundaaa[m]>
whether or not you allocate the buffer with a different modifier or scanout flag will not affect how it looks
<davidre>
if it doesnt the compositor will composit
<davidre>
in the end it's the same amount of work
<davidre>
just somewhere else in the stack
<Company>
davidre: right - as long as both parts of the stack would do the same work
<Company>
davidre: if they'd do things different, then you can get flicker
<zamundaaa[m]>
Company: "both parts of the stack" there is only one part, it's the compositor
<Company>
zamundaaa[m]: not if the app does the compositing
<zamundaaa[m]>
Yes, but that's the thing you shouldn't do
<davidre>
Yes but you would not switch parameters of your buffer on the fly
<davidre>
or just choose the best tool for your use case
<zamundaaa[m]>
mclasen: rounded corners is a good point, but that really just means that we need wp-rounded-corners-v1 :)
* mclasen
watches the folks who invented scanout flags and tranches tell us never to look at them
<zamundaaa[m]>
mclasen: that's not at all what this discussion is about
<Company>
zamundaaa[m]: people can use all sort of weird effects inside GTK that subsurfaces can't do - usually they don't (when maximized), but sometimes they do
<Company>
rounded corners is the obvious example for non-maximized apps ofc
<mclasen>
zamundaaa[m]: you just said to not switch parameters on the fly
<zamundaaa[m]>
mclasen: color management parameters don't have anything to do with modifiers or scanout flags, and only very little with buffer formats
fmuellner has quit []
<mclasen>
I thought we were talking about direct scanout
* mclasen
lets the color nerds have it and goes to do something else
fmuellner has joined #wayland
<Company>
we were talking about color management
<Company>
which involves direct scanout, because - same problem - the colorspaces supported by direct scanout are smaller than those a compositor can handle
<zamundaaa[m]>
direct scanout is not the same problem as clients offloading content
<pq>
If toolkit API has been designed so that all effects and stuff are free to use any time on anything, then yeah, that does make off-loading very hard. It has been intentionally designed to be app-composited. But then, only very few types of scenegraph objects should even be eligible for off-loading.
<zamundaaa[m]>
The compositor programs the KMS color pipeline
<zamundaaa[m]>
the client doesn't program the compositor color pipeline
<swick[m]>
yeah, direct scanout vs compositor compositing doesn't matter
<Company>
pq: in the GTK API you need to explicitly mark content for offloading, but GTK will then only offload if it's suitable
kts has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
<Company>
pq: which can change on a frame-by-frame basis
<zamundaaa[m]>
Company: how many applications use these effects that don't work with subsurfaces?
<pq>
Company, why wouldn't that marking also forbid effects that cannot be off-loaded?
<swick[m]>
zamundaaa: all of them basically because rounded corners
<Company>
pq: because GTK doesn't forbid things
<pq>
yes, why?
<zamundaaa[m]>
swick: Yeah, but we could offload that one to the compositor
<pq>
old-school X11: off-load every widget! modern X11 / old Wayland: off-load nothing! mor recent Wayland: off-load... something?
<swick[m]>
zamundaaa: that's just moving an entire rendering api to wayland
<swick[m]>
it is kind of stupid tbh
<zamundaaa[m]>
Company: If you had a protocol for corner rounding, couldn't you make the app opt in or opt out of those effects?
<Company>
pq: that would be really hard to communicate - when setting up your widgets, you don't know what effects they will ultimately use
<zamundaaa[m]>
zamundaaa[m]: as in, app-wide opt in/out
<Company>
zamundaaa[m]: themes can decide to round corners
<swick[m]>
zamundaaa: let's say you use some controls that use a popover and that gets on the content
<swick[m]>
and you're done
<zamundaaa[m]>
why would you be done? You'd put it on a subsurface
<swick[m]>
no you wouldn't
<mclasen>
fractional scaling makes subsurfaces useless
<zamundaaa[m]>
mclasen: that is a problem that can and should be solved
<swick[m]>
at that point you'd have to put literally everything on subsurfaces
<swick[m]>
every popover, every whatever
<swick[m]>
and then maybe you want some specific blending behavior
<swick[m]>
and you're done as well
<swick[m]>
or specific subpixel alignment, and you're done as well
<swick[m]>
that idea is much more ridiculous than trying to match the color conversion of the compositor
<zamundaaa[m]>
You wouldn't need to put every individual thing into a subsurface, only all things below, and all things above the thing you're offloading to the compositor
<Company>
that still assumes that the thing itself is offloadable into a subsurface
<mclasen>
we do that, to some degree
<mclasen>
but putting the offloaded subsurface below the main surface
guru_ has quit [Ping timeout: 480 seconds]
<Company>
and GTK allows you to write css that applies a css filter to stuff
<zamundaaa[m]>
mclasen: then this sounds quite doable
<Company>
so you can turn stuff black-and-white if you want to
<Company>
or make parts semi-opaque or whatever fun effect you want
<Company>
and that's independent of the offloading
<Company>
looking at the code that people have written, not offloading is a way too common case
<Company>
like, Adwaita used to (still does?) draw an outline shadow over the main window to make the window border appear thicker
<Company>
which of course it also drew over the video in the video player
mclasen has quit [Remote host closed the connection]
kts has joined #wayland
<Company>
but that's basically the thing I want to support - make things work fine always, and make optimizations require extra work by the app developer who cares
<Company>
because 95% of app devs don't care - but the 5% are the people who write Gimp and Inkscape, and they care about proper color management
<Company>
same for video players - there's gonna be 2 or 3 video players where the devs will make sure offloading works
mxz_ has quit [Remote host closed the connection]
mxz_ has joined #wayland
mxz_ has quit [Remote host closed the connection]
mxz_ has joined #wayland
Zeroine has quit [Remote host closed the connection]
Zeroine has joined #wayland
mclasen has joined #wayland
kts has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
guru_ has joined #wayland
Fxzxmic has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
JayBeeFOSS has quit [Remote host closed the connection]
JayBeeFOSS has joined #wayland
guru__ has joined #wayland
<bnason>
So I'm sure this is possible, but I have 0 idea of what would be involved. I want to create a small app that just detects the mouse hitting the edges/corners of the screens. How hard would that be?
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
JayBeeFOSS has quit [Remote host closed the connection]
<pq>
bnason, very hard. Wayland does not generally allow spying on the pointer motion, nor to place window at the edges to catch the pointer.
guru_ has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
JayBeeFOSS has joined #wayland
kts has joined #wayland
<bnason>
What about creating full screen windows that are transparent (visually and to mouse/cursor events)?
<pq>
you can try that, but it would just behave like a normal window: other windows could be on top, and then it won't get pointer motion
<bnason>
Isn't there a protocol for layering? So I can create a super top level layer? (I'm not super familiar with all the internals)
<pq>
if you make it truly fullscreen, as in the fullscreen mode, you cannot make it transparent because you get black background. You could do maximized, but then it won't necessarily cover full screen.
Fxzxmic has quit [Remote host closed the connection]
<pq>
bnason, not a generic one, no. There is a wlr extension that some compositors support.
<bnason>
I'm trying to figure out a working solution for my multi pc setup. I used to use Barrier, but after switching my main pc to wayland that no longer works. Right now I'm RKVM, which works great but requires key presses to switch between PCs. My idea was to create a wayland/x companion app that detects when I hit the edges of the screen and auto
<bnason>
switches for me.
iomari891 has joined #wayland
Fxzxmic has joined #wayland
<pq>
bnason, that kind of feature cannot be an independent app. I needs to integrate with the compositor somehow.
<bnason>
ah ok thanks
<pq>
*it needs to
<davidre>
there is a stack in the works for that iwth inputcapture portal, remote deskto portal and libei
<davidre>
it's implemented in input-leap and gnome
<davidre>
I am doing a plasma impl as we speak
<pq>
cool!
<bnason>
Yea, I'm using labwc so can't use that yet unfortunately. but it seems like if that support is added, input-leap would just work so my solution wouldn't even be needed. (though I do like how rkvm can be used in the console before my WM)
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
<bnason>
davidre, can you point me to that input capture protocol?
<bnason>
ah ok so technically that is outside wayland
bindu has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
bnason: you could in theory place overlay windows on the screen edges with layer shell to do what you want
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
<bnason>
wlr layer shell?
Fxzxmic has quit [Remote host closed the connection]
<zamundaaa[m]>
yes
Fxzxmic has joined #wayland
mart has quit [Quit: Konversation terminated!]
lsd|2 has joined #wayland
privacy has joined #wayland
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Remote host closed the connection]
<bnason>
thanks ill look into that
Fxzxmic has joined #wayland
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
guru_ has joined #wayland
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
narodnik has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
qyliss has quit [Quit: bye]
junaid has quit [Remote host closed the connection]
qyliss has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
riteo has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
paulk-bis has quit [Read error: Connection reset by peer]
paulk has joined #wayland
kts has quit [Remote host closed the connection]
guru__ has joined #wayland
graywolf has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
<graywolf>
Hello, I have laptop A running X11, and laptop B running Wayland (ubuntu, gnome in case it matters). I would like to be able to view windows from B on A. If B had X11, I would just use X11 forwarding over ssh, what can I use for wayland?
<MrCooper>
SSH X forwarding works in a Wayland session
<MrCooper>
(it's a real mystery why many people assume it doesn't :)
<MrCooper>
for native Wayland apps, waypipe works mostly the same
<graywolf>
Ah, ok, I will give it a try (I assumed it will not work).
<graywolf>
I found waypipe but I assumed it expectd wayland on both ends
<graywolf>
Thank you :)
<MrCooper>
doesn't matter what kind of session the remote machine uses, just what the app you run via SSH uses
<graywolf>
Oh... I am dumb. Right, the remote apps talks with my local X11, so it does not matter at all there is wayland there
<Ermine>
you can use cage with waypipe, since cage has x11 backend (as any other wlroots-based compositor)
soreau has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Remote host closed the connection]
Narrat has joined #wayland
soreau has joined #wayland
graywolf has quit [Quit: WeeChat 4.0.4]
<Consolatis>
bnason: > How hard would that be?
<Consolatis>
really simple, maybe 10 lines of python with gtk and layershell bindings
mvlad has quit [Remote host closed the connection]
kts has joined #wayland
fmuellner has quit [Remote host closed the connection]
fmuellner has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
fmuellner has quit []
kts has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
Brainium has quit []
lkn0 has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
privacy has quit [Quit: Leaving]
privacy has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
lsd|2 has joined #wayland
Narrat has quit []
siak has joined #wayland
guru__ has joined #wayland
Brainium has joined #wayland
<siak>
I am on Manjaro KDE and have recently switched to Wayland. Now I see some artifacts here and there like block traces of mouse icon and apps pane not rolling up.
roussinm has quit []
<siak>
Oh it is not Wayland suopport. But I am a developer so...
guru_ has quit [Ping timeout: 480 seconds]
kchibisov_ is now known as kchibisov
Guest103 has quit [Remote host closed the connection]
zvarde1988303206779191685 has quit [Ping timeout: 480 seconds]
<siak>
In what layer Wayland resided logically?
<siak>
resides*
<kennylevinsen>
siak: it's a protocol
<siak>
Between Windows manager and graphics driver?
<kennylevinsen>
no, between graphical applications and the display server
<kennylevinsen>
If you use KDE, your display server is kwin
<siak>
So there is still a display server? It resides between graphics driver and apps?
<siak>
DRI and apps
<kennylevinsen>
In Wayland there is *only* a display server. It takes roles similar to an X display server, window manager and compositor all in one
<kennylevinsen>
No that's not the task of a display server
<kennylevinsen>
For rendering, apps talk to your graphics driver and render devices directly. But they can't put stuff on screen or receive input that way.
<kennylevinsen>
The display server is the KMS/DRM master, controlling outputs (displays) ND inputs (keyboard/mice/etc.). It routes input to the focused application, and puts the rendered content supplied by applications on screen.
<kennylevinsen>
s/ND/and/ - dumb phone
<kennylevinsen>
So from a graphics perspective, the display server takes *already rendered content* from applications and stuffs it on screen, possibly transforming it in the process (scale, color, blending).
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
<siak>
How can an app have access to render devices but not be able to put stuff on screen? And why should it be this way?
<kennylevinsen>
that's how the GPU drivers work. Only one process (the master) has access to the outputs through the primary DRM device, while the render device can be used arbitrarily.
<zamundaaa[m]>
siak: rendering and displaying are simply separate things
<zamundaaa[m]>
On many devices they're even entirely different devices
<siak>
Yes I can understand that. Just did not know that there are different access level to them.
<kennylevinsen>
Clients also have no idea what's supposed to be on screen - they don't even know what output they're on, much less how colors or scale should be adjusted, or how to blend with other transparent content that they cannot access
<kennylevinsen>
and updating the screen is done by atomically swapping the whole output buffer out with a new one - not by drawing - so the process updating needs to know how everything needs to look
<siak>
On Wayland we don't care about render devices? Apps give rendered image to display server?
<siak>
Is the window manager the same thing as display server?
feaneron has quit [Quit: feaneron]
<kennylevinsen>
apps give rendered buffers yes
<kennylevinsen>
in Wayland, window management is part of the display server's tasks. We also often call the whole thing a "Wayland compositor", but it's still all those things in one.
guru__ has joined #wayland
<siak>
WHat other tasks it has?
rv1sr has quit []
guru_ has quit [Ping timeout: 480 seconds]
privacy has quit [Ping timeout: 480 seconds]
<siak>
And btw problems I see in Wayland on KDW are actuallt kwin bugs?
<kennylevinsen>
generally yes which is why this channel is not for end-user support, only for protocol, server or client development
<siak>
Are the apps aware of Wayland or they just talk to kwin?
<zamundaaa[m]>
Wayland is the API / language apps use to talk to KWin
<siak>
So all my apps knew Wayland? That is a surprise.
<kennylevinsen>
Most will, the few that do not go through the Xwayland compat layer
<siak>
Aha. Thanks for the info. I understand it way better.