ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
andyrtr_ has joined #wayland
akik has quit [Quit: leaving]
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
jmdaemon has joined #wayland
crazybyte has quit [Quit: Ping timeout (120 seconds)]
julio7359 has quit [Ping timeout: 480 seconds]
crazybyte has joined #wayland
julio7359 has joined #wayland
Szadek has quit [Ping timeout: 480 seconds]
Szadek has joined #wayland
julio7359 has quit []
caveman has quit [Remote host closed the connection]
<emersion>
zzag: by any chance, would you be interested in implementing a protocol to set an alpha value for a surface? kind of like your slide protocol
<emersion>
jadahl: do you have an opinion on this? ^
<zzag>
emersion: with color management and things as such, I'm not really sure. For animation purposes, we would probably go with a different approach where a client says that it wants its surface to be animated and the compositor would take care of animating the opacity. Don't take it as "no" and also don't take it as "yes"
<emersion>
zzag: ok
<emersion>
i will wait then
<emersion>
i don't think color management changes things that much
<emersion>
instead of using directly the alpha value from the buffer as-is, you'd just multiply it by some value
<daniels>
emersion: I guess the main thing tying it to xdg-shell was the choice to communicate it as toplevel rather than surface state
<emersion>
daniels: a compositor can choose to send the same visibility to all surfaces belonging to a toplevel if it wants to
<daniels>
so you want to remove it from xdg_toplevel and move it to wl_surface?
<emersion>
i think it makes more sense as a wl_surface addon
<emersion>
i don't know if it can be merged with another protocol
<jadahl>
emersion: my opinion is to put it as a xdg_toplevel state, it's trivial enough and if it becomes unused (which I doubt) it's like a sand grain of technical dept to deal with
<emersion>
for instance, one might want to use it with layer-shell
<daniels>
otoh, given it's a single enum, it should be pretty trivial to implement for layer-shell?
<daniels>
I'm mostly thinking about client implementation complexity here
<emersion>
layer-shell doesn't have states
<daniels>
for instance, if you're a browser, a single toplevel signal tells you that you can stop bothering to process most background JavaScript and also tell the tab that it's inactive
<emersion>
also, a sub-surface might want to use it in a library
<daniels>
otoh, if it's per-surface, you'd have to wait and collect for every subsurface
<daniels>
e.g. if it's strictly 'this surface is occluded' not 'this window group is inactive', what happens if your media embed occludes everything but you don't have a pointer to its surface because it's a subsurface?
<emersion>
i don't think sub-surfaces extend the bounds of the toplevel for a web browser
<daniels>
fullscreen video?
<emersion>
that's not a sub-surface
<emersion>
the fullscreen surface is the xdg-toplevel one
<daniels>
mostly it's implemented as a subsurface, because otherwise you'd end up fighting for surface ownership between EGL/Vulkan and media
<daniels>
you can solve this by plumbing state-change events back from the media side to the UI side of course, but eh
<emersion>
i mean that the xdg-toplevel is still mapped and has the same extents as the subsurface
<emersion>
in fullscreen mode
<jadahl>
I'd see 'not_shown' as a Wayland equivalent to "iconic" (minimized) that isn't tied to a specific concept of "not shown", and that isn't tied to "surfaces" but "toplevels". making it a per surface thing just complicates things
<daniels>
hmm, are you suggesting that we send the event to the wl_surface rather than the xdg_toplevel, but the semantics conceptually remain toplevel-grouped (e.g. we'd tell a wl_surface that it's active if any of the window group is active)?
<emersion>
jadahl: i see 'not_shown' explicitly not as 'iconic'
<jadahl>
it isn't yes, but the use case is similar
<jadahl>
or, a subset of the "iconic" use cases, rather
<daniels>
if you are suggesting that the per-surface events would still be driven by toplevel aggregation, that would solve the client complexity problem - no need to try to aggregate a bunch of events and do if (any(!not_shown)) - but is conceptually pretty weird (wl_surface acquires xdg/layer-shell/... semantics)
<emersion>
daniels: i don't think that's necessary
<emersion>
i can't think of any client which would need to wait for multiple events, even when they use sub-surfaces
<emersion>
simply because clients don't use sub-surfaces extending beyond the toplevel bounds
<emersion>
because these would get clipped in many situations
<emersion>
xdg-popups are a different case, and clients would need to indeed wait for multiple events if they care
<daniels>
ok, I think I was misled by your 'i mean that the xdg-toplevel is still mapped and has the same extents as the subsurface in fullscreen mode', which was in response to my suggestion that if an app had a subsurface for media playback in fullscreen mode, then the likely outcome would be that the app's wl_surface would be completely occluded by the subsurface which had the same extent as it
<emersion>
hm, right
<emersion>
hm, i see
<emersion>
if it's completely occluded, it'd get 'not_shown'
<jadahl>
if it really can't be a simple xdg-toplevel state, then at least it should be for the toplevel "equivalent" only, and not set on popups, subsurfaces, and act on the toplevel as a whole, not tied to the surface the new interface was created for
<daniels>
right, so it either has to ignore that, or go ask the media player if that's really true
<jadahl>
i.e. equivalent to a xdg toplevel state just with a whole bunch of plumbing around it
<daniels>
so that's my core objection, that having surface rather than surface-group semantics actually makes life worse for clients, whereas for compositors it's roughly equivalent effort either way
<jadahl>
but imo it'd be a lot cleaner to make it a toplevel state, and have layer shell get its own state, potentially with more targetted semantics
<daniels>
if you'd prefer surface vs. surface-group semantics then there's a discussion to be had there; if the main objection is just that layer-shell doesn't have a state enum and you'd like to reuse the same, then please let me go write the patch for layer-shell to give it a state enum :P
<emersion>
i still think not_shown doesn't anything to do with xdg-shell, but count me as "neutral"
<emersion>
doesn't have*
<emersion>
layer-shell can't use the same enum as xdg-shell, it doesn't make sense
<emersion>
layer-shell cannot be moving/maximized/etc
<jadahl>
it has something to do with xdg-shell since logically it ties to a "window" (xdg_toplevel)
<jadahl>
layer-shell would have its own state, with a 'NOT_SHOWN' equivalent
<jadahl>
doesn't need to be the same number
<daniels>
yeah, that ^
<daniels>
(with the caveat that I don't know how layer-shell is actually used, beyond 'a lego-block desktop where clients can z-order their surfaces')
<emersion>
yeah "just" have to replicate that in all shells
<daniels>
'that' -> 'not_shown'?
<emersion>
yea
<daniels>
I'll happily type up the XML if someone figures out the semantics which make sense :)
<emersion>
i'm not a fan of not_shown in general, i see it mostly as a band-aid for bad clients
<emersion>
surface suspension makes more sense to me to "stop doing expensive stuff"
<emersion>
not_shown is mechanism, surface suspension is policy
<emersion>
hm, one wouldn't even be able to use not_shown in mesa's GL impl
<emersion>
what was the use-case again?
* emersion
opens the MR
<emersion>
i mean web browsers' visibilitychange API for sure, but
<emersion>
ah, mpv, because it has a weird design
<daniels>
(sorry, in a call; bbiab)
<emersion>
GTK just exposes that state, right?
<emersion>
seems like so
<jadahl>
emersion: GTK will, but isn't. it only has minimized state, which the Wayland backend doesn't use at all. the minimized state on X11 will likely be translated to this new one though, and it'll likely follow whatever naming is decided for the Wayland protocol
<vbt>
emersion: what's the weird part of mpv you are talking about? where can i read more about it?
<jadahl>
and it'll tie to the toplevel
<emersion>
vbt: mpv internals do not work well with wl_surface.frame
<jadahl>
a use case could e.g. be not updating the widget tree when "not-shown" to same some CPU cycles
ahartmetz has joined #wayland
<d_ed[m]>
Our Qt equivalent docs are:
<d_ed[m]>
"When the window is not exposed, it is shown by the application but it is still not showing in the windowing system, so the application should minimize animations and other graphical activities."
<d_ed[m]>
right now this is run off fallback timers when we don't get frame events, but the false positives from that are quite problematic
<jadahl>
what's that state called?
<d_ed[m]>
QWindow::isExposed()
<zamundaaa[m]>
daniels: subsurfaces occluding other subsurfaces is a valid problem, but it's also a problem with frame callbacks. I don't really see a reason to single out occlusion as the problem to solve - especially not if surface suspension then has the same problem that still needs to be solved either way
Leopold___ has quit [Remote host closed the connection]
<daniels>
zamundaaa[m]: I'm not singling out occlusion as the problem to solve though - literally the opposite of that!
Guest3057 has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
daniels: let me rephrase that: What real world problem does a not_shown protocol solve, which isn't also solved by surface suspension that we *need* for other problems already? Because the problem with subsurface occlusion is the only one I see
<daniels>
zamundaaa[m]: as said, the usecase I'm looking at is somewhat orthogonal, and it's a higher-level expression. when my IM client is completely inactive, I want it to not bother registering for 'foo is typing...' notifications because that's a waste of power. when my editor is completely inactive, I want it to stop monitoring the filesystem for changes because it doesn't matter. when my browser is completely inactive, I want it to
<daniels>
stop animating carousels.
<emersion>
that's exactly suspension
<emersion>
is it not?
<daniels>
you _can_ derive those things from the cadence of wl_surface.frame, but I don't like that kind of reverse-engineering, it causes real problems as stated above (e.g. your app shouldn't stop doing work because its main surface is occluded by a subsurface that the media framework created), and I don't understand the difficulty
<daniels>
I don't like how suspension is reverse-engineered from frame, and I think it's less useful for being tied to surface rather than toplevel
<emersion>
by suspension, we don't mean reverse-engineering the frame callback
<daniels>
I think there is _also_ a case for suspension in terms of informing you what's happening with frame events, but they are not necessarily the same
<emersion>
we mean the surface-suspension protocol
<JoshuaAs->
I guess I still don't get what being a flag on top levels gets us aside from scoping down this flag for reasons I don't understand
<JoshuaAs->
Oh I am JoshuaAs- again... nice :/
<daniels>
emersion: the surface-suspension protocol is tied to wl_surface, not xdg_toplevel
<daniels>
surface-suspension also literally talks about the cadence of 'frame'
Szadek has quit [Ping timeout: 480 seconds]
<daniels>
I have no issue with communicating this to lower-level frameworks
<daniels>
however I also think - as above - there is a very good case for a higher-level window state
<daniels>
these would be used by different things for different purposes
Szadek has joined #wayland
<swick[m]>
I very much like the split between "this window is not being shown" and "this surface is mapped on a display which has certain refresh characteristics"
<JoshuaAs->
Higher level things are aware of wayland..?
<daniels>
JoshuaAs-: toolkits?
<JoshuaAs->
High level aspects of toolkits are showing Wayland state?
<JoshuaAs->
Certainly not when I was writing Qt stuff a few years ago :P
<daniels>
JoshuaAs-: eh?
<JoshuaAs->
What I mean is, if one state can be derived from surface suspension vs the flags I don't get the point?
<daniels>
surface suspension can be derived by waiting to see if 'frame' gets signalled in some amount of time which would ordinarily occur, so what's the point of that?
<JoshuaAs->
Because the amount of time you'd wait to derive that fucks over a bunch of apps
<swick[m]>
you can always commit
<zzag>
daniels: that's not ideal. see d_ed's comment above: "right now this is run off fallback timers when we don't get frame events, but the false positives from that are quite problematic"
<daniels>
JoshuaAs-: not true, but ok
<daniels>
JoshuaAs-: you also _cannot_ derive the global app state in a number of cases, like I said above - like you cited Qt as an example, but you can't implement https://doc.qt.io/qt-6/qt.html#ApplicationState-enum (exposed through QGuiApplication) by just looking at surface-occlusion state
<swick[m]>
a window can consist of multiple surfaces of which some might be suspended
<swick[m]>
the point here is that you need some heuristics to go from surface state to window state
<JoshuaAs->
Okay then check the suspension state on the top level surface(s)?
<zamundaaa[m]>
daniels: you're exactly describing the use case for surface suspension. It tells clients that they should stop rendering, stop tasks related to it and release resources related to it.
<zamundaaa[m]>
Arguably, surface suspension is actually the higher level protocol - if you stop thinking in terms of "what drivers use" and "what toolkits use" and just look at it in terms of language. "Stop rendering" vs "you're not shown"
<swick[m]>
JoshuaAs-: that's a heuristic. what if you now stop updating stuff which is visible?
<zamundaaa[m]>
JoshuaAs-: that runs into the subsurface occlusion mentioned above
<zamundaaa[m]>
If a subsurface is above the toplevel and covers it, the surface will always be suspended
<daniels>
zamundaaa[m]: ok, so I'm a media player with a toplevel UI window. I embed a media player which creates subsurfaces that completely occlude my UI window. the compositor tells me that my UI window is no longer visible so I pause what I'm doing and stop streaming the video.
<JoshuaAs->
Subsurfaces would be in bounds of their parent/top-level surfaces though? Or is that what I am missing here?
<swick[m]>
if you don't have to derive information with some heuristics and can just be told, why would you want to do the former?
<daniels>
^
<zamundaaa[m]>
daniels like I already said, that's a very different problem
<daniels>
zamundaaa[m]: go on ...
<zamundaaa[m]>
You have exactly the same problem if you try to check how many fps you should stream the video at with frame callbacks
<daniels>
yes
<zamundaaa[m]>
As you're already communicating with a subsurface anyways, because you're streaming frames, then I don't see any reason why you couldn't communicate a simple boolean as well
<zamundaaa[m]>
Just like you already have to do for the refresh rate
<swick[m]>
frame callbacks are useful for very narrow use cases and trying to make it more useful has not worked out
<daniels>
I don't understand how refresh is involved - ideally the subsurface would be annotated with something which allows the media player to communicate the source framerate but that is completely irrelevant
<daniels>
but let's say we do that
<daniels>
so now when my UI subsurface gets a notification that it's suspended, I have to go check with all embeds whether they're suspended too
<zamundaaa[m]>
daniels: it is not irrelevant at all. You're communicating states between subsurfaces, so what is so special about the surface visibility that it, and only it, needs to be handled by Wayland directly?
<daniels>
which probably forces a roundtrip just to make sure that you've actually received and processed every event you might receive
<daniels>
this seems ... not good?
<daniels>
zamundaaa[m]: why do we have 'activated' as an xdg state when you could just query the entire tree to see if any of them have focus?
Dami_Lu has quit [Remote host closed the connection]
<pq>
focus may not exist while window can still be activated
<pq>
happens in touch-only systems
<daniels>
right, just set a timer based off any input events you may have received off the window tree + which device classes are present + frame events, easy
<daniels>
we could get rid of minimised as well if we added something to force the client to be 0x0
<pq>
it sounds like the difference between "surface suspention" (high level) and "surface-suspension defined in term of frame callback behaviour" (low-level) is not getting through
<daniels>
yes
Dami_Lu has joined #wayland
<daniels>
xdg_toplevel already has a pile of high-level window-management state which is not directly related to super-low-level semantics, and is consumed by users who care about the overall state of a pile of aggregated surfaces
<zamundaaa[m]>
pq: there is no difference between those two. Surface suspension is always high level. It also giving guarantees about frame callbacks doesn't change that
<swick[m]>
frame callbacks should be left alone
<daniels>
adding high-level state to wl_surface does not make sense because it fundamentally mixes the two up
<swick[m]>
they are bad and anything adding more semantics to them is bad
<daniels>
adding low-level state to xdg_toplevel does not make sense either
<pq>
zamundaaa[m], there is huge difference between the two. Immense sematnioc
<pq>
zamundaaa[m], there is huge difference between the two. Immense semantical difference.
<zamundaaa[m]>
pq: go on. "no frame callbacks anytime soon" means "don't render, don't do stuff related to rendering, release resources related to rendering". What other meaning of surface suspension is there that's not exactly that as well?
<daniels>
right now a lot of protocol semantics are - in the real world - tied to wl_surface.frame because this is the only mechanism we've given people to date. it's the hammer for every nail, apparently.
<daniels>
doing this has caused a lot of real-world problems that we are trying to solve.
<daniels>
if the solution is tying even more things to frame, and imbuing it with even more magic meaning, then we've completely failed, and we're making the problem worse.
<daniels>
adding high-level state (
<daniels>
grr
<daniels>
adding high-level state is orthogonal, descriptive, solves real-world application usecases and problems, and is pretty trivial to implement
<daniels>
zamundaaa[m]: let's flip this around. what problem would the existence of a new state bit in xdg_toplevel cause you?
<daniels>
like I've said, I have no objection to surface-suspension and other things which describe the actual behaviour of wl_surface.frame on a per-surface basis. I think the two can coexist nicely. you have an objection to the existence of this enum state bit. what is it? what problems is it causing? why would it not be viable for your compositor to just never send that state bit?
<zamundaaa[m]>
daniels: surface suspension isn't about frame callbacks. It's just convenient to *also* fix frame callbacks with it
<daniels>
??
<zamundaaa[m]>
> why would it not be viable for your compositor to just never send that state bit?
<zamundaaa[m]>
Because clients may rely on it, and then the behavior with a compositor that doesn't send them regresses
<pq>
I would hope that the protocol extension that describes frame callback behavior will fall out of use once Mesa stops using frame callbacks for swap interval.
<JoshuaAs->
Is that the refresh cycle protocol?
<daniels>
clients could not rely on 'top-level not receiving this new state enum == all surfaces in the stack always get frame events', because that assumption would be violated on compositors which did send the new state enum, and compositors which didn't. clients which never received the new state bit wouldn't implement the new behaviour of going into a low-power/no-interaction mode, but that's not a regression based on today, it's
<daniels>
literally the status quo.
<pq>
I don't know. Someone said the surface-suspension protocol is describing frame callback behaviour.
<daniels>
zamundaaa[m]: secondly, I literally have no idea what protocol you're describing when you say 'surface suspension', but it isn't the one which was last proposed, because that one is _literally_ tied to the behaviour of wl_surface.frame ...
<daniels>
so if you have something else in your head then fine, but I don't know what that is, and trying to reverse-engineer what you might be thinking of plainly isn't working
<zamundaaa[m]>
daniels: what emersion and I want is a surface level suspension state
<daniels>
define 'suspension state'
<zamundaaa[m]>
If it's tied to frame callbacks or not is of secondary importance. It would however be nice to also finally fix frame callbacks using the same mechanism
<daniels>
fine
<daniels>
but you're describing a hypothetical
<daniels>
it's not !99
<daniels>
I really cannot see the reason why there must be a single protocol which ties visibility/occlusion/frame/etc all together. I think it's actively harmful. I'd really appreciate it if you could a) actually describe what you're talking about, b) describe why it's not harmful to the concrete usecases I've described, and c) describe how my proposal would be worse
<daniels>
if this could happen in bounded time that would be awesome
<davidre>
O(n!)? ;)
<daniels>
I honestly don't see how this could be practical - e.g. the roundtrip query I described just seems massively hostile to clients and it's still unclear to me what gain the added complexity and inbuilt race conditions would cause - but I'm happy to be surprised if something actually exists
<swick[m]>
don't try to fix frame callbacks :(
<pq>
Frame callbacks are being used for things they are not suitable for: swap interval. Why not replace frame callbacks with a thing a that is suitable for swap interval, instead of adding band-aid to let frame callbacks continue hobble along for swap interval? When the band-aid requires work in exactly all the same components as a better solution.
<daniels>
+++++++++++++++
<swick[m]>
^
<swick[m]>
please just let's all agree to never touch frame callbacks ever again
<swick[m]>
I also made that mistake multiple times
<daniels>
frame means 'the compositor thinks now is a good time to draw'. it's the only thing it ever has meant. it completely fucked us when people started assuming that it meant anything more than that. I understand why they did, because we didn't give them anything else to use. but I am hard hard opposed to trying to solve that problem by making it mean more and be more structural.
<zamundaaa[m]>
I don't disagree with that, we do need a proper replacement for them
<pq>
Frame callbacks are a good frame-level throttling mechanism when they are not used for blocking and you don't care about precise timings. Nothing more.
<daniels>
zamundaaa[m]: ok, so can we _please_ not tie 'you should stop monitoring for is-typing notifications' to frame callbacks then?
<zamundaaa[m]>
yeah
<daniels>
thankyou - so where does that land us on the toplevel enum?
<zamundaaa[m]>
I still think a surface level thing makes more sense
<daniels>
tbh I don't for the reasons above, because it's not clear from the client how to derive things like the QGuiApplication::applicationState() value
<zamundaaa[m]>
If it is really that complicated for clients to check !all_of(surface_tree, suspended) whenever the surface suspension state of any surface changes, then we should imo have a surface suspension state for the surface tree, and not for the toplevel
<zamundaaa[m]>
That has the advantage that it isn't tied to one specific toplevel protocol
<zamundaaa[m]>
And it makes things easier for embedded components
<daniels>
does it?
<daniels>
toplevels can already tell embedded components to pause/etc
<zamundaaa[m]>
Like, if you have an embedded browser, it can check the state of its surface tree, instead of having to communicate with the embedding application
<daniels>
!all_of(surface_tree, suspended) requires the toplevel & all embedders to negotiate whether or not they've registered for surface suspension, then to have a cascading query, which is new API between them
<zamundaaa[m]>
true, but so is the other way around
<daniels>
not really, no
<daniels>
you already have the notion that the embedder tells the embedded to stop doing things, or do things differently
<daniels>
the reverse is a new concept, and one that's inherently prone to races, since you have to make sure that everyone's at the same point in the event stream
<daniels>
like, say your compositor sends: surface A suspended, surface B suspended, surface C not-suspended
<daniels>
if surface A is the top-level, it can't issue an 'am I suspended?' query down the tree, because surface C hasn't processed its not-suspended event yet as it was sent after surface A
<zamundaaa[m]>
It's not really a new concept, as embedded components have state and state changes already. For video players, that could for example be the aspect ratio of the video
<daniels>
so you'd have to schedule an idle callback to do it, and everyone who received that query would have to make sure that they'd dispatched all events too - in effect a roundtrip - to get coherent results
mkotyla has joined #wayland
<zamundaaa[m]>
They would not, because state changes are propagated up as well
<daniels>
right, so when your toplevel receives a 'suspended' event, what do you do?
<zamundaaa[m]>
you ask the subsurface tree if they're all suspended too. If they're not, you assume not all surfaces suspended
<zamundaaa[m]>
And you do that same check whenever any subsurface reports its state changed
<mkotyla>
Hi, I want to use weston with chromium in my embedded system. I need also virtual keyboard - 'weston-keyboards' looks and works good, but I need something more advanced - with predefinied more languages and with option to use special characters (german, polish, turkish etc) - do you know any software which can I use?
<mkotyla>
I tried with squeekboard, but it seems to not work on weston without any gnome-specific software
<zamundaaa[m]>
daniels: The bit I want to focus on is that you can have the same semantic as for a toplevel only state, without having to attach it to a specific toplevel protocol or copy it all over the place. And if an embedded component wants to use it directly and not be tied to a toplevel state, it can do so too, without having to communicate with the toplevel
<daniels>
zamundaaa[m]: no, that doesn't work. a new occluding subsurface gets mapped. the compositor tells the client that the parent subsurface is suspended. the client queries all its subsurfaces to see if they're suspended, and they are. so you shut everything down. two events later, the client receives the event telling it that the subsurface is not suspended.
<daniels>
zamundaaa[m]: what's the problem with this being specific to xdg?
<daniels>
zamundaaa[m]: is there a usecase for layer-shell having a similar not-shown protocol which is also not inherently tied to the universal hammer of frame events? if so, what is it?
<zamundaaa[m]>
daniels: yes
<daniels>
what is it?
<zamundaaa[m]>
If you have an animated wallpaper, you want it to stop animating when you have a maximized window over it
<daniels>
and the animation is not driven by frame events?
<zamundaaa[m]>
You can have widgets on the desktop surface or in a panel, which can embed browsers and whatever
<daniels>
yes, and those already have to negotiate size, which is driven by xdg
<daniels>
or layer-shell
<zamundaaa[m]>
daniels: You can't say that surface suspension is independent of frame events and then say it's not needed in other cases because it could be solved by frame events too
<zamundaaa[m]>
You're arguing against your own protocol right now
<daniels>
wtf?
<daniels>
you're the one talking about surface-suspension, and a theoretical surface-suspension at that, which doesn't currently exist
<daniels>
I'm talking about a new enum of xdg-toplevel state
<daniels>
this is going in circles - please go put your vote on !210 and also file a MR describing the actual protocol that you have in your head right now
<zamundaaa[m]>
wait, I misread one of your comments, sorry
<zamundaaa[m]>
The argument against having a not-shown thing in layer shell is that you have to copy it into every single toplevel protocol
<daniels>
there aren't many of those
<daniels>
you already have to have size negotiation in them anyway - I don't see how it's onerous
<zamundaaa[m]>
we're actively working on adding more toplevel protocols though
<zamundaaa[m]>
Size negotiation is a bit different, because it depends on the specific protocol and its use case
bodiccea_ has joined #wayland
<daniels>
not being funny, but it seems like it would be quicker to add pause/resume to every toplevel than this conversation
bodiccea has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
<jadahl>
zamundaaa[m]: the argument against a generic wl_surface based separate one is that it has to be artificially and awkwardly limited to toplevels that know how to handle it and that's arguably worse
<zamundaaa[m]>
it doesn't have to be limited to those. I'll type up a protocol draft later
<jadahl>
e.g. it makes no sense for a cursor role, subsurface role, xdg_popup role, so that has to be made clear, so we probably need to make it clear in the protocols that declare some role that they can interoperate with this other extension to define an extra state, but why make it so complicated?
<daniels>
crouching surface, hidden cursor
<jadahl>
zamundaaa[m]: it should be, because it's a state that involves a high level "window", and clients nor compositors shouldn't have to be able to make mistakes by figuring out what set of surfaces it should set the state on, or clients having to reverse engineer what actual conceptual toplevel window it actually was meant for
<jadahl>
setting 'not-shown' on a subsurface makes no sense, and I don't want low level awkward knobs to define high level concepts where it's trivial to add such concepts to existing high level representations
rv1sr has quit [Remote host closed the connection]
rv1sr has joined #wayland
rv1sr has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
<pq>
swick[m], Re: public-colorweb; I like what Lemieux and Seeger wrote, but I didn't have time to really look into any reply yet.
fmuellner has quit []
fmuellner has joined #wayland
crazybyte has quit [Ping timeout: 480 seconds]
kenny has quit [Quit: WeeChat 3.8]
kenny has joined #wayland
<swick[m]>
pq: I'm stuck in meetings right now but I'm going to read them again before the telco
pochu has quit [Quit: leaving]
caseorum has joined #wayland
caseorum has quit []
flibit has quit []
rv1sr has joined #wayland
crazybyte has joined #wayland
rederick29 has joined #wayland
tzimmermann has quit [Quit: Leaving]
junaid has joined #wayland
rahl has joined #wayland
<rahl>
Having an odd issue with libinput, wayland and an elantech touchpad. No events seem to be registered from the touchpad at all
junaid has quit [Quit: leaving]
<rahl>
Using a fresh install of void linux
<rahl>
libinput list-devices shows the device
<rahl>
libinput debug-events only shows keyboard events
i509vcb has joined #wayland
Leopold has quit [Remote host closed the connection]