[winswitch] Xpra GL and gtkglext woes
antoine at nagafix.co.uk
Thu Aug 30 05:06:32 BST 2018
On 30/08/18 07:15, shifter-users-owner at lists.devloop.org.uk wrote:
> Now that I've established a connection again with Xpra server 2.3.3, I
> can try to address some of the issues I was/am experiencing. I haven't
> used it enough to encounter the first two issues, which were the most
> debilitating and largely made it unusable for me before (the stuck focus
> issue and the disappearing mouse cursor). Once I can re-create those
> I'll have more to offer.
> On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin <antoine at nagafix.co.uk
> <mailto:antoine at nagafix.co.uk>> wrote:
> On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote:
> > Hi. I'm including my previous correspondence below, as it will at
> > offer some history about my setup and prior issues.
> > I stopped using Xpra a few months ago due to numerous bugs that
> made it
> > unusable (this is using a Linux server and Windows client).
> > 1. windows get stuck with on-top focus
> Which windows from which applications?
> This was by far the most egregious bug. It seemed to happen at random
> and affected all applications. Considering I do a lot of work in a
> terminal, chances are it was a terminal such as xfce4-terminal. I will
> report back once this occurs again. My only solution was to minimize the
> window, rather than simply clicking on another window to give it focus.
This does ring a bell, but I don't think I ever saw it myself.
This could be a platform specific bug (ie: affecting mswindows clients)
in which case the newer Python3 GTK3 builds may fare better.
> > 2. disappearing mouse cursor when using X11-only no-toolkit apps
> that use
> > inverted black mouse pointer after clicking on something
> Do you have a specific application we can use to reproduce the problem?
> Unfortunately the application I encountered this issue with the most was
> Cadence's Simvision, a digital simulation waveform viewer that's part of
> their CAD/EDA software suite. The only observation I had was that it is
> an application which does not make use of a modern toolkit, such as GTK.
> Perhaps it's using Motif? When you click on a menu the mouse cursor
> inverts to a right-pointing black cursor, which is a cursor internal to
> the program and is not replaced by the client's cursor. That's when the
> menu items would disappear. I've attached a screenshot of it working,
> which required using an actual camera, as the inverted black cursor is
> not picked up by the Windows print screen function.
There were bugs in the cursor code on mswindows, including some fixed
quite recently, those could have caused the problems you describe - it
should now revert to the default cursor in case of failure.
> > 3. some windows don't show window bar until resized (e.g. gvim
> always gets
> > placed in upper-left without window bar)
> Some applications do weird things with their geometry sometimes, gvim is
> one of those. That said, I've just tried it and it worked fine and it
> does seem to request to be placed in the top left corner.
> Please provide more details so we can reproduce the window bar problem.
> (ie: server os and version, gvim version, etc..)
> This isn't a showstopper. I'm using gvim 8.0.586 with the latest Xpra
> 2.3.3 on Linux l-server-13 2.6.18-398.el5 #1 SMP Tue Sep 16 20:50:52 EDT
> 2014 x86_64 GNU/Linux. I've attached a screenshot showing this behavior.
> It corrects itself once I do any resizing of the window (which must
> initiate a redraw event). Perhaps Xpra could force a redraw event after
> opening the window?
I bet it's not a redraw event but a window "configure notification" that
gvim is waiting for. If I can reproduce this, it should be fixable. We
can synthesize an event if needed.
What's the server version? CentOS 7.5?
> > 4. dialog box black bars (appears to be trying to add scrollbars?).
> Can you provide example applications we can use to reproduce the
> I've never seen that anywhere except when X11 windows are smaller than
> the minimal window size on mswindows, then we have to pad it with
> Perhaps that's all it is.
Sadly, it's not. From the screenshot you attached, this looks like a
> Certainly not a big deal, and just a cosmetic
> annoyance. I've attached an example of this issue from a dialog box that
> pops up using diffuse. Perhaps this would be too much work, but a
> slightly more pleasing visual than black bars would be to sample the
> color of the edge pixels and use this color (or an average of samples)
> to extend the window to the minimum size.
Fixing the problem might be easier. (it looks similar to the gvim
problem - the application gets the window geometry wrong)
Do you have a sample application I can use to reproduce it?
> > 5. windows are all blank (white) when returning into work after
> > hours (requires restarting client)
> That's a known "feature" of some opengl drivers, they clear the video
> memory when the system goes into idle or suspended state.
> We try to detect that (slowing down the refresh rate) and then refresh
> the screen when the session resumes, but that doesn't always fix things.
> You should not need to restart the client: minimizing the windows and
> restoring them should be enough.
> Alternatively, turn off opengl in the client - the client performance
> will be much lower.
> OK, the next time this occurs I'll try to simply minimize the windows.
> > 6. flickering clipboard icon in systray
> That's a very obvious sign that something is not right and something is
> constantly requesting the clipboard contents. This will cause
> unnecessary traffic and instability. Try to figure out what is causing
> this and stop it. Usually, this is caused by clipboard managers or other
> clipboard synchronization tools (synergy, virtualbox, etc).
> Hmm. I don't have anything running like that. No VNC session,
> VirtualBox, etc. Microsoft's Remote Desktop is enabled, but certainly
> nothing is currently connected to it. It seems to flicker at a rate of
> once every 4 seconds or so.
OK, then it's not so bad that it will cause instability.
Some clipboard managers request the clipboard contents as soon as
they're available, swamping the system with clipboard events.
If you wish, you can confirm the rate of change by running the client
> It seems periodic, in the mathematical sense
> of the word. My PC at work is a standard issue Dell box. It has the
> typical Dell bloatware and some Symantec security software (not much
> control over this), but can't think of anything that could be
> potentially interfering with the clipboard. Any suggestions how to
> determine the cause?
Sorry, I don't know how. The API we use to interact with the clipboard
does not offer any information about the application which set or
queried the clipboard. Some third party tools may exist to monitor the
system at this level.
More information about the shifter-users