ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
chiku has joined #wayland
V has quit [Remote host closed the connection]
Sid127 has quit [Ping timeout: 480 seconds]
V has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
<orowith2os[m]>
Inochi2D (libsoba, specifically) would like to make use of it
V has quit [Remote host closed the connection]
<orowith2os[m]>
it would need to be able to shade it to the UI color, though
<orowith2os[m]>
basically, it would need to be more like what Windows and macOS provide
<orowith2os[m]>
for an end result, not the API, if it's a security concern
V has joined #wayland
<orowith2os[m]>
I was recommended to look at the macOS impl for reference, apparently it's pretty flexible
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
kts has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
garnacho has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
<soreau>
V: please fix your connection to avoid rejoining the channel so often
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
V has joined #wayland
V has quit [Remote host closed the connection]
kts has joined #wayland
V has joined #wayland
<soreau>
I really don't understand the logic behind clients that want to specify their own blur regions. The only argument that holds merit is the fact that most users don't want blurring behind drop shadows, a problem complicated by CSD and rounded corners. The compositor blur shader could detect a special ratio of color elements the client sets for shadows, normalize them and don't apply blur for that pixel
V has quit [Remote host closed the connection]
<soreau>
I'm not sure if setting negative values can carry through to the shader, but that might be convenient
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
chiku has quit []
Sid127 has joined #wayland
glennk has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
kts has joined #wayland
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
rasterman has joined #wayland
V has joined #wayland
V has quit [Remote host closed the connection]
V has joined #wayland
V has quit [Remote host closed the connection]
sewn has joined #wayland
V has joined #wayland
kts has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
MrCooper has quit [Remote host closed the connection]
<orowith2os[m]>
soreau: maybe it would be easier if the protocol worked with wl_surfaces instead?
<orowith2os[m]>
I'm not sure if "all we need" would be entire appropriate to use here, as it might be downputting the amount of work needed to get this going
V has joined #wayland
V has quit [Remote host closed the connection]
<orowith2os[m]>
maybe a shadow protocol would be useful for this too, so that apps can get shadows (also means the user decides here)?
V has joined #wayland
V has quit [Remote host closed the connection]
<orowith2os[m]>
I know KDE also has that, I just don't know if Mutter can, or would be willing to, implement that
V has joined #wayland
V has quit [Remote host closed the connection]
iomari891 has quit [Ping timeout: 480 seconds]
V has joined #wayland
V has quit [Remote host closed the connection]
<orowith2os[m]>
jadahl: curious to see if you'd be able to comment...?
<soreau>
but for the compositor to not blur shadows.. I guess you could take the input region, minus a few pixels for corner radius and assume the decoration border is opaque
<soreau>
for clients to start spewing about what it thinks should be blurred, this is not useful from compositor POV IMHO
pavlushka has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
kts has joined #wayland
<zamundaaa[m]>
soreau: assuming that the input region is to be blurred is pretty bad
<zamundaaa[m]>
You have no idea what resolution the input region is in, and it can extend past the visible surface
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
<soreau>
zamundaaa[m]: I use 'input region' term loosely as xdg shell configure bounds
<zamundaaa[m]>
That doesn't work either
<zamundaaa[m]>
This isn't just about xdg shell, and rounded corners exist
<soreau>
anyway, even if you had such a protocol, some compositors plain won't support it because they don't want to or don't even have a blur feature (pixman?)
<zamundaaa[m]>
Sure. What exactly is the problem with that?
<soreau>
it's kinda like saying 'the window shall burn exactly as the client specifies'
<soreau>
it's just kinda ridiculous to think the client knows better than the compositor in this case
coldfeet has quit [Quit: Lost terminal]
<zamundaaa[m]>
Not in any way or form, no
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
<soreau>
blur is candy, not a well-defined effect
<zamundaaa[m]>
So?
<soreau>
so there shouldn't be any protocol for it
<zamundaaa[m]>
That's not an argument for anything
<zamundaaa[m]>
We don't even have a definition for how blending is done. Will you next argue that transparency should be forbidden because there's no exact definition for it?
<soreau>
not forbidden, but to-be-handled-by-$compositor
<soreau>
not by some buggy client
<zamundaaa[m]>
Transparency isn't done by the compositor
<soreau>
anyway, this is fine for a compositor-specific protocol
<soreau>
but doesn't have a place in upstream protocols
<zamundaaa[m]>
That's not for you to decide
yrlf has quit [Ping timeout: 480 seconds]
yrlf has joined #wayland
<soreau>
zamundaaa[m]: what are your particular use cases?
<soreau>
is it so apps can turn blur on and off in app settings? not blur the shadows? something more?
<zamundaaa[m]>
In Konsole, it's so that its profiles can turn it on or off, yes
<zamundaaa[m]>
In the panels, it's for specifying the actual region though. Because rounded corners, and because the window is bigger than the visible bits in some cases
<soreau>
so the panel you're describing has rounded corners with drop shadows?
<zamundaaa[m]>
Yes
<soreau>
in addition to being semi-transparent in the 'main area'? (trying to avoid input-region term)
<zamundaaa[m]>
Yes
<soreau>
the problem I see happening is that the compositor goes out of its way to honor the region and the client gets it wrong, so you end up with something really ugly on the screen
<zamundaaa[m]>
Umm no
<zamundaaa[m]>
That's about as much a problem as the client rendering into the parts of its surface that should be transparent
feaneron has quit [Ping timeout: 480 seconds]
<soreau>
you mean rendering transparent where the opaque region covers?
<soreau>
hm, it seems gtk3 only puts drop shadows on focused windows(?)
<orowith2os[m]>
Discord on Wayland has a shadow when it's not focused on my end
<orowith2os[m]>
dconf-editor as well
<soreau>
must be a theme thing
fmuellner has quit []
<soreau>
but if you want a protocol that only allows toggling blur and rounded corner definitions, the only communication you would need is a request to toggle and another to set corner radiu
<orowith2os[m]>
not sure, I'm not using any sort of gtk3 themes
<soreau>
+s
<soreau>
the compositor can figure it out from there
<orowith2os[m]>
interesting, I guess. I wonder how Windows handles with Mica applications that want a fully transparent section of the window?
<soreau>
just.. render alpha = 0 there?
<zamundaaa[m]>
Alpha=0 doesn't mean you don't want it blurred
<soreau>
what?
<soreau>
you want a blurred area that is also fully transparent?
<soreau>
why would you want this?
<zamundaaa[m]>
Why not?
<soreau>
because it's ridiculous
<zamundaaa[m]>
Why?
<orowith2os[m]>
you'd want a blurred window, but a fully transparent window within it
<orowith2os[m]>
er, area, not window
<orowith2os[m]>
but a blurred, fully transparent background would also do it
<soreau>
zamundaaa[m]: I just don't think it makes sense in terms of reality
<soreau>
if there's a hole in a wall, why would things be blurry when looking through it?
<zamundaaa[m]>
soreau: why would a visual effect need to be based in reality?
<zamundaaa[m]>
How blending works in pretty much every compositor also has nothing to do with reality
<zamundaaa[m]>
Doesn't make it ridiculous
<soreau>
ok, I'll live over here in reality, and you can live wherever it is that you do
<orowith2os[m]>
the UI toolkit Inochi Session is going to use in the future would like to use a blur protocol, and would have a transparent background for the areas of the window that aren't covered in a UI element. It might want a fully transparent background, or a blurred one, depending on situation.
<orowith2os[m]>
if you want to think in terms of reality?
<soreau>
'we need to copy something elses future!'
<soreau>
sounds convincing
iomari891 has joined #wayland
<orowith2os[m]>
it should be. Applications coming from a Windows or macOS background already make use of this, and in this case, Linux is the only platform that doesn't.
<orowith2os[m]>
it's consistency.
<orowith2os[m]>
besides, if you use the justification of "we don't need to copy something else's future", why are we adding Wayland protocols? That's the future, of applications using those protocols. It's a broken argument.
<orowith2os[m]>
And if you want to look at something in the present on Linux, you could very well point at X11, but then it gets rejected because "we shouldn't be copying everything from X11"
<soreau>
well considering the unrealistic case of 3D transformed surfaces, such as partly rotated around x/y axis, using a blur region, how would you render the drop shadows without blurring? sounds like there would be some ugly edge cases
<orowith2os[m]>
oh, absolutely. And that's why a blur protocol is purely cosmetic. You don't need it to function.
<soreau>
it's much easier and sane from compositor perspective to just blend blur based on alpha, like > 0.25 is blurred and less than that is blended
<orowith2os[m]>
just to clarify: libsoba is going to support Linux, either way. It'll just do so without window blurring if this isn't a thing when the time comes.
<soreau>
I guess I think of client-compositor protocol as the nuts and bolts and the rest can fall to compositor specific communication side bands/custom protocols
<zamundaaa[m]>
Oro (any/all) It's already a thing. This is just about upstreaming an existing protocol that we've been using for many many years, and that at least two other compositor authors have asked us to upstream
<soreau>
zamundaaa[m]: what prevents the others from just using what kwin does?
<orowith2os[m]>
zamundaaa: I tend to take the mindset of "if it's not upstream, it doesn't exist" when it comes to applications wanting to support several compositors
<orowith2os[m]>
(exceptions for groups like wlroots, of course)
iomari891 has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
but I think the end result of what soba is looking for here is a slightly more customizable blurring protocol
<orowith2os[m]>
that way UI elements get their blur (and blurred according to how soba wants it, though I'm not sure if just using alpha settings does that job?), and fully transparent areas don't get blur if requested
<orowith2os[m]>
e.g. having the ability to request custom blurring algorithms would be amazing in the future
<orowith2os[m]>
er, not really custom, but well-defined blur algorithms that the compositor implements, that way it doesn't have to worry about CVEs
<soreau>
what about blur strength, algorithm, performance and saturation? there's like an infinite number of knobs you could put on this thing and for blurring compositors to follow along with every change just seems unreasonable
<soreau>
you might as well have a protocol request to upload a shader path to use
<orowith2os[m]>
that's a big jump
<soreau>
(not too far fetched, wayfire's filters plugin allows custom shaders for a surface or entire output)
<orowith2os[m]>
a well-defined set of algithms, saturation, and maybe some other stuff UI toolkits expect would be plenty
<soreau>
yea, that's really asking way too much
<orowith2os[m]>
i don't think so, but that's up to compositors to decide. Ideally they wouldn't have to support every single blur algorithm out there.
<zamundaaa[m]>
Oro (any/all): KDE's contrast protocol has some arguments like that, but tbh we've been looking at how to get rid of that...
<zamundaaa[m]>
Either way, I don't think everything needs to be solved at once
<orowith2os[m]>
I think just saturation and strength would be enough for now, in an ext-blur protocol
kts has quit [Quit: Leaving]
<orowith2os[m]>
I also think, for apps to be able to reliably expect what type of blurring algorithm the compositor uses, being able to select one would be fine. The initial protocol can just define one or two options.
<soreau>
it would be better for configure bounds request to grow a corner radius arg. compositors can already offer ways to blur only certain surfaces
<orowith2os[m]>
corner radius would also be helpful ^^
<soreau>
for blurring alpha = 0, that's just nuts
<orowith2os[m]>
blurring alpha = 0.1 :)
<orowith2os[m]>
I guess we go back down the rabbit hole in telling the compositor what alphas should be blurrable, when setting a region to not be blurred would be better
<soreau>
then if there's a setting in the compositor to blur certain surfaces and the client has a setting too, then they have to both be enabled to get blur of any kind
<soreau>
unless the compositor just ignores the protocol, as we've been doing all this time
<zamundaaa[m]>
soreau you're going on and on about non-issues. We've had this blur protocol for 9 years, and the "problems" you're talking about are just not a thing
<zamundaaa[m]>
Oro (any/all): unless there's significant complaints from people that can vote on the protocol MR, I'm going to go ahead with just upstreaming it as-is
<soreau>
zamundaaa[m]: I think they're only *not* problems if the compositor goes above and beyond out of its way to support this
<zamundaaa[m]>
More options, fixes or adjustments can be added later on
<soreau>
zamundaaa[m]: so when a compositor doesn't support the protocol, what does the client do, alpha = 1 for all pixels?
<soreau>
because that would be spectacular
<orowith2os[m]>
zamundaaa @zamundaaa:kde.org what's a "significant" amount? Would expecting it to model similar APIs for window backgrounds on things like macOS be too much?
<zamundaaa[m]>
That's up to the client, but yes, it may change to be less or not transparent at all
<zamundaaa[m]>
IIRC plasmashell does change depending on if the contrast and blur protocols are supported
<soreau>
zamundaaa[m]: because if you set alpha != 1 and get blurred, the client setting won't do anything
<zamundaaa[m]>
Oro (any/all): adding a mode where the blurred background is the wallpaper and not what's behind the window could be done later
<soreau>
that's a compositor feature, not a client..
<zamundaaa[m]>
It could be, sure
<soreau>
man, I am surprised that anyone wants clients to be 'in control' of blur
<orowith2os[m]>
zamundaaa: I suppose so. Even just having the protocol as-is is a great help.
<orowith2os[m]>
I challenge you to have apps that support Mica-style effects without having the client be somewhat in control of blur
<orowith2os[m]>
and not just forcing it onto all apps
<soreau>
zamundaaa[m]: and then if there is no background, then what? garbage?
<soreau>
it seems like the compositor is in the position to know what to do better than the client
<orowith2os[m]>
no blur
<zamundaaa[m]>
Discussing the exact details of a protocol addition that hasn't even been proposed yet is useless
<zamundaaa[m]>
So let's just not do that
<orowith2os[m]>
I'm curious, what happens with clients that allow transparency?
<orowith2os[m]>
they're not guaranteed of any behavior, are they?
<orowith2os[m]>
so I could very well have a black transparent area on any window in a given context
<zamundaaa[m]>
Oro (any/all): in principle, yes
<zamundaaa[m]>
In practice, if a compositor doesn't allow transparency at least between the client's own surfaces, things are expected to break
<zamundaaa[m]>
and look weird if it doesn't allow it to other surfaces too. Because CSD is a thing
<orowith2os[m]>
fun
<orowith2os[m]>
I think when I was playing around with capturing transparent X11 windows on Wayland, they completely broke in OBS
<orowith2os[m]>
haven't tried with a native wl app yet, I don't think
<zamundaaa[m]>
assuming you were using the xdg portal to get the window contents, that really shouldn't happen
<orowith2os[m]>
it might also be an app problem, not sure
<orowith2os[m]>
I have it installed right now, gonna test it
<orowith2os[m]>
oh, I suspect it's broken.....
<orowith2os[m]>
it allows me to set a background alpha (0-255) and it straight-up does not work
<orowith2os[m]>
wl and x11
<orowith2os[m]>
oh well
fmuellner has joined #wayland
fmuellner has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
fmuellner has joined #wayland
sima has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
fmuellner has quit [Remote host closed the connection]
fmuellner has joined #wayland
* DemiMarie
hopes for ext-zones to be upstreamed
fmuellner has quit [Remote host closed the connection]