Re: Problem with Cygwin/X from remote Linux

[Jon TURNEY <jon.turney@dronecode.org.uk>]

On 03/10/2014 05:19, Chris Carlson wrote:
>>> I discovered there are no visuals available to remote X connections that
>>> support OpenGL double buffering.  There used to be, but no longer.
[...]
> I thought the two logs that you requested were a bit large for this
> e-mail, so I put them on my web site.  You can access them as:

Thanks.

So, this is the set visuals that the X server supports.

> GL_VERSION:     3.1.0 - Build 8.15.10.2455
> GL_VENDOR:      Intel
> GL_RENDERER:    Intel(R) HD Graphics Family
[...]
> pxf vis  fb                      render         Ste                     aux    accum        MS    drawable             Group/
> idx  ID  ID VisualType Depth Lvl RGB CI DB Swap reo  R  G  B  A   Z  S  buf AR AG AB AA  bufs num  W P Pb  Float Trans Caveat
> -----------------------------------------------------------------------------------------------------------------------------
>   1  51  42 TrueColor    32   0   y   .  .       .   8  8  8  8   0  0   0   0  0  0  0    0    0  y . y     .     .     2
>   2  52  43 TrueColor    32   0   y   .  y xchg  .   8  8  8  8   0  0   0  16 16 16 16    0    0  y . y     .     .     2
>   3  53  44 TrueColor    32   0   y   .  .       .   8  8  8  8  24  8   0   0  0  0  0    0    0  y . y     .     .     2
>   4  21  45 TrueColor    32   0   y   .  y xchg  .   8  8  8  8  24  8   0  16 16 16 16    0    0  y . y     .     .     2
>   5  54  46 TrueColor    32   0   y   .  .       .   8  8  8  8  16  0   0   0  0  0  0    0    0  y . y     .     .     2
>   6  55  47 TrueColor    32   0   y   .  y xchg  .   8  8  8  8  16  0   0  16 16 16 16    0    0  y . y     .     .     2
>   7  56  48 TrueColor    32   0   y   .  y copy  .   8  8  8  8   0  0   0  16 16 16 16    0    0  y . y     .     .     2
>   8  57  49 TrueColor    32   0   y   .  y copy  .   8  8  8  8  16  0   0  16 16 16 16    0    0  y . y     .     .     2
>   9  41  4a TrueColor    32   0   y   .  y copy  .   8  8  8  8  24  8   0  16 16 16 16    0    0  y . y     .     .     2
>  10  58  4b TrueColor    32   0   y   .  .       .   8  8  8  8   0  0   0   0  0  0  0    1    4  y . y     .     .     2
>  11  59  4c TrueColor    32   0   y   .  y xchg  .   8  8  8  8   0  0   0  16 16 16 16    1    4  y . y     .     .     2
>  12  5a  4d TrueColor    32   0   y   .  .       .   8  8  8  8  16  0   0   0  0  0  0    1    4  y . y     .     .     2
>  13  5b  4e TrueColor    32   0   y   .  y xchg  .   8  8  8  8  16  0   0  16 16 16 16    1    4  y . y     .     .     2
>  14  5c  4f TrueColor    32   0   y   .  .       .   8  8  8  8  24  8   0   0  0  0  0    1    4  y . y     .     .     2
>  15  5d  50 TrueColor    32   0   y   .  y xchg  .   8  8  8  8  24  8   0  16 16 16 16    1    4  y . y     .     .     2

The mesa software renderer on the remote host constructs the set of 
visuals the client gets offered by picking the visuals from the server's 
set of visuals which match one of it's visuals

> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x300)
> OpenGL version string: 2.1 Mesa 8.0.4
[...]
>     visual  x   bf lv rg d st  colorbuffer  sr ax dp st accumbuffer  ms  cav
>   id dep cl sp  sz l  ci b ro  r  g  b  a F gb bf th cl  r  g  b  a ns b eat
> ----------------------------------------------------------------------------
> 0x051 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
> 0x053 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None

Unfortunately this set is small, and indeed doesn't contain any 
double-buffered visuals.

Workarounds are to use either start Cygwin X server with -nowgl (so it 
too uses the software renderer and will offer a set of visual which is 
probably exactly the same), or to run the client with the 
LIBGL_ALWAYS_INDIRECT env var set (so that indirect rendering is used 
and the remote client has access to the actual set of visuals the server 
supports)

I think the real fix to this is to fix the remote libGL, either so it 
matches visuals less precisely, or so it offers more visuals which can 
match, but this is not simple.

> Believe it or not, I just so happen to have an XWin.0.log from my old,
> old, old version of Cygwin.  It was:
>
> Package: version 1.15.1-2 built 2014-05-06

Now I can reproduce this, it seems that this can be an unfortunate 
side-effect of the "Improve visual matching with a remote libGL by not 
reporting pbuffer size limits" change in 1.15.1-3 [1], which was 
intended to have the opposite effect, if previously no visuals at all 
were matching, so the software renderer was disabled, and we were 
falling back to indirect rendering.

[1] https://cygwin.com/ml/cygwin-xfree-announce/2014-06/msg00002.html

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/