ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has quit [Ping timeout: 480 seconds]
ongy[m] has quit [Quit: Client limit exceeded: 20000]
marbol has joined #wayland
Brainium has joined #wayland
privacy has joined #wayland
marbol has quit [Quit: Quit]
kts has joined #wayland
<Company>
daniels: so it's basically for video players so they can send a black pixel buffer as the background and then put the video dmabuf on top?
<Company>
tiny rendering engine so to say
<Company>
I was wondering if there's any benefit I could get by making backgrounds in GTK into subsurfaces, but I suppose not - I have to send the whole window anyway and I get a background clear via the LoadOp - and it's irrelevant if I use the background color or transparency
Guest4880 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest5101
Brainium has quit [Quit: Konversation terminated!]
Dami_Lu has quit [Remote host closed the connection]
robert_ has joined #wayland
Company has quit [Quit: Leaving]
bim9262 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Guest5101 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest5107
privacy has quit [Remote host closed the connection]
kts has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Guest5107 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest5112
i509vcb has quit [Quit: Connection closed for inactivity]
Dami_Lu has joined #wayland
sima has joined #wayland
kts has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Remote host closed the connection]
mbalmer has joined #wayland
ambasta[m] has quit [Quit: Client limit exceeded: 20000]
<emersion>
there was a talk at XDC describing power savings for messages and browser apps when using KMS offload for solid color planes
kts has joined #wayland
glennk has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
qaqland is now known as Guest5131
Guest5131 has quit [Read error: Connection reset by peer]
qaqland has joined #wayland
pochu has quit [Quit: leaving]
<pq>
danieldg, wl_surface.offset is in surface-local coordinates, not in any pixels. The same as wl_subsurface.set_position. The design is consistent like that.
<pq>
I've always wondered if the fractional scale problem was not solved slightly better by strictly separating rendering resolution (keeping it strictly integer scale) and UI size (widget and font sizes). The trouble with that is that if you have an existing framework like a toolkit or API that only understands "pixels", it's probably going to be extremely painful to fit in.
<pq>
the same story as with all innovative Wayland design aspects, like the lack of an absolute coordinate system
<pq>
DemiMarie, the most fundamental problem with dpi is that you have to assume a standard viewing distance and eye sight.
<pq>
...which is not unlike video colorimetry standards design for color instead of size/resolution - and they do also define viewing distances
<kennylevinsen>
pq: so, using 2x integer scale on the wire but rendering UI widgets smaller to achieve, say, 1.5x perceived scale?
<pq>
yes, I believe we've been over that before. :-)
<kennylevinsen>
while it would solve the cordinate system issues, it would break split output rendition where the compositor scales the minority output to match
<kennylevinsen>
and definitely sounds like a way to add even more client complexity...
<pq>
Yes, it would. It's definitely different from the old ways.
<pq>
then again, is it not an explicit non-goal to make the UI the same physical size on different outputs with different dpi?
<kennylevinsen>
I would consider it a goal to consistently follow the user-specified scale, so a window portion on a 1.5x monitor is enlargened 50% compared to its portion on a 1x monitor
<pq>
one could choose a single global UI size, which is then a little different on outputs where the integer redenring scale does not quite match the output resolution, and clients would not need to resize widgets when moving from output to another, or...
<kennylevinsen>
which is not the same thing as physical size, as user-preference may dictate something other than that
<pq>
choose a separate UI size for each output and tolerate the UI resizing that happens when switching outputs
<pq>
kennylevinsen, how does a user specify a scale, so that we have a definition of what makes it consistent?
<pq>
if you refer to physical output pixels, then that is physical size
marbol has joined #wayland
<kennylevinsen>
I consider consistency only with respect to the individual outputs - if all UI widgets on one output roughly follow the same sizes, as dictated by the user-specified scale over some base UI size, then it is consistent
<pq>
ok - that's a given in my suggestion to begin with
<kennylevinsen>
I did not see it that way
<pq>
aah, but you must be thinking of windows spanning multiple outputs?
<kennylevinsen>
yes
<pq>
okay, that's different
<pq>
I find that the desire to keep line art crisp is in direct conflict with the goals of fractional rendering scales if the compositor is wanted to automatically scale images.
<kennylevinsen>
In the proposal, giving any priority to the rendition on portions on other outputs was a non-goal, and may be blurry and/or have terrible line-art
<kennylevinsen>
but I was expecting it to be roughly the right size
<kennylevinsen>
("right" being that e.g. rendered font size matched user expectation)
<pq>
kennylevinsen, hmm... or is it different? If you use a single UI size across all outputs, and compositor compensates the integer rendering scale differences, then isn't everything on a output the same size, regardless of spanning multiple outputs?
<pq>
I think it is, because the point of using a global UI size is that clients do not need to resize their widgets when switching from output to another.
<pq>
clients only need, if they want to, re-render the window in a different integer scale after switching from output to another.
<kennylevinsen>
assuming I understood your idea: If you have an output at 1x (1x render scale, 1x "UI scale"), and another at 1.5x (2x render, 0.75x UI), overlapping both outputs with a compositor that only compensates for render scale would lead to one part being effective 0.75x while the other effective 1.5x
glennk has quit [Ping timeout: 480 seconds]
kts_ has joined #wayland
<pq>
kennylevinsen, no, you have two different UI sizes there. Try using just one, and let go of the non-goal of making UI physically the same size (pixels nor mm) on different outputs.
<pq>
the whole point is that the compositor does not compensate for UI size at all
<kennylevinsen>
I never attempt to achieve same physical size, only "size consistent with output"
<pq>
you need pick a compromise UI size that is roughly good on each output simultaneously while being optimal on possibly none
<kennylevinsen>
with each output having a different user-selected preference for whatever reason - distance, size, dpi
<pq>
so, you could pick: UI size 125%, output A scale 1x, output B scale 2x
kts has quit [Ping timeout: 480 seconds]
<kennylevinsen>
I don't think that would be particularly useful then
<pq>
the UI is a little too big on output A, and little too small on output B, maybe, but it's perfectly usable and crisp everywhere
<kennylevinsen>
it would only handle monitor mismatches well if they are mismatched roughly 2x
<pq>
maybe it's easier to understand if I define UI size in surface-local coordinate units instead
<pq>
yeah, that's what I'm trying to explain: things on screen might never be optimal size on any output, they will be *crisp* and *perfectly usable* on all outputs.
<pq>
then you get used to it, and don't even notice it's not optimal
<kennylevinsen>
If UI scale is shared amongst all outputs, it becomes a common factor and can be ignored when it comes to output adjustment
<pq>
I'm not sure what you mean, but yes, that's my point, I guess.
<kennylevinsen>
I would personally much rather give up on allowing a window to be displayed on multiple outputs than I would give up fully output-independent scaling
<pq>
The UI size is essentially in surface-local coordinates, it's not quite a multiplier or a factor. "How big is the button" while keeping line art in surface-local coordinate units.
<pq>
you still have output independent *integer* scaling
<pq>
However, you need pick such an UI size that given the integer scaling, the UI works for you on all outputs.
<kennylevinsen>
yes but 1. that is not currently sufficient to account for laptop panels, 2. I do not want to give up 25%-50% of my screen real estate on one monitor to make UIs on *other* outputs usable
<pq>
it may not be optimal on any output, but the image will be crisp and totally usable
<pq>
once you have used that a couple hours, you don't even remember what "optimal" was
<kennylevinsen>
I don't agree - screen real estate is quite important to me, and I do not intend to give it up before degrading vision requires it
<kennylevinsen>
I pick monitors and dpis to maximize it
<pq>
okay, and are you willing to give away crisp line art as the trade-off?
glennk has joined #wayland
<kennylevinsen>
I see no reason to give it up for content local to the monitor
<kennylevinsen>
if you can apply the UI scale globally, you can apply it locally
<kennylevinsen>
I am willing to give up any and all ability to show the window on more than one output at a time though
<pq>
but you said you care about windows that span multiple monitors
<kennylevinsen>
No, but wayland currently does
<pq>
no, Wayland does not - well, I'm not including the current fractional scaling extension here
<kennylevinsen>
well it is fully well-defined and handled in the integer case, and the fractional case mimicked it with the degraded requirement that "crisp" was only a goal on the "majority output"
<kennylevinsen>
there was discussions about that, and I made a small chart of the various platform behaviours
<kennylevinsen>
]hang on
<pq>
don't bother :-)
<pq>
like I said, we had discussed this all before
<kennylevinsen>
I was only planning to find the chart, not the discussion ;)
<pq>
I think my suggestion would also allow the behaviour you want by including the choice between per-output and global UI size, while still keeping the integer rendering scale separated.
<kennylevinsen>
yeah that I could work with
<pq>
then, if a compositor wants to compensate also for UI size mismatch between surface and output, if can do the blurry fractional scaling.
<pq>
*it can
<kennylevinsen>
One could also add that the compositor tried to also apply the UI scale difference, at the cost of borking rendition of secondary outputs to match scale
<kennylevinsen>
yeah
<pq>
I mean, compositors are already free to blur out any window at a whim anyway. :-)
<kennylevinsen>
I suppose this could be done by simply allowing the client to specify what UI scale was used
<kennylevinsen>
that is, they receive a fractional scale and can decide to decompose that to an integer buffer scale and a UI scale
<kennylevinsen>
the compositor just needs to know that the 2x buffer shouldn't be further downscaled to achieve 1.5x
<kennylevinsen>
if we ignore individual pixel addressing, it would solve the subsurface problem of fractional-scale-v1 without the change of coordinate system
<kennylevinsen>
zamundaaa[m]: you might be interested in the above
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
elderbear has left #wayland [#wayland]
<zamundaaa[m]>
It's certainly an interesting idea, but you're resizing the surface to non-integer logical sizes (like 510 * (2/1.5)=382.5), without also scaling the requests related to the logical size. And if you round that value, you end up with a different window size from what the compositor requested, which may resize the window or in some cases throw a protocol error
<zamundaaa[m]>
So to do that well and race free you'd need a way to specify those fractional surface sizes, window geometries, configure events and a few other things... You'd end up with something like fractional-scale-v2
marbol has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
<pq>
kennylevinsen, yes, as always: the compositor tells end user's preference to client, client tells the compositor what it actually used, and the compositor compensates the mismatch if any and if end user so wants.
<pq>
zamundaaa[m], hmm, but window sizes should not be fractional at all in my suggestion. They are always integer in surface-local coordinate system like vanilla Wayland. So I'm not sure where the discrepancy between compositor suggested and actual size could arise.
<kennylevinsen>
hmm, I suppose a client submitting 2x buffer scale + 0.75x "UI scale" is no different than 1x buffer scale and 1.5x "UI scale"
bindu has joined #wayland
<zamundaaa[m]>
It is very different
<zamundaaa[m]>
pq: I was talking about Kenny's idea of decomposing the fractional scale factor
<pq>
I think I see it; compositor suggested size, even if surface-local, always assumes some UI size as well. If the compositor then compensates for UI size in addition to rendering scale, the window changes size relative to other windows in the scenegraph.
<kennylevinsen>
ah disregard my last statement, that was a brainfart :)
<pq>
zamundaaa[m], oh, that interacts with surface size in compositor vs. client?
<zamundaaa[m]>
Yes
<pq>
alright
<pq>
but I do see a (similar?) problem with my idea as well
<kennylevinsen>
yeah I believe they are identical - either way they operate in 2x logical space towards the compositor, with a 0.75x scale on content
<pq>
UI size would need to be factored into the configured size machinery
<pq>
I'd probably attempt to keep configured size as is (surface-local), and pre-scale it according to the compositor-side UI size and rounding it to a suitable integer before sending it to the client.
<pq>
for maximized and fullscreen states the compositor would just use the right configured size without regard to UI size
<pq>
....erm
<pq>
complicated to think about what happens then :-)
luna has joined #wayland
<pq>
maybe UI size mismatch would not be compensated for in the compositor for maximized/fullscreen states? or any state where the compositor relies on getting a specific surface size from the client?
<pq>
there is already the ack_configure for window state changes, and if the client is going to follow the recommended UI size, it has already done so when acking.
<pq>
all I can really say for sure is that all this would need to be tried before all the problems are found
<pq>
would be interesting but I have this other thing to work on first
<kennylevinsen>
agreed, and understandable :)
<kennylevinsen>
it's also been a while since I looked at the v2 proposal, needs another look
<pq>
My instinct tells me that letting wp_viewport access out-of-buffer areas, sampling some client-defined or completely transparent color there, is not a good idea. Would be nice to avoid that to begin with.
<pq>
heh, what started as "I want sealed ICC file fds" is going to end with "let's implement a per-client worker thread framework in a compositor" - which is a good idea.
<emersion>
i don't know about per-client
<pq>
MrCooper had a good argument: don't let clients DoS each other
<pq>
by e.g. sending a fd that takes ages to read
<emersion>
how can a process have control over this though?
paulk has joined #wayland
<pq>
explicit guaranteed control? If the compositor accepts a pipe or a socket, that's obvious. For regular files, not easily. It would happen more by accident than by malice.
<pq>
e.g. a spinning disk with heavy other I/O going on
<kchibisov>
emersion: to activate in a window currently present on workspace.
<kchibisov>
though I guess clients can use `Suspended` state?
<pq>
though I don't think I've ever seen anyone claiming that an app needs to put a window at a specific z-level, it's always on top - thinking of absolute positioning
<kchibisov>
pq: layer-shell ¯\_(ツ)_/¯
<pq>
right ;-)
<d_ed[m]>
emersion: the use case is you have a browser with tabs on desktop1 and on desktop 2
<d_ed[m]>
you're on desktop 2 and open a link. Which window gets the new tab?
<emersion>
right, and i said i'd prefer the compositor to pick, iirc
<kennylevinsen>
in order for a decoded workspace to be of any use you'd also need another protocol to tell each toplevel what workspace it is currently on
<d_ed[m]>
could maybe work but that still requires something new to exist
mblenc has quit [Ping timeout: 480 seconds]
<kennylevinsen>
alternatively, one could maybe add a preferred_surface event somewhere in xdg_activation_v1?
<d_ed[m]>
This situation can come up in a multi process setup too
<kennylevinsen>
hmm, that is more annoying
<emersion>
workspaces are just one example, i think there are more
<kennylevinsen>
but I guess you could have an xdg_activation interface that lets you query a token before use without consuming it first
<emersion>
meh
<emersion>
for example, on sway each output has a workspace
<kennylevinsen>
I feel less for turning the token into a data container though :/
<emersion>
if i have 2 firefox windows, one on an workspace not displayed, one an workspace on an unfocused output
<emersion>
i want that window to be activated, even if the workspace is not currently focused
<kennylevinsen>
ugh
<emersion>
IOW, "same workspace" is not a good enough policy
<emersion>
some compositors might have more groupings, different concepts
<emersion>
so i'd really prefer not to tie any of this to workspaces
<zamundaaa[m]>
kennylevinsen: just look at MR 203. It solves this nicely, without having to patch every single client to know about every single compositor concept
<zamundaaa[m]>
The client gives a list of toplevels to choose from, and the compositor returns which the client should activate (and open the new document in)
<emersion>
yeah, i think !203 is on the right track
<kennylevinsen>
so preferred surface, but where you know to try the next client
<emersion>
this doesn't address the multi-process case
<kennylevinsen>
well with new_candidate_preferred you can try from the next process?
<kennylevinsen>
but the compositor does not in advance know all candidate surfaces across all processes, so it cannot make a good decision in complex cases
<emersion>
i think it's fine security-wise, because xdg-foreign is designed to be used specifically for multiple processes that form the same logical client/app
<kennylevinsen>
having to xdg-foreign your own toplevels for single-process is a little silly, but manageable
<emersion>
you don't have to -- you can pass directly an xdg_toplevel in that case
<emersion>
oh no you can't
<zamundaaa[m]>
Yeah that isn't possible. We could add add_window_candidate_surface back again that takes a wl_surface, but a list of mixed types is also a bit weird
<emersion>
could have a candidate object
<emersion>
with two constructors
<zamundaaa[m]>
Or go with the design Jonas proposed, where the clients all attach their surfaces independently without xdg_foreign
<emersion>
that sounds funky to synchronize
<emersion>
ah, sounds like Jonas suggested a sync scheme
mvlad has quit [Remote host closed the connection]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
andreas1 has joined #wayland
<andreas1>
When using the wlroot screencopy protocol and doing a capture_output_region. What coordinate space is used for the x and y? I'm a bit confused because I have a |-| tie fighter 3 monitor setup (I hope that explains it) and when I do capture_output_region for (x: 0, y: 0) with any height/width, it seems to incorrectly take a screenshot of the bottom part of the portrait displays, but
<andreas1>
correctly the top part of the landscape display. It says that the region is in logical coordinates, it then refers to xdg_output.logical_size, though the explanation there seems to refer to scaling. I feel like I am not converting between coordinate spaces. Does anyone have any information on coordinate space expectations?
<emersion>
these are output-local coords, iirc
<andreas1>
That is what I understood as well, though I am having a hard time understanding why it's sending me the bottom half of the output instead of the top half.
<andreas1>
Meaning that it's the same coordinate space that is used to position outputs, but then relative to the output.
<andreas1>
So if I request x=0, y=0 with a specified size, I should get the top left of the screen, but I get the bottom right.
<andreas1>
And it's doing this only for my 2 portrait displays which have 90deg and 270deg rotation, but not for my 0deg rotation landscape one. I'm a bit stunned.
<andreas1>
This is on Sway and Hyprland, tested against both to check my sanity.
<Arnavion>
Sounds like the rotation is getting applied twice somewhere in the pipeline
<Arnavion>
instead of being applied once and then inversed
nerdopolis_ has joined #wayland
<andreas1>
Arnavion: in Sway/Hyprland?
nerdopolis has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
overholts has quit [Quit: overholts]
overholts has joined #wayland
lsd|2 has joined #wayland
<any1>
Well, hyprland has its own screencopy implementation, so if they're wrong, they're at least equally wrong.
<andreas1>
Let me look at grim's implementation as it does not have the issue. Perhaps it makes some stuff clear.
<any1>
It used to be that buffers were flipped upside down for whole-screen copy, but not when cropped. IIRC. There's a flag for that. Then you also need to take the output transform into account because you get the buffer without the transform.
<andreas1>
Grim captures the entire output and doesn't use capture_region so it's not seeing the bug.
<any1>
yeah, capture region is slow anyway. At least with the gles2 renderer. It's smarter to capture the whole thing and crop.
<andreas1>
I think I'm good with some confirmation on whether or not this is intended behaviour, or a bug. I can continue with my implementation and report the issues in Sway and Hyprland if so.
<andreas1>
any1: that's actually what I originally did. But for reasons that I won't go into now, capture region is used now.