Як організований графічний стек linux?

Чи може хтось пояснити (сподіваємось, що з малюнком), як організований стек графіки Linux? Я весь час чую про X / GTK / GNOME / KDE тощо, але я дійсно не маю уявлення про те, що вони насправді роблять і як вони взаємодіють між собою та іншими частинами стека. Як поєднуються Єдність та Вейленд?

Система X Window використовує архітектуру клієнт-сервер. X-сервер працює на машині, яка має дисплей (монітори + пристрої введення), тоді як клієнти X можуть працювати на будь-якій іншій машині та підключатися до X-сервера за допомогою протоколу X (не безпосередньо, а скоріше за допомогою бібліотеки, наприклад Xlib або більш сучасний XCB, що не блокує події). Протокол X призначений для розширення і має безліч розширень (див. xdpyinfo(1)).

X-сервер виконує лише низькорівневі операції, такі як створення та знищення вікон, виконуючи операції малювання (на сьогоднішній день більшість малюнків робиться на клієнті та надсилається як зображення на сервер), надсилає події до windows, ... Ви можете бачити, як мало X-сервер робить запуск X :1 &(використовуйте будь-яке число, яке ще не використовується іншим сервером X) або Xephyr :1 &(Xephyr запускає X-сервер, вбудований у ваш поточний X-сервер), а потім працює xterm -display :1 &та переходить на новий X-сервер (можливо, вам знадобиться налаштувати авторизацію X використовуючи xauth(1)).

Як бачите, сервер X робить дуже мало, він не малює заголовки, не робить мінімізацію вікон / іконіфікацію, не керує розміщенням вікон ... Звичайно, ви можете керувати розміщенням вікон вручну за допомогою команди як xterm -geometry -0-0, але зазвичай у вас буде спеціальний клієнт X, який виконує вищевказані речі. Цей клієнт називається менеджером вікон . Одночасно може бути активний лише один менеджер вікон. Якщо ви до цих пір відкрито голий X - сервер попередніх команд, ви можете спробувати запустити менеджер вікон на ній, як twm, metacity, kwin, compiz, larswm, pawm, ...

Як ми вже говорили, X виконує лише низькорівневі операції, і не надає понять вищого рівня, як кнопки, меню, панелі інструментів ... Це надається бібліотеками, що називаються наборами інструментів , наприклад: Xaw, GTK, Qt, FLTK, ...

Настільні середовища - це сукупність програм, розроблених для забезпечення єдиного досвіду користувача. Отже, настільні середовища зазвичай забезпечують панелі, пускові програми, системні треї, панелі управління, інфраструктуру конфігурації (де зберегти налаштування). Деякі відомі настільні середовища: KDE (створений за допомогою інструментарію Qt), Gnome (за допомогою GTK), Просвітлення (з використанням власних бібліотек інструментаріїв), ...

Деякі сучасні ефекти на робочому столі найкраще виконувати за допомогою обладнання 3d. Отже, з'являється новий компонент, композитний менеджер . Розширення X, розширення XComposite, надсилає вміст вікна до складеного менеджера. Композитний менеджер перетворює цей вміст у текстури та використовує 3d обладнання через OpenGL, щоб скласти їх багатьма способами (альфа-змішування, 3d-проекції, ...).

Не так давно сервер X спілкувався безпосередньо з апаратними пристроями. Значна частина цього пристрою керування переміщується до ядра ОС: DRI (дозволяє доступ до 3d апаратного забезпечення за допомогою X та клієнтів прямої рендерингу), evdev (уніфікований інтерфейс для обробки пристрою введення), KMS (переміщення налаштування графічного режиму до ядра) , GEM / TTM (управління пам'яттю текстури).

Таким чином, при складності керування пристроями, що в основному знаходяться поза X, стало простіше експериментувати зі спрощеними віконними системами. Wayland - це система вікон, заснована на концепції композитного менеджера, тобто віконна система - це композитний менеджер. Wayland використовує обробку пристрою, який перемістився з X та надає за допомогою OpenGL.

Що стосується Unity, то це настільне середовище, розроблене для того, щоб мати інтерфейс користувача, придатний для нетбуків.

Традиційний стек побудований на трьох основних компонентах:

• X сервер, який обробляє відображення
• Менеджер вікон, що встановлює вікна в рамки, обробляє мінімізацію вікон і т.д. Це частина відокремлення механізму від політики в Unix
• Клієнти, які виконують корисні завдання як показ веб-сайту stackexchange. Вони можуть використовувати протокол X безпосередньо (самогубство), використовувати xlib або xcb (трохи простіше) або використовувати інструментарій, такий як GTK + або QT.

Архітектура X була створена мережею, завдяки чому клієнти могли бути на окремому хості та сервері.

Все йде нормально. Однак це був образ із зворотного шляху. На сьогодні графікою не обробляє процесор, а графічний процесор. Були різні спроби включити його в модель - і місце, коли ядро ​​з'явиться на місці для більшого розширення.

По-перше, було зроблено деякі припущення щодо використання графічної картки. Наприклад, передбачалося лише екранне відображення. Зараз я не можу знайти цю інформацію у Вікіпедії, але DRI 1 також припускав, що лише одна програма одночасно буде використовувати OpenGL (я не можу одразу процитувати, але я можу викопати помилку там, де вона була близька як WONTFIX з приміткою, щоб зачекати до DRI 2).

Для непрямого візуалізації було запропоновано кілька тимчасових рішень (необхідних для складеної ШМ):

• XGL - рання пропозиція, що підтримує програми, що спілкуються безпосередньо з карткою
• AIGLX - прийнята пропозиція, яка використовує мережеві властивості протоколу OpenGL
• Власне рішення NVidia

Розпочато роботи над новою архітектурою (DRI 2). Це включало:

• Підтримка ядра для обробки пам'яті (GEM / TTM)
• Моделювання ядра (KMS), що дозволяє змінювати роздільну здатність в ядрі, отже, уникаючи затримок при перемиканні між X і консоллю та кількома іншими функціями (наприклад, відображення повідомлення про паніку, навіть якщо X працює - який IIRC планується реалізувати).

Якимось ортогональним способом перейти до ядра розпочато роботу над драйверами Gallium. Бібліотека Mesa почалася як реалізація OpenGL на процесорі, а потім почала використовувати прискорення GPU. Це завжди було жорсткіше до OpenGL. У OpenGL 3.0 модель суттєво змінилася, і перезапис бібліотеки було неминучим. Однак вони користуються можливістю розділити код на кілька шарів, витягуючи загальний код і надаючи API низького рівня, що дозволяє впроваджувати різні 3D API поверх нього - дозволяючи, наприклад, Wine надавати DirectX спілкуватися безпосередньо з Gallium, а не проходити через OpenGL Рівень API (який може не мати прямих 1-1 дзвінків).

Wayland - це проекти, які вважають вищезазначене трохи складним і з надто "історією". Дизайн 1984 року (хоча сильно модифікований та адаптований) не відповідає початку 21 ст. на думку прихильників.

Припустимо, пропонується більша гнучкість та краща продуктивність, хоча в ньому все ще відсутні деякі важливі функції, такі як повна підтримка OpenGL (а для деяких важлива - підтримка мережі).

Ще трохи про робочі середовища та менеджери вікон. Менеджер вікон - це програма, відповідальна за те, як буде вести себе вікно - наприклад, він відповідає за управління робочими просторами, малювання смужки заголовка (річ у верхній частині екрана з титром windo та мінімізація / максимізація / закриття кнопок) тощо.

По-перше, використовувався лише мінімальний WM, але згодом користувач почав бажати робочого середовища, тобто більш доступної версії, яка включала в себе запуск меню, фон робочого столу тощо. Однак більшість частин середовища робочого столу не є менеджером вікон, хоча вони часто інтегруються.

Через деякий час була представлена ​​складова WM, яка використовує OpenGL та непряме візуалізацію для своєї роботи. Вони надають не тільки графічні ефекти, але й дозволяють легше реалізувати деякі функції доступності (наприклад, лупа).

Перш за все, насправді немає графічного стека Linux. Linux не має можливості графічного відображення.

Однак програми Linux можуть використовувати графічні дисплеї, і для цього існує ряд різних систем. Найпоширеніші з них - всі, побудовані поверх X вікон.

X - мережевий протокол, оскільки посеред стеку протоколів X можна мати мережу як стандартний компонент. Давайте розглянемо конкретний випадок використання. Фізик у Берліні хоче провести експеримент у ЦЕРН у Швейцарії на одному з колайдерів ядерних частинок. Він віддалено входить у систему та запускає програму аналізу даних на одному із суперкомп'ютерних масивів CERN та графікує результати на своєму екрані.

У Берліні фізик має пристрій X-терміналу, на якому працює деяке програмне забезпечення X-сервера, яке забезпечує можливість графічного відображення віддалених програм. Програмне забезпечення X-сервера має фреймбуфер, який розмовляє з конкретним драйвером пристрою для конкретного обладнання. І X-серверне програмне забезпечення розмовляє з протоколом X. Тому шари можуть бути графічним пристроєм-> драйвером пристрою-> буфером кадру-> X-сервером-> X-протоколом.

Потім у Швейцарії додаток підключається до дисплея за допомогою протоколу X і надсилає графічні команди відображення типу "намалювати прямокутник" або "альфа-суміш". Додаток, ймовірно, використовує графічну бібліотеку високого рівня, і ця бібліотека, ймовірно, буде базуватися на бібліотеці нижчого рівня. Наприклад, програма може бути написана на Python, використовуючи інструментарій WxWidget, який побудований поверх GTK, який використовує бібліотеку під назвою Cairo для основних графічних команд малювання. Також може бути OPENGL також на вершині Каїра. Шари можуть бути такими: WxWidgets-> GTK-> Cairo-> X Toolkit-> X протокол. Очевидно, що протокол посередині з'єднує речі, а оскільки Linux також підтримує сокети UNIX, цілком внутрішній транспорт даних, ці два типи речей можуть працювати на одній машині, якщо ви хочете.

X посилається на протокол і все, що має фундаментальне значення для архітектури, наприклад, X-сервер, на якому працює графічний дисплей, вказівний пристрій і клавіатура.

GTK і QT - це дві бібліотеки графічного інтерфейсу загального призначення, які підтримують вікна, діалоги, кнопки тощо.

GNOME та KDE - це два середовища для робочого столу, які керують вікнами на графічному робочому столі, надають корисні аплети та речі, такі як панелі кнопок. Вони також дозволяють безлічі додатків спілкуватися через X-сервер (X-термінальний пристрій), навіть якщо додатки працюють на різних віддалених комп'ютерах. Наприклад, копіювати та вставляти - це форма взаємодії між додатками. GNOME побудований на вершині GTK. KDE побудовано поверх QT. Можна запускати додатки GNOME на робочому столі KDE або додатки KDE на робочому столі GNOME, оскільки всі вони працюють з тим самим базовим X-протоколом.

Це його організація, ви дізнаєтесь більше з цієї картинки, що з декількох сторінок тексту:

Linux на робочому столі та на деяких серверах все ще має всю графіку X та буферів кадрів. Під вікном X - приходить GTK + і Qt, ТАК БУТЬ використовує систему X, знову ж таки, багато робочого середовища - Gnome, KDE використовує X-дисплей та їх оболонки тощо.

До речі, нещодавно з’явилося відео з Linux conf (http://blip.tv/file/4693305/). Кіт Пакард від Intel розповів про X та GL * Це було цікаво.