[winswitch] Xpra GL and gtkglext woes

[Antoine Martin]

(..)
>>> So I then went ahead and installed gtkglext and the Python bindings,
>>> thinking it was somehow related to OpenGL.
>> What makes you think that?
>> What vfb are you using? Are you using Xdummy or Xvfb? Have you tried
>> switching to the other option? Does your vfb support opengl?
>> Is using VirtualGL an option?
>> (there's quite a bit on the wiki about all these options)
> It was just a hunch. Perhaps a poor one. I believe to be using Xdummy. I
> have the latest Xvfb as part of the xorg-server-1.19.6 tar ball. I placed
> the following line in my /home/tools/etc/xpra/xpra.conf
> 
> xvfb=Xorg -dpi 96 -noreset -nolisten tcp \
>                         +extension GLX +extension RANDR +extension RENDER \
>                         -logfile ${HOME}/.xpra/Xvfb-10.log -config
> /home/tools/etc/X11/xorg.conf
You should modify (...)/etc/xpra/conf.d/55_server_x11.conf instead.
To see which setting is being used, run "xpra showconfig | grep xvfb"
> I have built and installed the latest xf-video-dummy, am using the
> xorg.conf provided by Xpra. Is this sufficient to be using Xdummy?
Should be.

> I'll have to give VirtualGL a try. These servers at work are headless
> multi-Xeon CPU systems without much of a video card.
Then no, VirtualGL won't help you there.

> An lspci -v | grep VGA
> returns
> 
> 0a:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. G200eR2
> (rev 01) (prog-if 00 [VGA controller])
> 
> The are completely modern systems, so I find it odd that it would have a
> video card from the late 90s in it.
Those video cards are there to drive a console output and nothing else,
so a simple chipset can be seen as a positive thing.
(..)
> It's probably unrelated but I receive this error immediately when starting
> Xpra. This again is run as non-root. I have XDG_RUNTIME_DIR set to a path
> in my home directory. So I'm not sure why it's still attempting to access
> /run/xpra/system
> 
> 2018-03-05 21:16:04,755 get_enabled_encoders(['rencode', 'bencode',
> 'yaml']) enabled=['yaml', 'rencode', 'bencode']
> 2018-03-05 21:16:04,799 netifaces loaded sucessfully
> 2018-03-05 21:16:04,799 successfully loaded socket C library from libc.so.6
> 2018-03-05 21:16:04,804 failed to connect using <bound method
> _socketobject.connect of <socket._socketobject object at
> 0x2b9f9143e520>>/run/xpra/system
> Traceback (most recent call last):
>   File "/home/tools/lib/python/xpra/scripts/main.py", line 1910, in
> _socket_connect
>     sock.connect(endpoint)
>   File "/home/tools/lib/python2.7/socket.py", line 228, in meth
>     return getattr(self._sock,name)(*args)
> error: [Errno 2] No such file or directory
> Warning: cannot use the system proxy for 'start' subcommand,
>  failed to connect to '/run/xpra/system':
>  [Errno 2] No such file or directory
This directory is for shared sockets with group access.
Nothing to worry about, you can ignore the warning, create the directory
with group access and add your user to that group, or just remove the
directory from the list of "socket-dirs".

>> As for the gdkgl error, this is a build issue. I would just ignore it
>> and remove the package. Unless you also intend to use this same system
>> as an xpra client, in which case you do want accelerated rendering...
>>
> 
> I do not intend to use this system as a client. Thank you for your help!
Ah. In that case, you may prefer building trunk which supports a native
opengl backend that does not need pygtkgl.
Use it with: --opengl=native

Cheers
Antoine


> 
> 
>>
>> Cheers
>> Antoine
>>
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>