Testing: resolution too low, higher not available [Solved]

[Member sybok]

Hi, I run antiX testing with kernel 5.10.142-antix.2-amd64-smp and 4.19.0-256-antix.1-amd64-smp in a multiboot setup with the grub “owned” by antiX.
Both kernels are affected by the below described issue.

The antiX owned grub (grub-common: 2.06-8) starts with a low resolution (I guess it is 1024×768 based on output of ‘xrandr’) and this resolution prevails through the login screen to the session.
The old Acer monitor allows for resolution up to 1280×960 (that works in Windows 10).
Unfortunately, it is no longer listed by ‘xrandr’ as an option, hence not offered by antiX control centre -> Session -> Set screen resolution.

I can set a higher resolution using a script (with hard-coded values based on output of ‘cvt’) I made earlier when similar problem appeared in the past.
It works well for 1152×864 but it fails for the highest resolution 1280×960.
The failure at the highest resolution is a shift of the screen to the left and slightly up (hence making part of its range visually inaccessible).

This applies to both antiX-testing and Devuan-stable (in the multiboot setup).
The outputs of ‘xrandr’ and ‘cvt’ (I had to install ‘xcvt’ package missing from my system), see the attachment [SCREEN_RESOLUTION.txt] are identical in both systems.
The higher resolutions become listed after the resets by the script in both ‘xrandr’ and also in the aforementioned antiX’s GUI.

Ah, the perils of running testing (and Debian-based system since Devuan-stable is affected as well) on a low(er) end HW.

Any suggestions welcome.
Also, I would prefer to avoid hard-coding resolution in the system which is a solution sometimes reported.

Did already read (but found nothing new I dared to try):
https://www.antixforum.com/forums/topic/how-to-change-screen-resolution-when-only-one-is-listed/
https://www.antixforum.com/forums/topic/antix-will-not-set-the-native-monitor-resolution/
https://www.antixforum.com/forums/topic/asus-eeepc-900-antix21-display-resoluton-problem/

Attachments:

1. SCREEN_RESOLUTION.txt
2. INXI_Fzr.txt

[Member RJP]

Helpful

Up

0

::

Try

xrandr --newmode "1280x960_60.00"  101.25  1280 1360 1488 1696  960 963 967 996 -hsync +vsync
xrandr --addmode VGA-0 1280x960_60.00
xrandr -s 1280x960

[Member sybok]

Helpful

Up

0

::

Hi @RJP, thanks for replying.

1) I tried the first two lines (present in my script that I failed to upload even when renamed extension from ‘.sh’ to ‘.txt’ and commenting out the ‘#!/bin/bash’ line).
Adding the third line (setting up screen size) to the script did not help — it results to a shift of the screen again.

2) I forgot to mention an error message when creating the new-mode (i.e. the 1st line of your three)

X Error of failed request: BadName (named color or font does not exist)
Major opcode of failed request: 140 (RANDR)
Minor opcode of failed request: 16 (RRCreateMode)
Serial number of failed request: 25
Current serial number in output stream: 25

The same error is reported when re-setting to the “working” mode with higher resolution 1152×864.
Not sure if the error was present before.

3) I also explored some of the logs in ‘/var/log/’ but did not find anything useful which may be due to my lack of expertise.

4) I recall I used a default grub-configuration/setting file when upgrading in the past.
Perhaps, it contributed to the issue arising now.
If someone suspects it to be the case, I can try to restore the antiX’s version (e.g. from installation in a VirtualBox).

5) BTW, I plan to be out for several hours and my replies to any further comments may be delayed.

[Member RJP]

Helpful

Up

0

::

Just googling https://stackoverflow.com/questions/851704/xrandr-errors-badname-named-color-or-font-does-not-exist

Added quotes around the mode and made it shorter. No idea why thou, but it worked

Try

xrandr --newmode "1280"  101.25  1280 1360 1488 1696  960 963 967 996 -hsync +vsync
xrandr --addmode VGA-0 1280x960
xrandr -s 1280x960

[Moderator caprea]

Helpful

Up

0

::

sybok wrote:

Both kernels are affected

There’s a new kernel in the repos, linux-image-6.1.18-antix.1-amd64-smp
Might worth a try. I had to remove rtl8821ce-dkms to get it installed properly.

[Member sybok]

Helpful

Up

0

::

Hi, thank you all for the suggestions.

I tried to install the kernel 6.1.18 (linux-image-6.1.18-antix.1-amd64-smp).
It fails, I checked that package ‘rtl8821ce-dkms’ is not installed in my system (no wi-fi).

Binary /lib/modules/6.1.18-antix.1-amd64-smp/build/scripts/sign-file not found, modules won’t be signed
Building module:
Cleaning build area…
make -j2 KERNELRELEASE=6.1.18-antix.1-amd64-smp -C /lib/modules/6.1.18-antix.1-amd64-smp/build M=/var/lib/dkms/exfat/5.9/build…(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.1.18-antix.1-amd64-smp (x86_64)
Consult /var/lib/dkms/exfat/5.9/build/make.log for more information.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11

You may see the file [make.log] attached which reveals that the problem is that ‘exfat-dkms’ version 5.9.1-contribs1 is installed and the compat.h does not support v5.8+.
This version is also installed in my antiX-stable system which means that both stable and testing should be affected by this.
Perhaps, @anticapitalista could do something about it…

The error mention in my item no. 2) of my previous post comes from rerunning the script and thus trying to create a new mode with a name that already exists.
The script does not check whether the name is already present and this explains why the error does not always appear – it occurs only in reruns.
My mistake for not realizing it earlier.

Unfortunately, this is not the cause why setting up the highest resolution fails (resulting into a shift of the screen).

Attachments:

1. make.log_.txt

[Member sybok]

Helpful

Up

0

::

4) I recall I used a default grub-configuration/setting file when upgrading in the past.

This overwrite of antiX’s version was not the cause; the only significant difference in ‘/etc/default/grub’ was parsing name of the distribution.

6) [NEW ITEM] I entered the grub shell, executed command ‘videoinfo’
https://www.gnu.org/software/grub/manual/grub/html_node/videoinfo.html

Too many lines to display on the screen with the low resolution.
Hence I narrowed them down by providing resolution explicitly.
The output contains a header, the body and footer.
The body consists of triple-lines for each resolution; sometimes, there are several triple-lines.

List of supported video modes:
Legend: mask/position=red/green/blue/reserved
Adapter `Cirrus CLGD 5446 PCI Video Driver’:
No info available
Adapter `Bochs PCI Video Driver’:
No info available
Adapter `VESA BIOS Extension Video Driver’:
VBE info: version 3.0 OEM software rev: 10.94
total memory: 16384 KiB
<triple-lines>
Adapter `VGA Video Driver’:
No info available

Each of the triple-line has the following structure:
0x<3x hexadecimal> <resolution-x> x <resolution-y> x <uint = 8, 16, 32> <uint: 4-digit> <Description>
The unsigned integer ranging from 8 through 16 to 32 “is responsible” for the triple-lines.
The description is either short ‘Paletted’ or long with additional information such as ‘Direct color mask: 8/8/8/0 pos: 16/8/0/0’.

Regarding the resolutions listed/available: 1152×864 is present, 1280×960 is missing and another 1280x resolution, 1280×1024, is present.
Implementing the last into my BASH script (hard-coded output of ‘cvt’ used in ‘xrandr’) results into the same error as in the case of 1280×960 — shift of screen when applied after I login.
This leads me to suspect that enforcing higher resolution in grub (there is a line with resolution in the default configuration file) might behave oddly.

I’ve been unable to upload the shell script again (even after complete rename, adding prefix ‘!’ to each line, removing the ‘/bin/bash’ line etc.).

• This reply was modified 1 month, 2 weeks ago by sybok. Reason: Dumb-smart upload filter drives me crazy

[Member RJP]

Helpful

Up

0

::

If you cannot set higher resolution using xrandr, you can try to use scale option. For testing

xrandr --output VGA-0 --scale 1.11x1.11 && sleep 10 && xrandr --output VGA-0 --scale 1x1

[Member sybok]

Helpful

Up

0

::

Thanks for the tip. Will try when I get home.

It works.
The screen seems to be a little fuzzy, perhaps I need to re-adjust (my eyes) or the frequency could be tinkered with.

The kernel 6.1 installation is discussed in a separate thread/topic, see https://www.antixforum.com/forums/topic/cannot-install-kernel-6-1-18/

• This reply was modified 1 month, 2 weeks ago by sybok. Reason: Add aftert test comments

[Member RJP]

Helpful

Up

0

::

Scaling seems to be an safe option. 🙂

Attachments:

1. 

   testing.jpg
   

[Member RJP]

Helpful

Up

0

::

sybok wrote:

Thanks for the tip. Will try when I get home.

It works.
The screen seems to be a little fuzzy, perhaps I need to re-adjust (my eyes) or the frequency could be tinkered with.

When it works, you may need to add the command to startup? If IceWM, so the $HOME/.icewm/startup a line.

xrandr --output VGA-0 --scale 1.11x1.11 &

[Member sybok]

Helpful

Up

0

::

Yes, I know and I intend to do so, either ‘~/.desktop-session/startup’ or the file(s) for individual desktops.
One needs to re-set the background image and re-start conky as well to accommodate for the change in resolution.

[Member sybok]

Helpful

Up

0

::

I installed the kernel 6.1.18, it did not help.
I booted, logged in, set up the higher resolution with scaling.
Today’s update of mesa (and related libraries) resulted in a reboot to the best resolution.
This thread can be marked as solved.

[Author]

Posts