01:03 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?
01:04 Company: tiny rendering engine so to say
01:05 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
07:18 emersion: there was a talk at XDC describing power savings for messages and browser apps when using KMS offload for solid color planes
08:57 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.
09:09 pq: DemiMarie, maybe http://web.archive.org/web/20120102153021/http://www.fooishbar.org/blog "why you don't actually want dpi" for X11 and the links there give you some background on why dpi is such a difficult concept to make good use of.
09:20 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.
09:22 pq: the same story as with all innovative Wayland design aspects, like the lack of an absolute coordinate system
09:23 pq: DemiMarie, the most fundamental problem with dpi is that you have to assume a standard viewing distance and eye sight.
09:25 pq: ...which is not unlike video colorimetry standards design for color instead of size/resolution - and they do also define viewing distances
09:31 kennylevinsen: pq: so, using 2x integer scale on the wire but rendering UI widgets smaller to achieve, say, 1.5x perceived scale?
09:32 pq: yes, I believe we've been over that before. :-)
09:32 kennylevinsen: while it would solve the cordinate system issues, it would break split output rendition where the compositor scales the minority output to match
09:32 kennylevinsen: and definitely sounds like a way to add even more client complexity...
09:33 pq: Yes, it would. It's definitely different from the old ways.
09:34 pq: then again, is it not an explicit non-goal to make the UI the same physical size on different outputs with different dpi?
09:39 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
09:39 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...
09:39 kennylevinsen: which is not the same thing as physical size, as user-preference may dictate something other than that
09:39 pq: choose a separate UI size for each output and tolerate the UI resizing that happens when switching outputs
09:41 pq: kennylevinsen, how does a user specify a scale, so that we have a definition of what makes it consistent?
09:42 pq: if you refer to physical output pixels, then that is physical size
09:46 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
09:46 pq: ok - that's a given in my suggestion to begin with
09:47 kennylevinsen: I did not see it that way
09:47 pq: aah, but you must be thinking of windows spanning multiple outputs?
09:47 kennylevinsen: yes
09:47 pq: okay, that's different
09:47 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.
09:48 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
09:48 kennylevinsen: but I was expecting it to be roughly the right size
09:49 kennylevinsen: ("right" being that e.g. rendered font size matched user expectation)
09:49 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?
09:50 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.
09:52 pq: clients only need, if they want to, re-render the window in a different integer scale after switching from output to another.
09:52 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
09:53 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.
09:53 pq: the whole point is that the compositor does not compensate for UI size at all
09:54 kennylevinsen: I never attempt to achieve same physical size, only "size consistent with output"
09:54 pq: you need pick a compromise UI size that is roughly good on each output simultaneously while being optimal on possibly none
09:54 kennylevinsen: with each output having a different user-selected preference for whatever reason - distance, size, dpi
09:55 pq: so, you could pick: UI size 125%, output A scale 1x, output B scale 2x
09:56 kennylevinsen: I don't think that would be particularly useful then
09:56 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
09:56 kennylevinsen: it would only handle monitor mismatches well if they are mismatched roughly 2x
09:57 pq: maybe it's easier to understand if I define UI size in surface-local coordinate units instead
09:58 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.
09:58 pq: then you get used to it, and don't even notice it's not optimal
09:58 kennylevinsen: If UI scale is shared amongst all outputs, it becomes a common factor and can be ignored when it comes to output adjustment
09:59 pq: I'm not sure what you mean, but yes, that's my point, I guess.
10:00 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
10:00 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.
10:01 pq: you still have output independent *integer* scaling
10:02 pq: However, you need pick such an UI size that given the integer scaling, the UI works for you on all outputs.
10:02 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
10:02 pq: it may not be optimal on any output, but the image will be crisp and totally usable
10:03 pq: once you have used that a couple hours, you don't even remember what "optimal" was
10:04 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
10:05 kennylevinsen: I pick monitors and dpis to maximize it
10:05 pq: okay, and are you willing to give away crisp line art as the trade-off?
10:06 kennylevinsen: I see no reason to give it up for content local to the monitor
10:06 kennylevinsen: if you can apply the UI scale globally, you can apply it locally
10:06 kennylevinsen: I am willing to give up any and all ability to show the window on more than one output at a time though
10:06 pq: but you said you care about windows that span multiple monitors
10:06 kennylevinsen: No, but wayland currently does
10:07 pq: no, Wayland does not - well, I'm not including the current fractional scaling extension here
10:08 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"
10:08 kennylevinsen: there was discussions about that, and I made a small chart of the various platform behaviours
10:08 kennylevinsen: ]hang on
10:08 pq: don't bother :-)
10:09 pq: like I said, we had discussed this all before
10:10 kennylevinsen: I was only planning to find the chart, not the discussion ;)
10:11 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.
10:12 kennylevinsen: yeah that I could work with
10:13 pq: then, if a compositor wants to compensate also for UI size mismatch between surface and output, if can do the blurry fractional scaling.
10:13 pq: *it can
10:13 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
10:13 kennylevinsen: yeah
10:14 pq: I mean, compositors are already free to blur out any window at a whim anyway. :-)
10:16 kennylevinsen: I suppose this could be done by simply allowing the client to specify what UI scale was used
10:16 kennylevinsen: that is, they receive a fractional scale and can decide to decompose that to an integer buffer scale and a UI scale
10:16 kennylevinsen: the compositor just needs to know that the 2x buffer shouldn't be further downscaled to achieve 1.5x
10:20 kennylevinsen: if we ignore individual pixel addressing, it would solve the subsurface problem of fractional-scale-v1 without the change of coordinate system
10:22 kennylevinsen: zamundaaa[m]: you might be interested in the above
10:57 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
10:59 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
11:06 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.
11:07 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.
11:09 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"
11:10 zamundaaa[m]: It is very different
11:10 zamundaaa[m]: pq: I was talking about Kenny's idea of decomposing the fractional scale factor
11:10 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.
11:11 kennylevinsen: ah disregard my last statement, that was a brainfart :)
11:11 pq: zamundaaa[m], oh, that interacts with surface size in compositor vs. client?
11:11 zamundaaa[m]: Yes
11:11 pq: alright
11:12 pq: but I do see a (similar?) problem with my idea as well
11:18 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
11:19 pq: UI size would need to be factored into the configured size machinery
11:21 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.
11:22 pq: for maximized and fullscreen states the compositor would just use the right configured size without regard to UI size
11:23 pq: ....erm
11:23 pq: complicated to think about what happens then :-)
11:25 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?
11:25 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.
11:28 pq: all I can really say for sure is that all this would need to be tried before all the problems are found
11:29 pq: would be interesting but I have this other thing to work on first
11:35 kennylevinsen: agreed, and understandable :)
11:36 kennylevinsen: it's also been a while since I looked at the v2 proposal, needs another look
11:39 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.
11:41 pq: it's GL border color all over
11:53 wlb: weston/main: Pekka Paalanen * 7 commits https://gitlab.freedesktop.org/wayland/weston/compare/d18fd64a158a9c1b543ccd9a56f7f7e18d1cd733...cab1992b812d3f60733eead9748372e24f0ae006
11:53 wlb: weston Merge request !1370 merged \o/ (Do not represent stock sRGB color profile with NULL https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1370)
14:58 wlb: wayland-protocols Issue #164 opened by Pekka Paalanen (pq) How to rely on file sealing in protocol extensions? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/164
15:00 kchibisov: does xdg-activation token become invalid after calling `activate`?
15:01 kchibisov: I think it's valid for as long as compositor thinks that it's valid?
15:02 emersion: in practice activate consumes the token
15:03 kchibisov: It's just there's a wording like ". This token should be offered to the clients to be activated."
15:03 kchibisov: token to _clients_
15:03 emersion: yeah?
15:04 kchibisov: So it sounds to me that if I open 3 windows at the same time I can pass the same token to them and be good.
15:04 kchibisov: but in reality compositor will activate only one.
15:04 emersion: it's not very harmful
15:04 emersion: but yeah
15:05 kchibisov: Maybe it should just say that calling `activate` the token is dead?
15:05 kchibisov: that after*
15:05 emersion: maybe, not sure
15:15 wlb: wayland Issue #418 opened by Kirill Chibisov (kchibisov) xdg_activation: token reuse is not clear https://gitlab.freedesktop.org/wayland/wayland/-/issues/418
15:41 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.
15:43 emersion: i don't know about per-client
15:46 pq: MrCooper had a good argument: don't let clients DoS each other
15:46 pq: by e.g. sending a fd that takes ages to read
15:55 emersion: how can a process have control over this though?
15:56 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.
15:57 pq: e.g. a spinning disk with heavy other I/O going on
15:57 wlb: wayland-protocols Issue #165 opened by Kirill Chibisov (kchibisov) xdg_activation: token reuse is not clear https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/165
15:57 wlb: wayland Issue #418 closed \o/ (xdg_activation: token reuse is not clear https://gitlab.freedesktop.org/wayland/wayland/-/issues/418)
15:58 emersion: mmap only works on regular files
15:58 pq: reminds me of how people seemed to complain that writing sd-cards made their whole desktop stall, not sure why I never saw that personally
15:58 pq: if the compositor mmaps, sure
15:58 pq: but a thread would not mmap, because SIGBUS, pread() is better
15:59 emersion: you can pread in a non-blocking manner
15:59 emersion: er, read
15:59 pq: for pipes and sockets, yes
15:59 pq: for regular files, no
16:00 pq: you can try to, but regular files are *defined* to always poll as readable by POSIX
16:00 emersion: yeah, and regular files are hard to stall by outsiders
16:00 pq: unless by accident
16:01 emersion: which is why i'm not sure the per-client complexity is worth it
16:01 pq: I'm not talking so much about intentional malice, but coincidents that lead to jerky desktop
16:01 ids1024: If you can mount a fuse fs, you can make a "regular file" stall as long as you like
16:02 pq: emersion, yeah, my first thought was to use a single thread for all clients, too.
16:05 kchibisov: Was there some idea to encode workspaces into xdg-activation tokens somehow and expose workspaces information to the clients?
16:06 emersion: ids1024: that's why FUSE has restrictions
16:06 pq: workspaces... the third dimension of 2D desktops ;-)
16:06 emersion: mainly, you can't pass a proper FD to a compositor from your FUSE mount unless you can ptrace the compositor
16:06 kchibisov: pq: technically 4th.
16:06 pq: ooh, what was the third?
16:06 kchibisov: z orderding?
16:07 kennylevinsen: *compiz*
16:07 pq: true
16:07 emersion: kchibisov: why is that useful to clients?
16:07 d_ed[m]: there was, I'll find a link
16:07 d_ed[m]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/203
16:07 kchibisov: emersion: to activate in a window currently present on workspace.
16:08 kchibisov: though I guess clients can use `Suspended` state?
16:08 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
16:08 kchibisov: pq: layer-shell ¯\_(ツ)_/¯
16:09 pq: right ;-)
16:10 d_ed[m]: emersion: the use case is you have a browser with tabs on desktop1 and on desktop 2
16:10 d_ed[m]: you're on desktop 2 and open a link. Which window gets the new tab?
16:10 emersion: right, and i said i'd prefer the compositor to pick, iirc
16:14 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
16:15 d_ed[m]: could maybe work but that still requires something new to exist
16:18 kennylevinsen: alternatively, one could maybe add a preferred_surface event somewhere in xdg_activation_v1?
16:20 d_ed[m]: This situation can come up in a multi process setup too
16:23 kennylevinsen: hmm, that is more annoying
16:24 emersion: workspaces are just one example, i think there are more
16:24 kennylevinsen: but I guess you could have an xdg_activation interface that lets you query a token before use without consuming it first
16:25 emersion: meh
16:26 emersion: for example, on sway each output has a workspace
16:26 kennylevinsen: I feel less for turning the token into a data container though :/
16:27 emersion: if i have 2 firefox windows, one on an workspace not displayed, one an workspace on an unfocused output
16:27 emersion: i want that window to be activated, even if the workspace is not currently focused
16:28 kennylevinsen: ugh
16:28 emersion: IOW, "same workspace" is not a good enough policy
16:28 emersion: some compositors might have more groupings, different concepts
16:28 emersion: so i'd really prefer not to tie any of this to workspaces
16:30 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
16:31 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)
16:31 emersion: yeah, i think !203 is on the right track
16:33 kennylevinsen: so preferred surface, but where you know to try the next client
16:33 emersion: this doesn't address the multi-process case
16:34 kennylevinsen: well with new_candidate_preferred you can try from the next process?
16:34 wlb: weston Merge request !1381 opened by Marius Vlad (mvlad) build: bump to version 12.0.92 for the beta release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1381
16:35 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
16:36 emersion: indeed
16:38 wlb: weston/main: Marius Vlad * build: bump to version 12.0.92 for the beta release https://gitlab.freedesktop.org/wayland/weston/commit/47d58f7f1296 meson.build
16:38 wlb: weston Merge request !1381 merged \o/ (build: bump to version 12.0.92 for the beta release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1381)
16:39 emersion: maybe could use xdg_foreign somehow
16:40 zamundaaa[m]: That's what 203 currently does
16:40 emersion: add_foreign_candidate(zxdg_imported_v2)
16:41 emersion: ah, i missed that
16:41 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
16:41 wlb: weston New tag: 12.0.92 https://gitlab.freedesktop.org/wayland/weston/tags/12.0.92
16:42 kennylevinsen: having to xdg-foreign your own toplevels for single-process is a little silly, but manageable
16:46 emersion: you don't have to -- you can pass directly an xdg_toplevel in that case
16:46 emersion: oh no you can't
16:47 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
16:48 emersion: could have a candidate object
16:48 emersion: with two constructors
16:48 zamundaaa[m]: Or go with the design Jonas proposed, where the clients all attach their surfaces independently without xdg_foreign
16:49 emersion: that sounds funky to synchronize
16:50 emersion: ah, sounds like Jonas suggested a sync scheme
16:53 wlb: wayland.freedesktop.org Merge request !68 opened by Marius Vlad (mvlad) releases: add weston 12.0.92 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/68
16:53 wlb: wayland.freedesktop.org Merge request !68 merged \o/ (releases: add weston 12.0.92 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/68)
16:53 wlb: wayland.freedesktop.org/main: Marius Vlad * releases: add weston 12.0.92 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/cdf1da22ad76 releases/weston-12.0.92.tar.xz releases/weston-12.0.92.tar.xz.sig releases.html
19:57 wlb: wayland-protocols Merge request !261 opened by Simon Ser (emersion) presentation-time: stop referring to Linux/glibc https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/261
22:13 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
22:13 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?
22:19 emersion: these are output-local coords, iirc
22:23 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.
22:28 andreas1: Meaning that it's the same coordinate space that is used to position outputs, but then relative to the output.
22:30 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.
22:32 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.
22:32 andreas1: This is on Sway and Hyprland, tested against both to check my sanity.
22:35 Arnavion: Sounds like the rotation is getting applied twice somewhere in the pipeline
22:35 Arnavion: instead of being applied once and then inversed
22:38 andreas1: Arnavion: in Sway/Hyprland?
22:47 any1: Well, hyprland has its own screencopy implementation, so if they're wrong, they're at least equally wrong.
22:49 andreas1: Let me look at grim's implementation as it does not have the issue. Perhaps it makes some stuff clear.
22:51 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.
22:52 andreas1: Grim captures the entire output and doesn't use capture_region so it's not seeing the bug.
22:53 any1: yeah, capture region is slow anyway. At least with the gles2 renderer. It's smarter to capture the whole thing and crop.
22:53 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.
22:53 andreas1: any1: that's actually what I originally did. But for reasons that I won't go into now, capture region is used now.