07:25 tzimmermann: javierm, may i ask you to review the rest of v2 of the fbdev rework patchset? you already did the hard work. the rest of the patches are mostly one-liners throught the drivers. https://patchwork.freedesktop.org/series/131037/
07:30 javierm: tzimmermann: sure, I'll go through them today
07:36 tzimmermann: javierm, thank you so much
07:46 pq: bwidawsk, I'm curious, what do you want to achieve in general?
08:19 sima: rg3igalia, don't we have like 6 +1 already from current board members anyway?
08:19 sima: oops wrong channel :-)
11:08 daniels: demarchi: nice, thanks!
14:07 bwidawsk: pq: ultimately I would like to use writeback on chromeos for feedback reports. on chromeos I can share master. I wanted to make the tool work for Linux too with leases
14:08 bwidawsk: I can put it in the compositor but was hoping to have a discrete took
14:08 bwidawsk: tool
14:14 pq: bwidawsk, maybe it is the original KMS master that cleans up the KMS state before giving you the lease? They would not want to leak any content to you in the first place.
14:24 bwidawsk: pq: yeah I don't see anything that obviously does this, but it does make sense
14:24 bwidawsk: kinda a bummer for me though
14:24 pq: it just isn't what DRM leasing is for :-)
14:28 bwidawsk: but it's so close to being feasible
14:31 pq: a session switch from the original KMS master to you would be closer to what you want, but both would need to opt in to a seamless switch, and even then the original KMS client may clean up the image before handing it over.
14:33 pq: DRM lessor usually refuses to lease out the outputs its already using for the desktop in the first place
14:34 pq: or so I assume, given that leasing was first intended for HMDs
14:45 bwidawsk: session switch would require root, wouldn't it?
14:47 pq: If your tool could work without special privileges, then there would be an open security hole leaking information.
14:48 bwidawsk: well certainly master could refuse to lease
14:48 pq: I'm not sure if it requires root, but if it doesn't, it probably requires the current session to agree to release.
14:48 bwidawsk: as for session, yes of course
14:49 pq: I don't think you can avoid the compositor needing to explicitly allow you to grab the contents.
14:51 bwidawsk: seems so
15:44 MrCooper: bwidawsk pq: FWIW, the current DRM master can in principle grab the contents of any KMS FBs of its device, it just needs to brute-force the IDs
16:05 bwidawsk: MrCooper: interesting, but this still won't work for me since I don't have a way to know which fb was being read from
16:05 bwidawsk: /almost/ there
16:08 bwidawsk: hmm, I suppose before taking the lease, I could record what fb id the crtc is reading from?
16:08 sima: MrCooper, feels a bit like an oopsie to me :-)
16:08 bwidawsk: sima: I think any reasonable system just wouldn't allow leasing :D
16:10 bwidawsk: a lot of the valid use cases end up being in closed systems
16:17 sima: bwidawsk, I meant more for the vt switch case, if the other compositor doesn't clean up it's fb list
16:18 sima: otoh it's also gated behind CAP_SYS_ADMIN for actually getting at the buffer, so should be all ok
16:19 bwidawsk: oh, well if you have ADMIN all bets are off
16:28 MrCooper: sima: seamless handover to a non-CAP_SYS_ADMIN master couldn't work if so?
16:31 sima: MrCooper, hm right I misread
16:32 sima: not sure if compositors know this though, I certainly missed it
16:32 zamundaaa[m]: I was aware of it at least
16:32 sima: MrCooper, specifically thinking of fb that another compositor created but which aren't in active use on any plane
16:33 sima: zamundaaa[m], ^^ this part too?
16:33 sima: like that active fb are leaked is by design, and compositor can put up a splash to hide anything that needs hiding
16:34 zamundaaa[m]: Inactive fbs being leaked is surprising for sure, but KWin doesn't keep them around permanently so it's fine for us
16:34 MrCooper: right, seems like the best way to minimize the hole in the kernel would be to allow it only for FBs which are currently assigned to a plane for which the grabber is master
16:36 sima: MrCooper, yeah it's pretty easy fix, check if the fb is for our file_priv, and if not, walk the plane list
16:37 sima: bonus points for respective lease rules
16:38 sima: *respecting
16:43 bwidawsk: tl;dr I could make this work today with CAP_SYS_ADMIN but at some point it will get fixed?
16:43 bwidawsk: s/with/without
16:50 sima: bwidawsk, I lost context of what you want to do?
16:50 bwidawsk: I'd like to get the output of a connector via writeback without SYS_ADMIN
16:51 bwidawsk: (and without having master)
16:51 sima: oh for that if we fix the getfb/2 checks it wont hurt, since that's only about fb which are not displayed
16:51 sima: but yeah atm you can't
16:52 sima: also in general this wont work without coordination with the current owner, because writeback needs hw resources and might mess up the current compositors config
16:52 bwidawsk: well that's why I wanted to use leasing
16:54 bwidawsk: I wanted to have a generic way to do this. We can do it only for chromeos ofc, I think Weston has such functionality too... but seemed neat if I could do it with leases on generic linux
16:54 zamundaaa[m]: What you want to do is a very privileged operation and is intentionally not possible
16:55 zamundaaa[m]: Drm leasing doesn't give you access to all drm resources, but on generic compositors only to one crtc, one drm plane and one connector - that of a connected VR headset to be specific
16:56 sima: bwidawsk, writeback tends to need all kinds of additional hw resources, so trying to do that behind the compositor's back is far from guaranteed
16:56 sima: for specific systems, sure, but in general you need to cooperate with the compositor
16:56 sima: at that point just having a protocol with the compositor to give you the writeback frame is simpler
16:57 sima: could then use hw writeback, or render compositing or whatever it feels like
16:57 bwidawsk: yeah, what I have is already just a library, so it's fine, but again just trying to make it more generically usable
16:57 bwidawsk: oh well
16:57 sima: if you go the lease route, you need to hand over the entire compositor stuff and pray it's not going wrong (if you don't have protocol of some kind to coordinate the two)
16:58 sima: like if both do atomic TEST_ONLY then there's no guarantee they'll both work
16:58 sima: and things like that
16:59 bwidawsk: in theory, couldn't one just lease a crtc/writeback connector and then set the crtc of the writeback connector?
16:59 bwidawsk: hmm, yeah I guess lease API would make me lease a crtc
17:00 sima: hw resources are shared
17:00 sima: leases get out of this issue because the compositor can just revoke a lease and shut it all down
17:00 bwidawsk: well, in many cases, compositor wouldn't be using the writeback connector, but getting to the crtc is problematic
17:00 sima: but that's only clean if the lease is entirely separate set of kms things than what the compositor is using itself
17:00 sima: if there's overlap it gets messy
17:02 bwidawsk: It seems like if the API did allow me to lease just the writeback conector (which it doesn't), that wouldn't be true
17:02 bwidawsk: because just lease the wb connector and point it to the active crtc you want to get
17:04 bwidawsk: but yes, with the current API I'd need a shared CRTC and FB for the currently running master
17:06 sima: bwidawsk, this is a limitation of compositor protocols, not the kernel
17:06 bwidawsk: mm, I'm not using a compositor here, it's strictly DRM
17:06 sima: only thing the kernel enforces is that if the lessor isn't using universal planes, then the primary/cursor plane get automatically added with the crtc
17:07 bwidawsk: ```
17:07 bwidawsk: * struct drm_mode_create_lease - Create lease
17:07 bwidawsk: *
17:07 bwidawsk: * Lease mode resources, creating another drm_master.
17:07 bwidawsk: *
17:07 bwidawsk: * The @object_ids array must reference at least one CRTC, one connector and
17:07 bwidawsk: * one plane if &DRM_CLIENT_CAP_UNIVERSAL_PLANES is enabled. Alternatively,
17:07 bwidawsk: * the lease can be completely empty.
17:07 bwidawsk: ```
17:07 sima: because otherwise Xorg would have been broken when I fixed some holes in the lease validation
17:07 bwidawsk: well I can try to just lease the wb connector and see if I can make it work
17:08 sima: oh right
17:08 sima: we could probably ditch that limitation
17:09 bwidawsk: but what I'm doing is fundamentally insecure as previously mentioned right?
17:09 sima: since this validate_lease() code does not guarantee you at all that the lease is functional
17:09 sima: bwidawsk, well if you get compositors to create the lease for you so they know what's up, then no
17:10 sima: if you create it behind their backs, then you might steal some hw resources and the compositor looks at an atomic commit that it thought should work per TEST_ONLY, but now suddenly doesnt
17:11 sima: essentially the compositor needs to be able to revoke leases if something goes wrong
17:14 bwidawsk: hmm, if just doing this through DRM how do you know if your lease was revoked? You just start getting failures
17:14 zamundaaa[m]: bwidawsk: you can't get a lease "just through DRM"
17:14 zamundaaa[m]: You can only get it from the drm master
17:14 bwidawsk: oh, create_lease has to be called by master
17:15 zamundaaa[m]: yes
17:16 bwidawsk: hmm, it was seeming to work with kmscube + vkms, I wonder what I did wrong
17:17 austriancoder: I am seeing some wired build problem with debian/x86_64_test-android container on ci: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/57551594
17:18 austriancoder: DavidHeidelberg: eric_engestrom
17:18 bwidawsk: ah, I think I see what was going wrong
17:19 bwidawsk: in my test script I was using `kmscube -A` which apparently fails on vkms
17:19 bwidawsk: so kmscube didn't actually grab master
17:19 bwidawsk: zamundaaa[m], sima, pq, MrCooper: thanks for the enlightenment
18:30 lileo: what exactly does "universal" in the universal kms planes concept mean? Is it to say that all kms drivers expose the same types of planes, or that planes should have general-purpose support for things (rather than just for video/cursor/etc)?
18:37 emersion: universal means that primary + cursor planes are exposed
18:37 emersion: old userspace only expects overlay planes
18:37 emersion: new userspace should always enable it
18:38 emersion: (atomic implicitly enables it iirc)
19:19 lileo: hmm so more so exposing all the planes, rather than just the additional overlays
19:35 mareko: zmike: you also want this for mediump: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28685/
19:52 zmike: mareko: probably
19:52 zmike: though I doubt I'll ever enable mediump since I can't do 16bit io unless it's packed to 32bit
19:52 zmike: which is kinda 😬
20:09 mareko: zmike: skipping the high bits 16bit io during compaction would be possible
20:27 DavidHeidelberg: austriancoder: WIP :P
21:02 zmike: mareko: is it really gaining anything at that point?
21:10 mareko: zmike: yes if vulkan drivers do the tight compaction
21:11 zmike: so this would be 4 dwords with the low 16bits populated?
21:11 mareko: yeah the high 16 bits would be unused
21:12 zmike: hm
21:12 zmike: I suppose
21:12 mareko: is it a SPIR-V limitation?
21:12 zmike: yes, the Component decoration must be less than 4
21:12 zmike: so there cannot be 8x components for 16bit
21:13 zmike: I could manually pack it into dwords myself if a vk driver is going to unpack it, but that seems like wishful thinking
21:13 mareko: non-interpolated IO doesn't care about the bit size
21:14 zmike: probably something for a month or two from now anyway, I gotta switch contexts for a while