Chapter 32. Offloading Graphics Display with RandR 1.4
Version 1.4 of the X Resize, Rotate, and Reflect Extension (RandR 1.4 for short) adds a way for drivers to work together so that one graphics device can display images rendered by another. This can be used on Optimus-based laptops to display a desktop rendered by an NVIDIA GPU on a screen connected to another graphics device, such as an Intel integrated graphics device or a USB-to-VGA adapter.
System Requirements
X.Org X server version 1.13 or higher.
A Linux kernel, version 3.13 or higher, with CONFIG_DRM enabled.
Version 1.4.0 of the xrandr command-line utility.Using the NVIDIA Driver as a RandR 1.4 Output Source Provider
To use the NVIDIA driver as an RandR 1.4 output source provider, the X server needs to be configured to use the NVIDIA driver for its primary screen and to use the “modesetting” driver for the other graphics device. This can be achieved by placing the following in /etc/X11/xorg.conf:
Section "ServerLayout"
Identifier "layout"
Screen 0 "nvidia"
Inactive "intel"
EndSection
Section "Device"
Identifier "nvidia"
Driver "nvidia"
BusID "
EndSection
Section "Screen"
Identifier "nvidia"
Device "nvidia"
Option "AllowEmptyInitialConfiguration"
EndSection
Section "Device"
Identifier "intel"
Driver "modesetting"
EndSection
Section "Screen"
Identifier "intel"
Device "intel"
EndSection
See “What is the format of a PCI Bus ID?” for information on determining the appropriate BusID string for your graphics card.
The X server does not automatically enable displays attached to the non-NVIDIA graphics device in this configuration. To do that, use the xrandr command line tool:
$ xrandr --setprovideroutputsource modesetting NVIDIA-0
$ xrandr --auto
This pair of commands can be added to your X session startup scripts, for example by putting them in $HOME/.xinitrc before running startx.
Use the
$ xrandr --listproviders
command to query the capabilities of the graphics devices. If the system requirements are met and the X server is configured correctly, there should be a provider named NVIDIA-0 with the Source Output capability and one named modesetting with the Sink Output capability. If either provider is missing or doesn't have the expected capability, check your system configuration.
Synchronized RandR 1.4 Outputs
When running against X.Org X server with video driver ABI 23 or higher, synchronization is supported with compatible drivers. At the time of writing, synchronization is compatible with the “modesetting” driver with Intel devices on Linux version 4.5 or newer. If all requirements are met, synchronization will be used automatically.
X.Org X server version 1.19 or newer is required to support synchronization. Without synchronization, displays are prone to “tearing”. See Caveats for details.
If synchronization is being used but is not desired, it can be disabled with:
$ xrandr --output
and re-enabled with:
$ xrandr --output
See Vblank syncing for information on how OpenGL applications can synchronize with sink-provided outputs.
===
What is the format of a PCI Bus ID?
Different tools have different formats for the PCI Bus ID of a PCI device.
The X server's "BusID" X configuration file option interprets the BusID string in the format "bus@domain:device:function" (the "@domain" portion is only needed if the PCI domain is non-zero), in decimal. More specifically,
"%d@%d:%d:%d", bus, domain, device, function
in printf(3) syntax. NVIDIA X driver logging, nvidia-xconfig, and nvidia-settings match the X configuration file BusID convention.
The lspci(8) utility, in contrast, reports the PCI BusID of a PCI device in the format "domain:bus:device.function", printing the values in hexadecimal. More specifically,
"%04x:%02x:%02x.%x", domain, bus, device, function
in printf(3) syntax. The "Bus Location" reported in the information file matches the lspci format. Also, the name of per-GPU directory in /proc/driver/nvidia/gpus is the same as the corresponding GPU's PCI BusID in lspci format.
On systems where both an integrated GPU and a PCI slot are present, setting the "BusID" option to "AXI" selects the integrated GPU. By default, not specifying this option or setting it to an empty string selects a discrete GPU if available, the integrated GPU otherwise.
un cheat-sheet rappel pour tmux et screen ;)
cool ! et bien utile !
Hier, j'ai voulu modifier un peu le programme écrit en c "reboot-rtorrent" et je me suis heurté à quelque chose d'étrange.
Il n'est pas possible de se rattacher à une session screen si auparavant on s'est connecté via ssh et su à notre utilisateur.
Par exemple, je me connecte avec l'utilisateur alexandre via ssh, et j'ai envie de voir une session screen de l'utilisateur pierre.
Pour cela je fais : (ex : je veux regarder le rtorrent de pierre)
alexandre@machine-de-guerre:~$ su pierre
pierre@machine-de-guerre:~$ screen -ls
There are screens on:
9732.test (19/03/2015 23:13:19)(Detached)
9025.pierre-rtorrent (03/09/2081 32:11:18)(Detached)
2 Sockets in /var/run/screen/S-pierre.
pierre@machine-de-guerre:~$ screen -r pierre-rtorrent
Cannot open your terminal '/dev/pts/0' - please check.
Là, impossible de rattacher la session screen.
La petite astuce est d'exécuter la commande ci-dessous avant de vouloir rattacher une session screen
script /dev/null
Et le miracle opère.
alexandre@machine-de-guerre:~$ su pierre
pierre@machine-de-guerre:~$ script /dev/null
pierre@machine-de-guerre:~$ screen -r pierre-rtorrent
pierre@machine-de-guerre:~$ magic !
note : Pour quitter une session screen sans la tuer vous faîtes [Ctrl + a] + [d]
Pour tuer une session screen... il faut aller lire la doc big_smile
Voilà, c'est fini.
tmux est plus sympa que screen oui, mais si on n'a pas besoin de récupérer la main sur la commande (genre un tar, ou un find ou etc...) je rappelle qu'un simple nohup suivi d'un & à la fin de la commande ne demande aucune installation suplémentaire.
donc:
nohup "la commande qui va bien" 2>fichier_erreur.log 1>fichier_sortie.log &
nohup, va ignorer la mort du shell et donc rattacher le processus au père:
https://en.wikipedia.org/wiki/Nohup
le canal 2 est le canal d'erreur.
le cana 1 est le canal de sortie standard
& permet de rentre la main au shell en créant un fork.
Voila.
Sinon pour tmux:
via http://macahute.net/shaarli/?URV-MQ
As screen is not maintained anymore you should look for modern alternatives like tmux.
tmux is superior for many reasons, here are just some examples:
Windows can be moved between session and even linked to multiple sessions
Windows can be split horizontally and vertically into panes
Support for UTF-8 and 256 colour terminals
Sessions can be controlled from the shell without the need to enter a sessionBasic Functionality
To get the same functionality as explained in the post with the most votes you would need to do the following:
ssh into the remote machine
start tmux by typing tmux into the shell
start the process you want inside the started tmux session
leave/detach the tmux session by typing Ctrl+B and then DYou can now safely logoff from the remote machine, your process will keep running inside tmux. When you come back again and want to check the status of your process you can use tmux attach to attach to your tmux session.
If you want to have multiple session running side-by-side you should name each session using Ctrl-B and $. You can get a list of the currently running sessions using tmux list-sessions.
tmux can do much more advanced things then handle a single window in a single session. For more information have a look in man tmux or http://tmux.sourceforge.net/. A FAQ about the main differences between screen and tmux is available here: http://tmux.git.sourceforge.net/git/gitweb.cgi?p=tmux/tmux;a=blob;f=FAQ