https://codeberg.org/dnkl/foot/wiki/Performance #terminal

Я вот решил попробовать какой-то другой эмулятор терминала, один из самых популярных not hardware-accelerated - #foot. Автор, конечно, всячески пытается сделать вид, что он не конкурирует с alacritty:

1) Но вот в тест, где он рвет #alacritty, "срежиссирован" специально - он строчкой ранее пишет, что alacritty гораздо быстрее рендерит пустые глифы, чем заполненные, и, чтобы показать преимущество своего damage control, показывает этот damage control на полностью заполненном терминале. На терминале с небольшим числом непустых глиф даже его damage control не показал бы преимущества.

2) Чтобы его foot не совсем сильно тормозил, он сделал оптимизацию с копированием части буфера через memcpy, если он считает, что она не изменилась. И набажил - у меня при скроллинге, если предыдущие строки немного похожи на следующие, начинаются глюки отрисовки.

Ну не соревнуешься - так не соревнуйся, сделай простую, как 5 копеек, вещь, которой можно пользоваться без hardware acceleration.

———
https://github.com/dvdhrm/kmscon

#kmscon

Какой-то странный проект по замене линуксовой консоли во frame buffer. Я тоже задумался о такой штуке, но мне показалось, что гораздо проще взять киоск-style композитор на основе wlroots, и слинковать в одну программу эмулятор терминала(любой), киоск-style композитор, libinput, и все такое. Получаем бинарь с клиентом-терминалом и сервером-композитором, который умеет в консоль в fb.

———
Я хочу признаться в одной странности, которая меня никак не отпускает. Я строю prefix trie из путей к проектам в своей системе сборки Mix. Что это значит?

lib/pcre, lib/pcre/2, а не lib/pcre2. lib/tom/math, lib/tom/crypt, а не lib/tommath, lib/tomcrypt. lib/z, а не lib/zlib(а это уже что, граф?), net/wget и net/wget/2, и самое любимое - lib/curses/n, lib/curses/netbsd. Пока не сжал dev/build/autoconf, dev/build/automake, но руки чешутся.

Я хз, зачем я это делаю, но мне нравится!

———
У меня было время почитать интернеты про Vizio и ее предполагаемое нарушение GPL, понял, что зря записал ее в негодяи в прошлый раз. Вот то, что она пытается отменить суд на основе того, что иск подал не владелец кода, это не значит, что они негодяи, и у них нет возможности доказать, что они не используют GPL в своей прошивке, а это просто очень "техническая" вещь - так дешевле.

Вернулся к теме #kmscon, тем более, что у нее случился какой-то форк, который привел ее в собираемое и работоспособное состояние - https://github.com/Aetf/kmscon

В целом, мне удалось завести ее как замену обычной текстовой консоли Linux, и даже получить красивые цвета и нормальный шрифт, но случилась одна маленькая проблема - я так и не понял, как из нее запустить графическое окружение с wayland.

Из обычной консоли все просто - композитор перехватывает на себя текущий VT (virtual terminal), и запускает все в нем, через KMS. Но тут у нас уже другая программа получила владение этим VT (собственно, сама kmscon), и они начинают конфликтовать.

Я было подумал, что эту задачу должен решать seat management daemon (seatd, elogind, systemd), и он таки ее, в какой-то степени, помогает решить (программы могут открывать устройства через этот демон, и он будет правильно переключать владение при переключении между vt), но:

* не все программы используют seatd/elogind/etc (kmscon не умеет)

* а даже если и умеет, то там дальше начинаютя какие-то дебри, которые я вообще с трудом понимаю.

Например, я не понимаю, почему каждое приложение, которое пользуется 3d, пытается открыть устройство в /dev/dri/.

Казалось бы, вот есть wayland compositor, у него есть wl_drm, через которое приложение может попросить drm устройство в пользование, далее EGL умеет из этого wl_drm сконструировать egl context, для работы через него gl/vulkan.

Но нет, каждое приложение норовит само полезть в /dev/dri/, потому что в wl_drm лежит путь к render node, а не fd, а это, как по мне, ломает всю идею seat management daemon.

Код там донельзя запутанный, в интернетах особо про эти крайние случаи не написано.

Вот, например, текст про то, что клиенты wayland предпочитают использовать dmabuf расширение протокола, а не wl_drm: https://wayland-book.com/surfaces/dmabuf.html

Но и там написано, что "не лезьте в это темное место".

Короче, как заиспользовать kmscon в стеке, я пока не понял.

Можно городить какие-то схемы, что, когда надо запустить wayland композитор, kmscon должна уйти с дороги, но это будет та еще #herobora

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/10 - вот неплохой список проблем с текущим стеком, на эту тему.