x11 proxy или перемещение клиента между серверами

Протокол тут не нужен никакой. Тут просто нужен инструмент. Попытки такое сделать были. Например, xmove, но он вроде не развивается давно. Я как-то пробовал его.

Зачем в тегах xpra? Он указан, потому что он подходит? Тогда см. x2go или коммерческую NoMachine NX. Можно сессию отложить и потом ее продолжить на другой машине. Если нужно что-то другое, то лучше уточнить.

GTK2 умеет это искаропки. Т.е. окно любой софтины можно перекинуть на другой сервер не перезапуская софтину. GTK3 не проверял

xorg, перекидывание окна на другой DISPLAY, какого хрена?

Qt тоже можно заставить так делать, но надо в потрошках поковыряться.

Ну в идеале, как раз хотелось бы иметь XMove, но он похоже давно помер.

Xpra я пока смотрю, но это всё же прокси, особо ничем не отличается от x2go по своей идее.

Хочется следующего эффекта - пускаю все приложения, кроме DE на дисплее X. Они рисуются на произвольном количестве дисплеев, которые можно подключать/отключать от дисплея X.

Насколько я помню, xmove тоже как бы прокси. Но там идея в том, что при переносе X-клиента он сохраняет все ресурсы, которые тот создал на сервере, а потом воссоздает все на другом дисплее, используя еще и таблицу перекодирования XID, так как запущенное приложение оперирует с XID старого дисплея. Поэтому надо типа таблицу перекодировки иметь. На новом дисплее ресурсы новые XID будут иметь. Я припоминаю, что был pdf с описанием, как это работает в xmove. Надо поискать.

Вроде вот, хотя мне казалось, что он был немного по-другому оформлен: A PSEUDOSERVER FOR X WINDOW MOVEMENT

Спасибо

Ну, в общем, можно просто попробовать. Я уже давно как-то собирал его и пробовал. И если мне не изменяет память, даже работало. Вторая версия, самая последняя. Там вроде поддержку Render добавили. Софтина старая, да. И вряд ли она сгодится в том виде, в котором есть.

Еще глянь на Xdmx. Я не совсем еще ухватил потребность именно раздельных серверов, но вот Xdmx как раз с отдельными серверами работает. И тут я тоже не знаю, как сейчас это работает и подойдет ли это тебе. Есть видео на youtube.

Ох, на первый взгляд xdmx похоже самое подходящее, а на второй и третий, какая то адская наркомания :)

Ну, это надо попробовать. Но я думаю, что могут быть проблемы с OpenGL, GLX. Я читал, что его когда-то с Chromium 3D использовали. А как GLX Proxy работает, одному Патрику известно. К тому же, разрабы Xorg не слишком активно сопровождают.

Протокол тут не нужен никакой. Тут просто нужен инструмент.

А вот как раз для DMX есть расширение.

http://dmx.sourceforge.net/DMXSpec.txt

Не, xdmx всё же не то, хотя задумка классная.

Эта штука позволяет представить n x11 серверов, на разных устройствах, как части одного дисплея. Это всякие intell wireless дисплеи нервно курящие в сторонке в начале нулевых, в силу своего физического отсутствия.

Xpra тоже не совсем то, точнее совсем то же что и x2go как я понял, только глючней и без удобного gui. Зато позволяет именовать сессии на сервере в отличии от x2go.

Хочется чего-то типа XSpice видимо, но что бы на другом конце тоже был X11 а не spice...

Ну, а как хочется?

Хочется следующего эффекта - пускаю все приложения, кроме DE на дисплее X. Они рисуются на произвольном количестве дисплеев, которые можно подключать/отключать от дисплея X.

Вот твое объяснение я перечитал и что-то не совсем понял. Что такое дисплей X? И тоже не совсем уяснил, что значит, что приложения рисуются на произвольном количестве дисплеев? Клиент один, а отображение на многих одновременно? Или как?

Да, согласен изложил так себе.

Попробую обьяснить высокоуровнево, на примере, чего хочется добиться.

Я сижу за компом A локально. Пользуюсь его DE и x11, запускаю приложения X, Y, Z .

Потом, я сажусь за комп B, использую DE и x11 компа B, но хочу продолжить работу с приложениями с компа A, но при этом только с A-X и A-Z, в том же состоянии в котором я их оставил на A.

Затем, я опять оказываюсь за компом A, и вновь хочу продолжить работу с приложениями A-X и A-Z с того же состояния, как я оставил их на компе B.

Сиё можно организовать, запуская нужные приложения всегда через x2go (например глубоко встроив его в систему и используя логин только через x2go) или xpra. Но хочется интеграции именно на уровне иксов, при этом, что бы локальные приложения использующие графическое ускорение чувствовали себя так, будто прослойки нет.

Вот для случая, когда на другой стороне spice - есть XSpice(в теории, как оно работает на самом деле я не проверял).

Хотелось бы то же самое, но что бы на другом конце можно было подключить произвольный X11. Т.е. это должен быть одновременно и X11 сервер и сущность которая позволяет удобно выбрать (по заголовкам окон например) id клиента и открыть прокси соединение конкретно для выбранного клиента к указанному X11 серверу.

Клиент один, а отображение на многих одновременно?

Это было бы приятным дополнением, но оно отнюдь не обязательно.

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

Клиент один, а отображение на многих одновременно?

Это было бы приятным дополнением, но оно отнюдь не обязательно.

Для этого когда-то был псевдосервер XMX, но это такой древний пис оф шит, что я даже не знаю, скомпилировать это можно или нет. Он древнее Линукса. :) Как раз для целей мультикастинга на дисплеи X11. Да и он только для этого сделан был, больше ни для чего.

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

А чем тогда Xdmx для экспериментов не катит?

Такого механизма в чистых иксах нет. Всегда будет прокси и прослойки: xmove, NX agent + NX Proxy и т. д. В чистых иксах приложение привязано к одному X-серверу, создает на нем ресурсы: атомы, пиксмапы, фонтсеты и т. д. То есть часть данных клиента хранится на X-сервере. Ты не можешь просто оторвать клиента от сервера. Поэтому тут только прокси вопрос решает.

x2go использует NX, а NX, а это, в общем-то, протокол X11, но только пожатый. Он не аналогичен VNC или RDP, которые в сущности картинки гоняют. См. вот тут, например, схемки:

https://people.gnome.org/~markmc/a-look-at-nomachine-nx.html

То есть для 2D ты получишь локальное ускорение.

Насчет переноса приложений вроде как и xmove тоже подходит (если он хоть как-то еще работает), но тебе также надо перетащить и 3D? Допустим у тебя приложение назагружало в GPU текстур. Теперь надо перенести OpenGL приложение на другой дисплей, у которого свой GPU. В общем, хотелка очень развеселая у тебя. Варианты такие, может быть:

1. VirtualGL. С ним должен работать x2go по идее, но я не пробовал. Рендериться все будет на одной машине, где есть GPU, а потом картинкой вставляться в поток X11 на удаленный дисплей.

https://en.wikipedia.org/wiki/VirtualGL:

When using the X11 Transport with an X proxy, both the 3D and 2D rendering occur on the application server. VirtualGL reroutes the 3D commands from the application to the 3D accelerator hardware, reads back the rendered images, and draws them as a series of uncompressed bitmaps into the X proxy (VNC or a similar system.) Meanwhile, the 2D drawing commands (X11 commands) from the application are sent to the X proxy directly. The X proxy is solely responsible for compressing the images and sending them to remote clients.

2. Chromium (не путать с браузером). За это решение я даже говорить не буду. Оно само по себе крутое в свое время было. Я бумагу про него читал когда-то (была мысль одна), но что с ним сегодня, я ума не приложу. Вроде уже лет десять нет известий. Его как раз с Xdmx использовали в связке, чтобы было 3D ускорение на всех дисплеях и был распределенный рендеринг 3D. Демка: https://www.youtube.com/watch?v=ArVAFfIXNZU

https://en.wikipedia.org/wiki/Chromium_(computer_graphics)

Но я полагаю, что это тебе не подойдет по причинам, что реализуется старая версия OpenGL, да и то с проблемами (я полагаю, что там актуальное состояние описано):

http://chromium.sourceforge.net/doc/conformance.html

А чем тогда Xdmx для экспериментов не катит?

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

Про nx я читал и про virgl тоже. И как раз их я и использую на практике в лице x2go(тот же glxgears хорошо крутит даже через lte, и на сервере и на клиенте).

Ещё x2go хорош тем, что он единственный, кто позволяет использовать кастомный X11 под виндой из подобных решений, ибо XMing и VcXsvr страшное угрёбище по сравнению с cygwin'овской реализацией. По крайней мере на hidpi глаз вытекает.

Не хватает именно возможностей по пере использованию сессий, но видимо можно искать решение этой проблемы на уровне того же x2go. В той же pyhoca они подошли к этому вопросу интересней чем в дефолтном клиенте, а имена сессий поддерживаются на уровне протокола.

Попробовал я таки xpra, у меня оно сходу не завелось, ни само по себе ни через winswitch(кстати неплохая штука, умеет в много протоколов, но та же наркомания с именованием и выбором сессий как в x2go, хотя чуть ближе к тому чего бы я хотел).

Chromium

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

В любом случае мне нужно всё же переключение между дисплеями, а не их обьединение, это я точно уже понял :)

Я тут ради интереса попробовал xmove. Удивительно, но эта хрень еще кое-как работает даже. Я и раньше пускал. Я не тестировал обстоятельно, но перекидывание осуществляет. Проверил на inkscape, firefox, evince, librecad. Все перекинуло. Тестировал так: запустил Xephyr как дисплей :10. Запустил псевдосервер xmove, который создал дисплей :1. Далее запускаем какую-нибудь программу DISPLAY=:1 inkscape. В Xephyr запустил icewm, чтобы хоть какой-то оконный менеджер там был: DISPLAY=:10 icewm-session. Дальше перекидываем xmovectrl :1 -moveall :10 (вместо -moveall можно -move и указать номер из списка приложений, которые были через псевдосервер запущены). И перекинулось. И назад в :0 перекидывает.

Однако (ложка дегтя) есть проблемы, например, с djview. Саму программу перекидывает, но вот файл открывать отказывается и падает. Я думаю, что и в других приложениях могут быть проблемы, так как какие-то новые запросы он за давностью лет может не уметь обрабатывать. Мне кажется, можно допинать программу. Видимо, чего-то не хватает ему, не хочет он до конца с псевдосервером работать. Сразу жалоба была, что нет расширения XKEYBOARD, но вроде даже после жалобы запустился. Ну, это ожидаемо, что не все расширения в xmove сделали и даже если сделали (как Render), то не все запросы. Но так глянь ради интереса. Замедление работы из-а прокси сервера не сильно заметно. Предполагаю, что в нем нет MIT-SHM (надо глянуть исходник), уже точно нет XKEYBOARD, наверняка нет RandR, нет XInputExtension. Из-за отсутсвия MIT-SHM работа с XImage может идти медленнее, но на удаленном дисплее и без этого MIT-SHM не будет. По скроллингу в FF видно, что что он чуть замедлился. Может, еще чего-то нет. Но оно может быть юзабельно для каких-то приложений. Похоже, что с GTK работает лучше, чем с Qt.

Евгений, спасибо.

А по твоим ощущениям — насколько сложно сейчас будет реанимировать LBX и портировать lbxproxy на современное API?

А по твоим ощущениям — насколько сложно сейчас будет реанимировать LBX и портировать lbxproxy на современное API?

Смысла реанимировать LBX нет. Кит Паккард (автор LBX) признал эксперимент неудачным [1], так как даже через ssh получалось быстрее. Но он по какой-то причине не додумался до того, до чего додумались сначала в проекте Differential X Protocol Compressor [2] и впоследствии в Nomachine с протоколом NX. Последние взяли идею DXPC и развили ее, получив наилучшее решение для сжатия протокола X11, а также предложили решение для устранения roundtrips и эффективные методы кеширования. С NX пробит потолок. При этом всем он остался все тем же X11. А если еще добавить в эту схему XCB, то должно получаться более-менее неплохо. NX вполне юзабелен даже по модему. Он быстрее VNC, он быстрее RDP (это только со слов, так как RDP я сам не сравнивал). Минус только в том, что это тоже все прокси, как и LBX.

[1] https://keithp.com/~keithp/talks/lbxpost/paper.html

[2] http://www.vigor.nu/dxpc/

Нет, по поводу сжатия всё понятно — я тоже читал эту статью Паккарда.

Меня, скорее, интересует возможность воссоздания соединения (lbxproxy -reconnect).

Про nx я читал и про virgl тоже. И как раз их я и использую на практике в лице x2go(тот же glxgears хорошо крутит даже через lte, и на сервере и на клиенте).

Но вот сейчас Nomachine, начиная с версии 4.0, похоже, по другому пути пошли. Я так понял, что они теперь занимаются решением для всего на свете и используют метод превращения всего в видеопоток и/или поток сжатых картинок, используя самые разные современные кодеки. То есть они сейчас свои решения только вокруг X11 не строят, как я понял. Это действительно было бы проигрышной стратегией - им деньги зарабатывать нужно, а X11 жать нужно весьма узкому сегменту потребителей.

Ага, я пробовал реализацию коммерческую. Имхо оно сравнимо с rdp(виндовой реализацией). Который в свою очередь дюже тормозной(субьективно) по сравнению с x2go на соединениях типа lte.

Один плюс коммерческой реализации nx - кроссплатформенный сервер. И это очень круто конечно, но для x11 пока лучше чем x2go я ничего не видел.

Меня, скорее, интересует возможность воссоздания соединения (lbxproxy -reconnect).

А чем так интересна эта возможность? lbxproxy не умеет сохранять ресурсы X-клиента, которые он на X-сервере разместил. Поэтому эта опция не имеет отношения к восстановлению работы после краха X-сервера.

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

Смотри, как это реализовано в GTK2: https://demonastery.org/2011/04/change-gtk-display-on-the-fly/

Дело в том, что в GTK2 есть gtk_window_unmap/gtk_window_map (gtk_window_set_screen собственно это и делает), которые вызывают удаление/отрисовку_с_нуля окна и его детишек с/на текущий display/screen.

Если в тулките (ну или приложении) не предусмотрен способ перерисовать окно заново, с нуля, то Xorg мало чем поможет - чтобы добиться того же эффекта, придётся сохранять всю историю общения клиента с сервером, что весьма непрактично.

В Qt этот механизм тоже есть, но он спрятан от пользователя глубоко в кишках

Нет, это задача не Xorg, а прокси-уровня (коим в некотором роде и тулкит тоже является). Тут вообще нигде не говорится про то, чтобы этому научить именно Xorg. Он сделан так, как сделан - уже ничего не попишешь. Но вот возлагать эту работу на тулкит - это просто решение для конкретного тулкита. И такое решение было еще до GTK (например, XTk). Более того, приложение может быть вообще без тулкита, а сохранять надо.

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

Это не так много информации, на самом деле. А ты думаешь, что в GTK хранить пиксмап дополнительно не придется? Если тулкит гоняет картинками, которые отрендерились на стороне клиента, то все само собой решается, так как тулкиту не надо ничего из сервера выгружать, у него исходник. А изначальная концепция приложений X11 предполагала, что ты пиксмап грузишь на сервер, а потом оперируешь XID, рисуешь что-то на нем, композитишь, а само приложение у себя копию этого пиксмапа не хранит. И если сервер теряет pixmap или picture (в Render), то его надо где-то приложению взять, а ты на сервере уже туда градиентов нарисовал, кругов. И как выглядит теперь этот пиксмап знает только сервер. Если он его потеряет, то все. Тулкиты, которые работают именно по такой схеме, уже никак не восстановятся. Им только придется реализовывать отрисовку на своей стороне или придумывать сложные схемы, как это заново все рисовать (если такое вообще возможно).

https://demonastery.org/2011/04/change-gtk-display-on-the-fly/

А вот это еще надо выяснить, каков механизм. Потому что одно дело, когда клиент может выгрузить из сервера то, что ему нужно (пиксмап можно выгрузить, а остальные ресурсы пересоздать потом), но возникает вопрос, как это будет себя вести, если сервер упал внезапно? Будет ли это приложение persistent? То есть переход на другой дисплей возможен только пока это приложение живо или даже если сервер внезапно пропал? Пока мне кажется, что речь идет именно об управляемом переходе на другой дисплей при живых X-серверах. Может быть, я неправ, так как я не успел выяснить, как это реализовано.

Дело в том, что в GTK2 есть gtk_window_unmap/gtk_window_map (gtk_window_set_screen собственно это и делает)

Ну, в общем, да. Он перенесет клиента на другой дисплей/экран (настолько, насколько он это умеет делать корректно), но не переживет внезапного уничтожения сервера. Плюс еще играет то, что приложения на том же GTK не предоставляют возможности задействовать эту функцию, хоть она и есть, поэтому чувак через GDB полез.