LINUX.ORG.RU
решено ФорумTalks

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

 ,


0

1

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

Всякое УГ типа NX и совершенно долбанутые костыли типа xpra - никуда не годятся даже для xedit не говоря уж о всём остальном. Хотя казалось бы.

Есть ли какие-либо реальные решения реализующие данную фичу без костылей? Или современные тулкиты настолько прибиты гвоздями к локалхосту, что задача становится неразрешимой?

Дано: есть машина с DISPLAY=:0.0 на неё установлен коннект ssh -Y и соответственно есть ещё DISPLAY=localhost:10.0 . Требуется приложение, работающее на :0.0 перекинуть на localhost:10.0 . Для простоты считаем, что обе тачки абсолютно идентичны. Теоретически, если брать X11 как сферического коня в вакууме, никаких особых проблем быть не должно, однако на практике красивого и прямого решения нету. Какого хрена, собственно? Ведь фича - можно сказать просто мечта и предмет мастурбации для современных дезигнеров, причём настолько, что удостоилась многократной экранизации в худ.фильмах.

★★★★★

Ответ на: комментарий от stevejobs

VNC, RDP, NX и прочее - вообще из другой области. Речь именно об X11 и окне отдельно взятого приложения с использованием провозглашаемой сетевой прозрачности, а не о десктопе целиком.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

провозглашаемой сетевой прозрачности

Все вокруг говорят, что стёкла прозрачные. Я вчера попробовал пройти сквозь стекло, ничего не вышло, только шишку набил. Доколе?!

i-rinat ★★★★★
()

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

Sahas ★★★★☆
()
Ответ на: комментарий от leonidko

xmove давно протухло, теперь вместо него xpra и реализация того и другого на самом деле совершенно безумна - запускается виртуальный xserver на нём запускается софтина и потом можно окно оной вывести на любой DISPLAY. Однако, оно принципиально не может работать с уже запущенными на локальном Xserver приложениями.

Речь идет о чём-то типа такого:
запускаем сессию обычного Xserver'а на 0.0.0.0:6000 и выставляем DISPLAY=localhost:0.0 после чего всё что запускается на тачке работает через TCP. В произвольный момент смотрим с какого порта работает софтина и например пользуя iptables перекидываем её tcp соединение на другую тачку. Разумеется понадобится некая тулза которая откроет соединение с удалённым сервером, утащит текущую картинку соответствующую окнам софтины и всякие там атомы и пр с локального сервера, всё это пересоздаст на удалённом сервере и удалит окна и прочее барахло на локальном сервере. Ну и софтина как бы просто продолжит работать с удалённым сервером не подозревая о том, что сервак поменялся.

Чисто теоретически никаких проблем не видно, однако практической реализации нет и не предвидится, похоже.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Sahas

Надо, чтобы окно работающего приложения по какой-нибудь хитроумной команде перекинулось на удаленный дисплей?

Упрощённо - да, если у программы единственное окно (что встречается крайне редко). Но правильнее будет говорить о перекидывании соединения программы с одного сервера на другой с копированием состояния сервера для этого соединения.

Stanson ★★★★★
() автор топика

При отрисовке окна используются ресурсы Х-сервера.
Как синхронизировать эти выделенные ресурсы между двумя серверами?

Представь два веб-сервера никак не связанных друг с другом. Как пребросить клиента со всеми сессиями, состояниями и пр.? Никак или жуткими костылями. Вот и здесь так, можно, но сложно.

sdio ★★★★★
()

Кстати да. Тоже недавно нужно было, но так и не осилил. Хотя году эдак в 2006 ещё прокатывало.

ViTeX ★★★★
()
Ответ на: комментарий от sdio

Представь два веб-сервера никак не связанных друг с другом. Как пребросить клиента со всеми сессиями, состояниями и пр.? Никак или жуткими костылями. Вот и здесь так, можно, но сложно.

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

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

реализуй, раз все просто, зачем ныть?

sdio ★★★★★
()

Нельзя, сэр
Пробовал в 2008 еще - на ion3 с двумя мониторами сетап без ксинерамы
Оказалось, что уже тогда все костыли для этого протухли
Вот как-то так

takino ★★★★★
()
Ответ на: комментарий от takino

Если не ошибаюсь, именно тут мне (под анонимусом, правда, так что топик не найду) давали объяснение, что современные тулкиты на это никак не рассчитаны, и если и можно что-то так перебросить - то это приложение на xlib (даже не на xcb).

takino ★★★★★
()

То что ты хочешь, в Х11 в общем случае нереализуемо без сервера-прокси вроде xpra.

Представь что тебе нужно заставить программу без переоткрытия файла продолжить читать файл c другой машины так, чтобы неадаптированная под это программа этого не заметила. Протокол Х11 stateful.

PolarFox ★★★★★
()
Ответ на: комментарий от takino

Как раз тулкиты могли бы обеспечить наличие такой фичи, но сам протокол Х11 на такое не расчитан. Программа создаёт на сервере окна, пиксмапы и т.д., при перемещении окна на другой сервер от программы потребовалось бы пересоздание всех этих ресурсов.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

Представь что тебе нужно заставить программу без переоткрытия файла продолжить читать файл c другой машины так, чтобы неадаптированная под это программа этого не заметила. Протокол Х11 stateful.

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

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

И тут тоже аналогично… если залезть и в ядро (чтобы перепривязать сокет), и в иксы (чтобы получить ресурсы для отправки на другой сервер). И то не взлетит, если дескрипторы этих ресурсов не локальны для каждого соединения.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

Как раз тулкиты могли бы обеспечить наличие такой фичи,

Они делают всё, чтобы возможность такой фичи свести к 0.

но сам протокол Х11 на такое не расчитан.

Формально - да, но с костылём можно.

Программа создаёт на сервере окна, пиксмапы и т.д., при перемещении окна на другой сервер от программы потребовалось бы пересоздание всех этих ресурсов.

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

Сей костыль принципиально отличается от костыля типа xpra который просто создаёт псевдосервер а потом гонит картинку созданную прогой на этом псевдосервере на произвольно выбранную тачку.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

У хорошо продуманного тулкита есть описание окна и всех ресурсов в нём в декларативном виде, которое можно сериализовать и воссоздать на другом сервере.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

И то не взлетит, если дескрипторы этих ресурсов не локальны для каждого соединения.

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

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

Stanson ★★★★★
() автор топика
Ответ на: комментарий от PolarFox

У хорошо продуманного тулкита есть описание окна и всех ресурсов в нём в декларативном виде, которое можно сериализовать и воссоздать на другом сервере.

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

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

Ну как бы X является промышленным стандартом и есть коммитет который разрабатывает это стандарт. Сейчас используют X11, но через некоторое время наверно сделают X12, в котором обещали исправить многие недостатки X11. Подробнее в википедии.

rezedent12 ☆☆☆
()

совершенно долбанутые костыли типа xpra - никуда не годятся

Я пользовал - меня устраивало. Объясни чем не устраивает тебя - может у тебя задача другая? Потому что для описанного тобой ЕМНИП dmx+xpra - за глаза.

Pinkbyte ★★★★★
()
Ответ на: комментарий от Stanson

Если ВНЕЗАПНО, захочешь реализовать такое для современных Х серверов, то как мне кажется, стоит смотреть логику схем перемещения виртуальных машин без потерь соединения. Но там без прокси не обойтись никак.

leonidko ★★★★
()
Ответ на: комментарий от frame

Купи себе второй монитор

И наверно к нему сотни метров VGA кабеля?

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

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Pinkbyte

Объясни чем не устраивает тебя - может у тебя задача другая? Потому что для описанного тобой ЕМНИП dmx+xpra - за глаза.

xpra написан на питоне. Ну это полный пэ, примерно как написанный на питоне tar или там iptables.

Тормозище страшное. По сравнению с простой удалённой сессией X-ов раз в 10 наверно медленнее.

Ну и оно принципиально не может перетащить окно уже запущенного приложения из-за своего принципа работы.

A dmx уже 10 лет никто не трогал, оно как и xmove мёртвенькое...

Stanson ★★★★★
() автор топика
Ответ на: комментарий от leonidko

Если ВНЕЗАПНО, захочешь реализовать такое для современных Х серверов, то как мне кажется, стоит смотреть логику схем перемещения виртуальных машин без потерь соединения. Но там без прокси не обойтись никак.

Внезапно, я знаком с Xen и live migration в т.ч. Remus. Никакого прокси там нет. Просто копируется память и затем, если нужна постоянная синхронизация - далее копируются изменения в памяти.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

Тормозище страшное. По сравнению с простой удалённой сессией X-ов раз в 10 наверно медленнее.

[Источник?]

PolarFox ★★★★★
()
Ответ на: комментарий от Stanson

И наверно к нему сотни метров VGA кабеля?

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

/thread

frame ★★★
()
Ответ на: комментарий от Stanson

Потестил гткпёрфом… хпра на локалхосте — 4 с хреном секунды, напрямую — 9 секунд…

PolarFox ★★★★★
()
Ответ на: комментарий от frame

О, ещё корм пришёл :)

Ты правда дебил? Ну расскажи ещё про мышиный удлиннитель, клаву с полукилометровым проводом и прочий дурдом.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от PolarFox

Социальные сети, веб2.0

Понятно, УГ будут эти ваши облачные технологии =)

frame ★★★
()
Ответ на: комментарий от PolarFox

x11perf -complex100 например.

Удалённо - не хуже чем локально скорость.

50000 reps @ 0.0816 msec ( 12300.0/sec): Fill 100x100 equivalent complex polygons

и

60000 reps @ 0.0815 msec ( 12300.0/sec): Fill 100x100 equivalent complex polygons

Через xpra - ваще жопа.

60000 reps @ 0.2744 msec ( 3640.0/sec): Fill 100x100 equivalent complex polygons

при этом, самое важное - реальное изображение представляет собой слайдшоу. В общем-то понятно почему - x11perf измеряет скорость псевдосервера xpra, а не скорость передачи картинки на удалённую машину как в случае обычного удалённого запуска.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от frame

Какой вкусный корм! :)

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

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

Так иксы с современными тулкитами этого тоже не умеют, и не будут, ибо тот же dbus, к примеру, используемый для всплывающих окошек и много чего в той же бубунте (и не только) - ВНЕЗАПНО прибит гвоздями к локалхосту =)

frame ★★★
()
Ответ на: комментарий от Stanson

xpra написан на питоне.
Тормозище страшное.

Интересно, как я года 4 назад в нём KDE 3.5 запускал на Celeron D, удивительно прям. Может стоит для начала руки починить?

Ну и оно принципиально не может перетащить окно уже запущенного приложения из-за своего принципа работы.

Ну да, это больше как бы иксовый аналог screen.

A dmx уже 10 лет никто не трогал, оно как и xmove мёртвенькое...

Опять же, я в 2009 заводил. Возможно сейчас придётся чуть больше патчей наложить. Тебе надо - вот и займись. Судя по всему, остальным это надо чуть более чем никак.

Update: Хотя вот тут на тытрубе видео, датированное 2012 годом где Xdmx гоняют на убунте. Значит не такое оно уж дохлое как кажется.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

Да чего там хотеть-то.

socat TCP-LISTEN:6000 UNIX-CONNECT:/tmp/.X11-unix/X0
и вперёд. Дело нехитрое.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Pinkbyte

Интересно, как я года 4 назад в нём KDE 3.5 запускал на Celeron D, удивительно прям. Может стоит для начала руки починить?

С руками всё впорядке, проблема в том, как работает xpra. Картинки оно конечно гоняет не сильно хуже, а вот с примитивами и всякой прочей хренью - проблемы аццкие по вполне очевидным причинам.

Опять же, я в 2009 заводил. Возможно сейчас придётся чуть больше патчей наложить. Тебе надо - вот и займись.

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

Судя по всему, остальным это надо чуть более чем никак.

Судя по тому, что эта фича весьма внятно экранизирована в куче кинопродукции от аватаров всяких до самых захудалых сериалов, её обязательно запилят. Предложение рождает спрос и всё такое. Не удивлюсь, если её запилят в какой-нибудь «девяточке» быстрее чем в xorg, наковыряв костылей в RDP. Тем более что фича в общем-то небесполезна, в отличии от всяких прочих свистелок и перделок пришедших из синематографа на планшеты, смартфоны и десктопы.

Update: Хотя вот тут на тытрубе видео, датированное 2012 годом где Xdmx гоняют на убунте. Значит не такое оно уж дохлое как кажется.

Может и пилит кто-то. Или форкнули. Но это всё-же немного не то, что хотелось бы.

Stanson ★★★★★
() автор топика

Есть ли какие-либо реальные решения реализующие данную фичу без костылей?

Конечно. Зовется X11. Всё что надо сделать приложению - аттачнуться к новому X-серверу и отрисовать там себя. Приложение этого не умеет? Ну так это проблемы приложения.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Конечно. Зовется X11. Всё что надо сделать приложению - аттачнуться к новому X-серверу и отрисовать там себя. Приложение этого не умеет? Ну так это проблемы приложения.

Если с этой стороны подходить - то это проблемы не приложения а скорее тулкита, на котором написано приложение. Тулкит знает состояние всех виджетов, или умеет посылать приложению команду «отрисуй-ка заново вот этот GC»

Кстати, неплохой повод для раздумий, спасибо.

И, между прочим, оно даже офигенно работает по крайней мере с GTK приложениями. Вот типа солюшен http://demonastery.org/2011/04/change-gtk-display-on-the-fly/ нашёл.

И главное - работает без всяких ублюдочных костылей типа xpra или vnc

Stanson ★★★★★
() автор топика
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от frame

ибо тот же dbus, к примеру, используемый для всплывающих окошек и много чего в той же бубунте (и не только) - ВНЕЗАПНО прибит гвоздями к локалхосту =)

Внезапно, d-bus прибит к тому же хосту, на котором работает приложение, поэтому тут как раз ВНЕЗАПНО проблем нет. Если X-сервер отвалился, то отвалился X-клиент, который отображает переданное через d-bus сообщение (например, notification area или как там его). При этом, после того как будет запущен другой X-клиент, который подключится к dbus как отображалка сообщений, сообщения снова начнут показываться.

no-dashi ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.