LINUX.ORG.RU

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

 , ,


2

2

Сабж. Ну и как мне пересматривать свои проекты если этих разработчиков ядра нельзя оставлять наедине с ядром? Хорошо хоть поломав ncurses в ядерной консоли они через некоторое время сами всё починили. Однако, это только вершина айсберга.

Такой гангрены как ядро 4.19 не было со времён ядра 4.14. И, что ещё печальнее, эту заразу же бэкпортируют на прошлые ветки ядра.

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

С какими ванильными версиями ядра это ещё работало? Это ещё работало с ванильными ядрами 4.17.19 (24-Aug-2018) и 4.18.17 (04-Nov-2018). С ядром 4.18.18 (10-Nov-2018) это уже не работает. В ветку 4.14.x эту заразу тоже бэкпортировали. С ядром 4.14.79 (04-Nov-2018) всё тоже должно работать, а вот ядро 4.14.80 уже покорёжено этой заразой.

А вот патч для ядра 4.19.9 с которым SDL 1 начинает работать как и прежде: http://saahriktu.org/downloads/patches/linux-4.19.9_make_sdl1_working_again.p... .

★★★★★

Ответ на: комментарий от anonymous

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

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

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

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)

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

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

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

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

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от saahriktu

4.18.12

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

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

EXL ★★★★★ ()
Ответ на: комментарий от saahriktu

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

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

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

anonymous ()
Ответ на: комментарий от saahriktu

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

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

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

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

EXL ★★★★★ ()
Ответ на: комментарий от EXL

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

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

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

+1.

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

hobbit ★★★★★ ()
Ответ на: комментарий от saahriktu

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

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

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

EXL ★★★★★ ()
Ответ на: комментарий от EXL

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

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

hobbit ★★★★★ ()
Ответ на: комментарий от EXL

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

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

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

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

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

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

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

a1batross ★★★★★ ()
Последнее исправление: a1batross (всего исправлений: 1)
Ответ на: комментарий от system-root

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

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

saahriktu ★★★★★ ()
Ответ на: комментарий от linux-org-ru

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

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

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)

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

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

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

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от saahriktu

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

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

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

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от ZenitharChampion

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

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

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

saahriktu ★★★★★ ()
Ответ на: комментарий от EXL

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

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

saahriktu ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

saahriktu ★★★★★ ()