NVidia and XRandR 1.2

[Beamerboy]

Do we have any information on whether the driver team are working to make the NVidia Linux driver fully compatible with the new XRandR 1.2 spec? I just installed the new Beta Nvidia driver today with the hopes that it might have added support for the new spec, but when I try and use XRandR to setup Xinerama it crashes my entire system and is unrecoverable, requiring a hard reboot.

A little background on my setup and what I did to cause the crash:

Ubuntu Gutsy running xserver-xorg 7.2-0ubuntu12 (xserver-xorg-core 1.3.0.0.dfsg-4ubuntu2).

2x NVidia 6600GT 128MB SLI (currently not running in SLI mode)
2x 19" LCD monitors (1 attached to each card)

NVIDIA-Linux-x86-100.14.06-pkg1 Driver

I installed displayconfig-gtk which is a gnome frontend to XRandR 1.2 and then went to the Dual Display tab where it already had the second monitor set to RightOf the first. I clicked on Test to try it and I got dumped to a naked Xsession (big black X for cursor and a black/white mesh effect background) one of the monitors display was corrupted by a thick black band about 30% across from the left edge. Attempting to Alt+Ctrl+Backspace results in the display becoming very heavily artifacted before display eventually shuts off with a No Signal error. Attempting to switch to another VT to manually shut down Xorg has the same effect, no VT switch happens, the screen just becomes heavily artifacted and then displays shuts off with a No Signal error. Hard reboot required.

I wouldn't recommend anyone actually tries to reproduce the error as the fact the monitors shutdown is a little concerning.

So, are there plans to support XRandR 1.2 anytime soon please?

Thanks

Paladine

[AaronP]

The NVIDIA X driver does not yet support RandR 1.2. Support is planned for a future release, but no schedule has been set yet for when it will be finished. On xorg-server-1.3.0 and higher, current NVIDIA drivers should support everything provided by RandR 1.1.

As for the crash you're seeing, please see http://nvnews.net/vbulletin/showthread.php?t=58498

[Edit: Hit the post button too soon]

[Beamerboy]

Originally Posted by AaronP

The NVIDIA X driver does not yet support RandR 1.2. Support is planned for a future release, but no schedule has been set yet for when it will be finished. On xorg-server-1.3.0 and higher, current NVIDIA drivers should support everything provided by RandR 1.1.

As for the crash you're seeing, please see http://nvnews.net/vbulletin/showthread.php?t=58498

[Edit: Hit the post button too soon]

Yeah I am aware of this as a result of my testing today but thanks for the heads up all the same. And you are of course right, the current and beta drivers do function to XRandR 1.1 specification, but this still makes it impossible for Xinerama setups to use a composite window manager such as Compiz or Beryl since Xinerama disables the XRandR extension which is required to use a composite window manager.

I appreciate that XRandR 1.2 is a new spec and that it takes time to make changes and my post wasn't a gripe about that, I just wanted to outline my tests today and find out if there was a schedule for including 1.2 support.

Even when you guys do release a driver with this support, there are still issues in compiz/beryl with regards to desktops being larger than 2048x2048 which still leaves a problem for Xinerama if your resolution per monitor is >1024x768. So there is still a ways to go, but there is light at the end of the tunnel.

Thanks for confirming that NVidia are working towards XRandR 1.2 compliance, I will look forward to the new driver.

Sincerely

Paladine

[EDIT] In response to the link, I am using MMCONFIG but I am reasonably confident that the crashes I experienced today were a direct result of trying to use XRandR 1.2's new built in Xinerama as I have had zero stability issues whilst using the Xinerama "option" in xorg.conf instead of trying to let XRandR do it for me. Again thanks for the heads up.

[AaronP]

There may be some confusion here. RandR 1.2 and the Xinerama extension (the real one that glues together multiple X screens) aren't compatible with each other. The RandR 1.2 code has its own implementation of the Xinerama extension (which some people refer to as, "Fakerama"), which it uses to report the position of the CRTCs to clients. This is similar to the X driver's TwinViewXineramaInfo option.

[Beamerboy]

Originally Posted by AaronP

There may be some confusion here. RandR 1.2 and the Xinerama extension (the real one that glues together multiple X screens) aren't compatible with each other. The RandR 1.2 code has its own implementation of the Xinerama extension (which some people refer to as, "Fakerama"), which it uses to report the position of the CRTCs to clients. This is similar to the X driver's TwinViewXineramaInfo option.

Nope no confusion, I am fully aware of that. My test today was specifically to test if the new XRandR 1.2's internal "fakerama" worked with the NVidia drivers. I disabled `Option "Xinerama"` in my "Server_Layout" section in xorg.conf before doing the tests. The point is that because the traditional Xinerama option in xorg.conf disables XRandR you can't use a composite window manager, with the new 1.2 specification handling Xinerama internally, there will be no need to use the `Option "Xinerama"` setting in xorg.conf and therefore XRandR won't be disabled and the user will be able to run a composite window manager and still be able to use a Xinerama type setup by allowing XRandR 1.2 to handle it for them.

Paladine

[Beamerboy]

Aaron,

Do we have any updates regarding this situation yet?

Thanks

Beamerboy

[AaronP]

Nope

[Beamerboy]

This situation is becoming a real pain in the proverbial. In the last week I have encountered multiple segfaults in multiple applications as a result of Xinerama disabling XRandR.

So far I have discovered problems with the following:

Composite Window Managers - Totally Unusable on Xinerama Setups
MythTV - Segfaults unless ./configure --disable-xrandr is passed during the build
Torcs - Segfaults due to XRandR dependency.

These are just 3 problems I have discovered, I suspect the issue is far more widespread. Because of this it would make sense to add XRandR 1.2 support to the NVidia drivers as a priority so users can allow XRandR 1.2 to handle xinerama setups as opposed to enabling Xinerama in xorg.conf.

I request NVidia to take this matter seriously and provide support for the new XRandR 1.2 specification as a matter of urgency.

Beamerboy

[AaronP]

RandR 1.2 currently only works on a single X screen (a real one, not a Xinerama screen). You can get exactly the same "fakerama" behavior with the nvidia driver today with TwinView. To span multiple GPUs, you still need the real Xinerama extension, which still disables RandR. See hw/xfree86/modes/xf86RandR12.c in the xserver tree:

Bool
xf86RandR12Init (ScreenPtr pScreen)
{
    rrScrPrivPtr        rp;
    XF86RandRInfoPtr    randrp;

#ifdef PANORAMIX
    /* XXX disable RandR when using Xinerama */
    if (!noPanoramiXExtension)
        return TRUE;
#endif
...

(PanoramiX is the old historical name for Xinerama).

RandR 1.2 support in the nvidia driver is in the works, but don't expect it to magically make RandR + real Xinerama work.

[Beamerboy]

Originally Posted by AaronP

RandR 1.2 currently only works on a single X screen (a real one, not a Xinerama screen). You can get exactly the same "fakerama" behavior with the nvidia driver today with TwinView. To span multiple GPUs, you still need the real Xinerama extension, which still disables RandR. See hw/xfree86/modes/xf86RandR12.c in the xserver tree:

Bool
xf86RandR12Init (ScreenPtr pScreen)
{
    rrScrPrivPtr        rp;
    XF86RandRInfoPtr    randrp;

#ifdef PANORAMIX
    /* XXX disable RandR when using Xinerama */
    if (!noPanoramiXExtension)
        return TRUE;
#endif
...

(PanoramiX is the old historical name for Xinerama).

RandR 1.2 support in the nvidia driver is in the works, but don't expect it to magically make RandR + real Xinerama work.

I won't pretend to be a C programmer but what you just said is contrary to what the developer of XRandR has stated on his blog. It states that XRandR supports Xinerama internally, it says nothing about it only working with a single GPU, furthermore, in my own tests I managed to get output to both monitors (on 2 GPUs) using XRandR 1.2 with Xinerama disabled in xorg.conf, granted they were two seperate desktops but from what I have read (and I have read a lot on this issue for obvious reasons) XRandR's version of xinerama in the new spec gives no indication that this is limited to single GPUs. Without a pair of Intel Graphics Cards I can't confirm either way as to my knowledge only the Intel drivers currently support the new XRandR 1.2 specification (since the person who wrote XRandR 1.2 works for Intel from what I have been able to ascertain). It would be incredibly short sighted to limit this new feature of XRandR to a single GPU and would pretty much make the feature redundant as it would do nothing to solve the problem at hand.

In the modern age more and more people are using multiple GPUs, both with your own SLI system and your competitor's equivalents and this trend is likely to increase as equipment such as displays become less expensive. It would make no sense to start restricting software to single GPU systems in an age where more and people are doing the opposite.

I will send an email to the developer of XRandR 1.2 personally to try and get confirmation on the multiple GPU situation with the new spec. If indeed this is the case, then what would you suggest for those of us who do use multiple GPUs? Are we not permitted to play games or use a PVR or enjoy modern features such as composite window managers? Are we supposed to be excluded and penalised for purchasing additional hardware? By purchasing multiple video cards we are in essence increasing your (and other manufacturer's) revenue multiple times yet our usability and experience is significantly decreased as a result? It seems a little backwards to me.

If this is the case then obviously the situation needs to be addressed and a solution found, as it is in no way conducive of an innovative and evolving industry.

I will get back to you once I have a reply from the XRandR 1.2 developer, but I would request that yourself and your colleagues join the community in trying to find a suitable solution to this situation, not only because it is the logical and sensible thing to do, but because in doing so you will be protecting your own revenue streams instead of limiting them.

I appreciate your input in this thread so far and hope I have not said anything you may find insulting, as that is certainly not my intention, I am merely trying to find a solution to what I and others see as a serious problem with the current implementation of multiple GPUs.

Thanks again for the prompt reply.

Beamerboy

[AaronP]

Beamerboy,
You're preaching to the choir, here. I discussed this with Keith at the last X Developer's Conference, and we agreed that a solution for multiple GPUs is necessary, but the work hasn't been planned by anybody yet. In the meantime, you could try to encourage application developers to fix applications that crash when RandR is not available.

[Beamerboy]

Originally Posted by AaronP

Beamerboy,
You're preaching to the choir, here. I discussed this with Keith at the last X Developer's Conference, and we agreed that a solution for multiple GPUs is necessary, but the work hasn't been planned by anybody yet. In the meantime, you could try to encourage application developers to fix applications that crash when RandR is not available.

Oh don't worry, I am already doing that. Raised several bugs on my distro's bug tracker already based around the XRandR issue as well as solving one or two bugs raised by pointing out it is an XRandR/Xinerama issue. I am not having a go at anyone, I think you do a great job providing support for linux, thats why I only buy NVidia cards and it is also why I encourage all my friends to do the same.

However, the latest bug I raised re Torcs has been classified as wish list as the devs don't think it would be practical to disable XRandR dependency on all the effected software (which would be a lot by the looks of it) only to re-enable it at some point in the future when the issue is resolved.

In reality, it would be much more viable and much more efficient to fix the problem at the source (xorg and drivers) rather than provide temporary fixes to a boat load of apps as a workaround.

It is however very encouraging to know that NVidia are actively engaging in dialog with the relevant open source projects, so I applaud your efforts there. I just hope we can come up with a solution sooner rather than later.

It is also nice to be able to have a discussion of this nature (this thread) with an employee of such a large company, without the usual fob offs we deal with every single day in the consumer market. I have every confidence that the issue will be resolved, its just a question of when.

Hopefully threads like this will emphasize that there is a need to deal with these issues rather than have them brushed under the rug as a minor bug, I see this as a very progressive and positive discussion.