Sebastian Wick
Sebastian Wick
> It is unclear when or if it will ever exist It will exist when someone starts to work on it. Constantly complaining on an issue achieves nothing.
So, turns out I'm really not a fan of this. Can we maybe consider something along the lines of this: `--device=all --device=input --nodevice-if="all:has-input-device" --nodevice-if="all:has-usb-portal" --nodevice-if="input:has-wayland-inputfd"` Which would have the benefit...
I also think this doesn't work properly with the different priorities. I.e. if you have an override `--device=fallback:input,all` and then at the commandline `--device=all`, this might still remove the `--device=all`...
What this MR does is make it possible to remove one device permission when another device permission is supported. This isn't really that useful IMO. Yes, remove "all" when an...
> There is no priority. --nodevice=fallback:input,all will remove the fallback and the --device=all already present will work. The implementation doesn't work with the different priorities of the different configurations. You...
https://github.com/swick/flatpak/commit/c5385699b0ea4bdfe4e94771a6cf5a2d02d4a372 This works with the different levels of priority but it does flatten down to the bitmask on every level, so `flatpak_context_devices_to_string` can't represent the conditions.
https://github.com/swick/flatpak/commit/19af1b0596ea552d46a523c7fee3ff8f094006ad This one doesn't flatten anything at all just like the MR but it doesn't touch the `devices` and `devices_valid` fields. Conditions can be arbitrary things, it generalizes to e.g....
Sorry, I don't get it. Wayland/X11 fallback is exactly the same as usb to no usb fallback, except that the condition of when the fallback must be active is different...
You're asking for two different things: 1. Portals should make more use of static permissions for certain features 2. Remotes should be able to overwrite static permissions The first point...
The multiple options bug is fixed. I forgot to implement isLoggedIn which somehow caused this behavior. There are still things left to do like error handling when searching libgnome-keyring.so, improving...