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
Seirdy has quit []
Seirdy has joined #wayland
Seirdy has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
Seirdy has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
c7s has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Seirdy has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
Seirdy has joined #wayland
hardening has joined #wayland
gusnan has quit [Ping timeout: 480 seconds]
boistordu_old has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
boistordu_ex has quit [Ping timeout: 480 seconds]
gusnan has joined #wayland
meain[m] has joined #wayland
dcz has joined #wayland
yenaras has joined #wayland
yenaras has quit []
zebrag has quit [Quit: Konversation terminated!]
enilflah has joined #wayland
enilflah_ has quit []
dcz_ has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
ecloud has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
spstarr has joined #wayland
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #wayland
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #wayland
<jadahl>
ifreund: ah, I see :) I guess I saw one of the ways to interpret and incorrectly assumed the other was wrong or something
jgrulich has joined #wayland
hardening has joined #wayland
pnowack has joined #wayland
danvet has joined #wayland
mvlad has joined #wayland
adia has quit [Quit: Ping timeout (120 seconds)]
adia has joined #wayland
rgallaispou has joined #wayland
rgallaispou has quit []
rgallaispou has joined #wayland
aetnaeus has quit [Read error: No route to host]
dcz_ has joined #wayland
soreau has quit [Remote host closed the connection]
soreau has joined #wayland
radu242 has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
<ManMower>
kinda wondering if anyone would be really sad if we removed zoom in a future release
<ManMower>
I mean, it's visually neat, and I guess showcases how cool our input system is with funky transforms (see also window rotation), but it feels like a pop-up magnifier or something might be better for a11y, and the zoom stuff is pretty pervasive and not very well tested
<daniels>
yeah fr
<daniels>
I mostly just hate how it's a bolt-on path to the rest of the transform system
<daniels>
if (zoom) { /* hasn't been tested for a couple of years */ } else { /* something already mindbendingly complex */ }
<ManMower>
right :/
<daniels>
I'm definitely in favour of junking zoom, exposay, half of the desktop-shell transition effects, maybe workspaces too
<ManMower>
I'm updating my long dormant transform patch series, and keep banging into that zoom vs everything else split
<ManMower>
I guess we've "always" said weston wasn't really intended to be anyone's full featured desktop. but I guess simplifying all that code is going to bother people that didn't listen... :/
<daniels>
poor linkmauve
<daniels>
I'm not convinced that having those features is a bad thing per se, it's just that their current realisations are really really bad, and desktop-shell in particular is unknowable/unmaintainable as a result
<daniels>
like you say with zoom, I'd much much rather implement that as a proper magnifier, which would be a post-render effect
<daniels>
rather than just literally zooming the entire screen, hitting every single corner-case branch of the ugly tree on the way down
<ManMower>
I'll file an issue for removing zoom and see if anyone shouts me down...
<emersion>
i'd be in favor of removing these features as well
<daniels>
ManMower: further proof that Wayland makes it literally impossible to do videoconferencing
<ManMower>
should I make an umbrella "let's remove hard to maintain stuff from weston" issue?
jgrulich has quit [Ping timeout: 480 seconds]
devilhorns has quit []
<daniels>
I think it's definitely worth having one for burning desktop-shell to the ground
<daniels>
ivi-shell can go at this point imo
<daniels>
previous discussion about deleting clients
<daniels>
if there's an easy-to-use pipewire thing, I'd be super in favour of yeeting wcap into the sun
<ManMower>
oh, yeah
<daniels>
honestly the non-PW remoting plugin could probably go too ...
devilhorns has joined #wayland
* ManMower
looks up and notices fbdev came up
<ManMower>
oh that one has a ticket, nice
<daniels>
there's an argument for binning EGL_WL_bind_wayland_display and matching what wlroots does (hand-roll your own wl_drm server implementation and only support dmabuf), but it's really causing us ~no problems to keep around
<daniels>
already got an issue for binning off weston-launch iirc?
<ManMower>
yeah, there's an MR for that
<daniels>
omg I forgot we still have ZUC
<ManMower>
and wl_shell
<ManMower>
... zuc
<daniels>
that's only a couple of trivial tests
radu242 has quit [Ping timeout: 480 seconds]
<emersion>
what is ZUC?
<ManMower>
binning EGL_WL_bind_wayland_display would actually be a nice simplification in the gl-renderer, wouldn't it? I guess not that many lines shaved off, but I interacted with bits recently that would just disappear.
<emersion>
yeah, if we can keep EGL_WL_bind_wayland_display for weston, probably better for now. we had to bin it in wlroots because of our new architecture
<ManMower>
interesting
<daniels>
emersion: ZUC millions of voices suddenly crying out in terror.
<daniels>
*is
<ManMower>
ZUC is our roll-your-own-test-framework-because-nobody-else-makes-a-test-framework-right?
<emersion>
ahah
<daniels>
'hey guys I'm going to write my own test framework from scratch it's going to be amazing' 'please write some actual tests, those are useful, writing a test framework then immediately disappearing is not' 'gotcha, I'll definitely do that' [several months later] 'hey so why do we have a test framework which only has two trivial tests ported to it'
<ManMower>
I feel like we should keep it, and just use an existing framework to write some tests to test ZUC...
* ManMower
quietly walks away
<Sachiel>
are there test frameworks designed to test test frameworks specifically? If not, we might need to come up with a new one for that
<ManMower>
:D
* jadahl
remembers excitement about ZUC
yenaras has quit []
<daniels>
yeah?
<daniels>
I must've been dead that week
fmuellner_ has joined #wayland
fmuellner has quit [Remote host closed the connection]
<mahkoh>
hi. what is the meaning of the coordinates in wl_surface::attach if the surface is an xdg_surface or a wl_subsurface? A wl_subsurface can already be positioned via wl_subsurface::set_position. an xdg_surface should not be movable by the client as I understand it and it can have different coordinates attached via xdg_surface::set_geometry. How are the set_buffer coordinates supposed to interact with the coordinates s
<mahkoh>
For a cursor the behavior is clear
<mahkoh>
are there any applications that make use of these coordinates in wl_surface::attach outside of cursors?
<emersion>
drag icons
<emersion>
but for other stuff, if the surface role doesn't tell, it should be a no-op
<emersion>
hm
<emersion>
iirc can be used for client-side resizing of xdg-shell surfaces
<emersion>
i haven't seen compositors really implement this behaviour though
<mahkoh>
makes sense. thanks.
wahfato has joined #wayland
radu242 has joined #wayland
Narrat has joined #wayland
<jadahl>
Nei: that'd be #gnome-shell on irc.gnome.org
radu242 has quit [Ping timeout: 480 seconds]
radu242 has joined #wayland
radu242 has quit [Quit: Ping timeout (120 seconds)]
<gw>
I have some questions over how things would work in such a scenario with video surfaces. You'll have to forgive me, neither color management nor compositor internals are things I know much about, so bear with me here.
<gw>
Let's use a concrete example - we have a web page that has some background content, then a video surface spliced in the middle, and then some overlapping translucent surfaces (imagine hovering a mouse over a video, and web controls fade in and overlay).
<gw>
For simplicity, assume these are all LDR surfaces. Right now, we could create 3 wayland surfaces, have the blending done by the compositor, and _hopefully_ the video surface might get direct scanout, as I understand things (at least on frames where the web video controls don't overlap the video / aren't visible) - not that this is implemented, but that seems like the ideal, in terms of power consumption.
<gw>
How would such a scenario work with the changes referenced above, in such a way that the video can still be supplied as a separate surface and be composited optimally when feasible?
mahkoh has quit [Quit: Page closed]
<daniels>
gw: hopefully you have a long-lived IRC connection, because the relevant people are now asleep!
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #wayland
<daniels>
gw: anyway, some compositors (insert Weston plug here) will do direct scanout in that situation, at least as far as the hardware allows
<emersion>
as long as firefox uses wl_subsurface, yeah
<gw>
daniels: I do, connected via a persistent quassel core, so should be ok!
<daniels>
gw: \o/
<gw>
daniels: emersion: yes, we do currently use wl_subsurface. However, as I understand it, the proposal in the link above is that wayland wouldn't support doing this non-linear blending any more (could also be mis-understanding)
<daniels>
but yeah, combining HDR and SDR within the same scene is difficult, especially if blending is required
<daniels>
tbh I think we'd have to measure the performance characteristics of each approach on individual hardware to see where the damage is
maxzor_ has quit [Remote host closed the connection]
<gw>
And so, if wayland no longer supports the non-linear blending of subsurfaces, even when all content is LDR
<emersion>
right, the KMS API for this doesn't exist yet
<daniels>
gw: the suggestion is that it wouldn't do so at least in the presence of HDR
maxzor_ has joined #wayland
<gw>
And what about if all the surfaces were LDR, would wayland in the proposal above still support blending in that case?
<emersion>
it depends on the compositor impl, but in general if color management is not supported by the compositor or disabled it should still work
<gw>
ok, that would cover my main concern, I _think_, if that's still supported
<emersion>
note, no compositor other than weston supports this atm
<emersion>
but it's def on the roadmap for at least wlroots and mutter
<gw>
Yea, it's more about having a plan for what we need to do in firefox if the way we're currently using things was no longer supported
<jadahl>
then there is the question on whether compositors will start doing linear blending in sdr mode, which isn't very clear yet
<emersion>
we already do linear blending with our vulkan renderer
<gw>
If that blending was supported for LDR surfaces when not using HDR mode enabled, and we were expected to manage blending / compositing HDR video + LDR overlays ourselves, that sounds quite reasonable.
<jadahl>
emersion: doing that is what might be problematic for the transparent video overlay subsurface things
<gw>
right
<emersion>
it might be better to not composite the HDR video + LDR overlays in the client… depending on future KMS exts and hw capabilities
<gw>
Yea
<gw>
It feels like if we do it ourselves internally, we're removing information from the compositor that it may be able to take advantage of in future depending on platform / hardware support?
<emersion>
yes
<gw>
And, further to that:
<emersion>
jadahl: yeah, as it stands it won't be consistent with KMS blending
<gw>
I have a concern, possibly unfounded, that if we supply a HDR surface to wayland when no overlays are present, then try to switch seamlessly and composite it ourselves on mouseover when web content is present, then it won't actually look very seamless :)
<emersion>
in gamescope we had to hack around the kernel to convince it to blend in linear space :S
<gw>
(to take advantage of scanout of HDR when no overlays are present, that is)
<jadahl>
emersion: also turning that feature on/off in firefox will make it look different without kms overlays too
<emersion>
gw: pq is currently working on color management exts, and AFAIK one of the goals is to provide enough guarantees that this won't happen
<emersion>
but without the color management ext, yeah there's no guarantee how the compositor blending will happen…
<gw>
emersion: ok, that'd be good to know if it's something being considered as an expected use case
<gw>
(to go from compositing internally with an overlay, and then switching to a scanout / wayland subsurface when there isn't an overlay seamlessly, that is)