Comments 23
на котором что-то разобрать возможно лишь
с лупойприщурившись
Размер шрифта же редактируется
Редактируется, но чтобы на Ретине или большом мониторе это нормально выглядело я еще не видел. Даже на скриншотах.
Я себе на 27" 1440р мониторе для увеличенного шрифта с кириллицей прописал следующее в файл /etc/vconsole.conf
KEYMAP=ru
FONT=ter-c32b
FONT_MAP=8859-5
И выглядит это примерно вот так:
Оно и не может нормально выглядеть, откуда вообще взяться сглаживанию в ядерной консоли, которое вы упоминаете в статье? Там шрифт всегда монохромный (https://en.wikipedia.org/wiki/PC_Screen_Font), задаётся битмапом из нулей и единиц (1=закрашено 0=фон). Соответственно нет полутонов и всего остального, нужного для сглаживания. Максимум можно взять шрифт побольше.
там в лоадере можно пошуршать
kern.vt.fb.default_mode="1920x1080"
screen.font="8x16"соотв можно настроить, там еще при загрузке фрибсд можно посмотреть переменные и примерить размеры консольки
но сама проблема глубже с фреймбуферами, чтобы понять проблему глубже надо задаться вопросом, как рисовать квадратик в окне из пикселей, без драйвера, который в SDL например, в софтверном!(там где нет шейдеров, потомучто Xorg медленный на сколько я знаю) варианте, и более менее пазл встанет на свои места
тоесть надо получить доступ к текущей конфигурации оборудования на уровне ускорения напрямую в граффическую карту, через SHM возможно, другой способ писать свой драйвер KMS, раньше это был DOS int13h наверно
В гугловской библиотеке для логирования есть отличный макрос для таких случаев, LOG_EVERY_N_SEC(). Добавляет событие, но не чаще чем одно в указанное число секунд. Но наверное ещё лучше запилить фичу для самого ring buffer, дросселировать слишком часто повторяющиеся сообщения.
До появления DRM, каждый производитель мобильных устройств и медиаплееров выкатывал собственное SDK и кастомное ядро Linux. Чтобы поменять разрешение экрана, надо было изучить тонну китайского кода. Даже думать нельзя было, чтобы запустить какие-то сторонние приложения. Все прибито гвоздями и только от производителя. То что сейчас сделали, это просто фантастика, стандартизировали весь этот зоопарк.
Эта ошибка говорит о том, что pipe контроллера дисплея настроен не верно. 50/50 режим установится или нет. Наиболее часто встречается у DP / eDP портов ввиду link train процедуры. А поскольку вы говорите о ноутбуках, это 100% eDP.
Но главное: у драйвера i915 нет обязательных блобов, все опциональные и в этом смысле код чист. GuC, HuC, etc на работоспособность не влияют. Отсюда, постоянное их упоминание в статье выглядит не профессионально как минимум.
Скрытый текст
P. S. Времена патчей KDE под FreeBSD с появлением LinuxKPI вернулись, welcome
Эта ошибка говорит о том, что pipe контроллера дисплея настроен не верно
"Aw, snap!" от Intel, ага.
Написал же, что ошибка наведенная и никакого вменяемого смысла сама по себе не несет.
В случае появления мигания, реальная ошибка тоже появляется в логе - на скриншотах репортов ее видно.
нет обязательных блобов
Это как?
Самого чипа видеокарты ведь отдельно не существует — он реализован на кристалле процессора, где блобы очень даже есть. А «фирменное» и полностью закрытое управление питанием?
ошибка наведенная и никакого вменяемого смысла
Да-да. Прерывание об ошибке display engine само по себе появляется. А если серьёзно, регулярно его встречал при отладке раннего кода порта этого драйвера, сценарий уже описал. То, что ошибка не всехда приводит к видимым эффектами не значит, что её нет. Есть негласное правило компенсации 5-10% погрешностей modeline, вполне вероятно, что в конкретно этом сценарии не превысили и матрица компенсировала. А там, где замерцало модлайн попался не самый удачный.
Самого чипа видеокарты
Путаете чип (Hard) с драйвером (soft)? В коде драйвера бинарных закладок, кроме перечисленных мною, нет. DC, PMU, 2D и 3D реализуются на открытых исходных кодах. Блоб в драйвере это firmware, чьего исходника в опенсорсе нет. Внутренний микрокод контроллера таковым не является и присутствует в том или ином виде в любом контроллере.
Найдёте в коде драйвера i915 блоб, приведите ссылку. Как-то за более чем 10 лет его портировния в разные ОС так и не увидел. Управление питанием там также реализовано, как в виде различных профилей, так и в виде отключения отдельных блоков.
А там, где замерцало модлайн попался не самый удачный.
Вообще не было изменений modline: не было изменения частоты, разрешения экрана, не было suspend/resume или запуска чего-то нагружающего видеокарту. Так что не могу связать одно с другим ну никак.
Видимые эффекты проявлялись не на моем оборудовании а у багрепортеров в статье, там есть и версия чипа и версия прошивки. У них да - вплоть до зависания системы.
Найдёте в коде драйвера i915 блоб, приведите ссылку.
Есть вот такой репозиторий, в котором лежат файлы сборки для прошивки, используемыми KMS:
The firmware files are located in amdgpukmsfw-files, i915kmsfw-files and radeonkmsfw-files directories, for respective driver. The directories with the same names, but without -files, contain Makefiles for building firmware kmods for loading into the FreeBSD kernel.
Есть ссылка на git ядра Linux, откуда они берутся.
Выглядит все это как набор .bin файлов без исходников и загружаются они в момент инициализации KMS.
Что это если не бинарный блоб я не знаю.
Можно конечно называть их "друзьями по байтам" или "нечистыми данными" или еще как жонглировать терминами, но суть от этого не поменяется.
Ошибка кстати именно там, внутри, в этом самом бинарном блобе.
Вообще не было изменений modline: не было изменения частоты, разрешения экрана, не было suspend/resume или запуска чего-то нагружающего видеокарту
Модлайн не всегда берется системный. Для eDP вообще редко. Он вычитывается из пресетов VBT ("The contents of the VBT are independent of the driver or kernel version") или напрямую из EDID / DDC матрицы. Вы его может быть и не меняли, а вот "положили" вам его, видимо, вполне хорошо. Бывают девайсы (мониторы, панели, телевизоры, ...) у которых EDID вообще отсутствует или битый - в смысле прописанный там модлайн взят хз откуда, но данному девайсу не подходит. Как бэ тут драйверу законно сносит крышак в виде артефактов, отсутствия изображения и т.п., потому как угадать он его не может, если он не совместим с каким-либо из стандартов: CVT, GTF, RBT, RBT2, ...
Не то, чтобы я всё это защищал, но тут рыло в пуху не только у вендора GPU.
Что это если не бинарный блоб я не знаю
Да, это блобы. Но я о них написал вам в самом первом сообщении: "GuC, HuC, etc на работоспособность не влияют":
DMC - Display MicroController firmware provides support for advanced graphics low-power idle states
GuC / HuC - альтернативный механизм передачи команд CPU->GPU / опциональные ништяки для HEVC / H.265
В своих портах я их тупо не гружу и проблем не наблюдаю.
У тех же AMD, например, прошивка как раз безальтернативна и вокруг неё всё и строится, и вот тут бы я спорить не стал.
возможно лишь
с лупойприщурившись
Опечатка, надо так: «[…] возможно лишь за лупой прищурившись […]».
Все что нужно сделать — закомментировать этот блок, начиная с условия
Фи, как грязно. Если конкретно 0x00000080
Просто «что-то сломалось», в переводе с языка Intel.
то следует "душить" конкретно этот код, а другие таки пушить дальше в drm_err
В угаре оптимизации «ядростроители» дошли до использования 3D-ускорения (GPU) даже для отрисовки терминала текстовой консоли (тот самый KMS)
Внезапно, GPU это не только 3D. И даже аппаратное ускорение вывода на экран это тоже не только 3D.
То, что там при желании можно достучаться и до 3D тоже -- это просто побочный эффект работы с одним и тем же устройством вывода на экран через один и тот же интерфейс, что в терминале текстовой консоли, что за ее пределами.
GPU с аппаратным ускорением вывода это нынче такая же банальность, как вывод звука или сеть. Они тоже когда-то были опциональными внешними устройствами, которые в угаре оптимизации ядростроители включили прямо в стандартную поставку.
Вопрос не в банальности а в том что это с технической точки зрения шиза - использовать графический рендер для вывода текстового терминала.
Вот так выглядел один из первых VT100 терминалов, 1978й год:
И все замечательно работало 40 лет, поведение было предсказуемым.
Сейчас получается что буквы и цифры рисует GPU через шейдеры, собирая по пути все проблемы GPU - от нагрева до ошибок отрисовки.
Мой текстовый терминал не мигал экраном из-за сбоев в прошивке.
Я с вами-то совершенно согласен, разумеется, но справедливости ради хочу уточнить: эти терминалы мигали, как заведенные. Я бы даже сказал, мерцали. Не из-за прошивки, конечно.
с технической точки зрения шиза - использовать графический рендер для вывода текстового терминала
Шиза использовать один общий способ вывода на экран вместо нескольких разных?
Или вы думаете что без DRM в текстовом терминале какой-то другой GPU с какой-то другой прошивкой используется?
Если хотите настоящий текстовый терминал, то придется подключать UART. Все остальное уже сто лет как графический режим и разница между текстом, 2D и 3D чистая условность.
буквы и цифры рисует GPU через шейдеры, собирая по пути все проблемы GPU - от нагрева до ошибок отрисовки
А есть где-то свидетельства, что в процессе отрисовки консоли через DRM используется что-то сложнее простого вывода фреймбуфера на экран самыми базовыми для GPU средствами, или вы чисто интуитивно провели параллель GPU = 3D игры = какие-то непонятные шейдеры и нагрузка?
Вот так выглядел один из первых VT100 терминалов. И все замечательно работало 40 лет, поведение было предсказуемым.
VGA уже давным давно нет и задолго до DRM использовался fbdev и примерно такая же плотная работа с GPU.
Аморальный патч для Intel DRM