Прежде всего, извините за потенциально глупый вопрос, это моя первая попытка работать с Уэйлендом. Но я гуглил и не смог найти ничего связанного.
Система, которую я разрабатываю, очень критична по времени при запуске графических приложений, поэтому мне удалось запустить Weston и нужное приложение на этапе initramfs раньше systemd запускается. Все прошло нормально, за исключением того, что «нормальные» приложения, которые в свою очередь запускаются из большой файловой системы, отказываются запускаться, возвращая ошибку « Аутентификация не удалась» # 3 .
Вот подробности.
Initramfs был создан вручную и основан на busybox . Уэстон с одним приложением и необходимыми библиотеками (включая PAM и другие вещи, без которых он отказывался работать) также были скопированы. / dev - это c, с минимальным набором узлов. / init - это небольшой sh -скрипт, который монтирует / pro c, / run, / sys , запускает Weston и приложение, затем монтирует основные rootfs и передает управление используя switch_ root () . Кроме того, я монтирую существующий / run в / run_old , чтобы сохранить гнездо Wayland. Я не уверен, что все сделано правильно, но systemd перезаписывает / run в основных rootfs, и должен быть способ доступа к серверу, так что это работает как-то.
I также свяжите сокет « wayland-0 » и « wayland-0.lock » из / run_old в / run в основной файловой системе .
Диагностическое c программное обеспечение ( LayerManagerControl , weston-info ) работает и показывает информацию о сервере, но все, что пытается вывести изображение (следовательно, используя / dev / dri / card0 ), происходит сбой с вышеуказанной ошибкой.
Вот часть strace клиентского приложения:
https://pastebin.com/1K3EDUhB
Понятно, что он правильно подключает / run / user / 0 / wayland-0 , затем он отправляет ioctl DRM_IOCTL_GET_MAGI C в / dev / dri / card0 , затем отправляет (?) Маги c в гнездо сервер, который в свою очередь выдает ошибку.
Со стороны сервера это выглядит так:
https://pastebin.com/jkmeMzH7
Эта строка интересно:
[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)
Здесь совершенно ясно, что первое графическое приложение разрешает нормально, но не следующие.
Есть идеи?