[winswitch] Xpra GL and gtkglext woes

[Ben Sferrazza]

On Mon, Mar 5, 2018 at 8:07 PM, Antoine Martin via shifter-users <
shifter-users at lists.devloop.org.uk> wrote:

> (..)
> >>> 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"
>

OK. I see. I deleted that line from the default xpra.conf file, and it
starts up using the 55_server_x11.conf settings instead. So that looks good
now. That of course uses the (...)/etc/xpra/xorg.conf file too, so no need
to worry if I'm using the latest. Problem is, I'm not seeing anything
happen after it says xpra is ready in the log file. Even when I attempt to
connect with the client. Not connection detected. Time to turn my attention
to the client logs like you said.


> > 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".
>

Well, sadly I don't have root access. If I can just ignore it, I will.


>
> >> 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
>

OK great. I'll give that a try sometime in the next couple of days and
report back.


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