CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
16.12.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Окружение

Дискуссионный клуб :: Нетбуки

Прощай, консоль?

Сразу оговорюсь, что прощаться я предполагаю не с консолью вообще, а лишь с консолью вне gui. То есть, для *BSD/Linux — это консоль без запуска X Window, для MS Windows — recovery console (или как это там у них называется). Что касается консоли, запускаемой из-под gui, то она, кажется, бессмертна. Как минимум, из-за удалённых сеансов (связь никогда не бывает "слишком" хорошей) и всевозможных "изощрённостей", писать gui-приложения для которых — просто бессмысленно. Последних предостаточно, кстати, не только в мире *-nix-ов, но и под MS Windows.

Если оставить в стороне случаи, когда вычислительная система никаких других средств общения с собой, кроме консоли, не предоставляет ("тут уж — что уж"), "чистая" консоль в сравнении с консолью в среде gui может быть привлекательна только своей экономичностью. Почему бы и не сэкономить экранную площадь, электроэнергию, время и глаза, наконец?

"Подопытный"

В качестве последнего воспользуемся ASUS EEE PC. Оснований предостаточно.

  • Маленький, 7..9 дюймов экран. Ну, чего ради отдавать его под всякие панельки, док-бары и просто атрибуты окна, если меня в настоящий момент интересует, скажем, только текст или вывод nmap?
  • Нестандартная геометрия — бич современной консоли. LCD-мониторы (а что, бывают другие?) хорошо воспроизводят только при одном, рекомендованном, разрешении. Отношение сторон экрана, отличное от 4:3, потребует разрешения, отличного от стандартов VESA. Ушли от VESA — прощай framebuffer, "покрывающий" разрешения от 640х480 до 1280х1024.
  • Экономия электроэнергии лишней тоже не будет. Не из "глобальных" соображений, разумеется. Но если нетбук сможет жить без подзарядки дольше, а своей температурой перестанет напоминать щенка на ваших коленях — чем плохо?
  • Время загрузки — около 25 сек... Не так уж и плохо, в общем. Но из этих секунд до трети уходит на загрузку X Window и всего, что за этим "тянется". Пустяки, в принципе, но — зачем, если в конкретном случае я не предполагаю этим пользоваться?

"Лаборатория"

Под "лабораторией" в данном случае понимается операционная среда: конкретный дистрибутив. В настоящее время на EEE PC можно инсталлировать хоть Fedora, хоть Gentoo, хоть Debian. А Ubuntu представлен сразу несколькими своими "потомками". Дистрибутивно-специфичным рассматриваемый вопрос как раз не является: способ организации пакетного менеджмента не интересует "ни капли". А вот конфигурация ядра — весьма. Поэтому и оговоримся, что всё, описываемое ниже, проделывается с ASUS EEE PC под управлением Eeebuntu 3.0 Standard.

Что касается конфигурации ядра, то существенным является наличие поддержки framebuffer (какая-никакая консоль у EEE PC и так есть. Мы хотим — "хорошую"). Драйвера поддержки framebuffer могут быть частью ядра или модулями из каталога /lib/modules/$(uname -r)/. В случае Eeebuntu 3.0 все драйвера framebuffer — модули.

Итак, хотим использовать маленький экран с максимальным качеством — произвольные фонт и кегль, 32-битный цвет символов и фона, минимальные издержки. Решение очевидно: графическая консоль — единственная консоль, имеющая место в Solaris и PalmOS, известная для i386 как framebuffer. Ничего особенно нового... кроме упомянутой выше геометрии экрана и нежелания составителей дистрибутивов "заморочиваться" этим вопросом: ну, не описан для vesa-framebuffer ни видеорежим 800x400, ни 1024х600. Нельзя его задать параметром загрузки "vga=XXX" и... ладно.

"Попытка — не пытка"

А мы — попробуем. Для начала "от греха" отключим графическую загрузку — "закомментируем" запуск gdm (или иного дисплей-менеджера) в файле /etc/X11/default-display-manager. Так мы защитимся от возможных конфликтов между загружаемыми драйверами и X Window.

Теперь уберём из параметров загрузки все "vga=XXX" и "video=..." (если они там есть, разумеется). Цель — заведомо не использовать framebuffer после старта системы (проверяем: устройство /dev/fb0 должно отсутствовать. Так же, как и каталог /sys/class/graphics/fb0).

Теперь смотрим: что за драйвера аппаратной поддержки framebuffer есть у нас в системе. Для этого можно проанализировать файл конфигурации ядра (/boot/config-2.6.28-12-netbook), секция Frame buffer hardware drivers или состав каталога /lib/modules/$(uname -r)/kernel/drivers/video/. Практический интерес представляют только два универсальных драйвера — vesafb и uvesafb, а также один "специфический" — драйвер присутствующего в системе видеоадаптера, коим для ASUS EEE PC является intelfb. Остальные могут оказаться интересными, если вы будете проделывать аналогичные операции с видеоадаптером вашего десктопа.

Для загрузки драйвера vesafb необходимо (и достаточно) указать среди параметров загрузки ядра 'vga=ask'. С таким параметром загрузка будет останавливаться, предлагая вам указать видеорежим или просмотреть список доступных вариантов. Здесь обнаруживается первый интересный факт. В зависимости от того, подключен ли к нетбуку внешний монитор, список разрешённых видеорежимов — разный. Это иллюстрация того факта, что видеоадаптеры Intel умеют читать DDC-данные подключенных мониторов, но не получают аналогичную информацию от экранов ноутбуков. Ну, поскольку выбирать-то (при отключенном внешнем мониторе) практически не из чего, то перейдём к следующему драйверу.

По поводу использования драйвера intelfb полнее всего на русском рассказал в своём блоге Кирилл Забарнюк aka mosquito. "Непримиримое" требование этого драйвера "задавать видеорежим при загрузке" (intelfb: Video mode must be programmed at boot time) делает описанный Кириллом способ (программирование видеорежима с помощью grub-2, благо последний имеет такую возможность) едва ли не единственно возможным. Способ работает, но "патчить" и компилировать grub-2 только для того, чтобы посмотреть, стоит ли полноценный framebuffer внимания, — не всякий захочет.

Более ленивым предлагаю загрузить драйвер uvesafb с помощью банальной 'modprobe' (а выгрузить можно с помощью столь же банальной 'rmmod'). Таким образом, мы можем убедиться, что, как и в случае с vesafb, переход в режим framebuffer имеет место: устройство /dev/fb0 появляется, команда 'fbset -s', как и положено, выводит полное описание моды, да и изображение на экране претерпевает изменения. Беда только, что графический режим 640x480, в котором мы оказываемся после включения framebuffer, не многим лучше алфавитно-цифрового 80х25, который имели без всех этих хлопот. Да, разнообразие загружаемых фонтов существенно больше, и увеличилась глубина цвета. Но... "не то". Поскольку 640x480 — это всё ещё не рекомендованные для этой матрицы 800х480 (или 1024х600).

Единственное полезное наблюдение — явное превосходство uvesafb над vesafb в скорости. Практически — безукоризненно. [Не]счастливые обладатели видеоадаптеров от AMD/ATI могут не возмущаться: framebuffer-проблемы с их адаптерами — "притча во языцех". Но это не повод отказаться от framebuffer на других адаптерах.

"Эврика"

Поскольку я, как и Кирилл Забарнюк, не остановился в своём любопытстве перед перекомпиляцией grub-2, то назначение утилиты 915Resolution было мне известно. Утилита эта всего лишь позволяет модифицировать копию BIOS видеоадаптера, уже находящуюся в памяти. Код 915Resolution, выполняемый ещё до загрузки ядра, перестраивает BIOS видеоадаптера, делая возможным выбор режима, недоступного без такой модификации. Понятно, что аналогичная модификация, выполненная уже после загрузки intelfb, для этого драйвера ровным счётом ничего не изменит. Но не окажет ли она влияние на работу драйвера, загружаемого после её выполнения? Например, uvesafb? Если известно, что загрузка драйвера framebuffer приводит, в конце концов, к переключению в совершенно определёныый "видеорежим по умолчанию", то почему бы именно для этого режима не изменить разрешение?

Пробуем...

  • Со страницы Стива Томленовича (Steve Tomljenovic) можно загрузить исходный код 915Resolution. Но для особо ленивых есть ссылка и на deb-пакет.
  • deb-пакет не нужно пытаться инсталлировать — во-первых, это невозможно (конфликтует с актуальным драйвером intelfb из состава X Window), а во-вторых, не нужно: требуется извлечь из него лишь саму утилиту 915Resolution.
  • Запуск утилиты с ключом "l" (915Resolution -l) выведет список описанных в BIOS адаптера видеорежимов. Но ни режима 800х480, ни режима 1024x600 там, разумеется нет.
  • Но ничто не мешает нам модифицировать какой-нибудь режим. Например: 915Resolution 32 800 480. Здесь 32 — номер режима (изначально: 640х480, 8 bits/pixel), 800 480 — желаемое разрешение.
  • Повторный запуск '915Resolution -l' показывает, что изменился не только режим 32, но и остальные режимы, разрешение для которых задавалось как 640х480 (т.е. 8, 16 и 32 bits/pixel).
  • Осталось загрузить драйвер: 'modprobe uvesafb' — и абсолютно функциональный framebuffer 800х480 в нашем распоряжении.

Детали

Нюансы некоторые имеются... Так, после перехода в режим framebuffer требуется перезагрузка фонта, содержащего кириллицу, а драйвер консольной мыши "не видит" расширившегося экрана. Проще, наверное, привести скрипт, который выполняет все необходимые операции:

/usr/bin/915resolution 30 800 480
modprobe uvesafb
/etc/init.d/console-setup reload
/etc/init.d/gpm restart

При этом, естественно, предполагается, что 915resolution переписана в /usr/bin/, а сервис gpm — инсталлирован. Численные значения в командах предназначены для разрешения 800х480 (701-й), для 901-го — они несколько другие, но затруднений, мне кажется, это вызвать не должно.

Приведенные выше команды можно включить в /etc/rc.local (выполнение при каждой загрузке) или оформить в виде отдельного скрипта, вызываемого при необходимости. Для выполнения скрипта потребуются административные привилегии. А воспользуетесь вы для этого sudo или заблаговременно отредактируете /etc/sudoers — это уж кому как больше нравится.

Ну, и ещё несколько советов для тех, кто собирается "побороться" описанным выше способом за консоль на Ubuntu.

  • Отказавшись от автоматического запуска X Window (удалением имени дисплей-менеджера из /etc/X11/default-display-manager), запускайте Х-ы вызовом gdm. Канонический startx тоже, разумеется, сработает, но кое-какие апплеты панели можете потерять: не рассчитывали авторы на то, что схема загрузки будет так "раскурочена".
  • Когда вам надоест менять параметры консоли рекомендуемым 'dpkg-reconfigure console-setup', познакомьтесь с файлом /etc/default/console-setup. Редактирование последнего намного быстрее, а может стать и необходимостью, если захочется иметь независимые настройки консоли и X Window.
  • И загрузите, конечно, terminus: console-terminus для консоли и xfonts-terminus для X Window.

Выводы

Итак, прощаться с консолью (по крайней мере, из-за доминирующих тенденций в "экрано-строении") пока не обязательно. Трудности — преодолимы. Другое дело: "стоит ли овчинка выделки"? Спорить по этому поводу бессмысленно. Для не умеющего работать в консоли — нет, конечно. И, наоборот, — для умеющего данный вопрос аналогичен вопросу "а зачем нужны книги, если есть телевизор?".

Точно так же (то есть индивидуально) решается вопрос о целесообразности возни с "чистой" консолью. Изложенная выше история, кстати, закончилась вовсе не в пользу framebuffer. Выглядит он и правда неплохо, да только чтобы оценить это, мне, в частности, нужно одеть очки. А я этого не люблю даже в свои "за пятьдесят". Так что скриптик, незатейливо названный "h480", в /usr/bin "болтается", да и пользуюсь им я не так уж часто — в положении "без очков" банальная VGA консоль (80x25) оказывается на EEE PC вполне приемлемой.

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




Комментарии

Страницы комментариев: 1 :: 2 :: следующая

аноним, Mon Jun 22 10:36:53 2009:
Да уж.. про электроэнергию чушь какая-то написана +1 к прошлому отписавшемуся :-)
027, Tue Jun 16 01:24:48 2009:
Блять. Господа держатели ресурса. Может быть, пора оторвать жопу от стула и прикрутить, наконец, корректные скрипты для каментов?! Вместо этого бездарного сочинения обкуренного пэтэушника?
Только что я получил от этого бреда пасынка индуса-абстракциониста, сына побочного внука товарища Рериха, страницу без отправленного камента. И набрал по новой. Со смартфона, между прочим.
Вам сколько уже пеняют вменяемые люди! Вам что, доставляет изощренное удовольствие наблюдать это безобразие?
Блять.
Vertigo, Tue Jun 16 01:24:17 2009:
> Не вижу связи. Или вы полагаете, что в проприетарных Юниксах и им подобных эта проблема неразрешима?

Я про виндовс.
027, Tue Jun 16 01:04:13 2009:
Насчет экономии электроэнергии.
Вынужден разочаровать. Яркость свечения ламп подсветки никак не зависит от содержимого экрана. Просто сквозь темный фон просвечивают тощенькие контуры букв.
Лампы светят так же, как при черных буквах на белом фоне. Жрут так же.
027, Tue Jun 16 00:57:05 2009:
Насче экономии. Володь, тут какое дело. Яркость свечения ламп подсветки LCD панели не зависит от черноты экрана. Никакой экономии батарей тут нет. Светят лампы так же. Жрут столько же.
Черная консоль означает, что сквозь сплошное затемнение просвечивают тощенькие контуры букоф. О светоизлучающих LED панелях пока что приходитсяся лишь мечтать.
аноним, Mon Jun 15 15:14:17 2009:
>Дай ссылочку на описание данного режима. Желательно на русском.
http://kerneltrap.org/node/8242
оно?
sasha_k, Mon Jun 15 09:57:56 2009:
>Вот она - сила open source. А остальным
> предлагается довольствоваться тем, что за них там
>где-то решили.

Не вижу связи. Или вы полагаете, что в проприетарных Юниксах и им подобных эта проблема неразрешима?
аноним, Mon Jun 15 08:38:36 2009:
>aVaTaR, среда, 10 июня 2009 г. 11:43:54:
Согласен.
аноним, Mon Jun 15 08:37:46 2009:
>aVaTaR, среда, 10 июня 2009 г. 11:43:54:
>> а про kernel mode settings автор ничего не слышал?
Дай ссылочку на описание данного режима. Желательно на русском.
аноним, Wed Jun 10 19:10:08 2009:
> Вот она - сила open source. А остальным предлагается довольствоваться тем, что за них там где-то решили.

Это ты про кого?

Страницы комментариев: 1 :: 2 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds