URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 57582
[ Назад ]

Исходное сообщение
"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."

Отправлено opennews , 06-Авг-09 09:24 
Выпуск 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


Содержание

Сообщения в этом обсуждении
"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено iZEN , 06-Авг-09 09:24 
От клиент-серверной модели пора уходить.
Нужен нормальный (читай -- унифицированный и простой как оконное стекло) фреймбуфер.
Direct Rendering Module с необходимыми интерфейсами для проприетарных драверов — в ядро.

Мультитач -- это не функция графической подсистемы, а функция специализированного драйвера-контроллёра мультитач-устройства ввода.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено ig0r , 06-Авг-09 09:39 
в новости нету ни слова про мультитач

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено XoRe , 06-Авг-09 10:04 
>в новости нету ни слова про мультитач

Вот слово:
>В X.Org 7.5 / X Server 1.7 появится поддержка технологии Multi-Pointer X и переработанной подсистемы ввода X Input 2, что позволит организовать работу нескольких независимых устройств ввода, например, несколько управляемых разными мышами курсоров на экране или ввод в разные окна с разных клавиатур.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено ig0r , 06-Авг-09 10:38 
Multi-Pointer это не тоже самое что мультитач, идите учите матчасть

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено vitek , 06-Авг-09 10:38 
мультипоинтер - не мультитач.

пример - на клавиатуру можно давить только одним пальцем? а если больше - плати яблоку? :-D


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Andrew Kolchoogin , 06-Авг-09 11:01 
> а если больше - плати яблоку?

Там какие-то непонятки с "плати яблоку".

У меня вот есть субноутбук Acer Aspire One 531. Там мультитач вполне работает. Причём на уровне нативной трансляции (так когда-то, лет 10-12 назад, в X'ах мышиное колёсико работало: если приложение достаточно современное, т.е, написано с использованием современных тулкитов, которые поддерживают более, чем три кнопки мыши, движение колёсика мапировалось на 4 и 5 кнопку, а если нет -- тогда засада. Motif'ные приложения можно было обучить колёсику, похачив ~/.Xdefaults и руками замапив ивенты от 4-й и 5-й кнопки на какие-нибудь там "стрелка вверх"/"стрелка вниз", а вот что-то совсем тупое приходилось заставлять работать, запуская нативный транслятор -- imwheel), в частности, классическая Apple'овская "распальцовка" действительно приводит к увеличению кегля шрифта в окошке браузера.

И один из моих коллег прислал мне какие-то выдержки от Acer'а, что либо патенты от Apple не действуют потому, что у оптического тачпада разрешение сильно меньше, чем у тензометрического Apple'овского, либо патенты слишком тривиальны, либо не действуют нигде, кроме СГП.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено vitek , 06-Авг-09 18:43 
а в андроид гугл не добавляет его просто из-за вредности?

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено XoRe , 06-Авг-09 10:04 
>От клиент-серверной модели пора уходить.

Чем вам такая модель не нравится?
Одна компания от такой модели уже отказалась.
У неё ещё директором был Билл Гейтс)
В результате GUI стал такой неотъемлемой частью ядра, что проблемы у GUI - проблемы у ядра.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Andrew Kolchoogin , 06-Авг-09 11:04 
>> От клиент-серверной модели пора уходить.
> Чем вам такая модель не нравится?

    Латентностью в обработке ивентов, передаваемых через сокеты (а у текстового X-протокола ивентов ой, как немало). Этого недостаточно?

> Одна компания от такой модели уже отказалась.
> У неё ещё директором был Билл Гейтс)
> В результате GUI стал такой неотъемлемой частью ядра, что проблемы у GUI - проблемы
> у ядра.

    Мамо, Вы нулевое кольцо защиты (супервизор и HAL) с первым (драйверами) не путаете?

    Перед тем, как сравнивать архитектуры UNIX и Windows NT, надо чуть более литературки почитать.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено ixrws , 06-Авг-09 11:56 
>Латентностью в обработке ивентов, передаваемых через сокеты (а у текстового X-протокола ивентов ой, как немало). Этого недостаточно?

Аргумент сомнительный, так как не обязательно использовать unix sockets для транспорта. Можно задействовать разделяемую память например, способов межпроцессного взаимодействия много, и вопросы задержек решаемы без отказа от клиент-серверной модели. Да и оптимизацию X протокола тоже можно произвести. Сделать чтобы локально он работал по оптимизированному протоколу, а удалённо или по желанию - по сокетово-текстовому. Словом способов заставить работать эффективно Иксы не мало, вопрос только в том кто это это будет делать, а говоруны мы все:)


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено User294 , 06-Авг-09 12:28 
>Словом способов заставить работать эффективно Иксы не мало,

Более того - почему-то всякие там плееры, нексуизы и прочие SDLно-opengl'ные и т.п. не тормозят и никакой латентности особо нет.Так что наши бздуны - еще и вруны.Зато какие-то виндоподобные решения - сватают.Хотя MS и то нынче заметный кус графических драйверов вынес из ядра.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено iZEN , 06-Авг-09 13:22 
>Более того - почему-то всякие там плееры, нексуизы и прочие SDLно-opengl'ные и т.п. не тормозят и никакой латентности особо нет.

Ой-ой-ой. Никакой латентности нет только с NVIDIA-драйвером. А все остальное опенсурсное ЗАМЕТНО притормаживает.
Прямые вызовы сишных функций ВСЕГДА быстрее, чем работа с формализованым протоколом обмена, хоть даже через разделяемую память.

Изначально моя мысль о простом "как оконное стекло" фреймбуфере внутри ядра с функциями вывода пикселя на абстрактный холст (ладно -- ещё закраски полигональной области заданным цветом). "Холст" обеспечивает драйвер через слой DRM. А не о нагромождениях клиент-серверных ООП-подобных технологиях.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено vitek , 06-Авг-09 18:54 
на данный момент существуют только иксы. (не только конечно, но все они не серьёзные. а часть и загнулась не родившись)

если у Вас есть конкретные предложения и желание реализовать - лично я с удовольствием потестирую. ;-)
но есть два "но".
1. не знаю как с ати, но с интел уже работать вполне можно. в частности он показывает лучшую производительность, чем под теми же виндами. (намёк на gem, uxa, и т.д.)
а ведь что-то типа виндов Вы и предлагаете? по крайней мере функционал должен быть не меньше (иначе нахр..н никому не нужен)
2. а как же модная (или хорошо забытая старая) тема о микроядре?
в линухе есть устойчивая тенденции движения в этом направлении. (вот и иксы скоро без рута будем запускать)


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено iZEN , 07-Авг-09 20:52 
>если у Вас есть конкретные предложения и желание реализовать - лично я
>с удовольствием потестирую. ;-)

Конкретные предложения, или ТЗ на разработку:
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


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено vitek , 07-Авг-09 22:51 
ясно. заодно вспоминаем о много-оконности, много-пользовательности, много-задачности... потом о 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/
может Вы этим займётесь?


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено 74025 , 06-Авг-09 14:21 

>Более того - почему-то всякие там плееры, нексуизы и прочие SDLно-opengl'ные и
>т.п. не тормозят и никакой латентности особо нет.

Сказки не надо рассказывать. Тормозит и еще как. В том же нексуизе фпс гораздо меньше, чем под виндой, а если вы запустите штук 20 окон в smplayer с видео, то будет тормозить, а в винде те же 20 окон с видео в smplayer тормозить не будут.

Пора избавляться от костылей, коли уж Линукс на десктопы собирается.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено User294 , 07-Авг-09 02:19 
>Сказки не надо рассказывать. Тормозит и еще как

Ну, мне вполне хватает, чтобы неплохо побегать ;).С проприетарными дровами 1280х1024 со средними настройками весьма недурно пашут.

>20 окон в smplayer с видео, то будет тормозить,

Клевый use scenario.А 20 пар глаз мне где взять?Или нафиг мне 20 окон smplayer?А с одним зато HD - ничего не тормозит, даже загрузку проца не разглядишь.При том что иксы ползают на ядре которое даунклокается powernowd до жалких 800МГц.И он даже в ус не дует поднимать ядру частоту.Поднимается только по поводу декодирования HD видео иногда, на ядрах где плеер крутится, не более :)

> а в винде те же 20 окон с видео в smplayer тормозить не будут.

А что, в винде работает smplayer?И насчет него не в курсе а вот аэро в дефолтной висте периодически подклинивает.Может из-за того что система вечно тарахтит дисками и что-то делает.Хрен там этих редмондовцев разберет, пусть сами в своем ... копаются.

>Пора избавляться от костылей, коли уж Линукс на десктопы собирается.

Умные все что пи$%ец.Ну, допустим мы выкинем иксы.А софт какой тогда использовать?И кстати почему бы тогда по аналогии MS'у не похоронить GDI? А то он тоже частично клиент-сервер, хоть кусок и в ядре.И тоже тормоз.И ничо, живет вроде на десктопах.При том на 90%.Странно...


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено User294 , 06-Авг-09 12:25 
>    Латентностью в обработке ивентов, передаваемых через сокеты

А это, 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 и чем там еще.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено 74025 , 06-Авг-09 14:23 

>вы предлагаете насрать на портабельность?Иксы например довольно портабельны и их без
>проблем запускают на ARM, MIPS, PPC и чем там еще.

А для вас портабельность - это то, за что приходится платить цену ПОСТОЯННФМ архитектурным отставанием от винды на десктопе? Для вас Линукс всегжда должен только на роутерах и серверах стоять со светофорами?


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Alexey Vostrikov , 06-Авг-09 14:40 
Ой звездеть не надо про "Архитектурное отставание"
Архитектурно - Linux куда стройнее винды
винда - сборище грязных хаков

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено User294 , 07-Авг-09 02:26 
>А для вас портабельность - это то, за что приходится платить цену
>ПОСТОЯННФМ архитектурным отставанием от винды на десктопе?

Если уж говорить о архитектуре, в винде на основе NT как бы GDI тоже клиент-сервер строго говоря.Просто кус от него впихан в ядро для ускорения.Но он все-равно достаточно тормозной, скажем, видео через него играть крайне уныло (пожалуй даже более уныло чем через xshm).

>Для вас Линукс всегжда должен только на роутерах и серверах стоять со светофорами?

Вы не поверите но он у меня используется на моем основном десктопе.Настолько что я вообще стер к такой-то фене винды (все-равно в них не грузился по месяцам).И лично я с удовольствием рублюсь там в нексуиз и смотрю HD видео.Прикиньте? :D


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено iZEN , 06-Авг-09 15:04 
>Иксы например довольно портабельны и их без
>проблем запускают на ARM, MIPS, PPC и чем там еще.

В Google Android отказались от X'ов совсем. Там -- фреймбуфер.
И в других коммуникаторах-смартфонах тоже фреймбуфер.


Google Android запустили на ASUS EeePC: http://www.3dnews.ru/news/google_android_zapushen_na_eee_pc/


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Diogene the Open Source programmer , 06-Авг-09 18:22 
И чо? Там и от Kernel-API (C-API) отказались - нам что бежать и радостно одевать себе новые блестящие кандалы? :) Ню-ню опять.

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено User294 , 07-Авг-09 01:37 
>В 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-ядерник в качестве основного десктопа :).


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено User294 , 06-Авг-09 12:15 
> От клиент-серверной модели пора уходить.
> Нужен нормальный (читай -- унифицированный и простой как оконное стекло) фреймбуфер.
> Direct Rendering Module с необходимыми интерфейсами для проприетарных драверов — в ядро.

Слушайте, а может вам просто угомониться и свалить уже на виндовс?Или что там еще...
Иксы по своему хороши.И никакие тупые фреймбуферы никому не нужны.Где под них софт брать?

> Direct Rendering Module с необходимыми интерфейсами для проприетарных драверов — в ядро.

Ога, это чтобы даже винды переплюнуть с их win32k.sys и сплойтами которые анимированными курсорами имеют ажно сразу ядро системы? oO

А может вы уже упхнетесь и поюзаете виндовс (или реактос, если открытость принципиальна) если вам такое очень уж нравится?


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено iZEN , 06-Авг-09 13:29 
>> Direct Rendering Module с необходимыми интерфейсами для проприетарных драверов — в ядро.
>
>Ога, это чтобы даже винды переплюнуть с их win32k.sys и сплойтами которые
>анимированными курсорами имеют ажно сразу ядро системы? oO

Слой DRM общается с драйверами через программный интерфейс без LPC, то есть код драйвера никак не может быть выполнен внутри DRM. DRM из драйвера отдаются только карты памяти, буфера, в которые "пишет" фреймбуфер. Видеодрайвер на основе обновлённых карт памяти и буферов аппаратно отрисовывает графические примитивы.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено iZEN , 07-Авг-09 21:08 
>Иксы по своему хороши.И никакие тупые фреймбуферы никому не нужны.Где под них
>софт брать?

Вообще-то, приложения переднего плана привязаны к X'ам только через библиотеку Xlib-клиентскую часть X-server'а.
Можно установить полностью готовый Рабочий стол и настольные приложения (KDE4, Firefox, Eclipse, OpenOffice и т.д.) и... забыть поставить xorg-sever. :)

Всё это говорит о том, что давно уже ничего не привязывает к X'ам, кроме тонкой прослойки библиотек, выполняющейся в пространстве пользователя. Проблема в том, что ширина интерфейса между приложениями и этими библиотеками очень большая, а между библиотеками и Xorg-сервером очень узкая. То есть получается "бутылочное горлышко" где-то внутри этих библиотек.

Почему бы не сделать так, чтобы приложения использовали унифицированный "узкий" интерфейс самого ядра вместо кучи неупорядоченных вызовов набора библиотек X'ов. Ядро будет строить векторные сцены из математических примитивов, а подсистема DRM с помощью драйвера и механизмов преобразований драйвера будет эту сцену выводить на видеокарту и экран.

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


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено User294 , 07-Авг-09 23:08 
Все круто (как всегда только в теории), кроме того что на данный момент все кого колебал оверхед (3D игры, видеоплееры и прочая) уже и без этого нашли решения проблем в виде opengl, xv, xshm и прочая.

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Inspirra , 06-Авг-09 14:50 
>От клиент-серверной модели пора уходить.

Вот уже только не это! В этом вся сила X'ов! Наверное поддавшись на такие реплики и забросили XDMX и теперь он поломанный и никто его не фиксит. )-;


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено iZEN , 06-Авг-09 15:01 
>>От клиент-серверной модели пора уходить.
>
>Вот уже только не это! В этом вся сила X'ов!

Оверхед последовательного протокола...


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Аноним , 06-Авг-09 09:52 
Давно уже мечтаю поиграть в нексуиз двумя мышами без клавиатуры. Когда уже наконец? Или может уже можно?

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено User294 , 06-Авг-09 12:16 
>Давно уже мечтаю поиграть в нексуиз двумя мышами без клавиатуры.

А что, это обещает быть удобно?Какой-то инопланетный стиль управления :)


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Аноним , 06-Авг-09 12:32 
Я представляю себе это так:
Правая мышь - как обычно, левая - для передвижения. При отклонении от условного центра скорость в заданном направлении увеличивается. Ну можно скорость всегда по максимуму, только вектор учитывать, чтоб быстрее шевелится. Ну и кнопки - прыжок, приседание.
Можно будет двигаться с разной скоростью и в любом направлении. В моих фантазиях это все очень удобно выглядит :) .

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Nicknnn , 06-Авг-09 18:46 
>Я представляю себе это так:
>Правая мышь - как обычно, левая - для передвижения. При отклонении от
>условного центра скорость в заданном направлении увеличивается. Ну можно скорость всегда
>по максимуму, только вектор учитывать, чтоб быстрее шевелится. Ну и кнопки
>- прыжок, приседание.
>Можно будет двигаться с разной скоростью и в любом направлении. В моих
>фантазиях это все очень удобно выглядит :) .

Мне помниться, что первый quake с настройками по умолчанию так и работал. Это было очень неудобно.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено XoRe , 06-Авг-09 10:06 
Кстати.
Ссылка в новости ведет на фороникс.
Такое ощущение, что кому-то хочется внимания.
С тестами не получилось (тесты бредоватые).
Теперь решили постить новости? )

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено fMad , 06-Авг-09 12:50 
А меня больше волнует как там дела с карточками от Intel
всё теже 200fps вместо обычных 1500fps и мазня окнами по экрану?

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Lindemidux , 06-Авг-09 22:17 
>А меня больше волнует как там дела с карточками от Intel
>всё теже 200fps вместо обычных 1500fps и мазня окнами по экрану?

Пока ты тут смотришь на glxgears, народ запускает savage 2, lightmarks 2008 и ET:QW на интеловских видюхах.

Изучи архитектуру наконец, научись читать логи.


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено ffsdmad , 07-Авг-09 15:19 
>>А меня больше волнует как там дела с карточками от Intel
>>всё теже 200fps вместо обычных 1500fps и мазня окнами по экрану?
>
>Пока ты тут смотришь на glxgears, народ запускает savage 2, lightmarks 2008
>и ET:QW на интеловских видюхах.
>
>Изучи архитектуру наконец, научись читать логи.

можно пруф?


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Зилибоба , 06-Авг-09 13:57 
может каноникал уже пора самим заняться иксами? Выделить десяток кодеров и навести порядок в этом болоте...

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Inspirra , 06-Авг-09 14:59 
>В 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 в портеж... (-;


"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено mike lee , 06-Авг-09 17:34 
1.6.2 вполне себе нормально работает. что именно из изменений сделаных убунтоводами стоит перетаскивать?

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Inspirra , 06-Авг-09 18:29 
Нет предела совершенству. Если сборка Canonical повлияет на стабильность, скорость или повышение функционала в лучшую сторону (а именно это и предполагается), то почему бы это не использовать.
1.5 тоже нормально работал, только вот 1.6 гораздо шустрее, существенно меньше ест ресурсов и с приятной фичей определения устройств на лету, через hal. Если недо-1.7 по отношению к 1.6 будет хотя бы наполовину как 1.6 к 1.5 - почему бы и не перетащить эту сборку в Gentoo, или другие дистрибутивы.

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Vasily Pupkin , 06-Авг-09 23:36 
Нужно не избавляться от X-сервера, а сделать kernel mode X, для тех кому так очень хочется. Кстати такой существует, только за него бабки хотят.

"Выпуск X.Org 7.5 и X Server 1.7 перенесен на неопределенный ..."
Отправлено Semplar , 14-Дек-09 08:59 
> Нужно не избавляться от X-сервера, а сделать kernel mode X, для тех
> кому так очень хочется.

На сколько я думаю, Х-сервер должен быть в меру того, что должна быть поддержка удаленного десктопа.
А то в винде сделали свою внутреннюю систему как школьники делают в школе на паскале процедурным программированием, всё взгромоздили на кучу и вуаля.


> Кстати такой существует, только за него бабки хотят.

Полностью согласен с разрабами того самого "kernel mode X". Хочешь играться в игрули - плати бабки. Или иди на винду, на линуксе никто не держит.