How to solve Graphic card configuration problems on Trisquel GNU/Linux

Recently, when on one of my systems I replaced my Ubuntu installation with Trisquel, I believed, I might have discovered a very promising, and fully FSF compliant, migration path from Ubuntu based environments, to pure, completely proprietary software free GNU/Linux solution. However, my enthusiasm was short lived. Namely, the first "red flag" that signaled something may be wrong was the fact Trisquel unlike my Ubuntu previously would not be able to wakeup my display-monitor when it woke up from suspension.

Due to my similar past experiences with Ubuntu OS updates, I immediately suspected graphic board / display configuration, which now is usually not managed via xorg.conf file, I believed that falling back to xorg.conf might be a solution. Which brings me to the second red flag that went up, signaling my optimism was premature, when I engaged in conversations on the most popular and reputable technical public forums on the Internet, where you can ask for help about this kind of problems. As it turns out, the usual Internet help today is not what it used to be anymore. In particular these public help Internet forums are inundated with quick fix, short question, experts that rarely can operate beyond the prevailing 280 characters tweeter mentality. And they have a scoring system that supports their superiority over anyone with significantly larger experience than is their own. So if you have a multi-layered and more complex problem you need to first brake through the ego ceiling, enforced by countless Internet credentials and reputation-marks, each of these would be experts are adorned and venerated with, before you can even ask your question properly, or ask the question at all, risking parts of it being edited or deleted, perhaps even completely. The likelihood of getting an answer there before the problem is outdated (usually in years) are slim on these broadly public forums.

It is really not in the interest of those who know the answers to give those answers to the public. This cuts into their business model and indeed into their revenue. DIY is not a desirable effect for their activity on public knowledge base forums for knowledgeable experts.

The solution, at least for the FSF communities, seem to be these communities' focus groups that operate IRC channels, which are officially stated and published in the pertinent FSF project documentation on and their web pages.

But even there, when it comes to proprietary systems, that we are trying to replace with free-software systems a third red flag may pop up, as it seems, is the case with my "Xorg/suspend/hibernate" problem. Namely, when you join in the Xorg documentation published support #xorg channel on Freenode, you are faced with a message about "Open" and about "Close" Graphic-card driver variants that makes you wander Which is which, and is my project in trouble?

Despite the fact, I do not know exactly how to start addressing my "Xorg/suspend problem", or even where and what can I ask, let's move on to how this "Xorg/suspend problem" manifests itself on my newly installed Trisquel system.

1. How does my "Xorg/suspend" problem on Trisquel manifests itself?

1.1

I changed the line GRUB_CMDLINE_LINUX="" in grub

        $> sudo vi /etc/default/grub
        #> sudo uodate-grub

 GRUB_CMDLINE_LINUX="" ---> GRUB_CMDLINE_LINUX="nouveau.modest=0"

Ran sudo uodate-grub and tested if waking up the computer from suspend also wakes up the display monitor.

It does not!

Changing this line to

      GRUB_CMDLINE_LINUX="" ---> GRUB_CMDLINE_LINUX="amdgpu.modest=0

Also does not have any effect!

1.2

Next, I checked xrandr output which consistently, always, displayed the same output. In particular I could never really got rid of the following xrandr: Failed to get size of gamma for output default message:

    $> xrandr
    xrandr: Failed to get size of gamma for output default
    Screen 0: minimum 1600 x 1200, current 1600 x 1200,     \\s\
        maximum 1600 x 1200
    default connected primary 1600x1200+0+0 0mm x 0mm
       1600x1200     77.00* 
    uID@cKt:~/wk/wX
    $> 

1.3

Changing --gamma value to 1.0 seems to fail with the resulting gamma value 0, as shown here:

        $> xrandr --output default --gamma 1.0:1.0:1.0
        xrandr: Gamma size is 0.

1.4

I could never get System -> Preferences -> Hardware -> Display to reflect any changes I make by running xrandr's --newmode, --addmode, though a subsequent query by running xrandr without any arguments (see 1.4.4) does show the new added mode:

1.4.1

        $> gtf 1920 1200 59.95
        # 1920x1200 @ 59.95 Hz (GTF) hsync: 74.46 kHz; pclk: 192.99 MHz
        Modeline "1920x1200_59.95"                                  \\s\
                       192.99   1920 2048 2256 2592                 \\s\
                                1200 1201 1204 1242  -HSync +Vsync

1.4.2

        $> xrandr --newmode "1920x1200_60.00"                       \\s\
                       193.25   1920 2056 2256 2592                 \\s\
                                1200 1203 1209 1245  -hsync +vsync

1.4.3

        $> xrandr --addmode VGA1 1920x1200_60.00

1.4.4

        $> xrandr
        xrandr: Failed to get size of gamma for output default
        Screen 0: minimum 1600 x 1200,                              \\s\
                       current 1600 x 1200,  maximum 1600 x 1200
        default connected primary 1600x1200+0+0 0mm x 0mm
         1600x1200     77.00* 
         1920x1200_60.00 (0x2bf) 193.250MHz -HSync +VSync
         h: width  1920 start 2056 end 2256 total 2592 skew 0 clock 74.56KHz
         v: height 1200 start 1203 end 1209 total 1245        clock 59.88Hz
        igor@cenko-t:~
        $> 

None of the above has no effect, whatsoever, on the waking up of the display monitor when the computer wakes up from the suspend state.

1.5

I created ~/.xprofile and added the following to it:

    xrandr --output default --gamma 1.0:1.0:1.0
    xrandr --newmode "1920x1200_60.00" 193.25                   \\s\
                            1920 2056 2256 2592                 \\s\
                            1200 1203 1209 1245  -hsync +vsync

This ~/.xprofile also had no effect on SUSPEND problem, and Display app from the main Trisquel menu also did mot show the newly added mode!

1.6

Conclusion of manual settings using {{ xrandr )) command

In all of the above attempts, in many different combinations, when selecting System -> Preferences -> Hardware -> Display I was never able to get whichever resolution I managed to set by running xrandr commands. Also note that --gamme setting finally always failed and had an erroneous value 0.

But most importantly, I was never able to wake up my screen when
waking up the computer from the suspend state!

1.7

Finally, I wanted to test if falling back to xorg.conf configuration file could be the solution. Unfortunately, I was not able to demonstrate that. Indeed, I am also adding here both, my xorg.conf as well as /var/log/Xorg.0.log files, for anyone to look at, and perhaps point out to a source of all the problems that would hopefully also reveal a simple solution.

2. Questions about the "Xorg/suspend problem" and the procedures I took

2.1

The first part of the above steps from 1.1 to 1.6 is really deals with possibly some corrective actions to the automatic X-config. There's a lot of information on the Internet and in manual pages that one should get to understand. It is quite possible I have missed or misunderstood some parts of it.

Though, originally I was hoping to completely bypass the automatic X-configuration issues, since it mostly relies on software features and in hardware embedded device characteristics, specifications and parameters, all of which are most likely beyond user control. But since I still remember the days, when users, arguably, seemed to have more control over how their computer graphic devices worked, by managing the graphic parameters of their devices in configuration files not at all unlike the xorg.conf. Back in the day, a Unix administrator really had to know what they were doing, or risk burning ICs of your usually rather expensive monitor. (I am one of those unlucky guys, who experienced his monitor doing dark in smoke). Hence, naturally, I still believe in the power of, hopefully correct, manual configuration using xorg.conf, which I was almost certain would eventually help me overcome the modern and popular no-nonsense, and no-brainer automatic approach gone wrong. This indeed, is the second part (see 1.7) of the task above, namely, is there an obvious mistake or omission in my xorg.conf file.

But let's deal with things in order. So, the first I'd like to find out is whether the steps 1.1 through 1.6 above, were performed correctly and in a required order, as well as, that did not miss any essential steps there.

After we are certain we have done everything to get the 1st part (steps 1.1 through 1.6) working as it is expected, I believe we should look at the second part, (step 1.7) above.

And finally, if we are not able to solve "Xorg/suspend/monitor wake-up" problem, I would like to be able to identify what is the problem. Primarily is it related to a graphic card, or a driver, and would it be possible to solve the problem, by replacing a graphic board with a different one. And last but not list, how can one learn which graphic cards are supported.

As another peculiarity, here and at this point, I also need to mention, that the graphic-card with which my GNU/Linux distro and its Xorg libraries and utilities experience the problems we talk about here, is listed in my Xorg.0.log file, i.e., in the list of supposedly supported graphic cards for the pertinent Open drivers which for some reason do not recognize either the hardware itself, or the very same hardware (graphic cards, and/or monitors) are not EDID (Extended Display Identification Data) compliant, in which case it would be nice if xorg.conf could step in to force corrections over parameters introduced by misbehaving hardware devices. After all this is how things used to work, albeit with a lot of less help from external utilities, like xrandr, gtf, cvt, xvattr, etc, which today almost certainly additionally complicate the matters when one would like to fall back to the traditionally more reliable old ways.