Прежде всего, извините за потенциально глупый вопрос, это моя первая попытка поработать с Wayland. Но я погуглил и не нашел ничего связанного.
Система, которую я разрабатываю, очень критична по времени для запуска графических приложений, поэтому мне удалось запустить Weston и желаемое приложение на этапе initramfs до запуска systemd. Все прошло нормально, за исключением того, что «нормальные» приложения, которые, в свою очередь, запускаются из большой файловой системы, отказываются запускаться, возвращая ошибку «Ошибка аутентификации» № 3.
Вот подробности.
Initramfs был создан вручную на основе busybox. Weston с одним приложением и необходимыми библиотеками (включая PAM и другие вещи, без которых он отказывался работать) также были скопированы. / dev статический, с минимальным набором узлов. / init - это небольшой sh-скрипт, который монтирует / proc, / run, / sys, запускает Weston и приложение, затем монтирует основные rootfs и передает управление с помощью switch_root (). Кроме того, я монтирую существующий / run в / run_old, чтобы сохранить сокет Wayland. Я не уверен, что это сделано правильно, но systemd перезаписывает / run в главном rootfs, и должен быть способ доступа к серверу, так что это как-то работает.
Я также связываю сокеты "wayland-0" и "wayland-0.lock" из / run_old с / run в основной файловой системе.
Программное обеспечение диагностики (LayerManagerControl, weston-info) работает и показывает информацию о сервере, но все, что пытается вывести изображение (следовательно, используя / dev / dri / card0), происходит сбой с вышеупомянутой ошибкой.
Вот фрагмент strace клиентского приложения:
Понятно, что он правильно подключает / run / user / 0 / wayland-0, затем отправляет ioctl DRM_IOCTL_GET_MAGIC в / dev / dri / card0 , затем отправляет (?) магию в сокет сервера, который, в свою очередь, выдает ошибку.
Со стороны сервера это выглядит так:
Эта строка интересна:
[pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied)
Обработайте 14 точек (уже удаленных) / dev / dri / card0. Вот список дескрипторов всех открытых серверов:
https://pastebin.com/RTFNbEDW.
Единственная подсказка, которую я имею, это то, что switch_root () перед переключением на основную rootfs рекурсивно удаляет все файлы в initramfs, включая / dev / dri / card0 (это видно в список с пометкой «удалено»). Фактически, новые приложения уже взаимодействуют с новыми динамически создаваемыми devtmpfs. Но до сих пор не могу понять, как это может влиять, ведь ручка еще живая! И какая разница, какой именно узел устройства у нас и в какой момент он был смонтирован, если старшие / младшие номера совпадают? Итак, подсказка не самая лучшая, и я даже не знаю, как ее правильно проверить.
Кстати, вот еще один кусок трассировки серверов:
$ grep "AUTH_MAGIC" strace-wayland-log
[pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = 0
[pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied)
[pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied)
[pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied)
[pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied)
[pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied)
Здесь совершенно очевидно, что первое графическое приложение авторизуется нормально, а следующие - нет.
Любые идеи?
