Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Provide an NV-CONTROL "bridge" #404

Open
amonakov opened this Issue Apr 30, 2013 · 7 comments

Comments

Projects
None yet
5 participants
Contributor

amonakov commented Apr 30, 2013

Let's make this a "canonical" bug for issues arising due to NV-CONTROL not working under Bumblebee (it's an X extension, so the applications send requests to :0, but the nVidia driver able to answer those requests is at :8).

Previous discussion here: amonakov/primus#55, Bumblebee-Project/Bumblebee#391

@ArchangeGabriel ArchangeGabriel modified the milestone: Bumblebee Future Jan 2, 2015

Sorry to intrude, but after stumbling upon this and noticing no feedback on this for some time i was wondering if the users affected by this somehow had found a solution and no one bothered to update.

Owner

ArchangeGabriel commented Mar 18, 2015

No one worked on it, so this is still to be done.

This is not as trivial an issue as it sounds, and I've looked into it several times in the context of VirtualGL. The problem is that most applications that use NV-CONTROL statically link with libXNVCtrl instead of dynamically linking with it, so there is no straightforward way to intercept the application's calls to libXNVCtrl and redirect them to a 3D-accelerated display. One would have to basically interpose _XReply(), dissect the opaque X display structure pointed to by the dpy pointer, attempt to figure out whether the request stored in the display structure is meant to apply to the NV-CONTROL extension, lock the 3D X server, attempt to send the X request to said X server, receive the reply, unlock the 3D X server, blah blah blah. It also would require interposing on some of the Xext calls that XNVCtrl makes in order to detect the presence of the NV-CONTROL extension. Interposing on _XReply() is potentially a can of worms, which is why we haven't attempted this in VirtualGL. Every single X call touches that function, so if we get something wrong, a lot of stuff could break. I think the better long-term solution is for the XNVCtrl library to be provided as a dynamic library and for applications to start using it in that form instead of linking with it statically.

Contributor

amonakov commented May 8, 2015

When I considered this, I arrived to an idea of providing an nv-control shim module in the X server instead of trying to redirect it from within the client.

That's a reasonable idea, since my primary goal would be to get this to work in TurboVNC-- so I control the X server. But is there open source code for the NV-CONTROL extension? I was under the impression that the server side of that was proprietary. Obviously you could get away with some things in a Bumblebee context, since you're using a "real" X server, that we couldn't necessarily get away with in a VirtualGL + X proxy context.

@dcommander the NV-CONTROL extension is opensource, reference implementation in the NV control panel, and source code for the extension here:
https://github.com/TTimo/doom3.gpl/tree/master/neo/sys/linux/libXNVCtrl

The license and copyright snippet follows

NV-CONTROL X Extension

neo/sys/linux/libXNVCtrl/*
Copyright NVIDIA Corporation

ExtUtil.h

neo/sys/linux/extutil.h
/*

  • $Xorg: extutil.h,v 1.4 2001/02/09 02:03:24 xorgcvs Exp $
    *
    Copyright 1989, 1998 The Open Group

Permission to use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided that
the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation.

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the name of The Open Group shall not be
used in advertising or otherwise to promote the sale, use or other dealings
in this Software without prior written authorization from The Open Group.
*

  • Author: Jim Fulton, MIT The Open Group
  •                 Xlib Extension-Writing Utilities
    
  • This package contains utilities for writing the client API for various
  • protocol extensions. THESE INTERFACES ARE NOT PART OF THE X STANDARD AND
  • ARE SUBJECT TO CHANGE!
    */

https://github.com/TTimo/doom3.gpl

That's the source for the client library. I'm looking for source for the server portion of the extension. I don't think that part is open source.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment