История изменений

т.е. по протоколу Xnext клиент с сервером только договариваются о том, на каком конкретном API (OpenGL 4, Xrender, Xvideo, OpenGL ES 2.0), из поддерживаемых обоими, они потом будут общаться и переходят на него?

Нет, на локальной машине они никуда не «переходят». Клиент по указке сервера загружает переходник, который реализует девайсо-независимый API, такой как OpenGL, поверх внутренних API видеодрайвера и дальше чтобы порисовать общается с ядром через этот переходник.

какая же это тогда абстракция?

Именно такая, как я сказал: абстракция от рисующего API. Мы от инструмента рисования абстрагировались, мы от него не зависим. В задачи XNext предоставление какого-либо API рисования не входит. Задачи XNext: ICC, мандатный контроль доступа (кстати, не упоминал еще об этом; нужно проектировать сервер сразу с security in mind, а не как с иксами получилось), иерархия окон, диспетчеризация ввода, предоставление доступа к инструментам рисования.

На инструменты рисования должны существовать отдельные спецификации.

Xnext — это тогда просто протокол управления расширениями: договорились и перешли на конкретную реализацию Device'а. Тогда другой сервер, который, возможно, будет подключаться к клиенту после разрыва соединения, может не поддерживать тот тип девайса, о котором клиент договорился с первым сервером, и тогда это будет Epic Fail имени VNC, как ты описал пример ниже.

Если видеоподсистема физически не поддерживает какое-то API, то при чем тут дисплейный сервер? Вот запущу я его поверх голого фреймбуфера, да на системе, где даже программной эмуляции OpenGL не установлено, и откуда тогда этому OpenGL взяться? И что с этой ситуация сможет сделать дисплейный сервер, кроме как честно сообщить: «нету такого, идите нафиг».

Рисовать должна железка, используя промышленные API, такие как OGL или D3D. В крайнем случае: библиотека программной эмуляция. А пытаться втиснуть в протокол дисплейного сервера какие-то инструменты рисования.... ну и чем он рисовать будет?

причем, если на клиенте в качестве API для рисования используется OpenGL, то далее все это преобразуется в абстрактный Xnext-API, а на сервере, исходя из поддержки оборудованием, может быть выбран, например, XRender, и тогда из Xnext-API сервер будет преобразовывать в API-XRender
правда, я сомневался в возможности придумать такой абстрактный API

Нет. При локальном рендеринге у клиента есть какой-нибудь драйверо-специфичный lib_mesa_opengl.so, который ему сказал использовать сервер. При удаленном рендеринге у клиента есть прокси-заглушка а ля lib_transport_opengl.so, которая засовывает все команды в сокет, а на той стороне такая же заглушка их парсит и вызывает функции той самой lib_mesa_opengl.so.

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

т.е. по протоколу Xnext клиент с сервером только договариваются о том, на каком конкретном API (OpenGL 4, Xrender, Xvideo, OpenGL ES 2.0), из поддерживаемых обоими, они потом будут общаться и переходят на него?

Нет, на локальной машине они никуда не «переходят». Клиент по указке сервера загружает переходник, который реализует девайсо-независимый API, такой как OpenGL, поверх внутренних API видеодрайвера и дальше чтобы порисовать общается с ядром через этот переходник.

какая же это тогда абстракция?

Именно такая, как я сказал: абстракция от рисующего API. Мы от инструмента рисования абстрагировались, мы от него не зависим. В задачи XNext предоставление какого-либо API рисования не входит. Задачи XNext: ICC, мандатный контроль доступа (кстати, не упоминал еще об этом; нужно проектировать сервер сразу с security in mind, а не как с иксами получилось), иерархия окон, диспетчеризация ввода, предоставление доступа к инструментам рисования.

На инструменты рисования должны существовать отдельные спецификации.

Xnext — это тогда просто протокол управления расширениями: договорились и перешли на конкретную реализацию Device'а. Тогда другой сервер, который, возможно, будет подключаться к клиенту после разрыва соединения, может не поддерживать тот тип девайса, о котором клиент договорился с первым сервером, и тогда это будет Epic Fail имени VNC, как ты описал пример ниже.

Если видеоподсистема физически не поддерживает какое-то API, то при чем тут дисплейный сервер? Вот запущу я его поверх голого фреймбуфера, да на системе, где даже программной эмуляции OpenGL не установлено, и откуда тогда этому OpenGL взяться? И что с этой ситуация сможет сделать дисплейный сервер, кроме как честно сообщить: «нету такого, идите нафиг».

Рисовать должна железка, используя промышленные API, такие как OGL или D3D. В крайнем случае: библиотека программной эмуляция. А пытаться втиснуть в протокол дисплейного сервера какие-то инструменты рисования.... ну и чем он рисовать будет?

причем, если на клиенте в качестве API для рисования используется OpenGL, то далее все это преобразуется в абстрактный Xnext-API, а на сервере, исходя из поддержки оборудованием, может быть выбран, например, XRender, и тогда из Xnext-API сервер будет преобразовывать в API-XRender
правда, я сомневался в возможности придумать такой абстрактный API

Нет. При локальном рендеринге у клиента есть какой-нибудь драйверо-специфичный lib_mesa_opengl.so, который ему сказал использовать сервер. При удаленном рендеринге у клиента есть прокси-заглушка а ля lib_transport_opengl.so, которая засовывает все команды в сокет, а на той стороне такая же заглушка их парсит и вызывает функции той самой lib_mesa_opengl.so.

т.е. по протоколу Xnext клиент с сервером только договариваются о том, на каком конкретном API (OpenGL 4, Xrender, Xvideo, OpenGL ES 2.0), из поддерживаемых обоими, они потом будут общаться и переходят на него?

Нет, на локальной машине они никуда не «переходят». Клиент по указке сервера загружает переходник, который реализует девайсо-независимый API, такой как OpenGL, поверх внутренних API видеодрайвера и дальше чтобы порисовать общается с ядром через этот переходник.

какая же это тогда абстракция?

Именно такая, как я сказал: абстракция от рисующего API. Мы от инструмента рисования абстрагировались, мы от него не зависим. В задачи XNext предоставление какого-либо API рисования не входит. Задачи XNext: ICC, мандатный контроль доступа (кстати, не упоминал еще об этом; нужно проектировать сервер сразу с security in mind, а не как с иксами получилось), иерархия окон, диспетчеризация ввода, предоставление доступа к инструментам рисования.

На инструменты рисования должны существовать отдельные спецификации.

Xnext — это тогда просто протокол управления расширениями: договорились и перешли на конкретную реализацию Device'а. Тогда другой сервер, который, возможно, будет подключаться к клиенту после разрыва соединения, может не поддерживать тот тип девайса, о котором клиент договорился с первым сервером, и тогда это будет Epic Fail имени VNC, как ты описал пример ниже.

Если видеоподсистема физически не поддерживает какое-то API, то при чем тут дисплейный сервер? Вот запущу я его поверх голого фреймбуфера, да на системе, где даже программной эмуляции OpenGL не установлено, и откуда тогда этому OpenGL взяться? И что с этой ситуация сможет сделать дисплейный сервер, кроме как честно сообщить: «нету такого, идите нафиг».

Рисовать должна железка, используя промышленные API, такие как OGL или D3D. В крайнем случае: библиотека программной эмуляция. А пытаться втиснуть в протокол дисплейного сервера какие-то инструменты рисования.... ну и чем он рисовать будет?

причем, если на клиенте в качестве API для рисования используется OpenGL, то далее все это преобразуется в абстрактный Xnext-API, а на сервере, исходя из поддержки оборудованием, может быть выбран, например, XRender, и тогда из Xnext-API сервер будет преобразовывать в API-XRender

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

Нет. При локальном рендеринге у клиента есть какой-нибудь драйверо-специфичный lib_mesa_opengl.so, который ему сказал использовать сервер. При удаленном рендеринге у клиента есть прокси-заглушка а ля lib_transport_opengl.so, которая засовывает все команды в сокет, а на той стороне такая же заглушка их парсит и вызывает функции той самой lib_mesa_opengl.so.

т.е. по протоколу Xnext клиент с сервером только договариваются о том, на каком конкретном API (OpenGL 4, Xrender, Xvideo, OpenGL ES 2.0), из поддерживаемых обоими, они потом будут общаться и переходят на него?

Нет, на локальной машине они никуда не «переходят». Клиент по указке сервера загружает переходник, который реализует девайсо-независимый API, такой как OpenGL, поверх внутренних API видеодрайвера и дальше чтобы порисовать общается с ядром через этот переходник.

какая же это тогда абстракция?

Именно такая, как я сказал: абстракция от рисующего API. Мы от инструмента рисования абстрагировались, мы от него не зависим. В задачи XNext предоставление какого-либо API рисования не входит. Задачи Xnext: ICC, мандатный контроль доступа (кстати, не упоминал еще об этом; нужно сразу проектировать сервер сразу с security in mind, а не как с иксами получилось), иерархия окон, диспетчеризация ввода, предоставление доступа к инструментам рисования.

На инструменты рисования должны существовать отдельные спецификации.

Xnext — это тогда просто протокол управления расширениями: договорились и перешли на конкретную реализацию Device'а. Тогда другой сервер, который, возможно, будет подключаться к клиенту после разрыва соединения, может не поддерживать тот тип девайса, о котором клиент договорился с первым сервером, и тогда это будет Epic Fail имени VNC, как ты описал пример ниже.

Если видеоподсистема физически не поддерживает какое-то API, то при чем тут дисплейный сервер? Вот запущу я его поверх голого фреймбуфера, да на системе, где даже программной эмуляции OpenGL не установлено, и откуда тогда этому OpenGL взяться? И что с этой ситуация сможет сделать дисплейный сервер, кроме как честно сообщить: «нету такого, идите нафиг».

Рисовать должна железка, используя промышленные API, такие как OGL или D3D. В крайнем случае: библиотека программной эмуляция. А пытаться втиснуть в протокол дисплейного сервера какие-то инструменты рисования.... ну и чем он рисовать будет?

причем, если на клиенте в качестве API для рисования используется OpenGL, то далее все это преобразуется в абстрактный Xnext-API, а на сервере, исходя из поддержки оборудованием, может быть выбран, например, XRender, и тогда из Xnext-API сервер будет преобразовывать в API-XRender

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

Нет. При локальном рендеринге у клиента есть какой-нибудь драйверо-специфичный lib_mesa_opengl.so, который ему сказал использовать сервер. При удаленном рендеринге у клиента есть прокси-заглушка а ля lib_transport_opengl.so, которая засовывает все команды в сокет, а на той стороне такая же заглушка их парсит и вызывает функции той самой lib_mesa_opengl.so.

т.е. по протоколу Xnext клиент с сервером только договариваются о том, на каком конкретном API (OpenGL 4, Xrender, Xvideo, OpenGL ES 2.0), из поддерживаемых обоими, они потом будут общаться и переходят на него?

Нет, на локальной машине они никуда не «переходят». Клиент загружает переходник, который реализует девайсо-независимый API, такой как OpenGL, поверх внутренних API видеодрайвера и дальше чтобы порисовать общается с ядром через этот переходник.

какая же это тогда абстракция?

Именно такая, как я сказал: абстракция от рисующего API. Мы от инструмента рисования абстрагировались, мы от него не зависим. В задачи XNext предоставление какого-либо API рисования не входит. Задачи Xnext: ICC, мандатный контроль доступа (кстати, не упоминал еще об этом; нужно сразу проектировать сервер сразу с security in mind, а не как с иксами получилось), иерархия окон, диспетчеризация ввода, предоставление доступа к инструментам рисования.

На инструменты рисования должны существовать отдельные спецификации.

Xnext — это тогда просто протокол управления расширениями: договорились и перешли на конкретную реализацию Device'а. Тогда другой сервер, который, возможно, будет подключаться к клиенту после разрыва соединения, может не поддерживать тот тип девайса, о котором клиент договорился с первым сервером, и тогда это будет Epic Fail имени VNC, как ты описал пример ниже.

Если видеоподсистема физически не поддерживает какое-то API, то при чем тут дисплейный сервер? Вот запущу я его поверх голого фреймбуфера, да на системе, где даже программной эмуляции OpenGL не установлено, и откуда тогда этому OpenGL взяться? И что с этой ситуация сможет сделать дисплейный сервер, кроме как честно сообщить: «нету такого, идите нафиг».

Рисовать должна железка, используя промышленные API, такие как OGL или D3D. В крайнем случае: библиотека программной эмуляция. А пытаться втиснуть в протокол дисплейного сервера какие-то инструменты рисования.... ну и чем он рисовать будет?

причем, если на клиенте в качестве API для рисования используется OpenGL, то далее все это преобразуется в абстрактный Xnext-API, а на сервере, исходя из поддержки оборудованием, может быть выбран, например, XRender, и тогда из Xnext-API сервер будет преобразовывать в API-XRender

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

Нет. При локальном рендеринге у клиента есть какой-нибудь драйверо-специфичный lib_mesa_opengl.so, который ему сказал использовать сервер. При удаленном рендеринге у клиента есть прокси-заглушка а ля lib_transport_opengl.so, которая засовывает все команды в сокет, а на той стороне такая же заглушка их парсит и вызывает функции той самой lib_mesa_opengl.so.

т.е. по протоколу Xnext клиент с сервером только договариваются о том, на каком конкретном API (OpenGL 4, Xrender, Xvideo, OpenGL ES 2.0), из поддерживаемых обоими, они потом будут общаться и переходят на него?

Нет, на локальной машине оникуда не «переходят». Клиент загружает переходник, который реализует девайсо-независимый API, такой как OpenGL, поверх внутренних API видеодрайвера и дальше чтобы порисовать общается с ядром через этот переходник.

какая же это тогда абстракция?

Именно такая, как я сказал: абстракция от рисующего API. Мы от инструмента рисования абстрагировались, мы от него не зависим. В задачи XNext предоставление какого-либо API рисования не входит. Задачи Xnext: ICC, мандатный контроль доступа (кстати, не упоминал еще об этом; нужно сразу проектировать сервер сразу с security in mind, а не как с иксами получилось), иерархия окон, диспетчеризация ввода, предоставление доступа к инструментам рисования.

На инструменты рисования должны существовать отдельные спецификации.

Xnext — это тогда просто протокол управления расширениями: договорились и перешли на конкретную реализацию Device'а. Тогда другой сервер, который, возможно, будет подключаться к клиенту после разрыва соединения, может не поддерживать тот тип девайса, о котором клиент договорился с первым сервером, и тогда это будет Epic Fail имени VNC, как ты описал пример ниже.

Если видеоподсистема физически не поддерживает какое-то API, то при чем тут дисплейный сервер? Вот запущу я его поверх голого фреймбуфера, да на системе, где даже программной эмуляции OpenGL не установлено, и откуда тогда этому OpenGL взяться? И что с этой ситуация сможет сделать дисплейный сервер, кроме как честно сообщить: «нету такого, идите нафиг».

Рисовать должна железка, используя промышленные API, такие как OGL или D3D. В крайнем случае: библиотека программной эмуляция. А пытаться втиснуть в протокол дисплейного сервера какие-то инструменты рисования.... ну и чем он рисовать будет?

причем, если на клиенте в качестве API для рисования используется OpenGL, то далее все это преобразуется в абстрактный Xnext-API, а на сервере, исходя из поддержки оборудованием, может быть выбран, например, XRender, и тогда из Xnext-API сервер будет преобразовывать в API-XRender

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

Нет. При локальном рендеринге у клиента есть какой-нибудь драйверо-специфичный lib_mesa_opengl.so, который ему сказал использовать сервер. При удаленном рендеринге у клиента есть прокси-заглушка а ля lib_transport_opengl.so, которая засовывает все команды в сокет, а на той стороне такая же заглушка их парсит и вызывает функции той самой lib_mesa_opengl.so.