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
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Fulljab has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
hexhive has quit [Ping timeout: 480 seconds]
<ishitatsuyuki>
well, quick update: working on it for KWin + Qt
<ishitatsuyuki>
it's almost working but I need to fix it to properly align the window boundary to pixel edges
raoni has joined #wayland
slattann has joined #wayland
slattann has quit []
slattann has joined #wayland
slattann has quit []
zebrag has quit [Remote host closed the connection]
Fulljab has quit []
slattann has joined #wayland
Fulljab has joined #wayland
Fulljab has quit []
slattann has quit []
dcz_ has joined #wayland
hardening has joined #wayland
<ishitatsuyuki>
I'm considering whether to submit the fractional scaling protocol to wayland-protocols or to start as a KWin protocol
<ishitatsuyuki>
the official governance process look scary to me - in particular it seems to be a lengthy process even for unstable protocols
jgrulich has quit [Remote host closed the connection]
pnowack has joined #wayland
danvet has joined #wayland
jgrulich has joined #wayland
<kennylevinsen>
ishitatsuyuki: everyone wants it, and we all need to align on it, so wayland-protocols
<ishitatsuyuki>
ok
<kennylevinsen>
And yeah, pixel edge alignment was the thing that I imagined would be the most annoying to deal with between mixed compositor-scaked and client-scaled surfaces...
<jadahl>
kennylevinsen: indeed, can create a proposal, implement it, and if you don't want to wait and want it in kde, "fork" it into a kde_ extension while waiting for upstream
<jadahl>
err ishitatsuyuki
<jadahl>
eventually you can migrate to the upstream variant, just as e.g. gtk migrated from gtk primary selection to the upstream one
leon-p has joined #wayland
Fulljab has joined #wayland
sstiller has joined #wayland
<eruditehermit>
ishitatsuyuki, so does kwin do a better job with fractional scaling than mutter?
hendursa1 has joined #wayland
<ishitatsuyuki>
eruditehermit: wdym?
<ishitatsuyuki>
they mostly operate in the same fashion currently
<ishitatsuyuki>
I'm implementing Windows-like fractional scaling as a new protocol
hendursaga has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
rgallaispou has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
tzimmermann has joined #wayland
Fulljab has quit []
dreda has quit [Ping timeout: 480 seconds]
hendursaga has joined #wayland
hendursa1 has quit [Ping timeout: 480 seconds]
frytaped has quit [Remote host closed the connection]
frytaped has joined #wayland
frytaped has quit [Remote host closed the connection]
dreda has joined #wayland
<ishitatsuyuki>
oh god. most of Wayland seems to assume that people wouldn't use fractional logical (surface) coordinates...
<pq>
ishitatsuyuki, only most? Everything, really.
<ishitatsuyuki>
it's a dumb decision even when you restrict scale factor to integers
<pq>
only input events have fractional coordinates, down to 1/256th
<ishitatsuyuki>
because things like centering does create fractional coordinates
<pq>
ishitatsuyuki, no, and no.
<ishitatsuyuki>
Wayland just assume that use case doesn't exist. uh
<pq>
no
<ishitatsuyuki>
go on
<pq>
you said it's stupid, I say it's not. What's more to say?
<ishitatsuyuki>
uh ok, then we agree to disagree
<ishitatsuyuki>
but anyway. now I get why people were talking about that alignment thing. that surely is going to create a lot of inconsistency
<pq>
You can't split a physical pixel, which is where it comes from. GUI gfx pays absolutely no attention to Nyquist theorem, which means that any kind of resampling will lead to something bad. The assumption of integer positions acknowledges that.
<ishitatsuyuki>
but you can split a logical pixel. surface coordinates is in logical pixels.
<ishitatsuyuki>
on 2x scaled displays, therefore, you should be able to place a subsurface/popup at .5 coords
<ishitatsuyuki>
one use case, as I mentioned, is centered widgets
<pq>
The introduction of integer scale break that resampling idea a little bit, but it still maintains as much of the integer properties as possible. Fractional scaling just throws it all away.
<ishitatsuyuki>
IMO the solution is to use buffer coordinates
<pq>
No, you should not be able to position a sub-surface at 1 physical pixel precision on a scale 2 surface. That would lead to a lot of problems, as you may have noticed.
<ishitatsuyuki>
what kind of problem?
<pq>
windows with fractional sizes
<pq>
and fractional positions
<ishitatsuyuki>
...which is OK?
<ishitatsuyuki>
as long as they map to physical pixels
<pq>
No, it's not. Have you ever seem a GUI window resamples because it is 0.5 pixels off? That looks horrible.
<ishitatsuyuki>
it is obviously bad, but it is avoided as long as you operate in buffer coordinates/physical pixel units
<pq>
physical pixels may be different on each output, they are not a global coorindate system that a 2D compositor needs to operate
<ishitatsuyuki>
when the scale doesn't match resampling is inevitable
<ishitatsuyuki>
it's up to the client to decide which scale to adapt to
<ishitatsuyuki>
as long as it's adapted, buffer coordinate = physical pixel units
d_ed has joined #wayland
<pq>
Why are the integer surface coordinates a fundamental problem for fractional scaling? All you have to do is to align the surface-level geometry to integers.
<ishitatsuyuki>
that's right
<ishitatsuyuki>
I'll just pretend that rounding behavior inconsistency isn't an issue
<ishitatsuyuki>
The proper fix of using buffer coordinates probably will have a long way to go
<pq>
What inconsistency?
<ishitatsuyuki>
when you put a subsurface for example
<pq>
what about that?
<ishitatsuyuki>
since the coordinates are in surface units the subsurface would end up getting placed on fractional coordinates?
<ishitatsuyuki>
which, I'd just round them in my implementation
<ishitatsuyuki>
might become off-by-one, but probably ok
<pq>
No. The application arranged its contents so that sub-surfaces always coincide at integer positions with integer sizes in surface coordinate system.
<ishitatsuyuki>
you mean that the application always align things to multiple of 4 so it's still integer when it's scaled by 125% for example?
<pq>
I'm not sure where you got those numbers.
<ishitatsuyuki>
wdym by "sub-surfaces always coincide at integer positions with integer sizes in surface coordinate system" then
<ishitatsuyuki>
I interpret that as "use coordinates that are integer in both physical and logical coordinate system" which maps to the statement above
<pq>
mm, yes, I can see how you can come to that conlusion.
<pq>
I think of it from wp_viewport perspective: the source rectangle size and the destination rectangle size are decoupled and there is no need for them to have any common integer factor. Also source rectangle can be of fractional size.
<pq>
So with 125% buffer scale, you can still do 1 logical pixel size increments.
<ishitatsuyuki>
hm, interesting
<pq>
and each logical pixel increment takes 1.25 more buffer pixels - that you have to round up to be able to allocate and draw the buffer, but viewport uses the fractional buffer pixels.
<pq>
one thing I'm not sure is what problems does this pose to attempting to get 1:1 buffer to physical pixels on output when the scales match exactly, but the source rectangle is not quite integer.
<ishitatsuyuki>
guess I'll need to look into viewporter more, I'm not really familiar with that
rasterman has joined #wayland
<pq>
seems that also means that the physical destination rectangle on the output has the same factionality as the source rectangle on the buffer
<ishitatsuyuki>
I still retain my view that buffer coordinates are the right way to do things, since viewporter is more like a hack and it would be extremely confusing if it was a fundamental part of application development
<ishitatsuyuki>
if it was used as a fundamental part of HiDPI application development, I mean
<pq>
isn't the viewporter the way you intended to provide fractionally scaled buffers to surfaces?
<ishitatsuyuki>
nope. I'm implementing it through an explicit wl_buffer.scale replacement
<pq>
oh, that explains
<ishitatsuyuki>
because, yeah, you just said that the viewport source rect can't be fractional
<pq>
did I?
<ishitatsuyuki>
> one thing I'm not sure is what problems does this pose to attempting to get 1:1 buffer to physical pixels on output when the scales match exactly, but the source rectangle is not quite integer
<pq>
I said viewport source rectangle *can* be fractional.
tzimmermann has quit [Quit: Leaving]
<pq>
If you are working with scale factors only, I can imagine you get all kinds of problems, plus problems from floating point arithmetic being imprecise, and then you have round things to have positions and sizes make sense.
<pq>
for that reason viewporter uses rectangles, not scales
<ishitatsuyuki>
re: viewport, what I tried to say is that the dest rect has to be integer, which gets converted to... fractional physical size
<ishitatsuyuki>
I think that confused with your statement which might be unrelated.
<ishitatsuyuki>
I confused that*
<pq>
yes, which means that physical dest rect is exactly matching the buffer source rect, which is what you want for 1:1 pixels
<pq>
..when both use the exact same scale
<ishitatsuyuki>
hm, so much of black magic ;)
tzimmermann has joined #wayland
<pq>
the fractionality there is indeed unfortunate, but that is what happens with non-integer scales.
<pq>
Maybe it would make sense to have everything using floating-point coordinate systems, but retrofitting that to Wayland is... probably too much.
<ishitatsuyuki>
that's fair
<ishitatsuyuki>
viewporter kinda fits better, but it's has the drawback of being extremely hard to understand
<ishitatsuyuki>
I doubt tjat everyone reading the fractional scaling GitLab issue understood the whole idea of viewporter hack
<pq>
is that because of the interactions with all the other wl_surface state, or?
<pq>
It's not a hack in my opinion, though obviously I may be biased. It's a way to scale anything into anything.
<ishitatsuyuki>
it technically is, but there are no prior example that resemble this
<ishitatsuyuki>
which is also why I said it's hard to understand
<pq>
rathen than telling you have a scaling factor 1.2666453992, you tell the exact rectangles, source and destination.
<pq>
it also accommodates for non-square pixels that sometimes are found in video material
<ishitatsuyuki>
one reason I hate operating in logical coordinates is because it can cause nasty rounding errors
<ishitatsuyuki>
e.g. canvas gets mis-scaled with 175% zoom because canvas pretends to be integer-sized logically
<pq>
Right, so you *start* from logical coordinates and then compute everything else from those.
<ishitatsuyuki>
My opinion is that we should have *integer* physical size and *fractional* logical size
<pq>
All window management happens with logical coordinates, so it's best to start from those so that window management doesn't cause surprises.
<ishitatsuyuki>
in Wayland, you mean?
<pq>
yes
<ishitatsuyuki>
I can agree with that.
<pq>
That (frac logical coord) is a fair opinion, and I'd probably go with that if Wayland didn't exist yet.
<pq>
though if logical coordinates are fractional, then positioning things becomes quite tied to the output's physical pixels, I wonder how that would work.
<ishitatsuyuki>
in the case of CSS, it operates in floating-point for the majority of course then in the final phase rounds the coordinates so things look "hinted".
<ishitatsuyuki>
majority of the process*
<pq>
I suspect that as long as Nyquist theorem is a problem (physical pixels are so large that we can see them individually, or see e.g. aliased edges), there is always something that doesn't work, no matter which approach we take.
<ishitatsuyuki>
I don't think that's the problem, as long as you give application control of/access to the physical pixels
<ishitatsuyuki>
the application decides whether to display things in a hinted manner or to draw on fractional coordinates.
<ishitatsuyuki>
in the latter case, it would utilize alpha channels
<ishitatsuyuki>
(I'm thinking about subsurfaces)
raoni has quit []
<pq>
perhaps
<pq>
We just have to avoid the problem X11 had where the display server has no idea what parameters the app used for drawing, which leads to the problem that it's impossible for the display server to adapt the window image to other outputs.
<ishitatsuyuki>
while on this, I need to ask a thing about the viewporter method
<ishitatsuyuki>
how do you deal with the destination size being slightly larger due to the fractional part?
<ishitatsuyuki>
just pad the source by 1--2 pixel?
<kennylevinsen>
It would have been much better if we never had buffer scale but only viewporter...
<emersion>
no, because the compositor wouldn't have been able to compensate for an output scale != surface scale mismatch
<kennylevinsen>
ishitatsuyuki: an idea as part if the viewporter approach is to not use "scale factors", but communicate exact dimensions. The viewporter approach should only bypass scaling when things match exactly. Otherwise, if you're off by a few pixels it'll perform post scaling...
<kennylevinsen>
emersion: of course it would. The compositor side is identical - the viewporter approach handles the output scale == surface scale scenario - that is, if you viewporter request matches the output scale, scaling is bypassed and you get physical pixels
<ishitatsuyuki>
kennylevinsen: how does "communicate exact dimensions" work in practice? by specifying rounding behavior in the spec?
<emersion>
there might be multiple outputs each with their own scale, kennylevinsen
<kennylevinsen>
It handles arbitrary scaling, and integer scaling no worse than buffer scale setting. It just obviously requires viewporter to exist, and is a tad more complicated...
<ishitatsuyuki>
emersion: the logical (surface-coordinate) size remains the same, the application just needs to be notified of the new scale factor kicking in
<ishitatsuyuki>
... which is not a part of the protocol currently
<kennylevinsen>
emersion: yes, but we can have that right now too (you can set a fractional scale on one output, or different integer scales) and that will never be pretty unless we let surfaces submit per-output buffers. Not a priority in my opinion.
<emersion>
ah yes
<kennylevinsen>
ishitatsuyuki: no, target size in pixels. No ratios. Simple for fullscreens of course. Only do ratios if all else fails.
<ishitatsuyuki>
... but the user still sets a ratio, right? how does that work?
<kennylevinsen>
But the user-specified ratio might not align with anything useful. You want all your pixels in fullscreen, not some due to rounding.
<ishitatsuyuki>
sounds like that only works for the fullscreen case
<kennylevinsen>
The details were not hashed out, but idea would be that the application is told exact sizing in configure events, or could query exact sizing given a buffer.
<kennylevinsen>
It would absolutely work, question is how ugly it would get
<ishitatsuyuki>
how does that interact with subsurfaces?
<kennylevinsen>
Subsurfaces have their own scaling, so rinse and repeat. The lookup method might be better...
MrCooper has quit [Quit: Leaving]
<kennylevinsen>
if a ratio is used, it should only be done where the client dictates it's size anyway, should be fixed rather than float and have strict rounding rules. Won't work for fullscreen.
MrCooper has joined #wayland
<kennylevinsen>
But subsurfaces will in general be a pain, as nothing works unless we allow shifting the subsurfaces for alignment...
<kennylevinsen>
My perfect world only has physical pixels :<
<kennylevinsen>
And no fractions...
<emersion>
doesn't look like a perfect world to me…
<emersion>
the meaning of "physical pixel" can change as your plug/unplug/reconfigure outputs
anarsoul has quit [Ping timeout: 480 seconds]
<ishitatsuyuki>
is that much different from moving a window to a different monitor?
flacks has quit [Quit: Quitter]
<kennylevinsen>
Yeah, but I suspect life is easier for scaling bypass on multi-dpi if you always position/size in physical pixels. Logical pixels seem to make things easy to just apply output-wide scaling, but I don't think it has downsides when it comes to scaling awareness and dealing with mixed outputs and scales...
flacks has joined #wayland
<kennylevinsen>
E.g. rounding wouldn't be a problem - would be up to the client, compositor wouldn't care. Alignment would always work. Surfaces and multiple outputs might still be blurry on one, but eh.
<kennylevinsen>
*surfaces on multiple outputs
anarsoul has joined #wayland
<pq>
ishitatsuyuki, with viewporter I think it is impossible to reach a non-integer destination rectangle.
<pq>
maybe I didn't understand the question...
hendursa1 has joined #wayland
hendursaga has quit [Ping timeout: 480 seconds]
<pq>
kennylevinsen, when you say "physical pixels", whose physical pixels do you mean? Would it involve the client telling the compositor that it is using that particular wl_output's pixels in its buffer?
<pq>
so the surface coordinate system's "scale" would depend on what wl_output the client says it is, and then the coordinate system would be in that output's physical pixels?
<pq>
meaning that everything that uses surface-local coordinates, now uses this particular coordinate system that may differ on every surface
<pq>
input events, surface position, damage...
<pq>
*sub-surface position
<pq>
you know what? That might just be doable. A hell of a surgery to all compositors, but doable in a backward compatible manner.
<pq>
well, as an extension equivalent to that, maybe
<pq>
another multi-year project
hexhive has joined #wayland
<kennylevinsen>
Heck we could do per output buffers if we wanted to. wl_surface.attach_for_output(wl_output, wl_buffer)
<kennylevinsen>
but specifying what was native would work too, so the compositor knew when to translate.
<pq>
I don't think per-output buffers would solve the coordindate system problems
<pq>
they would get per-output content perfect, but not things like sub-surface size & position
<pq>
or even surface position in general
<kennylevinsen>
Hmm, input would also need to specify which of the buffers it targeted. And the client would need to know what rect intersects what output.
<pq>
with wl_surface.set_coordinate_system(nullable wl_output) the compositor can position the window based on that output's grid, to guarantee 1:1 pixel match on that output.
<kennylevinsen>
Yeah, that has fewer corner cases...
<pq>
if the surface was on a totally different output, then just extrapolate the intended output's grid over there - which results in crap, but that's what they asked for
<DemiMarieObenour[m]>
Is there a reason that situation cannot be a protocol error?
<daniels>
because it would kill clients when you dragged them from one output to another
<DemiMarieObenour[m]>
Can clients be expected to respond to such dragging by calling `set_coordinate_system` on all of their windows, then acknowledging the drag?
<DemiMarieObenour[m]>
s/all of their/their dragged
<kennylevinsen>
No, a window can intersect multiple outputs, so it can only pick one "main" in that case. The compositor will need to project between coordinate systems if it doesn't line up.
<kennylevinsen>
Also, it is not a requirement for applications to even support scaling.
<kennylevinsen>
Much less an extended version
<DemiMarieObenour[m]>
Would be interesting to have the concept of a protocol warning ― something that can’t be outright forbidden, but which probably indicates a bug.
<daniels>
it could but it also makes it quite janky, since your drag just abruptly stops if a client isn't immediately responsive
<kennylevinsen>
The compositor can print warnings if it wants to. Only errors matter on the wire. Note that soft errors can exist as part of a protocol, as opposed to true fatal protocol errors.
<dottedmag>
I had a look at what macOS draws during drag between outputs: the window is drawn for the output that's considered "current" (where most of the window resides), and for another output the content is rescaled to match the window size. They don't draw the window on several outputs at once though normally, only as a guide during drag.
<kennylevinsen>
Yeah macos behavior is a bit odd, but definitely solves the multi-output problem
<ishitatsuyuki>
I don't think macOS' behavior is odd in anyway, and isn't it also supposed to work that way in Wayland?
<ishitatsuyuki>
Mutter seems to for some reason replicate Windows's behavior, retaining the pixel-to-pixel relationship and giving an abrupt change in size once the window is on the new output
<pq>
DemiMarieObenour[m], in Wayland we have the principle that the compositor cannot ever wait for a client to respond to something. The compositor must always be able to run and repaint at any time. This principle keeps the system more responsive.
<ishitatsuyuki>
(in contrast to Windows where blocking RPC calls are quite common, and suspending a process in debugger can result in weird things to lock up in your system)
<pq>
DemiMarieObenour[m], I have floated the idea of a Wayland nagging interface before, through which compositors could deliver messages about not-good but not-illegal client behavior. But client toolkits would need to implement that...
<ishitatsuyuki>
pq: back to the viewporter question (sorry went for dinner), I meant that the destination rectangle would have a fractional physical size if fractional scaling is used. how do we deal with the pixels that are only partially covered?
<pq>
ishitatsuyuki, Wayland does not say that a window cannot straddle multiple outputs indefinitely. It sounded like on macOS it will be strictly transient instead. A Wayland compositor could implement the same.
<ishitatsuyuki>
not sure how the "window cannot straddle multiple outputs indefinitely" part relates
<pq>
ishitatsuyuki, that's the good question I don't have a good answer to.
<ishitatsuyuki>
yeah, I've been thinking about that too and haven't reached any good conclusion
<ishitatsuyuki>
oh hmm, maybe I misunderstood macOS' behavior
<pq>
ishitatsuyuki, I thought the question was about "how long", not about "how is it drawn". I.e. if the WM moves the window immediately fully to the target output when the drag ends, then there is no worrying about the quality of rendering on multiple outputs simultaneously.
<ishitatsuyuki>
makes sense, thanks
<pq>
if that was what kennylevinsen meant?
<pq>
and dottedmag
<dottedmag>
yep
<kennylevinsen>
Yeah, macOS only shows a window on one output at a time (except during window drag), while pretty much everyone else (most Wayland compositors included) will allow a window to sit between two outputs and render on both.
hexhive has quit []
NeoCron has joined #wayland
UndeadLeech has joined #wayland
<UndeadLeech>
The `callback_data` for frame requests is supposed to be the current time in miliseconds stored in a 32bit integer. However this will overflow every 49.7 days. It seems like this is supposed to be monotonic and always increasing, are applications supposed to deal with an occasional "reset" or is Wayland just not supposed to run more than 49.7 days?
<kennylevinsen>
The former. The purpose of the time is to allow you to compare to previous frames, and there is no need to compare frame durations more than 49 days. :)
<UndeadLeech>
Ah, so clients that just drop everything that's not monotonic without having special consideration for overflow are just broken then. Would probably be interesting to see how many run into issues with that.
<UndeadLeech>
Seems like an easy mistake to make at least if you just store the last frame's timestamp and check that the current one is bigger.
<pq>
UndeadLeech, it's more like apps would compute the difference between two timestamps and by the rules of unsigned subtraction underflowing the result would still be correct?
<pq>
UndeadLeech, although, I'd like to recommend that no-one uses the frame callback payload for anything. If you want timings, use the feedback extension.
<UndeadLeech>
Not sure what you mean, but if you don't adjust for the total 'distance' between the two timestamps an overflowed value can't really be distinguised from an outdated one.
<pq>
UndeadLeech, you know the value will always only march forward, so what's the problem?
<UndeadLeech>
Because after 49.7 days it will march backward.
<SardemFF7>
no, the actual value will be less, but you know it’s an overflow by design
<pq>
you can probably also assume that your frame to frame time cannot exceed, say, an hour.
<SardemFF7>
so (new - old) will still give you the correct diff
<UndeadLeech>
Yeah, you know it's an overflow. But going from 12304897230478 to 0 is still backward.
<UndeadLeech>
Well you only know if you considered this in the first place.
<pq>
why do you care if its backward or overflow? The result is the same.
<kennylevinsen>
It is well-defined with no information loss though
<pq>
but really, do not use this value to begin with
<UndeadLeech>
Yeah I'm just curious.
<DemiMarieObenour[m]>
<pq> "Demi Marie Obenour, I have..." <- A “nagging” interface could be part of `wl_fixes` 😉
<pq>
DemiMarieObenour[m], we don't tend to create "everything we could think of" extension.
<pq>
instead, separate extensions for separate things
<DemiMarieObenour[m]>
pq: very much valid
<UndeadLeech>
Also pq I was mostly thinking about this creating issues for clients that drop "outdated" frame requests, rather than clients using it to do some timing stuff. Because they might stop rendering after the overflow.
fmuellner has joined #wayland
<pq>
UndeadLeech, wow, I've never heard of that idea before. I certainly hope no-one used it.
<pq>
you're supposed to track the identity of the wl_callback object instead
<UndeadLeech>
Maybe I'm underestimating people, but I'd be surprised if nobody ever accidentally did that.
<SardemFF7>
you’re pretty much expected to have only one request “pending” at a time, because you’d wait for the previous one before committing a new buffer
<pq>
or at least you would destroy the previous wl_callback before creating a new one
<DemiMarieObenour[m]>
pq: so my current idea is to have a `wl_fixes` interface that serves two purposes:
<DemiMarieObenour[m]>
2. By _instantiating_ it, a client guarantees that it supports a `warning` event, either on itself or on `wl_display`.
<DemiMarieObenour[m]>
1. By _exposing_ it, a compositor promises that a destructor request for `wl_registry` exists and can be used.
<DemiMarieObenour[m]>
It is basically a workaround for `wl_display` and `wl_registry` being unversionable.
<pq>
DemiMarieObenour[m], sounds like you intend for libwayland-client to create a wl_registry object for itself. That would be the first time. But what if libwayland-client does not understand wl_fixes, yet some poor application goes and binds it?
<pq>
like wayland-info
<DemiMarieObenour[m]>
pq: oops, yeah that won’t work.
<pq>
hm, no, wayland-info has no reason to bind it, but anyway
<pq>
I guess you could document that one must never bind this interface...
<DemiMarieObenour[m]>
(unless one is a Wayland client library implementor)
<DemiMarieObenour[m]>
A cleaner design might have a request that contains the versions of `wl_display` and `wl_registry` supported by the client, and to which the server replies with an event containing the versions it support.
<pq>
yeah, but first the client needs to know that the server can handle those requests
<DemiMarieObenour[m]>
that can be handled through normal versioning
<pq>
what normal versioning?
<DemiMarieObenour[m]>
of `wl_fixes` itself
<pq>
oh, that
<DemiMarieObenour[m]>
To be clear, the name is the least important part of this.
<pq>
maybe you have something there
<DemiMarieObenour[m]>
Thanks!
<pq>
ManMower, you take over ^ ;-)
<DemiMarieObenour[m]>
Going AFK for now; will be back in ~20min
<swick>
it would be nice if there was a document which lists all bugs and bad designs that can't be fixed because of backwards compat
<swick>
basically a "if you create wayland 2.0 don't make those mistakes"
<pq>
swick, I think we have a couple, they are issues in gitlab with the label Wayland 2.0 or something.
<swick>
oh
<ManMower>
on no, I've been tagged in
<swick>
didnt know there was a tag for that
<swick>
protocol-next apparently
<pq>
oh, yeah, probably
<swick>
but they don't include wayland-protocols and things which mostly work and require lots of work to fix so nobody bothers to
<swick>
aaanyway, aint nobody got time for that
<pq>
I just haven't been keen on filing Wayland 2.0 issues, because I don't expect it to happen, and I don't want to scare people away from Wayland 1.0 either
<swick>
on the bright side a wayland 1.0 to wayland 2.0 translation layer might not be that hard to create
<pq>
don't tempt me ;-)
<swick>
but yeah, there is still a few really hard problems that we should try to solve before we start thinking about a 2.0
<ManMower>
maybe we need an overarching wayland 2.0 issue with a list of "unfixable" bugs all in one place...
<ManMower>
and we can grumpily leave it sit until it reaches critical mass, or a use case that demands fixing one/all of those problems arises
<ManMower>
wl_bind_client_version(major, minor); before display connect. ;)
* ManMower
runs and hides
<emersion>
uh uh, global state
<pq>
if we try, I'm sure we can squeeze in OpenGL style dispatch tables too
<emersion>
can we get atoms too?
<ManMower>
efl has them in the form of the "aux_hint" protocol.
<daniels>
or wl_2 which has one event sent on bind, delivering you an FD to a socket which speaks a backwards-incompatible protocol version
<swick>
I honestly can't tell if some of those ideas are jokes or not
<DemiMarieObenour[m]>
`wl_fixes` is certainly not a joke
<DemiMarieObenour[m]>
the whole idea behind it is to allow some of those “unfixable” bugs to be fixed ― `wl_display` and `wl_registry` versioning are just two of them
<pq>
I think seriousness left when ManMower started talking. ;-)
<pq>
except ManMower's jokes tend to be true in EFL
<ManMower>
I don't really like the idea of "bind this protocol object, it makes subtle changes to the behaviour of a bunch of other protocol objects, and when we bump its version it might make changes to even more"
<ManMower>
without having spent a second trying to implement it, my intuitive leap is that it will descend into a scary rats nest of conditionals inside libwayland (and other implementations)
<ManMower>
it might not be awful in the first revision, but it feels like it's the first step on a slippery slope
<emersion>
yeah, same
<emersion>
this adds some exceptions to some fundamental wayland rules
<DemiMarieObenour[m]>
Agreed
<DemiMarieObenour[m]>
Binding an object should not have nasty side-effects
<DemiMarieObenour[m]>
`wl_fixes` is only for stuff that cannot be fixed in any other way
<ManMower>
that implies wl_fixes is the only way to fix these things, and I don't think we've reached that conclusion yet
<ManMower>
but I also want to back up and assess whether they're really worth fixing Right Now
<ManMower>
because yeah, it absolutely sucks that you can't delete a registry
<ManMower>
but it really doesn't cause any trouble in the real world at all?
<ManMower>
(apart from when EFL made new registry objects for like every new window, but we fixed that pretty quickly!)
<ManMower>
what's the general worst case? gstreamer makes a reg object, mesa makes a reg object, your client makes its own reg object. we get some noise on seat/output traffic and we lose a few dozen bytes of ram?
<ManMower>
yeah, it's more technically pure to have the destructor, but it's less technically pure to get there via a bind with side effects, so it's really a toss up
<DemiMarieObenour[m]>
So `wl_fixes` doesn’t actually need a bind to have side effects. That was a proposal I added later.
<emersion>
maybe we could stuff a version number in the socket ancillary data
<ManMower>
DemiMarieObenour[m]: hi, I'm Derek, I'm one of the people stonewalling you on that impl. (sorry!)
<DemiMarieObenour[m]>
ManMower: Hi Derek, I’m Demi, the woman who came up with this whole idea.
<ManMower>
are you actually running into a real problem with memory leaked from wl_registry objects that can't be solved by just not creating a large number of registry objects?
<DemiMarieObenour[m]>
I came up with wl_fixes as a way to resolve fundamental problems with Wayland. I do not claim it is the only solution, or even the best solution. I do claim that, in my opinion, it is better than no solution.
<ManMower>
I understand that wl_registry's lack of destructor isn't the only problem
<ManMower>
but can wl_fixes also solve the unversionability of wl_buffer objects?
<ManMower>
is this a complete solution to all the "design issues" so we won't have to have another distinct fix for something else we just haven't thought about much yet?
<ManMower>
I kind of think the way forward would be to amass a bigger list than just this one issue. it may be that "wl_fixes" (clearly we could bikeshed the name forever, but that's not key) is indeed the way forward, but I think it needs to become part of a much large discussion before we charge of to fix "just" the wl_registry lack of destructor
<ManMower>
(which I think everyone agrees is annoying)
<DemiMarieObenour[m]>
I am not running into a real problem with wl_registry leaking memory. It does pose a problem for a Rust Wayland client library idea I had, but that implementation hasn’t passed the “idea in my head” stage.
<DemiMarieObenour[m]>
I am not sure about the other design issues. I would like to think that it is, but it would be hubris to actually claim so.
<ManMower>
fair enough
<pq>
DemiMarieObenour[m], why is the lack of destructor request a problem for a Rust Wayland client lib?
<pq>
wl_registry_destroy() does exist in the C API even. It just doesn't send a request.
<DemiMarieObenour[m]>
pq: It is an ugly special case, that is all.
<pq>
we have more interfaces that do not have a destroy request, and those objects get destroyed by other means on server side. A destroying event is an existing pattern.
<DemiMarieObenour[m]>
Indeed it is. My understanding is that there are some interfaces that have a destroy request, and others that have a destroy event, but `wl_registry` is the only one that has neither.
<DemiMarieObenour[m]>
Once `wl_fixes` or similar is implemented, `wl_registry_destroy()` could be made to send a request if the server supports it 😄
<ishitatsuyuki>
sounds so overengineered
<pq>
old versions of several interfaces used as globals lack a destroy request, they got a request named "release" later for that purpose.
<pq>
so depending on the object version, you may or may not have destructor request
<ishitatsuyuki>
btw, what can go into a revision of Wayland core, and what goes into an extension?
<DemiMarieObenour[m]>
ManMower: I wholeheartedly agree that amassing a bigger list is the way to go. Just because the lack of a `wl_registry` destructor is what inspired me to create `wl_fixes` does not mean it should be the only motivation.
<pq>
ishitatsuyuki, there very few Wayland interfaces that cannot be added to by bumping their version. OTOH, we usually prefer extensions rather than version bumps so that compositors can pick and choose what to support.
<ishitatsuyuki>
I see
<pq>
ishitatsuyuki, if you bump interface version +1 for Foo, then to +2 for Bar, it means that a compositor supporting Bar must also support Foo.
<pq>
sometimes that's not nice, sometimes it's perfectly reasonable
<ManMower>
which I suppose can lead to compositor authors not caring about version 2, 3, 4, 5, 6 of something, and then being interested in version 7 and neating to immediately write all of the missing features. heh
<ManMower>
*needing
<DemiMarieObenour[m]>
Looking at <https://gitlab.freedesktop.org/wayland/wayland/-/issues?label_name%5B%5D=Protocol-next>, I don’t know if wl_fixes could solve wayland/wayland#98, as that is a wire protocol problem. There is precedent in the X11 BIG-REQUESTS extension but I really do not know if we want to go down that route, especially since there may be an alternative, which I posted as a comment to that issue.
<ManMower>
ugggggh, zombie objects. yeah, that's an unrelated kind of pain.
<DemiMarieObenour[m]>
wayland/wayland#120 seems like it can be solved with just a version bump. A compositor can just never send pressure events, so this does not cause the problem pq described. On the other hand, I don’t know if it is even worth fixing, due to the human factors limitation mentioned [here](https://gitlab.freedesktop.org/wayland/wayland/-/issues/120#note_295074) which cannot be robustly worked around in software.
<ManMower>
I think samsung "fixed" that by doing an implicit flush any time an fd was marshalled
<DemiMarieObenour[m]>
yes, that is the proposal I mentioned
<DemiMarieObenour[m]>
Using `sendmmsg` and `recvmmsg` can avoid the huge overhead.
<DemiMarieObenour[m]>
And the need for flushing.
<DemiMarieObenour[m]>
I would only support touchpad and touchscreen pressure events for devices that had actual hardware pressure sensors.
<DemiMarieObenour[m]>
And in any case this is out of scope for `wl_fixes`.
<ManMower>
I didn't mean to imply that you should spend your day reading our immense backlog of issues. :/
<DemiMarieObenour[m]>
I only looked at issues with ~"Protocol-next"
<DemiMarieObenour[m]>
I consider fixing zombies to be far more important than the wl_registry leak. I just was not aware of the zombie issue.
<ManMower>
zombies have been my personal nightmare for a long time now.
<DemiMarieObenour[m]>
if `wl_fixes` is exposed then this request is supported.
andyrtr has joined #wayland
<DemiMarieObenour[m]>
When a zombie object is created by an event, immediately send a `delete_id` request on it.
<DemiMarieObenour[m]>
* request on `wl_display` that names it.
<DemiMarieObenour[m]>
This assumes that the object does not have any destructor events of its own, but that can be specified in code generated by wayland-scanner.
Doraemon has joined #wayland
<DemiMarieObenour[m]>
And if there are destructor events, the leak does not exist as the server will eventually destroy the object.
creich_ has joined #wayland
NeoCron has quit [Ping timeout: 480 seconds]
creich has quit [Ping timeout: 480 seconds]
mtretter has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Remote host closed the connection]
d_ed has quit []
d_ed has joined #wayland
d_ed has quit []
mtretter has joined #wayland
slattann has joined #wayland
rasterman has joined #wayland
slattann has quit []
tzimmermann has quit [Quit: Leaving]
eruditehermit has quit [Ping timeout: 480 seconds]