02:17 YaLTeR[m]: Company: it was intentionally omitted at the time, it renders the full combined outputs view and cuts from that (which will have all monitors at the same "scale" so that cross-monitor selection matches up). It needs a separate code path to render every monitor individually and when the selection is fully contained within one monitor, use a monitor specific render
11:33 pq: zzag, FWIW, when talking about output/buffer rotations, I find wording things based on orientation much more clear than based on what you rotate and in which direction.
11:34 pq: I also use pieces of paper where I draw the local coordinate system, and then play with those :-)
11:37 zzag: pq: re piece of paper: that's also what I did
11:37 zzag: I find the current wording a bit ambiguous
11:37 zzag: an example would help
11:39 zzag: e.g. the top left corner of the surface with transform T will map to xyz corner of the buffer (assuming there's no viewport)
12:10 pq: zzag, which wording where exactly?
12:12 zzag: in the wl_surface.set_buffer_transform request
12:13 zzag: as is, it's ambiguous
12:14 zzag: first of all, wl_output_transform's docs talk about compensation for rotation
12:14 zzag: then the same enum is used in wl_surface.set_buffer_transform
12:14 zzag: which adds even more confusion
12:15 pq: ah yeah, the protocol docs... it must have been only Weston docs that I recall improving
12:17 pq: so, wl_output.transform describes what the compositor will do to a (normally oriented) surface in order to display it on the output.
12:18 pq: e.g. "rotate 90 degrees counter-clockwise"
12:19 pq: take a piece of paper to represent the surface, rotate it, slap it on a monitor in normal orientation, then rotate both to the orientation the monitor is actually in, and the surface needs to end up up-right.
12:21 pq: wl_surface.set_buffer_transform IMO tries to say that this is the wl_output.transform that the client has already targeted with its drawing.
12:23 pq: take a piece of paper, draw coordinate axes on it according to the transform but do not rotate the paper; slap the paper on a monitor in normal orientation, and rotate both together to the monitor's actual orientation, and the drawn axes must come up up-right.
12:24 pq: complicated, could very much use a complete re-wording by orientation
12:26 pq: zzag, did I manage to clarify why both are using the same enum? That one says what the client should do, and the other is what the client decided to do.
12:47 zzag: pq: yeah, after some struggling I finally figured that out (and fixed kwin)
13:37 clarkk: I'm on Debian 12. As my system has a intel/nvidia chip, it suffers from the following memory leak bug, which causes it to become unresponsive after a couple of days, meaning I lose all my in-memory data. I've worked around the problem by using Wayland instead of X Windows. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017819
13:38 clarkk: My problem now is that, when I switch to different already-running applications, their windows aren't fitted to the screen properly. They are maximized, which is correct, but for example the bottom edge is offscreen, and I have to pin it to the left or right side first and then maximize it to make it fit the screen properly. Anyone know how I can resolve this, please?
13:38 clarkk: X Windows worked fine in this respect
13:43 soreau: clarkk: this sounds like the wm part of your compositor needs help
13:44 soreau: you can try asking in your compositor support channels, file an issue or try a different compositor
13:45 clarkk: soreau, could you clarify what the compositor is? Do you mean Gnome?
13:46 soreau: yes, gnome uses a process called mutter to render the desktop
13:46 soreau: mutter is the compositor
13:51 clarkk: soreau, I'm talking to someone in #debian who uses wayland but doesn't have this issue. They don't have an igpu and have dual monitors
13:51 soreau: clarkk: you need to ask in gnome support channels
13:51 clarkk: I just have a laptop, using its integrated screen
13:52 clarkk: soreau, ok. I've hardly ever got a response from the gnome irc channels, unfortunately
13:53 soreau: clarkk: sometimes you have to be patient. In the meantime you can try a web search to see if others might have a solution to your issue
13:53 ebassi: clarkk: GNOME is mainly on Matrix, these days
13:53 ebassi: so asking on IRC isn't going to work
13:53 soreau: my guess is that it would be more related to the version of the client or mutter, not a driver issue
13:54 soreau: ebassi: it only won't work if you don't have the answer :)
13:54 clarkk: soreau, what do you mean by client?
13:55 soreau: clarkk: a client in this context is a program that connects to a display server and conveys one or more surfaces to the compositor
13:55 soreau: in short: an app
13:56 daniels: Wayland is just a set of protocols and conventions
13:56 clarkk: soreau, that's interesting. Actually, most windows are correct, but a couple that I use all the time have the problem.
13:56 daniels: if you're having a 'bug with Wayland', this means that the things which implement them are buggy - in this case the server is GNOME Shell / Mutter (which decides where and how to place windows), and the clients are the apps you're running which should be following the server's direction
13:57 daniels: if there are only a couple that you use, the issue is very likely that those apps aren't doing the right thing, so I'd chase it up with them
13:57 clarkk: Those being the gnome terminal and telegram desktop (started from the terminal)
13:57 daniels: either way, it's not an issue with 'Wayland' specifically, because Wayland is not the thing putting your windows at the wrong position or making them be the wrong size
13:58 soreau: daniels: sometimes I imagine you have help-desk bindings that paste these texts for you xD
13:59 daniels: ha, not a bad idea
13:59 soreau: :-)
13:59 soreau: but the tried-and-true method is add !factiods to the bot :P
14:22 clarkk: soreau, daniels thanks for your help - much appreciated. I'm asking in the gnome channel now
20:18 wlb: weston Merge request !1442 opened by Derek Foreman (derekf) libweston/backends: Move damage flush into backends https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1442 [Core compositor], [DRM/KMS backend], [Headless backend], [Nested Wayland backend], [Nested X11 backend], [PipeWire Backend], [RDP backend], [VNC Backend]
20:23 ManMower: (someone complained that I don't set enough tags in my MRs)