Как заставить Эволюцию работать в VNC на Debian/Wheezy (или позже)?

После немного большего количества исследования все дороги, кажется, приводят к VirtualGL (документы), хотя я должен все же попробовать его (инструкции по установке являются несколько... пугающими). Документация указывает на некоторый .debs, и существует открыть ITP for Debian.

Как альтернатива, кажется, что может быть возможно создать tightvncserver с поддержкой GLX через Мезаструктуру (например, упоминание здесь). Это не был бы GPU, ускоренный, конечно (но в каком количестве графической лошадиной силы электронная почта может быть нужной???); из большего беспокойства то, что (по крайней мере, в прошлый раз я попробовал), Debian не позволит, Вы иметь больше чем один набор OpenGL освобождаете установленный на машине за один раз, и я не хотел бы бросать ускорение HW для локального использования.

Я обновлю здесь, если я буду иметь успех так или иначе; я, конечно, все еще интересуюсь любыми другими (возможными) решениями/указателями.

Прогресс: Установка VirtualGL через соответствующий .deb и следование инструкциям (не настолько плохо, как они сначала смотрят; покрытие множества платформ увеличивает объем их несколько), получает меня (ускоренный HW!) GLX поддерживают в tightvncserver. Это - первый раз, когда я видел это!

/opt/VirtualGL/bin/vglrun glxgears

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

Однако существуют некоторые значительные проблемы с этим методом. Это только работает, когда кто-то зарегистрирован к хост-машине (и не, когда gdm3 "зазывала" отображается, в этом случае vglrun получает, "не мог открыть display:0" ошибка), и любой вид перехода дисплея (например, кто-то ctrl-alt-Fn-ing к виртуальной консоли) уничтожит vglrun приложение с, "Не мог Считать Пиксели" ошибка). Блокировка экрана кажется OK все же. В моих целях я могу жить с этим (существует кто-то еще, кто основной пользователь машины, в которую я являюсь VNCing, и они всегда зарегистрированы и вряд ли сделать что-либо столь же техническое как ctrl-alt-Fn далеко от рабочего стола), но это не может быть идеально для других.

Обновление: на самом деле существует фиксация, разрешающая использование VNC+GLX, в то время как gdm3 "зазывала" показывает. Просто отбрасывание a xhost +LOCAL: строка около запуска /etc/gdm3/Init/Default. vglserver_config сценарий действительно на самом деле пытается сделать это (для небезопасных установок), но он ничего не знает о конфигурационных файлах gdm3 (он действительно проверяет на gdm и xdm хотя). Хотя примечание, которое, что было бы лучше (и что сценарий конфигурации пытается сделать, предполагая, что Вы пошли для большего количества безопасных опций во время установки с vglusers группой) должно иметь a vglgenkey там вместо этого, но это, кажется, ничего не делает (не создает a /etc/opt/VirtualGL/vgl_xauth_key как его воображаемое к).

Обновление: На самом деле, создание a /etc/opt/VirtualGL/vgl_xauth_key поскольку gdm3 может быть включен путем добавления пользователя Debian-gdm к vglusers группе. Но это просто перемещает проблему в другое место с vglrun, теперь жалуясь на неспособность заблокировать что-то в/var/run/gdm3/(который имеет полномочия root:Debian-gdm). Я вне своей глубины в этой точке и несомненно ужасно небезопасен xhost +LOCAL: строка должна будет сделать.

Обновление: Просто найденный время обновление этой неработоспособной старой машины Debian от Хрипящего до Jessie, и обновленный к virtualgl 2.5 debs из SourceForge. vglrun evolution работая отлично, после того как сервер настроен с vglrun_config.

Обновление: От Debian9 ("Фрагмент") я переключился на использование tigervncserver (новый в Debian, стабильном в этом выпуске, я думаю; через пакет tigervnc-автономного-сервера) вместо virtualgl. См. другой ответ.

Я сражался в той же проблеме, пытаясь получить QtCreator, работая над VNC и в конечном итоге выяснил, почему он не работает, а как его исправить;

http://minkiri.apana.org.au/wiki / Devjournal

Вам не нужен VirtualGL, и это может быть даже хуже, чем альтернативы. Главное, вы можете сделать его работать, просто используя стандартные пакеты Debian.

VirtualGL предназначен для ускорения аппаратного ускорения на стороне сервера App-Server. Glx предназначен для аппаратного оборудования X-Server. При использовании VNC обычно App-Server и X-Server находятся на одном компьютере вместе с вашим VNC-сервером, поэтому существует не так много различий между VirtualGl и GLX.

Проблема - это два наиболее распространенных VNC-серверов TightVServer и VNC4Server являются как серверами X-Proxy с их собственным внутренним X-сервером, который не поддерживает GLX. Вы все еще можете сделать с ними работы 3D-приложения, но вам нужно использовать рендеринг программного обеспечения для программ App-Server App-Server, что означает, что вам нужен Libgl1-Mesa-SWX11, установленный на вашем сервере App-Server, и это конфликты с нормально установленным аппаратным рендерингом. Версия libgl1-mesa-glx.

В качестве альтернативы вы можете установить обычный X-Server с помощью аппаратного рендеринга GLX поддержки и использовать X11VNC, который является VNCServer, который ScreenS-царапирует реальный X-сервер.

Было бы здорово, если кто-то написал новый X-Proxy VNC-сервер с надлежащей поддержкой GLX с использованием libvncserver (используется X11VNC). И ittlevncerver и VNC4Server получают немного хрустящую.