Материал из Linuxformat.

LXF Интервью

X-фактор

Кейт Паккард трудится над X Window System более 20 лет, но его по-прежнему восхищает будущее графического фундамента Linux.

X Window System, известная также как X11 или просто X, является стандартной базовой графической подсистемой в Linux и других клонах Unix. На конференции Fosdem 2008 в Брюсселе мы спросили уважаемого разработчика Х, Кейта Паккарда [Keith Packard], что ждет нас впереди и почему он до сих пор столь нежно привязан к графике…

Linux Format: Что вы делаете на Fosdem?

Кейт Паккард: Вот уже три года разработчики Х встречаются на Fosdem ради множества разнообразных докладов и презентаций. Обычно мы вывозим разработчиков Х на вечер в Брюссель. И, как обычно, нас сюда влекут пиво, шоколад и мидии.

LXF: И о чем ваш доклад?

КП: Последние пару лет я работаю в Intel и занимаюсь различными аспектами внутренней инфраструктуры Х-сервера, чтобы соединить оборудование Intel с более современными графическими архитектурами, которые мы разрабатываем. Около года мы перерабатывали графический драйвер Intel для более эффективного использования оборудования и создания еще более крутых штук – как обычно, ради ярких демонстраций. Так что в этом году мой доклад посвящен тем изменениям в архитектуре, которые мы делаем, и тем, которые нам еще предстоит сделать.

LXF: Эти изменения касаются Х в целом, или только драйвера Intel?

КП: Изменений много и на разных уровнях. Основная вещь, которую нам предстоит реализовать в последующие годы – перенести изрядную часть функциональности драйвера в ядро, чтобы обеспечить большую стабильность и дать людям больше возможностей для быстрого переключения между пользователями, загрузки, интеграции между [текстовой] консолью и X Window System. Среди крутых нововведений, которые мы собираемся предложить в будущем – синий экран с данными о сбое.

LXF: Переключиться на текстовый режим ANSI?

КП: Именно – одна из главных причин, по которой разработчики ядра и больших систем не могут работать с графическими интерфейсами, в том, что когда происходит сбой, невозможно вытащить информацию.

LXF: А как насчет BulletProofX, прокладывающей себе путь в Ubuntu и другие дистрибутивы? Что, конечная цель в том, чтобы Х вообще не требовал файла конфигурации?

КП: Безусловно! И мы уже сейчас очень близки к этому. Вы можете запустить Х, если у вас чипсет Intel или ATI, используя драйвер с открытым кодом, без файла конфигурации. Одно из ключевых требований для этого заключается в том, что «в общем правильная вещь» – не всегда то, чего хотят все. Во многом наша работа за последние несколько лет была нацелена на обеспечение возможности внесения изменений после старта системы, чтобы ничего не настраивать, пока не запустится Х. Добавление новых устройств ввода, подключение нового монитора и изменение его настроек необходимы этой новой среде, свободной от файлов. Войдя в систему, вы можете сказать: «Хочу настроить мышь для работы левой рукой», или: «Мне нужен планшет», или: «Пусть монитор моего ноутбука будет слева от монитора компьютера» – и тому подобное.

LXF: Мы всегда удивлялись, почему Х не мог благополучно вернуться к старому стандартному разрешению 640x480, вместо выдачи в текстовой консоли сообщения «Экран не обнаружен»…

КП: [Смеется] Да, мы пытаемся исправить множество подобных проблем – чтобы, если файл конфигурации неправильный, система вернулась бы к настройкам по умолчанию, а не выдавала сообщения об ошибках.

LXF: Или жгла монитор! Полагаю, с LCD такой проблемы нет?

КП: На самом деле, есть! Если вы неверно запрограммировали внутреннюю панель, вы можете легко повредить свой LCD. Интересно, что Х раньше умудрялся портить ЭЛТ-мониторы, но сейчас у них хорошая защита. Если вы неверно запрограммировали работу с LCD, управление ими переходит на постоянный ток, а это может привести к закипанию жидкости внутри ЖК-ячеек.

LXF: А я-то надеялся, что обойдусь несколькими сгоревшими резисторами и испорченными чипами там и сям!

КП: Нет-нет, разрушения могут быть катастрофическими. Дабы обойти эту проблему, драйвер Intel, в частности, не позволяет программировать тайминги видео – эта опция отсутствует. Он использует те значения, которые, по сообщениям карты, являются правильными.

LXF: Вы участвуете в работе над Cairo и freedesktop.org?

КП: Я по-прежнему во многом отвечаю за freedesktop.org. Это – зонтичная организация для множества разных проектов: мы предлагаем услуги хостинга, списки рассылки и т.п. Мы предлагаем хостинг на бесплатной основе в обмен на свободные программы.

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

LXF: Cairo может похвастаться несколькими весьма крупными достижениями – движок рендеринга Firefox 3, например, будет создаваться на нем…

КП: Приятно наблюдать такое единение. Когда мы начинали проект Cairo, его целью был только рендеринг в Х. А месяца через три мы осознали, что это было неправильно. И вместо этого он стал кроссплатформенной и поддерживающей различные устройства вывода библиотекой рендеринга, так что приложения можно писать на Cairo, и они будут работать на Windows, Mac OS X и Linux. Они могут создавать PDF, или PostScript, или обращаться напрямую к драйверам GDI в Windows, что придает программам феноменальную гибкость. Вы можете использовать одно простое API, и ваше приложение будет работать где угодно.

LXF: А чем Cairo отличается от библиотеки Anti Grain Geometry?

КП: Есть другие библиотеки рендеринга, и многие из них сосредоточены на тех же абстракциях, что и Cairo. Основное, над чем мы работали в Cairo, было создание понятного и простого в использовании дизайна API, а также стремление к этой цели – кроссплатформенности и поддержке различных выходных устройств.

По-моему, Anti Grain не поддерживает печати. А для приложения, которое создает презентации на экране и использует то же самое API для бумажной копии или вывода PDF, неплохо иметь API, пригодный для обеих целей.

LXF: Темпы разработки не замедлились после ответвления от XFree86? [До 2004 года XFree86 был основным поставщиком Х в Linux, но многие дистрибутивы перешли на другие ветви по причине лицензионных изменений]

КП: На самом деле, разработка ускорилась – и весьма заметно. X.org отвечал за развитие последние четыре или пять лет, и мы затеяли серьезные реформы оконной подсистемы. Конечно, у нас появились новые примитивы рендеринга, которые в настоящее время весьма эффективно использует Cairo, и мы говорим о серьезных изменениях функциональности вывода для мониторов и новшествах для планшетов и клавиатур «горячего подключения». Теперь мы говорим о перемещении всех процессов настройки и инициализации в ядро.

Инженеры Red Hat трудятся над получением более чистой системы загрузки, чтобы можно было загрузиться в консоль фрейм-буфера и мягко перейти в среду Х, а не проходить через черный экран со вспышками. Ubuntu работает над такой же функциональностью. И еще мы работаем над тем, чтобы вы могли видеть сообщения о проблемах в ядре на экране! Конечно, такое никто не хочет видеть никогда, и за это постоянно потешаются над Windows; и все же, чего хотят администраторы крупных систем? Они хотят использовать GUI для настройки и управления системой, и чтобы при этом на случай отказа интерфейс оставался текстовым.

LXF: Верно: в такой ситуации Х просто виснет, и невозможно понять, что вообще происходит.

КП: Точно, и поэтому-то мы и ждем с нетерпением, чтобы сообщения о сбоях появлялись на экранах!

LXF: Мне кажется, для вас есть Х и есть ядро, и они стоят особняком друг от друга – вы разделяете их жирной чертой…

КП: Вообще-то черта не такая жирная, как нам бы хотелось. Проблема была в том, что Х реализовывал значительную часть функций ядра в оконной системе – то есть в пространстве пользователя. В частности, у нас был код управления шиной PCI для перемещения видеокарты на случай, если ядро отобразит ее неверно. А для всего видео нам приходилось отображать регистры управления оборудованием в пространстве пользователя – в том числе и I/O-порты системы. А ведь это – сущее безумие! Так что приходилось запускать Х от имени root, а одна из главных целей – запускать ее от имени пользователя без привилегий.

LXF: И когда это будет? Работы, наверное, масса?

КП: Ну, на самом деле мы уже очень близки к этому. Мы надеемся скоро предъявить демонстрационный пример. Работы не так уж много – код установки режимов уже в ядре, а у нас есть работающий образец X-сервера для фрейм-буфера. У нас уже были демо-показы X-серверов, использующих инфраструктуру ускорения ядра; осталось только обсудить окончательный вид интерфейса и собрать его. Это очень чистая работа – наконец-то мы знаем, что делаем [смеется]!

LXF: Итак, вы хотите впихнуть побольше кода в ядро – а не получится ли у Х некий уклон в Linux?

КП: Вовсе нет; API ядра, которые мы разрабатываем, являются кроссплатформенными, и мы рассчитываем использовать те же самые интерфейсы в Solaris и BSD. У нас уже есть компоненты ядра этих систем для нашей 3D-среды, названной Direct Rendering Infrastructure, так что мы будем просто применять их. Мы не хотим ограничивать количество ядер, на которых мы можем работать, наша цель – просто решить основные проблемы.

LXF: Какие отношения у вас сейчас с парнями из XFree86? Продолжаете ли вы делиться кодом?

КП: Я был бы счастлив снова работать с ними над X Window System. Мы сотрудничаем по проблемам безопасности, чтобы исправления могли мигрировать в их систему. Но, помимо этого, совместной работы у нас нет.

LXF: Как вы представляете себе взаимоотношения между X.org, XGL и AIGLX? Мы можем говорить о DRI и 3D, но все пользователи ПК дружно скажут: «О-о-о, колышущиеся окна!»

КП: Именно, и это вовсе не плохо. Колышущиеся окна, которые мы используем сейчас, обычно строятся поверх AIGLX и XGL. XGL – интересный эксперимент, и он продемонстрировал часть инфраструктуры, нужной нам для плотной интеграции 2D и 3D в систему. Сейчас XGL не слишком активно разрабатывается – я не знаю, планируют ли дистрибутивы его долгосрочную поддержку.

Вся функциональность XGL, по сути, сводилась к ускорению и непрямому GLX, позволяющему X-серверу задействовать API GL при наличии подходящих драйверов. Именно это предоставляет AIGLX, но он предлагает данную функциональность без необходимости серьезно изменять остальную систему, так что мы смогли использовать более инкрементный подход.

LXF: Вы используете Compiz?

КП: Когда как. Я по большей части работаю без композитного менеджера, потому что мои 2D- и 3D-драйверы хронически находятся в стадии изменения. У меня есть группа QA в Intel, тестирующая разработку драйверов и изменения GL, которые мы производим, и они тестируют Compiz и 3D-игры, чтобы убедиться, что все работает. Но мой повседневный рабочий стол очень прост.

LXF: Значит, это не KDE и не Gnome?

КП: Вы будете смеяться, но до 2001 года я использовал Twm! А потом переключился на KDE, и он мне очень нравился, но недавно я перешел на Gnome. Мне они не кажутся слишком разными; оба они – двумерные. Я запускаю в них Emacs – чего еще нужно?

LXF: Линус Торвальдс недавно говорил, что ядро в какой-то мере «завершено», и самое интересное творится в пространстве пользователя. Вам не кажется, что Х находится в подобной ситуации? Он в основном закончен, и все интересное происходит исключительно на стороне приложений?

КП: Я уже 22 года работаю над Х, и продолжаю надеяться, что когда-нибудь он будет закончен! Ведь оборудование продолжает меняться, опыт пользователей продолжает меняться, и создатели приложений все так же жаждут новых разработок. Так что и требования к базовой системе продолжают меняться – отчасти даже быстрее, чем требования к ядру.

Однако, как мы знаем, скорость изменений ядра возрастает с каждым новым релизом. Хотя Линус и сказал, что оно стабилизировалось и работа выполнена, всегда есть много интересного, что можно попробовать, даже если в итоге это и не приведет к успеху. И при вовлечении в процесс новых людей появляются и новые идеи.

LXF: На своем ноутбуке я постоянно мучаюсь из-за необходимости иметь инструмент 915resolution, чтобы получить полноэкранное изображение. Это планируется изменить в драйвере Intel?

КП: Он вам больше не понадобится – он теперь встроенный. Программа манипулировала таблицами BIOS, чтобы создать альтернативную запись для родного разрешения вашего экрана, поскольку сам BIOS был неспособен сгенерировать ее. В таблицах BIOS имеется фиксированное количество слотов, и они обеспечивают фиксированные разрешения.

Windows не использует BIOS для программирования видеокарты, и изготовители ноутбуков иногда не меняют таблицу – не вносят в нее шесть чисел. Поэтому инструмент 915resolution фактически редактирует таблицы BIOS и замещает одно из разрешений – то, что используется наименее вероятно, например, 800 x 600. Теперь, когда драйвер Intel программирует оборудование сам, как драйвер Windows, мы получили возможность задействовать любой нужный нам режим. Это дает нам доступ к картам с ТВ-тюнером, с выходом HDMI и DVI – все теперь имеет полную поддержку.

LXF: Intel владеет немалой долей рынка графических чипов, и у ATI там тоже неплохая часть, так что все давление приходится на Nvidia, вам так не кажется?

КП: Раз я ношу логотип X.org, мне бы, конечно, хотелось, чтобы они предлагали драйверы с открытым кодом, чтобы удовлетворить пожелания многих своих клиентов, но у них есть свои планы по разработке и маркетингу, и я не в курсе, что они планируют.

LXF: При загрузке драйвера с закрытым кодом ядро Linux ставит флаг, чтобы из отчета об ошибке разработчики знали: причина проблем, возможно, кроется в закрытом модуле. Для Х планируется нечто подобное?

КП: Пока мы не видим в этом необходимости. Мы находимся в пространстве пользователя, а большая часть драйверов – в ядре. Если у вас есть видеодрайвер с закрытым кодом, значит, есть и компонент ядра с закрытым кодом.

Так что значительная часть оконной системы зависит от видео-драйвера; это – не ядро, где у вас может быть драйвер SCSI, сетевой драйвер, драйвер Wi-Fi, драйвер клавиатуры… а, и еще драйвер Nvidia. Вы не принимаете сообщения об ошибках, если в ядро был загружен драйвер Nvidia. Это все сильно отличается от практики Х, когда у вас есть драйвер клавиатуры, драйвер мыши и огромный, всеобъемлющий видеодрайвер. И если вы получаете сообщение об ошибке от человека, который использует только-двоичный драйвер, или драйвер, отстающий на 47 ревизий (хотя и открытый), нам это неважно – мы вам просто скажем: «Используйте последнюю версию драйвера с открытым кодом, и сообщите нам, если в нем будет ошибка».

LXF: Потратив столько времени на Х, вы никогда не испытывали желания заняться чем-то другим?

КП: А я получаю ничуть не меньше удовольствия, продолжая заниматься оконной системой и созданием графики на 2D-уровне. И что особо приятно, моя задача постоянно меняется, каждый год. Двадцать лет назад мы были счастливы, когда на экран выводилось цветное изображение!

LXF: И, наконец, есть ли в Х какие-нибудь «пасхальные яйца»? Например, комбинации клавиш, выводящие на экран изображение кролика, или что-то еще в том же роде?

КП: А что, было бы круто! В 1993 я работал над проектом Х-терминала. Помните классический хранитель экрана Х, в котором по экрану перемещалась плоская буква Х? Мы сделали его так, что через каждые 300 или 400 изображений он выводил картинку Джо «Боба» Доббса [Joe “Bob” Dobbs], лидера Церкви Субгениев [псевдорелигиозная группа, пародирующая всяческие культы, – прим. ред.]. Мы отправили его некоторым нашим клиентам! [Смеется] У нас даже были звонки в службу технической поддержки с вопросом: «Это что еще такое?!» Они думали, их компьютер заражен каким-то жутким вирусом! LXF