В свежих ядрах поломали работу SDL 1 в ядерной консоли, но я собрал патч, который возвращает всё обратно

а тебе кто-то обещал, что задротом быть легко?

При чём тут я? Зачем ломать то, что работало годами и десятилетиями?

Суть в том, что SDL 1 нужно выставлять параметры. А разработчики ядра решили, что больше никто ничего выставлять не будет, поскольку, видите ли, всё равно по сути ничего не меняется, т.к. эти параметры не поддерживаются.

Пусть они и не поддерживаются, но SDL 1 эти параметры же нужны. Ну и зачем их выпиливать?

SDL 1

Зачем он нужен в ядерной консоли? Музычку через него слушать? Так и без него можно

Я же написал:

Эта библиотека в ядерной консоли нужна в т.ч. для работы эмуляторов. Retro Arch, fceux, FUSE Spectrum Emulator, dosbox,... и т.д.

А если в иксах запускать?

В иксах свои механизмы. Про них никто ничего не говорит. Тема конкретно про drivers/gpu/drm/drm_fb_helper.c.

А работа приложений на Qt не сломалась?

sudo QT_QPA_PLATFORM=linuxfb qbittorrent-qt5
sudo qbittorent-qt4 -qws

А вот патч для ядра 4.19.9 с которым SDL 1 начинает работать как и прежде

Так ты создай багрепорт на kernel.org и прикрепи свой патч. На ЛОРе-то большинству пофиг.

Не могу протестировать, поскольку Qt в ядерной консоли у меня нет.

4.18.12

Как я понимаю, на этой версии проблемы нет? Просто я не хочу обновляться на новую версию ядра, чтобы проверить. А ты видимо не хочешь устанавливать библиотеки Qt, чтобы проверить.

За сим можно выносить вердикт: сломали потому что никому не было нужно.

SDL 1 в ядерной консоли
При чём тут я?

Действительно....

А вообще тебе правильно сказали - багрепорт разрабам с патчем. Мы благословляем есличо.

Суть в том, что SDL 1

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

Да, в ядре 4.18.12 ещё ничего не поломали. Так SDL 1 в ядерной консоли нужнее чем Qt.

Ну и где этот SDL 2 превосходит SDL 1? Только если в иксах или вейланде. А в ядерной консоли SDL 2 нормально работает разве что на Raspberry Pi, но не на x86_64.

Так SDL 1 в ядерной консоли нужнее чем Qt.

Бред. Qt во фреймбуферной консоли иногда использовался в Embedded для Kiosk-приложений, потому что жирные и неповоротливые иксы тянуть никто не хотел.

А вот SDL 1 видимо только для развлечений задротами и юзался. Нужность поддержки фреймбуферной консоли в SDL была поставлена под сомнение и удалена в SDL 2. А вот в Qt 5 модуль linuxfb заботливо перенесли сами разработчики, потому что на этом был завязан какой-то бизнес/ынтерпрайз.

Хочешь проверить реальный юзкейс — проверяй Qt, а не игрульки.

Нужность поддержки фреймбуферной консоли в SDL была поставлена под сомнение и удалена в SDL 2

На самом деле нет. Поднял сейчас документацию. На Raspberry Pi всё и так подхватывается автоматом. Там можно и через SDL 2 софт в ядерной консоли гонять (в т.ч. mpv). А на x86_64 поддержка фреймбуфера в SDL 2 тоже есть. Через устаревший directfb. По умолчанию она не собирается. Нужно указывать опцию --enable-video-directfb.

А вообще тебе правильно сказали - багрепорт разрабам с патчем. Мы благословляем есличо.

+1.

(Шёпотом: а ещё теперь без SDL2 нельзя собрать ffplay из ffmpeg-а...)

Через устаревший directfb. По умолчанию она не собирается. Нужно указывать опцию --enable-video-directfb.

Это всё равно что через иксы. Поддержки чистого linuxfb, как в SDL 1 или Qt 4, Qt 5 — там теперь нет.

А DirectFB протух и сдох, вместе со всеми своими сайтами. Особенно смищно сейчас смотрится вот это:
http://www.directfb.org/how-to-prepare-for-the-first-sex/

Это не «смищно». Это очень грустно.

Получается, что если я захочу использовать проверенную старую технологию для работы со слабеньким железом (даже не обязательно старым — вон сколько всяких одноплатников развелось), я не смогу найти документацию. А может, даже и исходников не найду, если они на каком-нибудь sourceforge не уцелели...

Они уцелели на GitHub'е.

https://github.com/DirectFB/directfb

Каталог docs там имеется тоже. Найдёшь, если потребуется.

Спасибо. Не уверен, что потребуется, но спасибо.

Тем не менее, иксы тут ненужны. Другой вопрос, что SDL 2 плохо работает с DirectFB.

Ещё, сейчас смотрю, есть --enable-video-kmsdrm. Теоретически тоже должно работать с фреймбуфером, причём напрямую. Однако, на практике тоже как-то не работает.

А SDL 1 работает как часы.

Ядреная консоль делает тебя сильней.

А может, даже и исходников не найду, если они на каком-нибудь sourceforge не уцелели...

Здесь тоже есть (хотя пока дальше github и debian похоже не пошли, beta всё же).

А нужно ли?

В SDL2 есть поддержка kmsdrm. Только по умолчанию его зачастую не включают, но если пересобрать, то на Intel/AMD запустится.

Не обязательно. У меня kmsdrm этого SDL 2 на AMD R7 240 не заработал.

Ты лучше проверь Qt и если там есть проблемы, смело создавай багрепорт.

Я лишь предполагаю, что с радеонами заработает, так как от них есть свободные драйвера.

У меня на Intel на ноутбуке получилось. А на ПК с двумя мониторами вообще прикольно получилось — игра на втором мониторе(который до этого дублировал текущий tty), а stdout на первом.

Ну и да, EXL прав. У Qt это вынужденные меры поддерживать KMS DRM, а у SDL2 скорее всего просто задротство.

Мне фиолетова эта поддержка Qt. Поэтому я всё равно оформил баг, пусть и про SDL1: https://bugzilla.kernel.org/show_bug.cgi?id=202001 .

А вообще тебе правильно сказали - багрепорт разрабам с патчем. Мы благословляем есличо.

+1 к благословителям.

Интересно, что бы сказал на это Линус «WE DO NOT BREAK USERSPACE!» Торвальдс =).

угадал автора по заголовку

ядерной консоли не существует.

Трудно не угадать автора по заголовку!

Очень даже существует. И, как написано в исходниках, ядерную консоль написал Линус Торвальдс (как часть ядра (потому и «ядерная» или «ядровая»)):

/*
 *  Copyright (C) 1991, 1992  Linus Torvalds
 */

«ядерная» консоль была у поехавшего, который делал TempleOS и он от такого рипнулся.
а ты — необучаемый невежда.

Раз реализация в ядре, значит она «ядровая» или «ядерная».

Есть мнение что патчить надо SDL, а не ядро.

Есть и такой вариант, да. Однако, во-первых, даже если его и будут патчить, то это время. А, во-вторых, это ещё вопрос как там устроены потроха. Перепроверить все возможные видеорежимы для таких библиотек - это обычное дело. А тут решили это запретить в ядре. Мол, всё равно только один рабочий режим, и не надо тут проверок и прочих видеопараметров.

Я, кстати, посмотрел кто написал этот патч, который поломал SDL1. Это был Eugeniy Paltsev из Synopsys. Этот патч в т.ч. подтвердил кто-то из Intel'а. И ещё его подтвердил Greg Kroah-Hartman.

> Такой гангрены как ядро 4.19 не было со времён ядра 4.14

Грег Хартман же делал, а не Линус Торвальдс. Возможно что не выдержал многократно возросшей нагрузки - и совершил несколько ошибок. Привыкнуть надо пока расширится до нужного диаметра к бешеному ритму такой работы

С другой стороны - ядро 4.19 досталось ему на этапе rc (релиз-кандидата). Где там можно было ошибиться?

> Этот патч в т.ч. подтвердил кто-то из Intel'а

Ну это как с оптимизациями Glibc под SSE4. Я не помню, какое слово я искал по GIT проекта Glibc, но удалось вывести на 1 экран все оптимизации memcpy() при помощи SIMD-инструкций, которые добавляли за всё время. Там и MMX, и SSE, и SSE2, и т.д. Добавлять оптимизацию SSE4 было и вовсе не обязательно, ведь memcpy() и так была оптимизирована по самое не хочу.

Напомню, что вместе с этими оптимизациями разрешили порядок символов делать обратный, в том случае, если это даст прирост в скорости. И патч этот отправил Intel. И без переворачивания символов прироста не было. И потом был огромный скандал - мол, «переписывайте весь затронутый софт, он нарушает спецификацию Си, а Glibc не виноват. Никто и не был обязан делать именно такой порядок буковок, хоть это и было так на протяжении 20 лет»

Где там можно было ошибиться?

Он, как минимум, подтверждал бэкпортирование этих патчей в другие ветки ядра, в т.ч. в 4.14.x.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Ну и Евгеша, ну и жопашник. Ну ничё, ща у всех вся встройка отвалится сразу очухаются. ::)

Патч не настолько ломает фреймбуфер. Сам fbdev остаётся вполне рабочим даже для запуска какого-нибудь mplayer'а или mpv. А вот SDL1 этот патч не пережёвывает.

Это был Eugeniy Paltsev из Synopsys

Раз он русскоязычный, достань из коммита мыло и напиши ему тоже. И на ЛОР ссылку кинь.

+, я уже сам было хотел, но лучше saahriktu

Зачем беспокоить конкретно автора патча? У него свои причины по которым он его написал.

Теперь уже оформлен багрепорт, и это теперь дело коллектива разработчиков ядра решать что с этим теперь делать.

Бесполезная лишняя зависимость.

Я думал у тебя на первом месте в жизни стоит уважение к разносторонности мнений и используемых технологий, а тут фиолетова.

Так я и не против чтобы Qt работала с фреймбуфером. Однако, мне она в ядерной консоли не нужна. Пусть с этим вопросом разбираются те, кому она нужна.

Не совсем. Просто под фреймбуфер мало кто что делает. Разработчикам обычно нужна кроссплатформенность. И вот её-то и обеспечивает SDL. И именно потому она и нужна.

И, да, под SDL1 гораздо больше всего написано чем под SDL2.