LINUX.ORG.RU

Избранные сообщения Sunderland93

Кластер из старых китафонов на базе Debian Stretch

Галерея — Рабочие места
Кластер из старых китафонов на базе Debian Stretch

Давным давно я покупал всей семье аппараты UMI-X2 (mt6589). Время этих телефонов прошло, апдейтов на них уже не прилетит, некоторые трубки частично убиты. К UMI-X2 еще и добавился еще и мой старый iOcean-X8 (mt6592) с убитым SIM-слотом. Выкидывать весьма производительные железки мне не хотелось, потому я сделал для аппаратов кастомные ядра и портировал Debian Stretch.

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

Бокс отпечатан из пластика PLA, крышка держится на пазах+магнитах. Сверху стоит вентилятор, под ним проложен фильтр от пыли, между «этажами» предусмотрены отверстия для вентиляции. На дне дырки, через которые выходит воздух.
В виде ножек использованы силиконовые антиударные самоклеющиеся накладки для мебели, которые легко можно купить в любом леруа.

Время печати всего удовольствия - около 30 часов на моем Flying Bear P902. Моделировал в SolveSpace.

Каждый аппарат по USB определяется как композитное устройство в составе которого: сетевая карта (cdc-eem), виртуальный последовательной порт с консолью и usb mass_storage (если потребуется прямой доступ к SD/eMMC).

На данный момент аппараты планируется использовать как ферму для сборки debian-пакетов под arm через Jenkins CI. Тут два варианта: если удастся завести docker, то узлы будут эквивалентны, с контейнерами под debian armhf/armel и raspbian armhf. А если нет - то на каждый аппарат по своему дистру. Нет только аппарата на aarch64, но что-то подсказывает мне, что если второй раз разобью экран своего K6000 Pro, будет и эта архитектура в этой чудной зомби-ферме.

Кстати, за время с прошлой новости, я добавил в MediaDeb поддержку WiFi для UMI-X2, перевел систему сборки проекта на cmake, добавил в ядро все необходимое для поддержки iotop, оптимизировал систему для работы с еMMC и еще сделал много мелких доделок, включая еженедельные сборки для поддерживаемых аппаратов. А еще сделал бенчмарки

>>> Просмотр (1920x3237, 2079 Kb)

 , ,

ncrmnt ()

Canonical полностью прекращает развитие Mir и Unity 8

Новости — Ubuntu Linux
Группа Ubuntu Linux

Сегодня Марк Шаттлворт на insights.ubuntu.com объявил о прекращении разработки Unity 8 и дисплейного сервера Mir. Говорится, что в Ubuntu 18.04 LTS будет использоваться GNOME с Wayland или X Server. Также будет прекращена разработка Ubuntu Phone. Правда, стоит отметить, что компания Canonical не планирует останавливать разработку Ubuntu для IoT-устройств. Вместо Ubuntu Phone и Ubuntu Touch на базе click-пакетов будет Ubuntu Personal на базе snap-приложений.

>>> Подробности

 , , ,

Root-msk ()

Игры в Linux: переходим в следующее поколение?

Форум — Games

Эта статья является переводом статьи из блога главного разработчика композитного менеджера KWin (используется в KDE) Мартина Гресслина. Оригинал вы можете прочесть по ссылке. Далее идёт повествование от автора. Прошу сильно не пинать за качество перевода.

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

Ситуация с X11

В X11 главная проблема для игр, это композитор. Играм необходим прямой доступ к графическому процессору (видеокарте), без каких либо посредников. Для сравнения, возьмём игровую консоль Playstation: когда вы запускаете игру, вы можете быть уверены, что она получила полный доступ к графическому процессору (GPU). Композитинг X11 предоставить такого не может. Композитор в X11 должен полностью скомпоновать сцену. Выглядит это так:

  • Игра рендерится через OpenGL/GLX;
  • X-сервер уведомляет композитор через расширение Xdamage;
  • Композитор рассчитывает область для перерисовки;
  • Композитор использует расширение Xcomposite для получения пиксельной карты для игрового окна;
  • Композитор связывает пиксельную карту с текстурой OpenGL;
  • Композитор рендерит текстуру, используя OpenGL/GLX поверх игрового окна;
  • X-сервер предоставляет готовое изображение из композитора через KMS.


При таком раскладе, мы имеем 5 вещей, которые не оптимальны для полноэкранных игр: проходы туда-сюда через композитор X-сервера, что добавляет серьёзные задержки. В такой ситуации, композитор всегда будет замедлять игру, так как будет выполнять вертикальную синхронизацию и так далее.

Обходные пути в X11

Существует готовое решение чтобы исправить это, известное как «unredirection full-screen window (отключить перенаправление для полноэкранных окон)». Идея заключается в том, что композитор не будет работать для полноэкранного приложения, и будет использована обычная, «не композитная» функциональность X-сервера.

На мой взгляд, это неправильное решение проблемы, потому что композитор по-прежнему работает, он по-прежнему получает события через XDamage (отслеживание областей для перерисовки, прим.перев.) (от, например, других окон) и работа композитора может внезапно возобновиться (например, при выводе уведомления на экран).

В KWin/Plasma, у нас есть лучшее решение: блокировка композитора. Мы можем это сделать, так как не требуем композитинга, в отличии от окружений с обязательным композитингом, где можно использовать только unredirection. У нас даже есть высокоуровневый API для игр, для того чтобы они могли сообщать, что необходимо заблокировать композитинг.

Это также объясняет, почему в KWin/Plasma не включена по умолчанию опция отключения полноэкранного композитинга. Это может вызвать проблемы в работе неигровых приложений (например тиринг в видеоплеере. прим.перев.), но рекомендуется для игр. Также это объясняет почему мне пофиг на тесты PTS (Phoronix Test Suite), так как по моему мнению они проводятся с неправильными настройками. Если бы нас это волновало, то можно было бы просто убедиться, что используемые в PTS игры, отключают композитинг.

Ситуация с Wayland.

В Wayland всё гораздо лучше, так как теперь нет X11-прослоек. Теперь процесс выглядит так:

  • Игра рендерится через OpenGL/EGL;
  • Композитор получает уведомление через wl_surface;
  • Композитор напрямую представляет wl_buffer через KMS, так как знает что тут больше не на что смотреть.


Так что ситуация значительно улучшилась. Хочу отметить, что KWin пока не поддерживает эти этапы и всё ещё рендерит через OpenGL, но мы движемся в этом направлении.

Однако, я думаю, ещё есть проблемы. Наш композитор (KWin) по-прежнему получает события от других окон, может «проснуться» и так далее. Запуск игры в режиме рабочего стола означает, что будут другие процессы в системе, с которыми игра должна разделить ресурсы. Мы хотим пойти по примеру Playstation: игре всё, остальным - ничего. Я не хочу чтобы KWin отбирал ресурсы CPU/GPU у игры.

Управление видеорежимами в ядре (Kernel Mode-Setting, KMS) в играх.

Итак, что мы можем сделать? Я думал об этом и предлагаю кардинально решить проблему с играми в Linux: убрать оконную систему! Игры должны общаться с KMS напрямую, игры должны взаимодействовать с libinput (библиотека ввода, прим. перев.) напрямую. Давайте удалим все лишние прослойки, нам это не нужно, это только мешает игровой производительности.

Когда игра запустится в полноэкранном режиме, можно создать отдельную сессию на другом виртуальном терминале (tty) и предоставить управление этой сессией через logind. Это позволит игре открыть файлы для рендеринга и обработки ввода также, как это делает композитор Wayland. Рендеринг может быть осуществлён через EGL поверх DRM/GBM, также как в композиторе Wayland. Игра получит полный контроль над KMS. Нужно другое разрешение экрана? Без проблем, бери и выставляй. В режиме рабочего стола, это всегда проблематично (гораздо хуже в X11, но лучше в Wayland). Для игр в оконном режиме ничего не изменится, они так и будут запускаться в режиме рабочего стола. (Прим.перев. По сути автор предлагает давно известную концепцию «запуска в отдельных иксах», но лишённую кучи недостатков).

Конечно, это должно убрать все взаимодействия с окружением рабочего стола. Это то, что нужно рассматривать в первую очередь, например, как заставить, скажем, Mumble (программа для аудиоконференций, прим. перев.) работать с такой конфигурацией? Может игре нужно запускать собственный Wayland-сервер?

Это также сломает Alt+Tab (сворачивание игры, прим.перев.). Ну, не совсем, правда. Для X11, который захватывает клавиатуру в некоторых играх, Alt+Tab всё равно не работает, так что тут особо ничего не потеряешь. Но конечно, всегда можно будет переключиться через Ctrl+Alt+F1 в рабочую сессию. Игры также должны иметь общий путь для достижения этой цели, на мой взгляд.

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

 , , , ,

Sunderland93 ()

Ситуация с Wayland: факты о X и Wayland.

Новости — Open Source
Группа Open Source

Это вольный перевод статьи, намедни размещённой на phoronix. Оринальная статья — обзор недостатков, их исправлений и преимуществ между X и Wayland. Её написал Eric Griffith, при участии Daniel Stone, специально для ресурса phoronix. Работа собрана по кусочкам из презентаций Keith Packard, David Airlie, Kristian Høgsberg, из страниц про X11, X12, Wayland в вики и на freedesktop.org, из прямых интервью с разработчиками.

Оригинал выпущен под Creative Commons версия 3, с указанием авторства; перевод доступен на тех же условиях (с указанием на авторов оригинала, как мне кажется).

( читать дальше... )

>>> Подробности

 ,

quiet_readonly ()