В Kwin ведётся работа для поддержки Wayland-клиентов

я так понял, что речь про мультимедиа-клавиши
Нет.

А про что?

Загляните в /usr/include/linux/input.h.

К.О. спешит на помощь:

Nvidia, скорее всего не станет писать драйвер под Wayland. Они и раньше не очень хотели, а сейчас еще и с MS дружить начали... Поэтому, драйвера не будет вообще.

>Все эти autofs

ты вообще в курсе, для чего предназначен autofs ? Мы его используем очень активно. А использовать его для работы с флешкой это один из возможных вариантов его использования, причём маргинальный

> ты вообще в курсе, для чего предназначен autofs ? Мы его используем очень активно. А использовать его для работы с флешкой это один из возможных вариантов его использования, причём маргинальный

в курсе. А ты видимо плохо прочитал мой пост и предыдущие - речь там шла о монтировании сменных носителей

>так и сетевая прозрачность в иксах в 99.9% не нужна, но вон какой срач каждый раз случается :)

тебе не кажется, что в век многоядерных компутеров и значит моря неиспользованных процессорных ресурсов, важнее универсальность приложения, объём его возможностей, чем оптимизация ?

> man NAS

немного не то. Если надо _только_ передавать звук по сети, тогда подойдет

man EsounD

RIP

>А ты видимо плохо прочитал мой пост и предыдущие - речь там шла о монтировании сменных носителей

Я как раз потихоньку читаю тред. Но выражения надо писать так, что бы не возникали неправильные выводы - ты ведь модератора, а не троль, в случае с autofs для это достаточно было написать пару дополнительных слов

ИМХО

> тебе не кажется, что в век многоядерных компутеров и значит моря неиспользованных процессорных ресурсов, важнее универсальность приложения, объём его возможностей, чем оптимизация ?

Чем больше будет таких «умников», делающих программы по принципу «нахер оптимизации, компьютеры мощные — и так схавают», чем быстрее мы увидим hello world-ы, не запускающиеся без многоядерного процессора и гигабайт оперативки. Ты уверен, что хочешь такого «развития» софтостроения? А ведь и так всё именно к этому идёт — рост производительности «железа» нередко компенсируется ростом (далеко не всегда оправданным) тяжеловесности и тормознутости софта...

s/чем быстрее/тем быстрее/

> Чем больше будет таких «умников», делающих программы по принципу «нахер оптимизации, компьютеры мощные — и так схавают», чем быстрее мы увидим hello world-ы, не запускающиеся без многоядерного процессора и гигабайт оперативки. Ты уверен, что хочешь такого «развития» софтостроения? А ведь и так всё именно к этому идёт — рост производительности «железа» нередко компенсируется ростом (далеко не всегда оправданным) тяжеловесности и тормознутости софта...

А теперь погугли, в каком году была разработана X Window, и придумай менее унылый вброс.

> А теперь погугли, в каком году была разработана X Window, и придумай менее унылый вброс.

Я не против иксов, мне они не мешают. Я против принципа «вычислительных ресурсов много, поэтому вопросами рационального их использования можно не заморачиваться» в разработке ПО. В контексте данного треда это можно отнести к тем, у кого аргументация против Wayland-а ограничивается лишь сетевой «природой» X Window и что поэтому не стоит даже пытаться разрабатывать альтернативы. Возраст и сетевая прозрачность иксов — не повод сидеть на них вечно и отказываться даже от мыслей придумать что-то другое.

> Я против принципа «вычислительных ресурсов много, поэтому вопросами рационального их использования можно не заморачиваться» в разработке ПО. В контексте данного треда это можно отнести к тем, у кого аргументация против Wayland-а ограничивается лишь сетевой «природой» X Window

Я сильно подозреваю, что вяленду нужно будет больше ресурсов, чем голым иксам. Собственно, это один из флагов, которыми размахивают аффторы вяленда - «мы сможем эффективно использовать новые возможности железа!!11».

> В контексте данного треда это можно отнести к тем, у кого аргументация против Wayland-а ограничивается лишь сетевой «природой» X Window

В контексте данного треда такую аргументацию «защиты» иксов можно встретить только у троллей-вейландофилов, пытающихся в подобном свете выставить точку зрения нормальных людей, понимающих реальные достоинства X Window.

Так что опять мимо.

>> А где уже сейчас клавиатуры с 255+ клавишами?

А где сейчас клавиатуры с горячими клавишами для вызова (например) видео-плеера и аудио-плеера, на которых эти кнопки работают в Linux?

А, то есть ты проблему линукса перекладываешь на иксы?

Загляните в /usr/include/linux/input.h.

То, что линукс пытается собрать в кучу все кнопки всех устройств с кнопками в мире, и пересчитать их по порядку номеров — его личные половые трудности. Иксы работают совершенно иначе: там кнопка 10 на клавиатуре 1 в текущей группе с действующими модификаторами может означать символ «√», а на клавиатуре 2 — запуск DVD-проигрывателя.

Линукс хочет, чтобы это были разные кнопки, иксам достаточно того, что это разные клавиатуры. Покажи мне клавиатуру с 255+ кнопками.

> Так что опять мимо.

Ну, я надеюсь, ты хотя бы не будешь отрицать неидеальность X Window и что разработка альтернатив имеет право на существование и может оказаться полезной? Или и тут мимо?

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

Ух. Как мультиплексор экрана может являться альтернативой оконной системы? Как может получиться что-то толковое из проекта, который не содержит ничего нового и не ставит таких целей? Зачем кому-то пытаться отрицать неидеальность иксов, когда вейланд не решает ни одной актуальной проблемы, стоящей перед иксами?

Ладно бы кто-то заговорил о реальной альтернативе иксам — реализации оконной подсистемы, построенной схожим с Photon microGUI образом, например. Да я обеими руками за развитие графических интерфейсов, но только где же оно?

Ну да, такой вот мультиплексор экрана в вакууме, очередной DirectFB, «пусть пилят, вдруг чего толковое в итоге получится», даже если эти ожидания никак не согласуются со здравым смыслом. Да я разве против — пусть пилят, ведь кто-то надеется, что очередная Модная Фишечка решит Все Проблемы Линукса На Десктопе — жестоко было бы лишать людей веры, ага.

>> тебе не кажется, что в век многоядерных компутеров и значит моря неиспользованных процессорных ресурсов, важнее универсальность приложения, объём его возможностей, чем оптимизация ?

Чем больше будет таких «умников», делающих программы по принципу «нахер оптимизации, компьютеры мощные — и так схавают», чем быстрее мы увидим hello world-ы, не запускающиеся без многоядерного процессора и гигабайт оперативки.

Я говорил о другом. Я говорил, что в современных реалиях нет смысла заботься о ресурсоёмкости программы за счёт урезания её функционала, даже если этот функционал используется не так часто.

В контексте нашего разговора это означает, что нет смысла урезать универсальность X-в только ради того, что бы отказаться от не очень часто используемого функционала. А как правило очень часто используется простейший из возможных функционал, а более редкие возможности используются более или менее грамотными людьми. Т.е урезание x-в будет бить в первую очередь по грамотным пользователям

его личные половые трудности
Кто вам сказал, что это решение ошибочное, и решение в Иксах лучше? И, если в исках решение правильное, зачем в XI2 и Wayland на сканкоды отведено больше? Абсолютно с тем же успехом вы можете доказывать что монтирование разделов по буквам, как в Windows, лучше подхода UNIX.

>А толку?

Как наткнёшься на 0, так сразу его обнаружишь.

>Ладно бы кто-то заговорил о реальной альтернативе иксам — реализации оконной подсистемы, построенной схожим с Photon microGUI образом, например.

С таким активным использованием IPC как на микроядре - ядро Linux склеится в два счета.

Ну да, такой вот мультиплексор экрана в вакууме, очередной DirectFB

А что там общего с DirectFB ?

> А что там общего с DirectFB ?

Общая ненужность для десктопа.

С таким активным использованием IPC как на микроядре - ядро Linux склеится в два счета.

Это интересно. Насколько архитектура Photon-а требует более интенсивного IPC, по сравнению с иксами?

>Общая ненужность для десктопа.

А - понятно, очередной пук, а я думал что-то интересное скажешь. Все никак не получается получить ответ от «нормальных людей, понимающих реальные достоинства X Window» - каковы же реальные преимущества X Windows :-)

Насколько архитектура Photon-а требует более интенсивного IPC, по сравнению с иксами?

Настолько же как микроядро ОС по сравнению с монолитным.

> Все никак не получается получить ответ от «нормальных людей, понимающих реальные достоинства X Window» - каковы же реальные преимущества X Windows

А ты и не спрашивал. На: http://www.linux.org.ru/jump-message.jsp?msgid=6363973&cid=6364563

Настолько же как микроядро ОС по сравнению с монолитным.

«А - понятно, очередной пук, а я думал что-то интересное скажешь.» (c)

А - понятно

Для успешной реализации ОС на основе микроядра в первую очередь было необходимо добиться максимальной эффективности IPC (так как от IPC зависит производительность всей ОС). Благодаря воплощенному в QNX механизму IPC с низкими издержками, стало возможным создание структуры GUI как графического «микроядра», окруженного командой взаимодействующих процессов, общающихся через IPC.

Хотя на первый взгляд это может показаться похожим на построение графической системы по классической схеме клиент/сервер, используемой в X Window System, архитектура Photon отличается за счет ограничения функциональности, реализуемой внутри самого графического микроядра (или сервера), и распределения большей части функций GUI между взаимодействующими процессами.

Микроядро Photon выполняется как маленький процесс (размер кода 45K), реализуя только несколько фундаментальных примитивов, которые внешние опциональные процессы используют для построения более высокого уровня функциональности оконной системы. По иронии, для самого микроядра Photon «окна» не существуют. Микроядро Photon не может также «рисовать» что-либо или управлять мышью либо клавиатурой.

Скорость IPC микроядер на порядки выше чем в монолитных ядрах.

> Кто вам сказал, что это решение ошибочное, и решение в Иксах лучше?

А кто говорит про ошибочность и лучшесть? Просто в иксах оно уже было от рождения, а в линуксе не так давно нородилось. Теперь у линукса есть два выхода:

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

2) Сделать всё то же самое, только под новые расширения. Затем написать эти расширения и убедить авторов программ начать ими пользоваться.

Разработчики линукса явно идут по второму пути: NIH во все поля.

Абсолютно с тем же успехом вы можете доказывать что монтирование разделов по буквам, как в Windows, лучше подхода UNIX.

Аналогию можно рассмотреть так: в иксах все клавиатуры (разделы) используют свои кеймапы/кейсимы (свои точки монтирования), образующие древовидную структуру, а в линуксе все клавиатуры (разделы) свалены в одну кучу, и чтобы не попутаться, плодятся кейкоды (буквы разделов) в едином корне.

скорее к кривизне алгоритма, анализирующего изображения

Давай поступим так: сначала ты сдашь вторую сессию, а потом начнешь предлагать и рассуждать?

Пример на пальцах - есть RGBA пиксмапы со словам «жопа», «ЖоПа», «жОпА», «ЖОПа» и «жОПА», все четыре пиксмапа полупрозрачные, размером 80x16. И есть окно 1280x1024 заполненное тайлингом некоторой картинкой, в котором мы в случайных местах рисуем случайно взятые пиксмапы из этих четырёх, 1000 раз:

fill_with_pixmap(win,bgpixmap,0,0,1280,1024); for (int i=1;i<1000;i++) put_pixmap(win,rand(1280),rand(1024),pixmaps[rand(4)]);

_Любой_ алгоритм работающий не от команды, а от пиксмапа, сдохнет уже на первой строке. Протокол, работающий «от команды» передаст пиксмап фонаи потом команду заливки этим пиксмапом. Всё, вэйланд-технологии в огромной толстой жопе, и «командно=отриентированные» методики (X11, RDP) празднуют.

А теперь добиваем. Я корпоративный юзер. Клиент редхата. Сижу на тонком клиенте (X-терминале). Видеокарты на сервере у меня нет, а на клиенте (X-терминале) есть... И ого-го какая. Командно-ориентированный X11 летает как электровеник. И OpenGL-ный приложения (визуализации всякие) работают только шум стоит. И тут приходят вялендофилы и рассказывают, что оказывается (!) у меня все неправильно, и теперь мне надо... Купить видеокарты в сервер (в каждый) и поставить 10-гигабитную сеть, поскольку у них есть более передовая технология.

P.S.: да, работал в банке. Да, у юзеров были X-терминалы. Да, вяленд сосет.

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

IPC с теми клиентами, которые являются клиентами в иксовом понимании, вряд ли может быть каким-то качественно иным — в иксах мы видим те же яйца с посылкой событий на каждый чих. Другое дело — клиенты-драйверы. Тут можно использовать грязных хак: предусмотреть API для загрузки такого клиента в пространство сервера как *.so. Архитектурно он всё-равно остаётся равноправным с остальными клиентом, просто доставка событий ему не требует IPC.

> Насколько архитектура Photon-а требует более интенсивного IPC, по сравнению с иксами?

Намного. Ядро Фотона (сервер) занимается только тем, что диспатчит сообщения между различными процессами (серверами и клиентами), при этом оно ничего не знает ни об окнах, ни о клавишах/мышах, даже рисовать не умеет. Зато полностью прозрачно для сети: клавиатура может быть на одном узле, приложение на другом, а окно вообще рисоваться на нескольких дисплеях, причем на некоторых только его кусочки.

Аплодирую стоя.

> Ядро Фотона (сервер) занимается только тем, что диспатчит сообщения между различными процессами (серверами и клиентами), при этом оно ничего не знает ни об окнах

Понятием региона он оперирует? Насколько я понимаю, окно приложения — частный случай региона.

Другое дело — клиенты-драйверы. Тут можно использовать грязных хак

И получим в итоге классическую архитектуру X Windows. Разве не ты говорил

Ладно бы кто-то заговорил о реальной альтернативе иксам — реализации оконной подсистемы, построенной схожим с Photon microGUI образом, например.

> И получим в итоге классическую архитектуру X Windows.

Нет. В X Windows интерфейсы к устройствам не выделены как равноправная сущность на уровне архитектуры. Они — скрыты глубоко в кишках реализации сервера, их «не существует» на том уровне абстракции, на котором лежат окна.

>Всё, вэйланд-технологии в огромной толстой жопе, и «командно=отриентированные» методики (X11, RDP) празднуют.

Так передавай по сети команды а рендеринг делай на локальной машине - Waylend здесь причем ? Вся разница в том что в иксах это есть «из коробки» а Waylend этим не занимается.

Если дело в этом:

да, работал в банке. Да, у юзеров были X-терминалы.

таких сферических юзеров можно по пальцам перещитать.

>Аплодирую стоя.

Ну вот послал тебе твой кумир

[quote]
«жопа», «ЖоПа», «жОпА», «ЖОПа» и «жОПА»
[/quote]

чего - он тебе пиксмапами это послал ? все эта ерись отрендерилась на твоей локальной машине без всякой необходимости в сетевой прозрачности иксов, более того он сидит в своем банке под вендой :-)

Так передавай по сети команды а рендеринг делай на локальной машине - Waylend здесь причем

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

Так вот бизнес-клиенты, которые несут подавляющую долю выручки для юниксовых вендоров, увидев вяленд покрутят пальцем у виска, так что если вялендофилы не возьмутся за ум и не сделают НОРМАЛЬНУЮ архитектуру с нормальнм низкоуровневым API базирующемся на прорисовке примтивов, вяленд ждет судьба DirectFB - вроде и есть, вроде и жив, вроде и на..у никому не нужен.

> в иксах это есть «из коробки» а Waylend этим не занимается

Вот именно. Обрезанный по самое «не могу» композитор от иксов не нужен — у нас есть нормальные иксы.

Что, анонимус, контрапримерчика не нашлось? X11 разрабатывали весьма умные дядьки, на два порядка умнее тебя, и не с хрена все системы подобного назначения строятся по одному и тому же принципу и к одной и той же архитектуре сходятся

>> man EsounD

RIP

4.2

Не обрезанный а делающий минимум задач с максимальной эфективностью - данные для рендеринга ты можешь передать хоть посредством 9p.

>на два порядка умнее тебя

Это вряд ли :-)

все системы подобного назначения строятся по одному и тому же принципу и к одной и той же архитектуре сходятся

Все системы - это Windows чтоли ?

> Не обрезанный а делающий минимум задач с максимальной эфективностью

Поддержку DRI под иксами уже отменили, а я всё проспал?

Кроме Windows, есть еще другие слова - Citrix, NX, X11. Боюсь, правда, что ты о них и не слыхивал :-)

>на два порядка умнее тебя

Это вряд ли :-)

Ну да, тут я тебя переоценил. Скорей не на два, а на четыре...

данные для рендеринга ты можешь передать хоть посредством 9p.

Угу, вот только вяленд рендерит только top-level окна (окна приложений), а пиксмапы «{жЖ}{оО}{пП}{аА}» это внутренние ресурсы приложения, на которые вяленд исходя из его архитектуры плевать хотел. Так что увы, про тонкие клиенты с вялендом придется забыть, про нормальные терминальные решения тоже, потом забыть про копроративный линукс, потом редхат забьет на линукс и он сдохнет.

И это еще раз докажет, что тупое школие способно развалить любую инфраструктуру.

>Ну да, тут я тебя переоценил.

Твое мнение меня не интересует так что утрись :-)

>>> man EsounD

RIP

4.2

не напомнишь когда там был последний релиз?

Ага, еще один админ локалхоста попытался сделать хорошую мину при плохой игре...

> Понятием региона он оперирует? Насколько я понимаю, окно приложения — частный случай региона.

Оперирует, но регион — это не только окно. Из какого-то региона пришло сообщение, его надо передать дальше, но что это за сообщение: код клавиши от io или команда нарисовать примитив от приложения — ядро не знает, и узнавать не собирается.

API для загрузки такого клиента в пространство сервера как *.so

И получим иксы. Всё равно, что загрузить сервисы в пространство микроядра, и получить монолит.

В X Windows интерфейсы к устройствам не выделены как равноправная сущность на уровне архитектуры.

Ортогонально. Иксы сейчас — монолит с загружаемыми модулями.

> Всё равно, что загрузить сервисы в пространство микроядра, и получить монолит.

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

Ортогонально. Иксы сейчас — монолит с загружаемыми модулями.

лицорука.jpg Иксы — монолит с различными бэкэндами, выбираемыми во время компиляции. Возможность загрузить модули драйверов — частная фича одного конкретного бэкэнда. Это принципиально отлично от случая, когда два независимых агента помещаются в общее адресное пространство в целях повышения производительности, но _всё_ _равно_ _остаются_ _независимыми_.

Я тут в роли К.О. должен объяснять очевидные вещи?