The Wayland Situation: Facts About X vs. Wayland / Факты о состоянии X и Wayland: The Failings of X

То, что поломано в X

kravich 08.06.13 в 07:54

С точки зрения автора, преимущества и особенности Wayland лучше всего рассмотреть со стороны недостатков X.

kravich 08.06.13 в 03:10

I) Последние 10 лет были проведены в попытках исправить X-сервер с помощю расширений и плагинов. Проблема заключается в том, что X имеет плохую поддержку версионирования в системе расширений.

kravich 08.06.13 в 03:12

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

kravich 08.06.13 в 03:16

B) Теоретический пример: Rekonq поддерживает Xinput 2.2. Kdelibs поддерживают Xinput 2.0, Флэш-плагин поддерживает Core X11, и все эти компоненты будут бороться за ту версию, которую поддерживает Rekonq, и в конце концов вы получите версию, которую поддерживают все, причем эту версию не обязательно будут поддерживать АБСОЛЮТНО ВСЕ приложения.

kravich 08.06.13 в 03:23

C) Если вам повезло, вы получите минимальную поддерживаемую версию и все будет работать. Если не повезло, то будет задействована максимальная версия, и вы будете передавать бесполезную, потенциально могущую вызвать ошибки информацию между клиентом и X-сервером.

kravich 08.06.13 в 03:27

II) X поддерживает четыре подсистемы ввода: Core X11, Xinput 1.0, Xinput 2.0 и Xinput 2.2. Xinput 1.0 устарел и не используется, но оставшиеся три в большей степени зависимы друг от друга, чем независимы. По словам Дэниэла Стоуна, "Есть только три человека, кто действительно понимает, как подсистемы ввода взаимодействуют друг с другом, и я хотел бы не быть одним из них."

kravich 08.06.13 в 03:32

III) Много лет назад, у кого-то появилась идея "Механизм, но не способ." Что это означает? То, что X имеет свой собственный X-специфичный API отрисовки, свой собственный тулкит наподобие GTK+ или Qt. Он определяет такие низкоуровневые вещи, как отрисовка линий, дуг, окружностей, простейших шрифтов и других "строительных" компонентов, которые бесполезны сами по себе. Примечание от Дэниэла: "Широкие линии должны отрисовываться с точностью до пикселя по спецификации, что в результате делает их выглядящими уродливо."

kravich 08.06.13 в 03:42

IV) X-сервер огромен. До того, как комьюнити взялось за работу над ним и начало выкидывать отдельные его части, он был почти что целой OS.

kravich 08.06.13 в 03:44

A) Например, X-сервер имел свой собственный сервер печати. Он был отделен после того, как кому-то пришлось добавлять поддержку Xprint в glxgears (не уверен в точности перевода данной фразы - прим. пер.)

kravich 08.06.13 в 03:46

B) Он имел в комплекте бинарный интерпретатор форматов ELF, COFF и a.out.

kravich 08.06.13 в 03:46

V) Композитинг и согласование окон. Разработчики научили X композитингу через расширение Composite. Для простых вещей, таких как десктоп и GL, оно работает хорошо. Если же вы хотите использовать аппаратные оверлеи (для видео), все становится просто ужасным.

kravich 08.06.13 в 03:52

A) Согласование медиа. Что такое согласование медиа? К примеру, есть браузер с открытой страничкой Youtube. Это окно. Флэш-плеер, проигрывающий видео, это суб-окно. Кто занимается их синхронизацией? Никто. События обрабатываются данными окнами раздельно, и в нынешней ситуации остается только молиться, чтобы обработка событий не разошлась слишком сильно друг от друга. Поэтому, когда вы проматываете страницу с встроенным видео, все дергается и рвется.

kravich 08.06.13 в 04:08

VI) Шрифты. Разработчики пытались научить X-сервер работать со шрифтами через расширение STSF. Идея заключалась в том, чтобы отрисовывать шрифты на сервере и раздавать клиентам достаточно информации для того, чтобы они могли правильно определить наложение шрифтов на их окна. Количество информации, достаточной для выполнения даной задачи, превышало размер самих шрифтов. Так что в конце концов было решено просто отдавать шрифты клиентами и позволить им самим работать с ними.

kravich 08.06.13 в 04:19

VII) Statelessness... Другими словами - X ничего не запоминает.

kravich 08.06.13 в 04:22

A) "Пожалуйста, сгенерируй мне конфиг файл." В конечном счете исправлено тем, что X-сервер использует конфиг-файл только для переопределения и имеет адекватные параметры по умолчанию и использует автоопределение.

kravich 08.06.13 в 04:27

B) Кто не имел проблем с мультимониторной конфигурацией под Linux? Или не настраивал все заново после перезагрузки? X сбрасывает все настройки, и только если вы прописали их в /etc/X11/xorg.conf.d/50-monitors.conf, они будут запомнены. Однако вам скорее всего все придется писать руками.

kravich 08.06.13 в 04:32

C) Это, возможно, будет исправлено созданием libkscreen, враппером для xrandr, который запоминает конфигурацию мониторов по их уникальным EDID.

kravich 08.06.13 в 04:36

D) В течение долгого времени, возможно даже до сих пор, была возможна ситуация, когда при подключении дополнительного монитора на основном мониторе работал композитинг, а на дополнительном нет. Это ВОЗМОЖНО исправлено RandR1.4, однако автор не нашел единогласного да или нет по этому вопросу.

kravich 08.06.13 в 04:41

VIII) Иерархия окон - это полный беспорядок. В X каждый элемент ввода и текстовое поле были отдельными окнами, которыми владело родительское окно. По этой причине никто не понимает функию, проверяющую дерево окон. Реальные тулкиты (не Core X11) не делают так уже давно.

kravich 08.06.13 в 04:48

IX) Хоть это и придирки, но все же заслуживает внимания. В X11, глобальный счетчик пикселей имеет размер 15 бит. Что означает, что на всех ваших дисплеях суммарно не может быть больше 32 768 пикселей. Для 100dpi это соответствует дисплею диагональю 8.3 метра. Windows XP поддерживает 95dpi. У телефонов сейчас больше 320dpi. А если учитывать большие разрешения и мультимониторные конфигурации, то ситуация станет рискованной уже очень скоро.

kravich 08.06.13 в 05:11

X) Для X все является окнами. Не существует различных типов окон, это просто "окна".

kravich 08.06.13 в 05:13

A) Скринсейвер? Это окно, которое говорит X:
1) Размести меня поверх всех окон
2) Сделай меня полноэкранным
3) Отдай мне весь ввод

kravich 08.06.13 в 05:16

B) Всплывающее окно? Это окно, которое говорит X:
1) Помести меня в эту позицию
2) Отдай мне весь ввод

kravich 08.06.13 в 05:17

C) В чем проблема? Скринсейвер не активируется, пока активно всплывающее окно, так как они конфликтуют друг с другом.

kravich 08.06.13 в 05:20

D) Ваш скринсейвер и скринлокер, возможно, не умеют обрабатывать медиа клавиши, забирая при этом весь ввод. Пример: вы работаете дома, слушая музыку, собираетесь уходить, захлопываете крышку ноутбука. Ноутбук засыпает, оно скринсейвера является активным. Как только вы открываете крышку, музыка возобновляется, и легче просто снова захлопнуть ноутбук и разобраться с этим позже, чем ввести пароль, добраться до медиаплеера и приостновить его или ткнуть Mute. (имхо ССЗБ, но тем не менее - прим. пер.)

kravich 08.06.13 в 05:31

E) Разработчики пробовали исправить это. Они спроектировали расширение, проработали теорию. Однако когда пришло время реализовать все это, они осознали, что необходимые изменения слишком сильно сломают модель функционирования X. Так что этот дефект является не исправленным в течение 26лет и не похоже, что ситуация улучшится.

kravich 08.06.13 в 05:37

XI) "Если X11 такой ужастный, почему бы не сделать X12 вместо создания совершенно нового протокола?" Частично это было сделано: http://www.x.org/wiki/Development/X12

Проблема с тем, чтобы развивать замену X11 под именем "X" в том, что те, кто заинтересован в X, будут иметь право голоса и в будущих версиях X. Если называть нововведения "Wayland", то этой проблемы нет. Это независимый проект, и его разработчики могут делать с будущим дисплейным сервером что хотят, не оглядываясь на требования тех, кто заинтересован в X. Те же, кто заинтересован именно в "X", могут участвовать в разработке X12.

kravich 08.06.13 в 05:50