Okay, that was a bold move. Took this old Acer 3633WLMi and gave it a SSD and a shiny 18.04.3 in Lubuntu flavor.
According to most Ubuntu Wikis, this specific laptop should run smoothly, no issue reported...
NOPE

Apart from the wifi being dead silent (will address this later on), my current main problem is being stuck in a 640x480 screen resolution!

Of course, I tried to find some forum discussing this issue, but couldn't find any.... which is pretty understandable, this problem being usually caused by Intel cards and this Acer thing boasting a SiS proprietary [censored] chipset.

Now, to the point (and diagnostic):

$ cat /etc/default/grub
[...]
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
[...]

$ dmesg |grep VGA
[    0.454387] pci 0000:01:00.0: vgaarb: setting as boot VGA device
[    0.454391] pci 0000:01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[    2.360257] fb0: VESA VGA frame buffer device

$ grep driver /var/log/Xorg.0.log
[    11.433]    X.Org XInput driver : 24.1
[    11.532] (==) Matched sis as autoconfigured driver 0
[    11.532] (==) Matched modesetting as autoconfigured driver 1
[    11.533] (==) Matched fbdev as autoconfigured driver 2
[    11.533] (==) Matched vesa as autoconfigured driver 3
[    11.533] (==) Assigned the driver to the xf86ConfigLayout
[    11.539] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    11.551] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[    11.560] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[    11.562] (==) Matched sis as autoconfigured driver 0
[    11.562] (==) Matched modesetting as autoconfigured driver 1
[    11.562] (==) Matched fbdev as autoconfigured driver 2
[    11.562] (==) Matched vesa as autoconfigured driver 3
[    11.562] (==) Assigned the driver to the xf86ConfigLayout
[    11.563] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    11.570] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[    11.571] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[    11.571] (II) FBDEV: driver for framebuffer: fbdev
[    11.579] (II) VESA: driver for VESA chipsets: vesa
[    12.803]    ABI class: X.Org XInput driver, version 24.1
[    12.803] (II) Using input driver 'libinput' for 'Power Button'
[    12.955] (II) Using input driver 'libinput' for 'Power Button'
[    12.973] (II) No input driver specified, ignoring this device.
[    12.978] (II) Using input driver 'libinput' for 'Sleep Button'
[    13.243] (II) No input driver specified, ignoring this device.
[    13.245] (II) Using input driver 'libinput' for 'Sleep Button'
[    13.258] (II) Using input driver 'libinput' for 'Power Button'
[    13.463] (II) Using input driver 'libinput' for 'AT Translated Set 2 keyboard'
[    13.740]    ABI class: X.Org XInput driver, version 24.1
[    13.740] (II) Using input driver 'synaptics' for 'SynPS/2 Synaptics TouchPad'

$ lspci |grep VGA
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter

$ xrandr --verbose
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 640 x 480, maximum 640 x 480
default connected 640x480+0+0 (0x2ab) normal (normal) 0mm x 0mm
        Identifier: 0x2aa
        Timestamp:  3715368
        Subpixel:   unknown
        Clones:
        CRTC:       0
        CRTCs:      0
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter:
        non-desktop: 0
                supported: 0, 1
  640x480 (0x2ab) 22.426MHz *current
        h: width   640 start    0 end    0 total  640 skew    0 clock  35.04KHz
        v: height  480 start    0 end    0 total  480           clock  73.00Hz

I don't get what's wrong with this.

Looks like the graphic adapter is recognized (it's indeed a SiS 6xx thing), but the screen is not?!

Of course, trying to manually change the resolution doesn't work.

That doesn't make any sense, since during the install, everything was working fine in 1024x768!

Update (better late than never). After several tries, couldn't get better than 640x480 on the long run. I figured out a better resolution could be forced through the xorg.conf, but it didn't last: logging out or bringing the laptop to sleep or (of course) rebooting would simply reset the damn default values. I wish I could post more about this issue (and I wish I could have solved it), but alas the laptop's had to be scraped for parts.

If you encounter this problem with this specific laptop, I'd recommend you search and remove anything that would mess with Xorg configuration as well as any other kind of windows manager.

As soon as i loaded my test image i noticed the gradient was no longer smooth but it contained some vertical artifacts. I should point out that the gamma is set to default in Ubuntu: xgamma gamma 1.0

I also have Windblows 10 and OSX and there the gradient is smooth. However in Ubuntu it is brighter and contains vertical artifacts. And each time i take a screenshot, test image becomes brighter. This is driving me crazy.

So here is a test image:

Here is a screenshot from Ubuntu. Look into the black area and notice how an extra gamma is applied, reducing the amount of black compared to original. Also notice vertical artifact:

Notice how bright the image becomes after a couple of screenshots (a screenshot of a screenshot of a screenshot to be exact):

The test image in the last example has become stupidly bright indicating there is another layer of gamma control present in the display settings that is just hidden from access and is added to the previous gamma which was present in a screenshot.

Please keep in mind before you mention i should change gamma, this is all happening at gamma 1.0.

On X, I could change gamma by tuning the xorg.conf file and add a "Gamma" line with the right value to the "Monitor Section". How do I do this on wayland? [edit]Or: What's the name of the tool for doing this in wayland and how can I make that config persistent?·[/edit]

I have this problem... When Im on Ubuntu 16.04 (LTS) or basicly every Linux distro that i tried before, i have a bug. On open-source drivers, my brightness and gamma are normal, but when i use any nvidia driver (newer, older, doesnt matter), my gamma and brightness are way too dark. Im using a workaround with xgamma on startup, but its kinda not a permanent solution (because i use fullscreen apps and they reset the gamma upon exiting). So is there a way to set the same gamma that open-source driver has? Or do i have to use open-source driver until nvidia fixes it?

Background: More red / Less blue at night

To save the eyes at night, adding more red and/or subtracting blue, is becoming popular in Windows 10 (blue-light filter) and Linux; Gnome Desktop (Night Light) and Ubuntu Unity Desktop with add-ons such as Red Shift or f.lux.

I'm wondering how to accomplish the same with Ubuntu's built-in command line xrandr <monitor> --gamma 1:1:1 feature. The 1:1:1 represents percentage of red:green:blue. I presume 1 = 100%. I'm not sure if the above packages add more red (1.2:1:1) for ~20% increase or reduce blue (1:1:0.8) for ~20% decrease or both for ~40% change.

Gnome Night Light example doesn't help

According to OMG Ubuntu, within Gnome's Night Light you can use these numerical values:

• 1000 — Lowest value (super warm/red)
• 4000 — Default night light on temperature
• 5500 — Balanced night light temperature
• 6500 — Default night light off temperature
• 10000 — Highest value (super cool/blue)

To test these numerical values, how would does one translate them to override the default --gamma 1:1:1?

What xorg's documentation says

Xorg's documentation doesn't say very much about --gamma controls:

−−gamma red:green:blue

• Set the specified floating point values as gamma correction on the crtc currently attached to this output. Note that you cannot get two different values for cloned outputs (i.e.: which share the same crtc) and that switching an output to another crtc doesn’t change the crtc gamma corrections at all.

Floating decimal points will be helpful because the script I want to upgrade sets xbacklight brightness slowly once a minute over a 90 to 120 minute transition period at dawn and dusk. I want to enhance the script with both xrandr --brightness software support for external monitors and OLED built in displays and xrandr --gamma support for red light / blue light filters. Xorg doesn't say how many decimal positions are supported but I think I think I will set bc calculations should be to 3 or 4 decimal positions for readability / precision balance.

Summary

I'm hoping to mimic what "the big guys" at Microsoft and Gnome are doing with their "more red" and/or "less blue" techniques. I haven't delved into Wayland yet but answers using that system will also be appreciated as it will no doubt be a future concern.

What adjustment to --gamma 1:1:1 are appropriate for night time?