LINUX.ORG.RU

История изменений

Исправление 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.