On Thu, Jun 23, 2011 at 11:31:29AM -0700, Mark Knecht wrote: > On Thu, Jun 23, 2011 at 10:39 AM, YoYo Siska <y...@gl.ksp.sk> wrote: > > On Thu, Jun 23, 2011 at 05:21:07PM +0100, Neil Bothwick wrote: > >> On Thu, 23 Jun 2011 08:54:01 -0700, Mark Knecht wrote: > >> > >> > My question is about running nvidia-settings. I'm finding that if I > >> > shell into his machine using > >> > > >> > ssh -X -Y -C IP-address > >> > > >> > and run nvidia-settings I get it displayed here, as it should be. The > >> > problem is it is seeing my GTX 465 and not his 8400GS. > >> > >> Looking at the man page, it appears you need to use the -ctrl-display > >> parameter or the $DISPLAY env var. The man page mentions that > >> nvidia-settings queries the X server, which is running locally. It looks > >> like this setting may force it to use another. > > > > > > as neil wrote, it is > > nvidia-settings -c :0 > > > > nvidia-settings connects to the remote xserver to communicate > > with the graphics card (through a special nvidia xtenstion to the x > > protocol), so you need to be able to access the remote xserver, if you > > are logged in as the user running the xserver, you should be ok > > > > yoy > > Yeah, I've been tripping over doing this right since Neil pointed me > toward the -c command. I think the problem is that I don't have the > permissions set correctly to allow this to work right. The owner of > the remote machine is logged in and possibly using X. I'm not sure > about that but I'm not 'running the X server' in any meaningful way. > I'm just remotely trying to access his GPU with nvidia-settings but > display the GUI here. The problem seems to be getting the right number > of his server or else permissions. > > This page is one of the better ones I've found about running > nvidia-settings remotely, specifically section 6 which gives this > example: > http://www.makelinux.com/man/1/A/alt-nvidia-173-settings > > (issued from bartok.nvidia.com) > xhost +stravinsky.nvidia.com > > (issued from schoenberg.nvidia.com) > xhost +stravinsky.nvidia.com > > nvidia-settings --display=bartok.nvidia.com:0 > --ctrl-display=schoenberg.nvidia.com:0 > > which "allows all X clients run on stravinsky.nvidia.com to connect > and display on bartok.nvidia.com's X server and configure > schoenberg.nvidia.com's X server."
this seems pretty old... defaults on most distros these days are that X server does not listen on tcp/ip (ip-address:0) only on a local unix sockets (:0), see below for more > > It seems this program allows you to run it from machine1, display it > on machine2 which controlling machine3? > > So, locally I ran > > mark@c2stable ~ $ xhost > access control enabled, only authorized clients can connect > mark@c2stable ~ $ xhost +DWP-Linux > DWP-Linux being added to access control list > mark@c2stable ~ $ xhost > access control enabled, only authorized clients can connect > INET:DWP-Linux > mark@c2stable ~ $ > > which I think allows the remote machine access here in my server. I > then log in which creates the .Xauthority file: > > mark@c2stable ~ $ ssh -XYC DWP-Linux > Password: > Last login: Thu Jun 23 14:11:33 EDT 2011 from > c-67-161-57-1.hsd1.ca.comcast.net on pts/3 > /usr/bin/xauth: file /home/mark/.Xauthority does not exist > mark@DWP-Linux ~ $ ls -al .Xauthority > -rw------- 1 mark mark 55 Jun 23 14:21 .Xauthority > mark@DWP-Linux ~ $ cat .Xauthority > DWP-Linux11MIT-MAGIC-COOKIE-1��:��T'6�@R��mark@DWP-Linux ~ $ > mark@DWP-Linux ~ $ > > On that machine I see this $DISPLAY: > > mark@DWP-Linux ~ $ echo $DISPLAY > localhost:11.0 > mark@DWP-Linux ~ $ > > so I run > > mark@DWP-Linux ~ $ nvidia-settings -c :11 > > which sees my GPU, not his, presumably because I said to control my > system with -c :11. However if I try something like > > mark@DWP-Linux ~ $ nvidia-settings -c :0 > > I get a bunch of stuff ending with > > > ERROR: Unable to assign attribute XVideoSyncToDisplay specified on > line 62 of configuration file > '/home/mark/.nvidia-settings-rc' (no Display connection). > > No protocol specified > > ERROR: Cannot open display ':0'. > > mark@DWP-Linux ~ $ > > I'm a bit lost at this point. (OBVIOUSLY!) :-) To connect to an Xserver, you need to know its "address", which is something like machine_or_ip:NUMNER for tcp/ip connection or just :NUMBER for (local) unix socket connection. When you do a ssh -X , ssh creates a tunnel from the remote computer to your local Xserver (:0 at your side), and creates a new "address", usually localhost:10 (or 11, 12, which on is free) if i'm behing a laptop named 'tabletka' and there is also a desktop named 'yoyo' (its the same as my username... on both), you could do: yoyo@tabletka ~ $ DISPLAY=:0 xterm which runs xterm here (tabletka), displays it here yoyo@tabletka ~ $ DISPLAY=yoyo:0 xterm runs xterm here, displays it on yoyo however as i said, most distributions don't allow Xservers to listen on tcp/ip and only allow it to listen on local sockets... you can however use ssh to tunnel X traffic, so you could do: yoyo@tabletka ~ $ echo $DISPLAY :0.0 yoyo@tabletka ~ $ ssh -X yoyo yoyo@yoyo:~$ echo $DISPLAY localhost:10.0 now if you run an X application, it would connect to localhost:10.0 which would be transfere by ssh to your local :0.0 (on tabletka) but you could also do (still in the ssh session) yoyo@yoyo:~$ DISPLAY=:0.0 xterm which would run xterm on the xserver on that remote desktop computer... (note that apps use the DISPLAY variable, but usually also have a command line option to specify the Xserver on which they should display things, that is the --display option from nvidia-settings) however the example above most probably won't work, because the Xserver uses authentication to only allow authorized clients/applications to display things on it... the xhost commands in the example you found basically allow access to all applications from a certain ip, but this only works for the tcp/ip connections, which are not used... Xserver uses xauth "cookies" to authenticate a user... so if you can get a hold a "cookie" for that remote Xserver, you can connect to it / control it. If a user is logged on the remote Xserver, he most probably has a ~/.Xauthority file in his home (or a file pointed to by $XAUTHORITY variable), which contains the cookie, so if you can read his files (it is of course only readable by him, but if have root on that machine...) you can run xauth merge /home/LOGGED_USER/.Xauthority of course, if you log in as that user, it is not needed... if there is no-one logged in, it is a bit more problematic, because the login manager takes care of the auth cookies, but for KDM the cookies are in /var/run/xauth/ (readable only by root), so you could either do xauth merge /var/run/xauth/* or set XAUTHORITY to the path of the file corresponding to :0 (kdm names them A:0-somethingrandom, so it si /var/run/xauth/A:0* ), but that might override any XAUTHORITY file ssh might have set up for the -X tunnel to your local Xserver ;) the kdm xauth cookie should work even if a user is logged in, of course... note that if you do a ssh -X othermachine, and then su in that ssh session, the DISPLAY and XAUTHORITY vars might get reset... so in short, if there is kdm on the remote machine: ssh -X othermachine (now $DISPLAY should be something like localhost:10) sudo chmod 644 /var/run/xauth/A:0* xauth merge /var/run/xauth/A:0* (now your xauthority file should have cookies fot both yor tunneled local xserver (if ssh created it) and also for the :0 xserver on the remote machine) nvidia-settings -c :0 (nvidia-settings uses $DISPLAY to select where to display it's ui -> i.e. your ssh tunel to your local display, and "controls" the graphics card on the :0 display) yoyo
