Выпуск X.Org 7.5/X Server 1.7, изначально запланированный на апрель, в очередной раз задерживается (http://www.phoronix.com/scan.php?page=news_item&px=NzQzNA). Новые сроки не называются, но еще не выпущена даже бета версия нового X сервера, хотя релиз был последний раз перенесен (http://www.opennet.me/opennews/art.shtml?num=21916) на 17 августа. Из-за неопределенности с выпуском X.Org 7.5/X Server 1.7 разработчики Ubuntu намерены (https://lists.ubuntu.com/archives/ubuntu-x/2009-August/00060...) использовать в релизе Ubuntu 9.10 версию X Server 1.6.3, самостоятельно портировав из ветки 1.7 наиболее важные исправления.
В X.Org 7.5 / X Server 1.7 появится поддержка технологии Multi-Pointer X и переработанной подсистемы ввода X Input 2, что позволит организовать работу нескольких независимых устройств ввода, например, несколько управляемых разными мышами курсоров на экране или ввод в разные окна с разных клавиатур.
URL: http://www.phoronix.com/scan.php?page=news_item&px=NzQzNA
Новость: http://www.opennet.me/opennews/art.shtml?num=22905
От клиент-серверной модели пора уходить.
Нужен нормальный (читай -- унифицированный и простой как оконное стекло) фреймбуфер.
Direct Rendering Module с необходимыми интерфейсами для проприетарных драверов — в ядро.Мультитач -- это не функция графической подсистемы, а функция специализированного драйвера-контроллёра мультитач-устройства ввода.
в новости нету ни слова про мультитач
>в новости нету ни слова про мультитачВот слово:
>В X.Org 7.5 / X Server 1.7 появится поддержка технологии Multi-Pointer X и переработанной подсистемы ввода X Input 2, что позволит организовать работу нескольких независимых устройств ввода, например, несколько управляемых разными мышами курсоров на экране или ввод в разные окна с разных клавиатур.
Multi-Pointer это не тоже самое что мультитач, идите учите матчасть
мультипоинтер - не мультитач.пример - на клавиатуру можно давить только одним пальцем? а если больше - плати яблоку? :-D
> а если больше - плати яблоку?Там какие-то непонятки с "плати яблоку".
У меня вот есть субноутбук Acer Aspire One 531. Там мультитач вполне работает. Причём на уровне нативной трансляции (так когда-то, лет 10-12 назад, в X'ах мышиное колёсико работало: если приложение достаточно современное, т.е, написано с использованием современных тулкитов, которые поддерживают более, чем три кнопки мыши, движение колёсика мапировалось на 4 и 5 кнопку, а если нет -- тогда засада. Motif'ные приложения можно было обучить колёсику, похачив ~/.Xdefaults и руками замапив ивенты от 4-й и 5-й кнопки на какие-нибудь там "стрелка вверх"/"стрелка вниз", а вот что-то совсем тупое приходилось заставлять работать, запуская нативный транслятор -- imwheel), в частности, классическая Apple'овская "распальцовка" действительно приводит к увеличению кегля шрифта в окошке браузера.
И один из моих коллег прислал мне какие-то выдержки от Acer'а, что либо патенты от Apple не действуют потому, что у оптического тачпада разрешение сильно меньше, чем у тензометрического Apple'овского, либо патенты слишком тривиальны, либо не действуют нигде, кроме СГП.
а в андроид гугл не добавляет его просто из-за вредности?
>От клиент-серверной модели пора уходить.Чем вам такая модель не нравится?
Одна компания от такой модели уже отказалась.
У неё ещё директором был Билл Гейтс)
В результате GUI стал такой неотъемлемой частью ядра, что проблемы у GUI - проблемы у ядра.
>> От клиент-серверной модели пора уходить.
> Чем вам такая модель не нравится?Латентностью в обработке ивентов, передаваемых через сокеты (а у текстового X-протокола ивентов ой, как немало). Этого недостаточно?
> Одна компания от такой модели уже отказалась.
> У неё ещё директором был Билл Гейтс)
> В результате GUI стал такой неотъемлемой частью ядра, что проблемы у GUI - проблемы
> у ядра.Мамо, Вы нулевое кольцо защиты (супервизор и HAL) с первым (драйверами) не путаете?
Перед тем, как сравнивать архитектуры UNIX и Windows NT, надо чуть более литературки почитать.
>Латентностью в обработке ивентов, передаваемых через сокеты (а у текстового X-протокола ивентов ой, как немало). Этого недостаточно?Аргумент сомнительный, так как не обязательно использовать unix sockets для транспорта. Можно задействовать разделяемую память например, способов межпроцессного взаимодействия много, и вопросы задержек решаемы без отказа от клиент-серверной модели. Да и оптимизацию X протокола тоже можно произвести. Сделать чтобы локально он работал по оптимизированному протоколу, а удалённо или по желанию - по сокетово-текстовому. Словом способов заставить работать эффективно Иксы не мало, вопрос только в том кто это это будет делать, а говоруны мы все:)
>Словом способов заставить работать эффективно Иксы не мало,Более того - почему-то всякие там плееры, нексуизы и прочие SDLно-opengl'ные и т.п. не тормозят и никакой латентности особо нет.Так что наши бздуны - еще и вруны.Зато какие-то виндоподобные решения - сватают.Хотя MS и то нынче заметный кус графических драйверов вынес из ядра.
>Более того - почему-то всякие там плееры, нексуизы и прочие SDLно-opengl'ные и т.п. не тормозят и никакой латентности особо нет.Ой-ой-ой. Никакой латентности нет только с NVIDIA-драйвером. А все остальное опенсурсное ЗАМЕТНО притормаживает.
Прямые вызовы сишных функций ВСЕГДА быстрее, чем работа с формализованым протоколом обмена, хоть даже через разделяемую память.Изначально моя мысль о простом "как оконное стекло" фреймбуфере внутри ядра с функциями вывода пикселя на абстрактный холст (ладно -- ещё закраски полигональной области заданным цветом). "Холст" обеспечивает драйвер через слой DRM. А не о нагромождениях клиент-серверных ООП-подобных технологиях.
на данный момент существуют только иксы. (не только конечно, но все они не серьёзные. а часть и загнулась не родившись)если у Вас есть конкретные предложения и желание реализовать - лично я с удовольствием потестирую. ;-)
но есть два "но".
1. не знаю как с ати, но с интел уже работать вполне можно. в частности он показывает лучшую производительность, чем под теми же виндами. (намёк на gem, uxa, и т.д.)
а ведь что-то типа виндов Вы и предлагаете? по крайней мере функционал должен быть не меньше (иначе нахр..н никому не нужен)
2. а как же модная (или хорошо забытая старая) тема о микроядре?
в линухе есть устойчивая тенденции движения в этом направлении. (вот и иксы скоро без рута будем запускать)
>если у Вас есть конкретные предложения и желание реализовать - лично я
>с удовольствием потестирую. ;-)Конкретные предложения, или ТЗ на разработку:
1) Реализовать математическую модель 2D-холста (math_view) внутри ядра, в нём же реализовать векторные примитивы (точка, прямоугольник, дуга, полигон);
3) Реализовать цветовую модель на уровне модуля(ей) ядра (RGB, CMYK, LMS, CIE LAB, CIE XYZ);
4) Написать унифицированный модуль DRM с чётко определёнными интерфейсами в обе стороны -- от ядра к DRM и от DRM к видеодрайверу;
5) Все необходимые системно-независимые трансформации из математического представления в растровое реализовать через систему плагинов DRM -- вендор-зависимых и системно-зависимых библиотек-"трансформаторов" (transformers), поставляемых вместе с драйвером видеокарты.Работа всей цепочки заключается в следующем:
Ядро строит математическую векторную сцену и передаёт её подсистеме DRM.
Подсистема DRM, используя вендор-специфик-трансформатор преобразует сцену в формат, понятный видеодрайверу. Готовую структуру отдаёт видеодрайверу для аппаратного преобразования и растеризации на видеокарте.ядро -> math_view <-> DRM <-> Driver <-> videocard
DRM <-> transformers
ясно. заодно вспоминаем о много-оконности, много-пользовательности, много-задачности... потом о 3д, опенжл (не забывая о вышесказанном)... и связанными с ними технологиями и проблеммами....
в общем Ваше описание процессов - далеко до реализации.ну и framebuffer (The Linux framebuffer (fbdev) is a graphic hardware-independent abstraction layer to show graphics on a console without relying on system-specific libraries) под линухом давно уже имеется. вот только путного из этого ничего не получается. и в частности фильмы смотреть там очень даже можно. толку то?
http://www.absoluteastronomy.com/topics/Linux_framebuffer
например есть такая шняга - fbui (FBUI, or FrameBufferUI, is a small, in-kernel graphical user interface for Linux. It works only with kernel 2.6.9.)
http://home.comcast.net/~fbui/
может Вы этим займётесь?
>Более того - почему-то всякие там плееры, нексуизы и прочие SDLно-opengl'ные и
>т.п. не тормозят и никакой латентности особо нет.Сказки не надо рассказывать. Тормозит и еще как. В том же нексуизе фпс гораздо меньше, чем под виндой, а если вы запустите штук 20 окон в smplayer с видео, то будет тормозить, а в винде те же 20 окон с видео в smplayer тормозить не будут.
Пора избавляться от костылей, коли уж Линукс на десктопы собирается.
>Сказки не надо рассказывать. Тормозит и еще какНу, мне вполне хватает, чтобы неплохо побегать ;).С проприетарными дровами 1280х1024 со средними настройками весьма недурно пашут.
>20 окон в smplayer с видео, то будет тормозить,
Клевый use scenario.А 20 пар глаз мне где взять?Или нафиг мне 20 окон smplayer?А с одним зато HD - ничего не тормозит, даже загрузку проца не разглядишь.При том что иксы ползают на ядре которое даунклокается powernowd до жалких 800МГц.И он даже в ус не дует поднимать ядру частоту.Поднимается только по поводу декодирования HD видео иногда, на ядрах где плеер крутится, не более :)
> а в винде те же 20 окон с видео в smplayer тормозить не будут.
А что, в винде работает smplayer?И насчет него не в курсе а вот аэро в дефолтной висте периодически подклинивает.Может из-за того что система вечно тарахтит дисками и что-то делает.Хрен там этих редмондовцев разберет, пусть сами в своем ... копаются.
>Пора избавляться от костылей, коли уж Линукс на десктопы собирается.
Умные все что пи$%ец.Ну, допустим мы выкинем иксы.А софт какой тогда использовать?И кстати почему бы тогда по аналогии MS'у не похоронить GDI? А то он тоже частично клиент-сервер, хоть кусок и в ядре.И тоже тормоз.И ничо, живет вроде на десктопах.При том на 90%.Странно...
> Латентностью в обработке ивентов, передаваемых через сокетыА это, shared memory тоже латентностью обладает?А то там где латентность не пофиг - юзается shared memory (плееры там всякие, etc).
>у текстового X-протокола ивентов ой, как немало). Этого недостаточно?
Я всегда подозревал что бсдшники имеют тягу к извращениям.Вы с ихреном это успешно подтверждаете.Простите, вы что, во времена доса до компа не добрались?А то ваши решения - где-то из тех времен родом по уровню.
> Мамо, Вы нулевое кольцо защиты (супервизор и HAL)
>с первым (драйверами) не путаете?Простите, а кто пользует нынче ring1?В свое время это делала полуось.А еще?Из ныне живых?
И кстати (во прикол!) в мире есть не только x86.И иксы например работают на моей Nokia n800.С ARM процессором.Там деление на кернел и юзер есть, но вот привычных вам колец как у интеля - нет.Факапнуть портабельность в пользу только 386 - это круто и модно, да?Или некоторые дальше своего сраного писюшника с антикварным как помет мамонта i386-compatible в упор не видят?> Перед тем, как сравнивать архитектуры UNIX и Windows
>NT, надо чуть более литературки почитать.Вот и сделайте это, особенно не забыв уточнить на скольких архитектурах работает *nix и подобное и черт возьми, покажите пожалуйста у ARM, MIPS или PPC хотя-бы кольца в том виде каком вы тут вещаете.Или вы предлагаете насрать на портабельность?Иксы например довольно портабельны и их без проблем запускают на ARM, MIPS, PPC и чем там еще.
>вы предлагаете насрать на портабельность?Иксы например довольно портабельны и их без
>проблем запускают на ARM, MIPS, PPC и чем там еще.А для вас портабельность - это то, за что приходится платить цену ПОСТОЯННФМ архитектурным отставанием от винды на десктопе? Для вас Линукс всегжда должен только на роутерах и серверах стоять со светофорами?
Ой звездеть не надо про "Архитектурное отставание"
Архитектурно - Linux куда стройнее винды
винда - сборище грязных хаков
>А для вас портабельность - это то, за что приходится платить цену
>ПОСТОЯННФМ архитектурным отставанием от винды на десктопе?Если уж говорить о архитектуре, в винде на основе NT как бы GDI тоже клиент-сервер строго говоря.Просто кус от него впихан в ядро для ускорения.Но он все-равно достаточно тормозной, скажем, видео через него играть крайне уныло (пожалуй даже более уныло чем через xshm).
>Для вас Линукс всегжда должен только на роутерах и серверах стоять со светофорами?
Вы не поверите но он у меня используется на моем основном десктопе.Настолько что я вообще стер к такой-то фене винды (все-равно в них не грузился по месяцам).И лично я с удовольствием рублюсь там в нексуиз и смотрю HD видео.Прикиньте? :D
>Иксы например довольно портабельны и их без
>проблем запускают на ARM, MIPS, PPC и чем там еще.В Google Android отказались от X'ов совсем. Там -- фреймбуфер.
И в других коммуникаторах-смартфонах тоже фреймбуфер.
Google Android запустили на ASUS EeePC: http://www.3dnews.ru/news/google_android_zapushen_na_eee_pc/
И чо? Там и от Kernel-API (C-API) отказались - нам что бежать и радостно одевать себе новые блестящие кандалы? :) Ню-ню опять.
>В Google Android отказались от X'ов совсем. Там -- фреймбуфер.Да, елки, там замечательная платформа.В которой сперва вообще только яву сделали (свобода выбора внушает, да... прям как в СССР).Ни с кем не совместимую.Ну а потом поняли что тормозит.Сделали возможность запускать нативный код.Через жопу, разумеется.Опять ни с чем не совместимо.Отличный пример для подражания.Для изобретателей велосипедов и тех у кого шило в ж.Как раз типа вас.
>И в других коммуникаторах-смартфонах тоже фреймбуфер.
А вот например в моей N800, которая выпущена далеко не вчера - иксы, как ни странно.Да, облегченные и заточенные.Но - иксы :).И как-то вроде работают.Вполне себе прилично.А еще GTK и Qt.Нормально вполне вроде :).И программы нормальные.В отличие от игрушек - обычные порты программ с десктопа, а хоть и адаптированные под мелкий скрин.И совместимость не потеряна, портирование на эту платформу (и с нее на допустим десктоп) - вполне простое.
>Google Android запустили на ASUS EeePC: http://www.3dnews.ru
>/news/google_android_zapushen_na_eee_pc/Осталось только придумать - напуркуа б практически полноценный комп даунгрейдить до жава-игрушки?Чтоб жава-фанат izen был счастлив?Ха-ха-ха, лолз. На большинстве eee с атомом нормально работает опенофис и файрфокс.Так что андроид на нем интересен разве что как научный курьез :D.Хотя лично вы можете себе воткнуть андроид на 4-ядерник в качестве основного десктопа :).
> От клиент-серверной модели пора уходить.
> Нужен нормальный (читай -- унифицированный и простой как оконное стекло) фреймбуфер.
> Direct Rendering Module с необходимыми интерфейсами для проприетарных драверов — в ядро.Слушайте, а может вам просто угомониться и свалить уже на виндовс?Или что там еще...
Иксы по своему хороши.И никакие тупые фреймбуферы никому не нужны.Где под них софт брать?> Direct Rendering Module с необходимыми интерфейсами для проприетарных драверов — в ядро.
Ога, это чтобы даже винды переплюнуть с их win32k.sys и сплойтами которые анимированными курсорами имеют ажно сразу ядро системы? oO
А может вы уже упхнетесь и поюзаете виндовс (или реактос, если открытость принципиальна) если вам такое очень уж нравится?
>> Direct Rendering Module с необходимыми интерфейсами для проприетарных драверов — в ядро.
>
>Ога, это чтобы даже винды переплюнуть с их win32k.sys и сплойтами которые
>анимированными курсорами имеют ажно сразу ядро системы? oOСлой DRM общается с драйверами через программный интерфейс без LPC, то есть код драйвера никак не может быть выполнен внутри DRM. DRM из драйвера отдаются только карты памяти, буфера, в которые "пишет" фреймбуфер. Видеодрайвер на основе обновлённых карт памяти и буферов аппаратно отрисовывает графические примитивы.
>Иксы по своему хороши.И никакие тупые фреймбуферы никому не нужны.Где под них
>софт брать?Вообще-то, приложения переднего плана привязаны к X'ам только через библиотеку Xlib-клиентскую часть X-server'а.
Можно установить полностью готовый Рабочий стол и настольные приложения (KDE4, Firefox, Eclipse, OpenOffice и т.д.) и... забыть поставить xorg-sever. :)Всё это говорит о том, что давно уже ничего не привязывает к X'ам, кроме тонкой прослойки библиотек, выполняющейся в пространстве пользователя. Проблема в том, что ширина интерфейса между приложениями и этими библиотеками очень большая, а между библиотеками и Xorg-сервером очень узкая. То есть получается "бутылочное горлышко" где-то внутри этих библиотек.
Почему бы не сделать так, чтобы приложения использовали унифицированный "узкий" интерфейс самого ядра вместо кучи неупорядоченных вызовов набора библиотек X'ов. Ядро будет строить векторные сцены из математических примитивов, а подсистема DRM с помощью драйвера и механизмов преобразований драйвера будет эту сцену выводить на видеокарту и экран.
Так как сцена векторная (объектная), то исключается оверхед, возможен параллельный рендеринг объектов (ядро будет обслуживать графические транзакции). А бутылочное горлышко в виде последовательного протокола обмена с X-сервером больше не нужно.
Все круто (как всегда только в теории), кроме того что на данный момент все кого колебал оверхед (3D игры, видеоплееры и прочая) уже и без этого нашли решения проблем в виде opengl, xv, xshm и прочая.
>От клиент-серверной модели пора уходить.Вот уже только не это! В этом вся сила X'ов! Наверное поддавшись на такие реплики и забросили XDMX и теперь он поломанный и никто его не фиксит. )-;
>>От клиент-серверной модели пора уходить.
>
>Вот уже только не это! В этом вся сила X'ов!Оверхед последовательного протокола...
Давно уже мечтаю поиграть в нексуиз двумя мышами без клавиатуры. Когда уже наконец? Или может уже можно?
>Давно уже мечтаю поиграть в нексуиз двумя мышами без клавиатуры.А что, это обещает быть удобно?Какой-то инопланетный стиль управления :)
Я представляю себе это так:
Правая мышь - как обычно, левая - для передвижения. При отклонении от условного центра скорость в заданном направлении увеличивается. Ну можно скорость всегда по максимуму, только вектор учитывать, чтоб быстрее шевелится. Ну и кнопки - прыжок, приседание.
Можно будет двигаться с разной скоростью и в любом направлении. В моих фантазиях это все очень удобно выглядит :) .
>Я представляю себе это так:
>Правая мышь - как обычно, левая - для передвижения. При отклонении от
>условного центра скорость в заданном направлении увеличивается. Ну можно скорость всегда
>по максимуму, только вектор учитывать, чтоб быстрее шевелится. Ну и кнопки
>- прыжок, приседание.
>Можно будет двигаться с разной скоростью и в любом направлении. В моих
>фантазиях это все очень удобно выглядит :) .Мне помниться, что первый quake с настройками по умолчанию так и работал. Это было очень неудобно.
Кстати.
Ссылка в новости ведет на фороникс.
Такое ощущение, что кому-то хочется внимания.
С тестами не получилось (тесты бредоватые).
Теперь решили постить новости? )
А меня больше волнует как там дела с карточками от Intel
всё теже 200fps вместо обычных 1500fps и мазня окнами по экрану?
>А меня больше волнует как там дела с карточками от Intel
>всё теже 200fps вместо обычных 1500fps и мазня окнами по экрану?Пока ты тут смотришь на glxgears, народ запускает savage 2, lightmarks 2008 и ET:QW на интеловских видюхах.
Изучи архитектуру наконец, научись читать логи.
>>А меня больше волнует как там дела с карточками от Intel
>>всё теже 200fps вместо обычных 1500fps и мазня окнами по экрану?
>
>Пока ты тут смотришь на glxgears, народ запускает savage 2, lightmarks 2008
>и ET:QW на интеловских видюхах.
>
>Изучи архитектуру наконец, научись читать логи.можно пруф?
может каноникал уже пора самим заняться иксами? Выделить десяток кодеров и навести порядок в этом болоте...
>В X.Org 7.5 / X Server 1.7 появится поддержка технологии Multi-Pointer X
>и переработанной подсистемы ввода X Input 2Хорош уж дразнить! (-: В каждой новости, которая про Xorg, приписка про MPX и XI2! (-:
Скорей бы уж!>использовать в релизе Ubuntu 9.10 версию X Server 1.6.3,
>самостоятельно портировав из ветки 1.7 наиболее важные исправления.Надеюсь кто-нибудь перетащит эту версию X'ов из ubuntu в портеж... (-;
1.6.2 вполне себе нормально работает. что именно из изменений сделаных убунтоводами стоит перетаскивать?
Нет предела совершенству. Если сборка Canonical повлияет на стабильность, скорость или повышение функционала в лучшую сторону (а именно это и предполагается), то почему бы это не использовать.
1.5 тоже нормально работал, только вот 1.6 гораздо шустрее, существенно меньше ест ресурсов и с приятной фичей определения устройств на лету, через hal. Если недо-1.7 по отношению к 1.6 будет хотя бы наполовину как 1.6 к 1.5 - почему бы и не перетащить эту сборку в Gentoo, или другие дистрибутивы.
Нужно не избавляться от X-сервера, а сделать kernel mode X, для тех кому так очень хочется. Кстати такой существует, только за него бабки хотят.
> Нужно не избавляться от X-сервера, а сделать kernel mode X, для тех
> кому так очень хочется.На сколько я думаю, Х-сервер должен быть в меру того, что должна быть поддержка удаленного десктопа.
А то в винде сделали свою внутреннюю систему как школьники делают в школе на паскале процедурным программированием, всё взгромоздили на кучу и вуаля.
> Кстати такой существует, только за него бабки хотят.Полностью согласен с разрабами того самого "kernel mode X". Хочешь играться в игрули - плати бабки. Или иди на винду, на линуксе никто не держит.