NVFBC with Xinerama (driver 430.50)

When enabling xinerama on a 2 monitors config, the call to nvFBCGetStatus() gives a struct of type NVFBC_GET_STATUS_PARAMS with members dwOutputNum = 0
My later call to nvFBCCreateCaptureSession() will fail.

Is it possible to use NVFBC while Xinerama is enabled?

In looking for an alternative to Xinerama, I’ve found that XRandR would be an option, but here: https://wiki.archlinux.org/index.php/Multihead#Xinerama
I’ve read that

Since randr version 1.5, it has been possible to combine monitors into one virtual display. This is an updated version of what was possible with Xinerama and works with open source drivers and does not require an Xorg restart.

For an image processing reason, I’ll need CUDA (version > 6.5) to be available.

I’ve also read that TwinView would make it for 2 monitors. But in a short future I would have 4 monitors instead of 2, which makes TwinView not usable.


The page you linked to seems a little bit outdated. Our drivers have been supporting RANDR 1.5 for quite a while and combining screens into a virtual display is supported. I just tested it locally to double check.

In this mode, you will want to use the NVFBC_TRACKING_SCREEN tracking mode with NvFBC to capture the entire X framebuffer.

At this point, there is no difference between RANDR and TwinView, and note that you won’t be limited to 2 monitors. I do not recommend using Xinerama for this setup.


Hi Damien,

Thanks for your prompt reply.

I’ll try out the NVFBC_TRACKING_SCREEN tracking mode with NvFBC, in case we use RandR.
I set up the XRandR with such command, right?

xrandr --setmonitor myDualMonitor auto DP-4, DP-6

Because when I do that, applications in full screen mode doesn’t fill the entire X screen (2 monitors for ex.)
Your xrandr command to set it up would be welcome.

Other point. You wrote “I do not recommend using Xinerama for this setup.”
Can you please be more explicit :

  • is Xinerama supported but not recommanded ?
  • or Xinerama not supported ?

Supporting xinerama is important for us because se would have clients who don’t want to change existing working setups with Xinerama.


I might have been mistaken about xrandr --setmonitor. I would have to spend some time digging into the code to figure that out. I tested it on a bare X server and glxgears -fullscreen properly spanned through the monitors, but in fact it can do that without unifying the displays through RANDR.

But even without --setmonitor, applications ought to expand on all monitors. I know the SDL can do that and apps like glxgears too.

Regarding Xinerama, it is the old way of doing multi monitor and some of our more recent features aren’t supported. That is the case of Vulkan applications and NvFBC, for example.



For your information, using NVFBC_TRACKING_SCREEN tracking mode with NvFBC is well capturing the entire framebuffer, when Xienrama is enabled.
It’s a good news!
Thanks for your support.

Now I’ll have to write a cuda kernel to split the entire framebuffer into smaller screen.

I’ll also inform our customer that Xinerama is the old way of doing mulit-monitor, and that he may want to use XRandR later. But that’s assuming that it’s unifying the displays. Do you have any update on that please?