Setting GDM Resolution Without Knowing The Monitor Specs

Home » CentOS » Setting GDM Resolution Without Knowing The Monitor Specs
CentOS 11 Comments

We had a complaint recently from a customer that received a server we shipped out that their monitor just showed a black screen. It turns out that they’d hooked it up to an ancient POS with 800×600 as its best resolution, and gdm in CentOS 7 apparently assumes at least 1024×768. It was apparently a major hassle for them to hunt down a reasonable monitor for us.

Since we almost never use the GUI on these things, we thought we’d solve that problem going forward by shipping these boxes out to use a fixed 800×600, so they’ll work on any monitor the user plugs in.

The first problem you run into is that the Settings > Devices > Display GUI only affects the login you do it under. GDM doesn’t pay attention to this, not even to the configuration set as root!

Then you go web searching and find solutions involving xrandr and advice to just put it in /etc/gdm/Init/Default, but that doesn’t seem to work.

I then got soooo close when I found the advice to set the monitor configuration in the GUI, then copy ~/.config/monitors.xml to /var/lib/gdm/.config. That works…until you plug in a different monitor, because that file has a hard tie to the monitor brand, model and *serial number*!

The monitors.xml file looks like this:





0
0 yes

VGA-1
SAM SyncMaster H1AK500000


800
600
60




I have tried:

1. Removing the section entirely. gdm then gives me a black screen on “systemctl restart gdm” from a text console.

2. Filling out all fields except with values like “default”, “generic”, “any”, “*”, etc. GDM decides you couldn’t possibly mean for this configuration to apply to that monitor, since it differs, so it ignores you and does whatever it likes instead.

3. Lots and lots of web searching for documentation on the file format to see if I can find out if there is a different way of specifying “any monitor, I don’t care”.

I was about to go reading the source code, but I thought I’d ask here first.

Keep in mind that we ship these systems out without knowing what monitor they’ll plug in, and once the systems are out in the field, it’s often difficult to get remote access to them. That means we can’t just log in with SSH, probe it with xrandr, and fix it remotely; we’re probably having the customer log in via the GUI to fix the problem that prevents us from SSHing in in the first place!

It’s fine in our case to pin the configuration to “VGA-1”, because we know what connectors are on the server itself. We just don’t know what the customer will plug into it.

I assume there’s a minimum screen resolution for CentOS 7, probably 1024×768, but we’re installing these systems with a reasonable screen. We only need this low resolution post-install, and then only so the customer can pull up a terminal and maybe run the Network settings tool. For that, 800×600 is fine. You do have to drag the Settings app around a bit to see everything, but it works.

Our current fallback is Ctrl-Alt-F2 and nano, which is tolerable for some things — “Okay, type ‘ifconfig’…now find the line that has ‘inet’ in it, and read that back to me…’ — but remotely talking someone through changing ifcfg-noisenoise via nano is a minor nightmare, especially now that Confusing Network Device Naming is the default.

11 thoughts on - Setting GDM Resolution Without Knowing The Monitor Specs

  • Hi, I would try the old days way at a lower level..

    Create a file 00-monitor.conf under /etc/x11/xorg.conf.d

    Something like this below, using conservative range values for horiz and vert syncs

    [root@desktop xorg.conf.d]# cat 00-monitor.conf Section “Device”
    Identifier “Default Video Device”
    EndSection

    Section “Monitor”
    Identifier “Default Monitor”
    HorizSync 30.0-62.0
    VertRefresh 50.0-70.0
    EndSection

    Section “Screen”
    Identifier “Default Screen”
    Monitor “Default Monitor”
    Device “Default Video Device”
    DefaultDepth 24
    SubSection “Display”
    Depth 24
    Modes “800×600”
    EndSubSection EndSection
    [root@desktop xorg.conf.d]#

    This way it should be forced to use 800×600 resolution, also because of conservative values the vesa settings for higher resolutions should be out of range. I tried with a CentOS 7 VM in oVirt where by default it gets 1024×768 and after these settings and reboot, both gdm and graphical sessions got 800×600

    In Xorg.0.log I get

    [ 15.554] (==) Using config directory: “/etc/X11/xorg.conf.d”
    [ 15.554] (==) Using system config directory “/usr/share/X11/xorg.conf.d”
    [ 15.558] (==) No Layout section. Using the first Screen section.
    [ 15.558] (**) |–>Screen “Default Screen” (0)
    [ 15.558] (**) | |–>Monitor “Default Monitor”
    [ 15.559] (**) | |–>Device “Default Video Device”
    [ 15.559] (==) Automatically adding devices
    [ 15.559] (==) Automatically enabling devices
    [ 15.559] (==) Automatically adding GPU devices
    . . .
    [ 15.659] (II) qxl(0): Not using mode “1920×1200” (hsync out of range)
    [ 15.659] (II) qxl(0): Not using mode “1920×1080” (hsync out of range)
    [ 15.659] (II) qxl(0): Not using mode “1600×1200” (hsync out of range)
    [ 15.659] (II) qxl(0): Not using mode “1680×1050” (hsync out of range)
    [ 15.659] (II) qxl(0): Not using mode “1400×1050” (hsync out of range)
    [ 15.659] (II) qxl(0): Not using mode “1280×1024” (hsync out of range)
    [ 15.659] (II) qxl(0): Not using mode “640×480” (hsync out of range)
    [ 15.659] (II) qxl(0): Printing probed modes for output Virtual-0
    [ 15.659] (II) qxl(0): Modeline “800×600″x59.9 38.25 800 832 912
    1024 600 603 607 624 -hsync +vsync (37.4 kHz UP)
    [ 15.659] (II) qxl(0): Modeline “1024×768″x59.9 63.50 1024 1072 1176
    1328 768 771 775 798 -hsync +vsync (47.8 kHz P)
    . . .
    [ 15.659] (–) Depth 24 pixmap format is 32 bpp
    [ 15.662] (II) UXA(0): Driver registered support for the following operations:
    [ 15.662] (II) solid
    [ 15.662] (II) copy
    [ 15.662] (II) composite (RENDER acceleration)
    [ 15.662] (II) put_image
    [ 15.663] (II) qxl(0): RandR 1.2 enabled, ignore the following RandR
    disabled message.
    [ 15.664] resizing primary to 1024×768

    HIH, Gianluca

  • Why not just ship it with text mode login and get rid of all the video problems? With a 800×600 resolution I doubt they can do a lot with the GUI
    anyway.

    Regards, Simon

  • Because I can talk a Windows admin through an IP change over the phone easier via Settings > Network than with nano in /etc/sysconfig/network-scripts. I’ve tried it both ways several times, and it’s not even a close thing.

    Once I’ve got remote access, the screen gets turned back off, never to turn back on for perhaps years at a time.

  • A relevant war story might help here.

    We were upgrading an old CentOS 5 box in the field. They refused to ship it back to us, and they refused to buy a whole new box, but they had to have the newest software.

    This being CentOS, “yum upgrade” wasn’t going to get us to CentOS 7. What to do?

    So, I logged into it remotely, poked around a bit, and got it to divulge the motherboard, CPU, etc. that we’d used on it, and I found that we had a nearly-identical box sitting around powered off locally, it having given us many years of useful service and then been retired. Same motherboard, same CPU, same RAM, probably even bought within the same year.

    So, I dropped a fresh system drive into that box, loaded CentOS 7 and all of our stuff onto it, configured the network and everything else under /etc the same as the box in the field, and shipped the drive out to the customer.

    They put the drive in, booted it up, and it didn’t reappear on their network. No remote access, no presence on the LAN. It wouldn’t even ping.

    After a ridiculous amount of remote troubleshooting, it turned out that these two motherboards — despite having the same model number and EFI firmware version — had a sliiiight difference: the first NIC appeared as enp2s0 and the second as enp3s0 on one motherboard, but as enp3s0 and enp4s0 on the other! So, one network config wasn’t being applied, and the second was being applied to the wrong NIC.

    And here I thought the point of [CNDN][1] was to make such replacements more reliable than the plug-and-pray logic behind ethN.

    This is the sort of reason why I need non-Linux sysadmin types to be able to change IPs in the field.

    [1]: https://en.wikipedia.org/wiki/Consistent_Network_Device_Naming

  • One of the reasons why I hate the new naming scheme. It was also easy in the past to always monitor eth0, eth1 on a server, now you always have to first find out how the devices are named. I don’t see progress here, I see a step back only. Maybe that’s only me :-)

    Regards, Simon

  • I’d like to add here that the reason for not having /dev files for network devices was a historical “accident” in Unix development. Would be nice to have them to make Linux more consistent and then it could be handled similar to disk devices by udev or other means. I’m just dreaming…

    Regards, Simon

  • Warren Young wrote:

    Oh, yeah, right, and those “consistant names” mean *ANYTHING* to an ordinary sysadmin, dealing with systems from different vendors of varying age, who’s not an EE. I *loathe* them. Give me eth0 or em1, not some random string. It was fine when Sun used it… but that was on *their*
    hardware, not hardware from three or four different vendors.

    mark

  • This works fine here on our test monitors, with the exception that the first ‘x’ needs to be capitalized.

    Thanks again!

  • Il Ven 1 Mar 2019, 17:28 Warren Young ha scritto:

    Great!
    Yes it was a typo. Well done, Gianluca