From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29198 invoked by alias); 3 Oct 2014 16:52:18 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Received: (qmail 29185 invoked by uid 89); 3 Oct 2014 16:52:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: out1-smtp.messagingengine.com Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 03 Oct 2014 16:52:15 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by gateway2.nyi.internal (Postfix) with ESMTP id 84A81208B4 for ; Fri, 3 Oct 2014 12:52:12 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 03 Oct 2014 12:52:12 -0400 Received: from [192.168.1.93] (unknown [86.139.181.83]) by mail.messagingengine.com (Postfix) with ESMTPA id EDD11C00006; Fri, 3 Oct 2014 12:52:11 -0400 (EDT) Message-ID: <542ED43B.80905@dronecode.org.uk> Date: Fri, 03 Oct 2014 16:52:00 -0000 From: Jon TURNEY User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com, cygwin-xfree@cygwin.com CC: cwcarlsonc@cox.net Subject: Re: Problem with Cygwin/X from remote Linux References: <542CCC31.5090303@cox.net> <542E23EF.80508@cox.net> In-Reply-To: <542E23EF.80508@cox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00006.txt.bz2 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/