История изменений
Исправление SkyMaverick, (текущая версия) :
Если уж совсем точно, pipewire вообще просто транспорт и для, собственно, захвата не нужен от слова совсем.
Смысл в чём:
- вот у нас есть приложение, которому нужен скриншот (видеозахват, и т.д.). Приложение простое/во flatpak/ограниченное apparmor-ом и т.д. не суть.
- вот у нас есть композитор, в котором есть все битмапы и который функцию захвата может осуществить
Задача: связать их неким транспортом, таким чтобы надёжно передать битмапы, но при этом не нарушить порядок доступа в каждом. Мы же не хотим, чтобы один лез в другой.
И тут у нас удачно появляется pipewire, у которого обработчики - это стандартный fd (файловый дескриптор), с которыми хоть flatpack, хоть кто угодно, умеет работать.
Соответственно, через механизм портала (который из себя представляет, по сути, стандартный (что важно!!!) IPC-интерфейс DBus с какой-то композиторозависимой хренью за ним (поэтому -portal-gnome/kde/wlr), которая конечное приложение не интересует) мы договариваемся от том, дадут-ли нам дескриптор «на том конце провода» и если дают, то просто читаем из него, как из банального fd, то что нам надо. А механизм передачи «точка-точка» (fd-композитора -> fd-клиента) прозрачно берёт на себя pipewire, на то он и медиасервер, чтобы это делать.
Исправление SkyMaverick, :
Если уж совсем точно, pipewire вообще просто транспорт и для, собственно, захвата не нужен от слова совсем.
Смысл в чём:
- вот у нас есть приложение, которому нужен скриншот (видеозахват, и т.д.). Приложение простое/во flatpak/ограниченное apparmor-ом и т.д. не суть.
- вот у нас есть композитор, в котором есть все битмапы и который функцию захвата может осуществить
Задача: связать их неким транспортом, таким чтобы надёжно передать битмапы, но при этом не нарушить порядок доступа в каждом. Мы же не хотим, чтобы один лез в другой.
И тут у нас удачно появляется pipewire, у которого обработчики - это стандартный fd (файловый дескриптор), с которыми хоть flatpack, хоть кто угодно, умеет работать.
Соответственно, через механизм портала (который из себя представляет, по сути, стандартный (что важно!!!) IPC-интерфейс DBus с какой-то композиторозависимой хренью за ним (поэтому -portal-gnome/kde/wlr), которая конечное приложение не интересует) мы договариваемся от том, дадут-ли нам дескриптор «на том конце провода» и если дают, то просто читаем из него, как из банального fd, то что нам надо. А механизм передачи «точка-точка» (fd-композитора -> fd-клиента) прозрачно берёт на себя pipewire, на то он и медасервер, чтобы это делать.
Исправление SkyMaverick, :
Если уж совсем точно, pipewire вообще просто транспорт и для, собственно, захвата не нужен от слова совсем.
Смысл в чём:
- вот у нас есть приложение, которому нужен скриншот (видеозахват, и т.д.). Приложение простое/во flatpak/ограниченное apparmor-ом и т.д. не суть.
- вот у нас есть композитор, в котором есть все битмапы и который функцию захвата может осуществить
Задача: связать их неким транспортом, таким чтобы надёжно передать битмапы, но при этом не нарушить порядок доступа в каждом. Мы же не хотим, чтобы один лез в другой.
И тут у нас удачно появляется pipewire, у которого обработчики - это стандартный fd (файловый дескриптор), с которыми хоть flatpack, хоть кто угодно, умеет работать.
Соответственно, через механизм портала (который из себя представляет, по сути, стандартный (что важно!!!) IPC-интерфейс DBus с какой-то композиторозависимой хренью за ним (поэтому -portal-gnome/kde/wlr), которая конечное приложение не интересует) мы договариваемся от том, дадут-ли нам дескриптор «на том конце провода» и если дают, то просто читаем из него, как из банального fd, то что нам надо. А механизм передачи «точка-точка» (fd-композитора -> fd-клиента) прозрачно берёт на себя pipewire.
Исходная версия SkyMaverick, :
Если уж совсем точно, pipewire вообще просто транспорт и для, собственно, захвата не нужен от слова совсем.
Смысл в чём:
- вот у нас есть приложение, которому нужен скриншот (видеозахват, и т.д.). Приложение простое, во flatpak, ограниченное apparmor-ом и т.д. не суть.
- вот у нас есть композитор, в котором есть все битмапы и который функцию захвата может осуществить
Задача: связать их неким транспортом, таким чтобы надёжно передать битмапы, но при этом не нарушить порядок доступа в каждом. Мы же не хотим, чтобы один лез в другой.
И тут у нас удачно появляется pipewire, у которого обработчики - это стандартный fd (файловый дескриптор), с которыми хоть flatpack, хоть кто угодно, умеет работать.
Соответственно, через механизм портала (который из себя представляет, по сути, стандартный (что важно!!!) IPC-интерфейс DBus с какой-то композиторозависимой хренью за ним (поэтому -portal-gnome/kde/wlr), которая конечное приложение не интересует) мы договариваемся от том, дадут-ли нам дескриптор «на том конце провода» и если дают, то просто читаем из него, как из банального fd, то что нам надо. А механизм передачи «точка-точка» (fd-композитора -> fd-клиента) прозрачно берёт на себя pipewire.