#imgui #shell
Запилил с фабулой очень крутую штуку, AFAIK сейчас так никто не делает, и делать не умеет.
TL;DR - эмулятор KMS в userspace.
Современные wayland композиторы тестируют почти end to end - от потока команд до реальной картинки, которую должен увидеть пользователь.
За одним маленьким исключением - никто не знает, что на самом деле пользователь увидит, потому что то, что он увидит, определяет не только картинка, но и настройки самого output (встроенный экран, внешний монитор, и так далее) - sdr/hdr, цветовое пространство, яркость, разрешение и частота, vsync, edid, и так далее, и так далее.
Вот, насколько я знаю, современные композиторы (как и я раньше) тестируются в headless mode - до рендеринга картинки в bitmap, а дальше все.
Но это очень важная часть - она включает в себя подключение и отключение output на лету, смену его режимов, failure injection (на твою коробочку села кошка, и статика с нее ебнула в hdmi кабель, true story), на все это надо уметь реагировать корректно.
Чтобы это тестировать end to end, мы с фабулой запилили эмулятор этой state machine - https://github.com/pg83/imway/blob/main/kms_fake.cpp
// Everything KMS that device_kms.cpp needs, modeled in userspace: the
// object/property tables, atomic commits with page-flip events on a real
// pipe, framebuffer and GEM bookkeeping. Rendering stays on the real GPU;
// syncobj ioctls forward to a companion render node so explicit sync is
// backed by genuine kernel fences. The point is a scriptable state machine:
// tests can flip the connector or make commits fail on demand.
Фактически, перехватили парочку сисколлов, https://github.com/pg83/imway/blob/main/kms_fake.cpp#L1209-L1251, и дали тестовой машинерии управлять этой state machine.
Конечно, сразу нашли кучу багов, связанных c connect/disconnect, и прочим HDR настройками.
Уверяю, что сейчас ни один другой композитор так не тестируется.
Запилил с фабулой очень крутую штуку, AFAIK сейчас так никто не делает, и делать не умеет.
TL;DR - эмулятор KMS в userspace.
Современные wayland композиторы тестируют почти end to end - от потока команд до реальной картинки, которую должен увидеть пользователь.
За одним маленьким исключением - никто не знает, что на самом деле пользователь увидит, потому что то, что он увидит, определяет не только картинка, но и настройки самого output (встроенный экран, внешний монитор, и так далее) - sdr/hdr, цветовое пространство, яркость, разрешение и частота, vsync, edid, и так далее, и так далее.
Вот, насколько я знаю, современные композиторы (как и я раньше) тестируются в headless mode - до рендеринга картинки в bitmap, а дальше все.
Но это очень важная часть - она включает в себя подключение и отключение output на лету, смену его режимов, failure injection (на твою коробочку села кошка, и статика с нее ебнула в hdmi кабель, true story), на все это надо уметь реагировать корректно.
Чтобы это тестировать end to end, мы с фабулой запилили эмулятор этой state machine - https://github.com/pg83/imway/blob/main/kms_fake.cpp
// Everything KMS that device_kms.cpp needs, modeled in userspace: the
// object/property tables, atomic commits with page-flip events on a real
// pipe, framebuffer and GEM bookkeeping. Rendering stays on the real GPU;
// syncobj ioctls forward to a companion render node so explicit sync is
// backed by genuine kernel fences. The point is a scriptable state machine:
// tests can flip the connector or make commits fail on demand.
Фактически, перехватили парочку сисколлов, https://github.com/pg83/imway/blob/main/kms_fake.cpp#L1209-L1251, и дали тестовой машинерии управлять этой state machine.
Конечно, сразу нашли кучу багов, связанных c connect/disconnect, и прочим HDR настройками.
Уверяю, что сейчас ни один другой композитор так не тестируется.