Simon McVittie

Flatpak isn't the component that does this; moving the issue to xdg-desktop-portal.

> Who is the person I should nag for a review then? Please be patient, I will get to this when I can. Nagging potential reviewers is likely to be...

@SoumyaRanjanPatnaik, if you can provide a separate PR that supersedes this one, using `Co-authored-by` to credit both yourself and @alyssais, that would probably be the way forward here.

> Flatpak apps with --device=all still don't have monitoring - the devices you get when the sandbox is mounted is what you get for the lifetime of the application. That's...

> or if we bind-mount `/dev/hidraw0` but not the rest of `/dev/` ... or, perhaps more relevant to this particular PR, since input devices are explicitly out-of-scope for this PR:...

> What does this mean? That the application can know all the devices we have and access them freely (without permission)? If it has `--device=all`, yes. If it has `--device=input`...

> In my case, xdg-desktop-portal-gnome ate 5.7 GiB of RAM xdp-gnome is not maintained by this project. If you have a way to reproduce that large memory use, or other...

> Go via Nautilus to /proc/$PID/root (where $PID is your flatpak app which running) and search via Nautilus for some file > I found another case which could have more...

> xdg-desktop-portal version 1.10.1 What distribution? Any distro patches applied? `register_document()` assumes that the global `documents` object is non-NULL, but in your case it's NULL. This means the `xdp_documents_proxy_new_sync()` call...

xdg-desktop-portal should have error-handling for `xdp_documents_proxy_new_sync()` having failed, but it's possible that a fixed kernel would mean that `xdp_documents_proxy_new_sync()` didn't fail in practice.