03:54 wlb: wayland Merge request !354 opened by David Benjamin (davidben) connection: avoid calling memcpy on NULL, 0 https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/354
11:31 pq: JoshuaAshton, leasing overlay planes would also be horrible for update timings, either causing unexpected random full refresh cycle delays or maybe just everything tears if the hardware can tear. Or both.
11:32 pq: I suppose it would also be accompanied by random EBUSY errors from atomic commits.
11:36 pq: It'd also make atomic test commits unreliable, but I guess that applies to KMS leasing in general.
12:11 daniels: pq: unless I’m very wrong, test commits aren’t subject to EBUSY
12:15 pq: daniels, no, but they become unreliable.
12:15 pq: someone else can change the device KMS state between test and real commit
12:15 emersion: test something, then something changes on the lease, then test again, and results are different
12:15 emersion: yea
12:23 daniels: ah yeah, iswym
12:31 JoshuaAshton: pq: Why would it be horrible for update timings?
12:31 JoshuaAshton: on hw where there are 4 planes per-head, I don't see the problem
12:32 JoshuaAshton: if the planes are shared across multiple heads then yes... it's a problem then
12:33 zamundaaa[m]: I think you're all talking about different things
12:34 zamundaaa[m]: JoshuaAshton: you mean leasing overlay planes *with* crtc and connector, right?
12:35 pq: I've been talking about leasing *only* an overlay plane for a CRTC that is driven by the lessor.
12:36 pq: You would have two independent processes both updating planes on the same CRTC, and that causes all the problems I mentioned.
12:36 emersion: ah, right, that sounds pretty dangerous and broken
12:36 pq: JoshuaAshton, which scenario did you mean?
12:36 emersion: i was thinking leasing more planes alongside a CRTC+connector
12:42 JoshuaAshton: Yes, I was thinking overlay with crtc and connector
12:44 JoshuaAshton: and obviously a primary
12:46 emersion: (not so obvious, because it's possible to only light up an overlay on some hw :P )
12:46 emersion: (without a primary)
12:46 pq: ok, nothing strange with that.
12:47 pq: I've heard that embedded product developers like to drive each plane of one CRTC from different independent processes, so I jumped to conclusions. We got requests to make that work with e.g. Weston.
12:47 pq: as in "Weston's primary plane needs to be able to see through to the underlay planes we drive with video player"
12:47 JoshuaAshton: i see
12:48 pq: *KMS video players
12:51 daniels: you could lease entire outputs (connector+crtc+(n*plane)) to fullscreen clients but I'm not sure what benefit it would bring
12:52 emersion: you're no longer able to interact with the mouse with such clients, so less game addiction as a benefit?
12:54 JoshuaAshton: daniels: Gamescope has a branch where I tried to make that work but something falls over kernel side on AMDGPU at least since a recent-ish kernel
12:55 JoshuaAshton: I think I want to try doing a thing where we re-make the scene graph on wayland commit/commit done and push it up with subsurfaces instead of compositing ourselves at some point soon
12:56 pq: subsurfaces is a good idea
12:57 pq: well, again depending on what actually have in your scenegraph
12:58 JoshuaAshton: yeah, really for our side it would be the same as our existing logic for VRR but just pushing up the scene graph with subsurfaces instead
12:58 JoshuaAshton: some cases we'd still need to composite for eg. FSR though
12:59 JoshuaAshton: zamundaaa[m]: Would KDE handle mixed HDR and SDR with subsurfaces right now?
12:59 pq: subsurfaces are good for buffers that are potentially scanout-able
12:59 zamundaaa[m]: JoshuaAshton: yeah
13:00 JoshuaAshton: and would it also take advantage of overlay planes there if available?
13:00 zamundaaa[m]: Not yet, no
13:01 JoshuaAshton: I guess it cant without color mgmt drm kernel side stuff
13:01 pq: How does VRR vs. FSR make a difference to sub-surface usage? What's FSR?
13:02 JoshuaAshton: For VRR I mean like, us committing up the scene graph to the compositor would be very similar logic to what we do for VRR on the DRM side
13:02 JoshuaAshton: FSR is just an upscaling method
13:03 pq: oh, nothing to compare to fixed-rate refreesh, ok
13:03 JoshuaAshton: ye
13:10 wv: Hello, I seem to have something odd on my imx53/freedreno platform. I'm on 1920x1080, but it seems only 1919x1079 is written to the screen. Although all logs mention 1920x1080. But if I take a screenshot using weston-screenshooter, it appears the bottem row (1080) and right column (1920) are just black. Even with the normal weston background of the desktopshell
13:12 wv: And to extend, when I run my cog/wpewebkit instance on top, with a size of 1920x1080, with a box inside of 1 pixel on the outer edges, also the bottom and right are just black
13:16 daniels: wv: please start weston with --debug and pastebin the output of 'weston-debug scene-graph' whilst it's running somewhere
13:19 wv: daniels, sure, here you go -> https://pastebin.com/2m0QJMTb
13:21 wv: daniels, and as reference, this shows the issue -> https://pasteboard.co/FjLNo7CEEY0q.png It's a snip of the screenshot. As you can see, the lower pixelrow is just black, as is the right pixelcolumn
13:22 wv: and it's just the default background of desktopshell. Nothing fancy at this moment
13:47 wlb: wayland/main: David Benjamin * connection: avoid calling memcpy on NULL, 0 https://gitlab.freedesktop.org/wayland/wayland/commit/50ea9c5b1c08 src/connection.c
13:47 wlb: wayland Merge request !354 merged \o/ (connection: avoid calling memcpy on NULL, 0 https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/354)
15:33 quantun`: I have a herd of KVM virtual machines and need remote desktop access to them. I knw this has been blocked in Wayland. What do you guys do?
15:40 kennylevinsen: What? Wayland does not block remote desktop access
15:40 pq: quantun`, I suppose the usual answers are RDP and VNC for full desktop, and waypipe for individual apps.
15:41 pq: assuming there are not virtual display hardware for the virtual machines, and a viewer for that
15:41 quantun`: kennylevinsen: It sure used to. I haven't been able to use it as a result.
15:42 daniels: it works
15:42 quantun`: pq: VNC has always been jittery and weird, like putting many copies of the screen bertically. Haven't tried RDP
15:42 daniels: if you're using GNOME, there's built-in support for VNC/RDP; if you're using KDE then I believe they also have something similar; if you're using stuff built on wlroots then there's wayvnc; if you're using Weston it has built-in VNC and RDP backends
15:43 daniels: if those aren't working then please file bug reports with the appropriate projects
15:43 quantun`: KDE here. I'll look into it when I have time.
15:45 d_ed[m]: KDE's server is unimaginative named "krdp". It might not be shipped by default, as it's a relatively new venture
15:45 quantun`: Thx d_ed[m].