CentOS 7 current, TDE current. Nvidia Quadro M2000 (4 x DP out), 2 x Dell P2416D displays.
Applied patches last week and one of them (that seemed to be related to the Nvidia proprietary drivers) blew up the system. Eventually ended up re-installing in an ultimately-failed bid to get productive again (this is my work system).
Decided to forgo the Nvidia drivers and use the open source stuff. Xrandr is a nightmare though, so I thought "well, just use the TDE built-in screen controls".
Problem is that System Settings -> Monitor & Display can only see one of the displays. How do I get it to see the 2nd display?
Yes, it's plugged in. Yes, I've checked "Enable global display control". Yes, I've clicked "Rescan Displays" (many times). "Test Settings" gets me "xrandr: Failed to get size of gamma for output default".
Not sure the system is seeing the first display correctly even though it's working (I am typing this message on it) because while is sees 2560 x 1440 pixel, it thinks the refresh rate is 0 Hz (though, again, its working).
Do I have to create and edit an Xorg.conf? Because I tried that and it didn't go well not to mention defeating the purpose of a "settings" GUI ...
-- Peter Laws, BS, MRCP / N5UWY National Weather Center / Network Operations Center University of Oklahoma Information Technology plaws@ou.edu
said Peter Laws: | CentOS 7 current, TDE current. Nvidia Quadro M2000 (4 x DP out), 2 x | Dell P2416D displays. | | Applied patches last week and one of them (that seemed to be related | to the Nvidia proprietary drivers) blew up the system. Eventually | ended up re-installing in an ultimately-failed bid to get productive | again (this is my work system). | | Decided to forgo the Nvidia drivers and use the open source stuff. | Xrandr is a nightmare though, so I thought "well, just use the TDE | built-in screen controls". | | Problem is that System Settings -> Monitor & Display can only see one | of the displays. How do I get it to see the 2nd display? | | Yes, it's plugged in. Yes, I've checked "Enable global display | control". Yes, I've clicked "Rescan Displays" (many times). "Test | Settings" gets me "xrandr: Failed to get size of gamma for output | default". | | Not sure the system is seeing the first display correctly even though | it's working (I am typing this message on it) because while is sees | 2560 x 1440 pixel, it thinks the refresh rate is 0 Hz (though, again, | its working). | | Do I have to create and edit an Xorg.conf? Because I tried that and | it didn't go well not to mention defeating the purpose of a "settings" | GUI ...
I encountered much the same thing, also with a Nvidia vid card, just recently. Like you, I got no satisfaction with the Monitor & Display setting in KControl, which also failed to see one of my two monitors.
I ended up installing, again, the current Nvidia driver for my card, and the Nvidia control application. Then I went in the Nvidia app to "X Server Display configuration" where both monitors were seen. I was able to configure them as to their relative position and so on.
That having been said, there *is* a little voodoo to it, but it gives you something that if fiddled with will ultimately work.
On Mon, Aug 14, 2017 at 12:20 PM, dep dep@drippingwithirony.com wrote:
I encountered much the same thing, also with a Nvidia vid card, just recently. Like you, I got no satisfaction with the Monitor & Display setting in KControl, which also failed to see one of my two monitors.
Yeah ... but while my own *video* experience with the proprietary drivers was problem free, the patch issue which appeared related to those drivers is enough to want to make me want to stay far, far away from them.
If I can't find a way to make the open source stuff function, I'll go back to Nvidia's drivers, but I'll make certain that they never get patched again. I lost most of Friday to this nonsense. Even today, I've only got half my desktop.
Going back to Ubuntu is another option, but since all the servers I run are Centos (a few still RHEL) it makes sense for me to have CentOS in front of me all day. Thank goodness none of the servers have displays! :-D
Peter
Peter Laws composed on 2017-08-14 11:41 (UTC-0500): ... 1-arandr should configure specific to each individual user running TDE
2-xrandr in a startup script can configure either to one user or globally
3-xorg.conf* can do the same as xrandr in a startup script
4-screen configuration in TDE Control Center has been reported to be functional in recent weeks here.
What does xrandr in a terminal report?
Is there a firmware package for NVidia hardware that needs to be installed?
Do either 'dmesg | grep fail' or 'systemctl | grep fail' provide clues?
The nouveau Xorg driver is a separate package. The modesetting driver is integrated in 1.17.x+ servers. Fedora and Debian not terribly long ago changed the default for NVidia hardware to using the modesetting driver. In any event, Xorg should be using the modesetting automatically if neither NVidia nor Nouveau drivers are installed, if the NVidia hardware is not too new to be supported.
According to Wikipedia, the M2000 was released 2016-04-08. CentOS 7 provides server 1.17.2, which is older, and kernel 3.10, which is much older. The OP reports your system had been working with proprietary NVidia drivers. Could it be that that was because required M2000 support in FOSS hadn't been backported to CentOS7?
GMail no longer supports Quote Selected Text, so replies have become laborious - bear with me.
On Mon, Aug 14, 2017 at 1:47 PM, Felix Miata mrmazda@earthlink.net wrote:
What does xrandr in a terminal report?
xrandr: Failed to get size of gamma for output default Screen 0: minimum 640 x 480, current 2560 x 1440, maximum 2560 x 1440 default connected primary 2560x1440+0+0 0mm x 0mm 2560x1440 0.00* 1600x1200 0.00 1280x1024 0.00 1280x800 0.00 1024x768 0.00 800x600 0.00 640x480 0.00
Is there a firmware package for NVidia hardware that needs to be installed?
No idea. Maybe, since the CentOS installed only works in "basic graphics mode" (cleverly hidden under the troubleshooting menu in the GRUB menu). One would think that the OS installer would take care of that or at least warn the user to go and get them if installing them would otherwise violate someone's conscience. You would be wrong, but one would think.
grepping the RPMs installed, I see xorg-x11-drv-nouveau-1.0.11-4.el7.x86_64 (in addition to many other xorg packages including xorg-x11-server-Xorg-1.17.2-22.el7.x86_64 )
Do either 'dmesg | grep fail' or 'systemctl | grep fail' provide clues?
Yes, both fail to provide clues.
According to Wikipedia, the M2000 was released 2016-04-08. CentOS 7 provides server 1.17.2, which is older, and kernel 3.10, which is much older. The OP reports your system had been working with proprietary NVidia drivers. Could it be that that was because required M2000 support in FOSS hadn't been backported to CentOS7?
You got me.
Searching through the repos I have enabled (one of which must include the NVidia proprietary drivers because ...) I see kmod-nvidia. It's that patch that dorked my machine late last Thursday. I'm reluctant to put those back on. They *work* fine, but if patches are going to break things (which appears to be the case but I can't be certain).
I appreciate your reply!!
Peter
said Peter Laws:
| Maybe, since the CentOS installed only works in "basic | graphics mode" (cleverly hidden under the troubleshooting menu in the | GRUB menu). One would think that the OS installer would take care of | that or at least warn the user to go and get them if installing them | would otherwise violate someone's conscience. You would be wrong, but | one would think.
So you're running with some kind of framebuffer support, nothing specific to the card. That's typically the fallback.
I've killed the splash screen at bootup and, weirdly, the boot drops into fb about halfway through. But it *seems* to then recover and go to the Nvidia driver. Which may or may not have anything at all to do with what you're experiencing. If memory serves, a good way to check this us to determine whether your Mesa support is software-only or hardware. If the former, you may not be using the Nvidia driver at all. Open a terminal and enter "glxinfo" and then scroll back to the top and see if it sheds any light. It should begin something like this:
name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4
I do not believe that a framebuffer device supports direct rendering.
On Mon, Aug 14, 2017 at 3:12 PM, dep dep@drippingwithirony.com wrote:
said Peter Laws:
former, you may not be using the Nvidia driver at all. Open a terminal and enter "glxinfo" and then scroll back to the top and see if it sheds any light. It should begin something like this:
name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4
I do not believe that a framebuffer device supports direct rendering.
Well, here's my problem - it's not a Dell, it's an Indy! (or an Onyx or an ... gah, can't remember what the other SGIs were called).
name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4
WTH?
Not sure I follow this thread..but here goes.
1. I don't understand the op's first post comment re: applied patches & resulting failure? I do not use Red Hat so don't know the reference.
2. The vendor NVIDIA drivers have been the canonical driver and setup for my quadro cards...by far.
3. glx -SGI is the library, I think Mesa with origins from SGI, /usr/lib/xxx;
libglx.so is my Nvidia library../usr/lib/nvidia/libglx.so
hth
Greg M On 08/14/2017 12:23 PM, Peter Laws wrote:
On Mon, Aug 14, 2017 at 3:12 PM, dep dep@drippingwithirony.com wrote:
said Peter Laws:
former, you may not be using the Nvidia driver at all. Open a terminal and enter "glxinfo" and then scroll back to the top and see if it sheds any light. It should begin something like this:
name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4
I do not believe that a framebuffer device supports direct rendering.
Well, here's my problem - it's not a Dell, it's an Indy! (or an Onyx or an ... gah, can't remember what the other SGIs were called).
name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4
WTH?
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Peter Laws composed on 2017-08-14 14:51 (UTC-0500):
GMail no longer supports Quote Selected Text, so replies have become laborious - bear with me.
I almost never think about quoting selected. It's too simple just to intersperse the new and delete the unneeded at any point in a traditional email client. How the Gmail editor could foul that ability up I can't fathom.
Felix Miata wrote:
...
xrandr: Failed to get size of gamma for output default Screen 0: minimum 640 x 480, current 2560 x 1440, maximum 2560 x 1440 default connected primary 2560x1440+0+0 0mm x 0mm 2560x1440 0.00* 1600x1200 0.00
...
Is there a firmware package for NVidia hardware that needs to be installed?
No idea. Maybe, since the CentOS installed only works in "basic graphics mode" (cleverly hidden under the troubleshooting menu in the GRUB menu).
Grub's non-default selections usually limit Xorg's ability to function. What's on the cmdline in yours' default?
...
grepping the RPMs installed, I see xorg-x11-drv-nouveau-1.0.11-4.el7.x86_64 (in addition to many other xorg packages including xorg-x11-server-Xorg-1.17.2-22.el7.x86_64 )
The modesetting driver is integrated in the server. Is the failure the same after removing the nouveau driver package to enable the integrated driver and restarting?
Note that Debian and Fedora 6 months ago or longer made the integrated modesetting driver the default for most non-antique gfxchips. Other distros have at least acknowledged that FOSS driver development has been heavily focused on minimizing the need for gfxchip-specific drivers.
Do either 'dmesg | grep fail' or 'systemctl | grep fail' provide clues?
Yes, both fail to provide clues.
Might be one that one of us could spot if we could see Xorg.0.log.
According to Wikipedia, the M2000 was released 2016-04-08. CentOS 7 provides server 1.17.2, which is older, and kernel 3.10, which is much older. The OP reports your system had been working with proprietary NVidia drivers. Could it be that that was because required M2000 support in FOSS hadn't been backported to CentOS7?
You got me.
Your is unlikely a problem specific to TDE. TDE cannot use a screen that xrandr cannot find. Thus, querying a forum with more CentOS and/or recent video hardware users is more likely to get needed results.
Something else to think about: boot a live disk of something recent enough that it surely should support M2000 out of the box. https://wiki.trinitydesktop.org/LiveCDs
Peter Laws wrote:
Do I have to create and edit an Xorg.conf? Because I tried that and it didn't go well not to mention defeating the purpose of a "settings" GUI ...
Hi there, I use debian and no NVid, so I can't tell much regarding to this, except that I recall a similar nightmare experience couple of years ago, just had to learn how this opengl thing relates to all of that.
On the debian (mostly dell notebooks with intel card) I had to create my own xorg.conf to initialize the displays. After this, I can handle it via xrandr or the controls.
If using the proprietary NVid driver, you may need to look into the specific settings, but hey, once it works it works forever (or until you break it).
regards
-
deloptes -
dep -
Felix Miata -
Greg Madden -
Peter Laws