08:03 tzimmermann: sima, hi. i made a patch series to better integrate gem-shmem with the kernel's page tracking (see https://lore.kernel.org/dri-devel/20260204114341.195143-1-tzimmermann@suse.de/T/#m29bf6ed03bdbb0a177ad5c37b89f61c672200b73). but now I've come accross the old commit 8b93d1d7dbd5 ("drm/shmem-helper: Switch to vmf_insert_pfn"). Although get_user_pages doesn't seem to be relevant any longer, I assume that mmaping with
08:03 tzimmermann: VM_PFNMAP is still a deliberate choice?
08:04 tzimmermann: bbrezillon ^
08:14 MoeIcenowy: tzimmermann: BTW do you have any free time for applying my DC8200 v7 patchset?
08:14 MoeIcenowy: sorry for disturb
08:14 MoeIcenowy: (or maybe my SMTP server failed?
08:15 tzimmermann: MoeIcenowy, hi. sure. i'll take a look later today. everything goes into drm-misc, right?
08:15 MoeIcenowy: I think it's patch 1-5
08:15 MoeIcenowy: 6-7 is already in thead tree
08:15 tzimmermann: ok, 1 to 5
08:16 tzimmermann: don't worry about reaching out via irc. email get lost too easily in my busy inbox
08:16 MoeIcenowy: hahaha
08:17 MoeIcenowy: managing such a big tree sounds busy
08:17 MoeIcenowy: ah should I send a follow up patch add T: drm/misc for the driver?
08:17 MoeIcenowy: I think many other SoC KMS drivers has it
08:19 bbrezillon: tzimmermann: unfortunately, I don't know enough about MM to help here :grimacing:. I did find this idea of flagging individual folios dirty/accessed when the are faulted appealing though. I guess this can still be done with PFN mappings, because we have the pages array at the gem_shmem level
08:21 tzimmermann: bbrezillon, yeah, we can still track access and dirty for the entire buffer with the existing pages_mark_ flags
08:22 bbrezillon: nah, I mean even fine-grained tracking is possible, I think
08:22 bbrezillon: you can just use the vmf->pgoff to get the right page, and turn into a folio
08:23 bbrezillon: *the right page in the gem_shmem::pages[] array
08:23 tzimmermann: MoeIcenowy, sure that follow-up makes sense
08:23 tzimmermann: bbrezillon, right. then let's try that
08:24 bbrezillon: first commit in the patchset is good to go, if you want to apply it now
08:31 MrCooper: (how) can a compositor detect that a connected monitor is powered off?
08:35 K900: Depends on the monitor really
08:35 K900: Some will report it over DDC/CI but also DDC/CI is probably not something you want to be touching by default
08:50 MoeIcenowy: Some monitor just de-assert HPD on poweroff
08:50 MoeIcenowy: although this kind of monitor tends to create more problems
08:51 MrCooper: yeah, my question was specifically about monitors which don't do that
08:51 K900: Yeah I think it's between DDC/CI shenanigans and nothing
08:51 K900: At least for the overwhelming majority of cases
08:51 K900: And DDC/CI is giga cursed
08:54 MrCooper: 'ddcutil vcpinfo --verbose' doesn't have anything obviously related for this monitor (looks like one could turn off the monitor via DDC/CI though :)
09:36 mlankhorst: remote: ERROR: The git server, Gitaly, is not available at this time. Please contact your administrator.
09:36 mlankhorst: Works on 5th attempt
09:43 MrCooper: that was probably due to gitlab getting upgraded, as discussed on #freedesktop
11:58 sima: tzimmermann, yeah, very much
11:58 sima: or at least VM_SPECIAL, to make sure get_user_pages does not work
12:00 sima: I've even done patches to ensure every gem and dma-buf mmap is VM_SPECIAL, but there's some exceptions on some embedded platforms where dma_mmap gives you a gup-able mapping unfortunately
12:00 sima: so can't enforce that in full generality, but maybe we should try at least for x86 to make sure this doesn't ever break
12:00 sima: x86 and arm64 maybe, should cover most things
12:01 sima: but also auditing this is an absolute pain, there's so many paths