Puppy Linux Discussion Forum

Kjellinux wrote: ↑Mon Jul 05, 2021 10:34 pm

@amethyst

amethyst wrote: ↑Mon Jul 05, 2021 3:59 pm

Could it be that the Xorg version is too "new" for that old hardware? Could be a reason why you have no problems with the resolution running the older Puppy's.

In the xorgwizard in BionicPup32 8.0+27 it states "Xorg server 1.19.16 regular"
In the xorgwizard in Precise Light 5.7.2 it states "Xorg server 1.11.3"
In the xorgwizard in Slacko 6.3.2 there's no version information.

Is that information sufficient to answer your question? If it's too new, could it be changed to an older?

Yes, I think so. So everything works with Xenial? If so, that will be a good choice for you otherwise use Precise.

@williams2

williams2 wrote: ↑Tue Jul 06, 2021 12:53 am

this should display the EDID data (works in BionicPup64):

Code: Select all

get-edid | parse-edid

This is the result I get:

get-edid | parse-edid
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
Looks like no busses have an EDID. Sorry!
Attempting to use the classical VBE interface

	Performing real mode VBE call
	Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
	Function supported
	Call successful

	VBE version 200
	VBE string at 0x11100 "ATI RADEON XPRESS 200M Series"

VBE/DDC service about to be called
	Report DDC capabilities

	Performing real mode VBE call
	Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
	Function supported
	Call successful

	Monitor and video card combination does not support DDC1 transfers
	Monitor and video card combination supports DDC2 transfers
	0 seconds per 128 byte EDID block transfer
	Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
	Read EDID

	Performing real mode VBE call
	Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
	Function supported
	Call successful

Checksum Correct

Section "Monitor"
	Identifier "�	"
	ModelName "�	"
	VendorName "QDS"
	# Monitor Manufactured week 0 of 2005
	# EDID version 1.3
	# Digital Display
	DisplaySize 330 210
	Gamma 2.20
	Option "DPMS" "false"
	Modeline 	"Mode 0" 68.90 1280 1301 1333 1408 800 804 808 816 -hsync -vsync 
EndSection
Looks like VBE was successful. Have a good day.

Does this help?

@williams2

williams2 wrote: ↑Tue Jul 06, 2021 12:53 am

Edit /etc/X11/xorg.conf and add Option "ModeDebug" "On" to the Section "Device", like this

Code: Select all

Section "Device"
   Device     "Card0"
   Option "ModeDebug" "On"

There was no Section "Device", but I found a Section "Screen" that contained #Device "Card0". I removed the "#" and added Option "ModeDebug" "On" on a new line according to your example.

This is how the section looks now:

Section "Screen"
	Identifier "Screen0"
	Device     "Card0"
	Option "ModeDebug" "On"
	Monitor    "Monitor0"
#	DefaultDepth 24
	#Option         "metamodes" "1280x800_60 +0+0" #METAMODES_0
	Subsection "Display"
		Depth       24 #screen0depth
		Modes       "1280x800" #screen0modes
	EndSubsection
EndSection

@williams2

williams2 wrote: ↑Tue Jul 06, 2021 12:53 am

you can put something like this in xorg.conf:

Code: Select all

Section "Monitor"
   VertRefresh 48.0-75.0
   Modeline "1280x800"     68.90   1280 1301 1333 1408    800  804  808  816 -hsync -vsync
   Option          "PreferredMode" "1280x800"
etc, etc

and something like this:

Code: Select all

Section "Screen"
	Subsection "Display"
	   Depth       24
	   Modes       "1280x800"   

Section "Monitor" now looks like this:

Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "Monitor Vendor"
	ModelName    "Monitor Model"
	HorizSync    35-81
	VertRefresh  48.0-75.0
	Modeline "1280x800"	68.90	1280 1301 1333 1408	 800 804 808 816 -hsync -vsync
	#UseModes     "Modes0" #monitor0usemodes
	Option      "PreferredMode" "1280x800" #monitor0prefmode
EndSection

And Section "Screen" looks like this:

Section "Screen"
	Identifier "Screen0"
	Device     "Card0"
	Option "ModeDebug" "On"
	Monitor    "Monitor0"
#	DefaultDepth 24
	#Option         "metamodes" "1280x800_60 +0+0" #METAMODES_0
	Subsection "Display"
		Depth       24 #screen0depth
		Modes       "1280x800" #screen0modes
	EndSubsection
EndSection

@williams2

williams2 wrote: ↑Tue Jul 06, 2021 12:53 am

Actually, Xorg is supposed to be able to run without an xorg.conf file.
If you delete the xorg.conf file, Puppy will create a new one.
You can start Xorg without any configuration in xorg.conf by replacing all the text in xorg.conf with a comment character, like this:

Code: Select all

echo "#" > /etc/X11/xorg.conf

I think I will save this one for my last attempt.

I have now done the above edits to xorg.conf and rebooted. I guess I was not entirely surprised that the screen resolution is still stuck at 800x600.

I think I will save this one for my last attempt

If you delete xorg.conf and restart X (or reboot) then Puppy should automatically create a new xorg.conf file.

If you are not yet ready to give up, you could gzip copies of /etc/X11/xorg.conf and /var/log/Xorg.0.log and post them to the forum or upload them to somewhere like pastebin.com, so that anyone willing to help would have more information to work with.

@williams2

williams2 wrote: ↑Tue Jul 06, 2021 3:39 am

If you delete xorg.conf and restart X (or reboot) then Puppy should automatically create a new xorg.conf file.

Now I have tried deleting xorg.conf too. No difference...

williams2 wrote: ↑Tue Jul 06, 2021 3:39 am

you could gzip copies of /etc/X11/xorg.conf and /var/log/Xorg.0.log and post them to the forum

I tried to do this, but I don't know if I got it right.

I looked at your xorg.conf file.

The driver was set to vesa. The best you will get from vesa is 800x600.
I commented the driver "vesa" line.
If it still uses vesa you could try uncommenting (delete the # character at the beginning of the line) for Driver "radeon"
I think that you said Slacko used the radeon driver.
Or the ati driver might work.

If the display doesn't look right, kill X immediately by pressing ctrl+alt+backspace
Then delete the xorg.conf file by typing rm /etc/X11/xorg.conf
You don't need to type the whole thing, it should work to type:
rm /e<TAB>/X<TAB>xo<TAB>
Then you can restart X by typing xwin

I added the modeline from Xenial or Slacko that you said worked, to Section "Monitor"
I uncommented the HorizSync and VertRefresh lines, hopefully they are set to reasonable values.

Appended: my xorg.conf file, gzipped (just click it to unzip it)
Appended: a little script to copy your xorg.conf and Xorg.log files to /tmp/ and create a file named xorg.tar.gz from them. Click it to unzip. If you put the script in /root/ you could run it by typing sh tarxorg.sh

@williams2

williams2 wrote: ↑Tue Jul 06, 2021 9:00 pm

The best you will get from vesa is 800x600.

What sets this limit? Using the xorgwizard there's 1280x800 in the list.

williams2 wrote: ↑Tue Jul 06, 2021 9:00 pm

If it still uses vesa you could try uncommenting (delete the # character at the beginning of the line) for Driver "radeon"
I think that you said Slacko used the radeon driver.
Or the ati driver might work.

I used your xorg.conf and uncommented radeon and ati, one at the time. Something changed in the screen that flashes by a split second before the desktop comes up. As soon as the desktop came up, it was back to 800x600. It's as if something overrides whatever changes and settings I try to do.

williams2 wrote: ↑Tue Jul 06, 2021 9:00 pm

Appended: a little script to copy your xorg.conf and Xorg.log files to /tmp/ and create a file named xorg.tar.gz from them. Click it to unzip. If you put the script in /root/ you could run it by typing sh tarxorg.sh

I ran your script and this is the result:

What sets this limit? Using the xorgwizard there's 1280x800 in the list.

Just from reading the Xorg log, it falls back to vesa, and tests and rejects various modes. 800x600 is the highest resolution in the list. the other modes are mostly rejected because the horizontal sync rate is not in the range.
It is using the hsync and vrefresh ranges from the xorg.conf fille:
[ 332.197] (II) VESA(0): Monitor0: Using hsync range of 35.00-81.00 kHz
[ 332.197] (II) VESA(0): Monitor0: Using vrefresh range of 59.00-76.00 Hz

Have you read this: https://wiki.archlinux.org/title/ATI

One thing it suggests is to add radeon.modeset=1 to the kernel boot options (where pfix= and pmedia= are, in menu.lst or grub.cfg or syslinux.conf etc etc)
And then maybe try rebooting with that option and a blank xorg.conf file
(create a blank file like this: echo '#' > /etc/X11/xorg.conf )
(Puppy will make a new xorg.conf file if you delete it and restart X)

You can generate a vesa Modeline like this: cvt 1280 800

You can create a EDID.bin file from the monitor's EDID data and use that file instead of the monitor's EDID data (I think, I haven't actually done it)
The idea is to edit the data so that it works properly.
This displays the EDID data: get-edid | parse-edid

you can list the builtin vesa modes like this: grep Mode: Xorg.0.log
The resolutions listed in your Xorg.0.log file range from 320x200 to 1600x1200.
The only 1280 vesa mode listed is 1280x1024.

@williams2

I guess I have reached the point where I'm ready to give up. Not because i like to, but because I have to realise my limitations. I don't mind searching and testing, but I need at least to understand what to search for and what to test and how.

williams2 wrote: ↑Thu Jul 15, 2021 7:55 pm

Just from reading the Xorg log

This is hurdle #1. I don't understand most of what I read in the Xorg log.

williams2 wrote: ↑Thu Jul 15, 2021 7:55 pm

the other modes are mostly rejected because the horizontal sync rate is not in the range.

Hurdle #2. I consulted Google to find out the horizontal sync rate of the Acer Aspire 3100, but failed.

williams2 wrote: ↑Thu Jul 15, 2021 7:55 pm

Have you read this: https://wiki.archlinux.org/title/ATI

Hurdle #3. I got as far as reading the table of contents and the first paragraph. Already in the first paragraph there were 3 links to other documents that was beyond my level of understanding.

williams2 wrote: ↑Thu Jul 15, 2021 7:55 pm

One thing it suggests is to add radeon.modeset=1 to the kernel boot options (where pfix= and pmedia= are, in menu.lst or grub.cfg or syslinux.conf etc etc)

Hurdle #4. I tried to find some search function in the file manager to find these files. It appeared that "Ctrl+F" should fill this function, but the only thing that happened was that the pointer changed into 3 concentric circles.

williams2 wrote: ↑Thu Jul 15, 2021 7:55 pm

And then maybe try rebooting with that option and a blank xorg.conf file
(create a blank file like this: echo '#' > /etc/X11/xorg.conf )
(Puppy will make a new xorg.conf file if you delete it and restart X)

I deleted the xorg.conf file before. Does that give the same result?

williams2 wrote: ↑Thu Jul 15, 2021 7:55 pm

You can generate a vesa Modeline like this: cvt 1280 800

Is that to be edited into xorg.conf or entered as a command?

williams2 wrote: ↑Thu Jul 15, 2021 7:55 pm

You can create a EDID.bin file from the monitor's EDID data and use that file instead of the monitor's EDID data (I think, I haven't actually done it)

This one I don't understand at all. "create a EDID.bin file from the monitor's EDID data and use that file instead of the monitor's EDID data".

williams2 wrote: ↑Thu Jul 15, 2021 7:55 pm

This displays the EDID data: get-edid | parse-edid

This I have done already (p.7 of this thread).

I guess I should be flattered that you expect me to understand everything you write, but this is way beyond my level of knowledge. I need much simpler and more step by step instructions to understand.

Given the above, I also try to put this problem into a bigger picture. I have tried 8 other Puppy versions and a number of other distributions. All of them, without exception, have booted directly into the correct screen resolution. Several of the Puppy versions have also informed me in the initial Quick Setup thet "The ati video driver is currently being used". This suggests to me that the problem might not primarily be that my test rig is too old, but that BionicPup32 8.0 in particular differs from all the others in some way that causes this problem. Finding out exactly how appears to be quite difficult, and definitely beyond my level of knowledge.

I'm not exactly an X guru myself.

One thing it suggests is to add radeon.modeset=1 to the kernel boot options

I'm not sure, but I think radeon.modeset is enabled by default, in which case radeon.modeset=1 would not do anything.
But if it is disabled, the radeon ati driver won't start. That would be set in your boot loader configuration file. In my case, syslinux.conf on my plugin usb flash drive.

I deleted the xorg.conf file before. Does that give the same result?

you can delete the xorg.conf file any time you like, Puppy will create a new one the next time you start X/ Which is convenient if xorg.conf is damaged or corrupted or accidentally deleted.

But if you want to start X without an xorg.conf file, for example, if Puppy is creating an xorg.conf file that doesn't work, then deleting xorg.conf won't work, Puppy will just recreate it. The echo '#' > /etc/X11/xorg.conf trick is a work around that allows X to start with blank xorg.conf file, which is about the same as deleting the file.

I think that the newer Xorg in Bionic no longer supports your hardware, compared to the older Xorg in Xenial.
If so, adding a modeline might be all it needs.

I can still think of a few things to try, but you can give up any time you like.

I don't think you tried adding a modeline to xrandr (successfully.) If you want to try that, I've attached a script to give me some information. Just download the script named script.gz. It's not gzipped, just run it in a terminal (console) like this:
sh script.gz

Then upload the file /tmp/scriptout.gz to the forum.

@williams2

williams2 wrote: ↑Tue Jul 20, 2021 1:21 am

I'm not sure, but I think radeon.modeset is enabled by default, in which case radeon.modeset=1 would not do anything.
But if it is disabled, the radeon ati driver won't start. That would be set in your boot loader configuration file. In my case, syslinux.conf on my plugin usb flash drive.

So, I'll try one thing at the time. I don't seem to have a syslinux.conf. Which one could be my boot loader configuration file?

Which one could be my boot loader configuration file?

The configuration file you use to boot could be:

grub.cfg
isolinux.cfg
menu-advanced.lst
menu.lst

isolinux is a boot loader for cd/dvd optical discs. An iso file is usually burned to a cd or dvd. An iso file could be copied to a usb flash drive, but it would probably be a read only file system, iso9660.

grub.cfg and menu-advanced.lst and menu.lst are all used by various versions of Grub.

You should be able to type radeon.modeset=1 when you see the boot loader screen.
With Grub I think you select which Puppy you want to boot, then press e, type radeon.modeset=1 at the end of the line you are editing, then press <enter> or ctrl+X or something to boot. Then, if it works, you could later edit the config file to work every time you boot.

But I think radeon.modeset is enabled by default, because the radeon driver won't run if it's disabled.

Boot loaders are much more complicated than they used to be, even a few years ago.
And it's possible that your configuration file might be on another partition on your boot drive.

Downloading script.gz and running it would take less that 5 minutes. If I had that information I could write a simple script to add a modeline to xrandr and switch to it. Which might not work. If it does work, you would still be using the vesa driver.

@williams2

williams2 wrote: ↑Tue Jul 20, 2021 6:45 pm

You should be able to type radeon.modeset=1 when you see the boot loader screen.
With Grub I think you select which Puppy you want to boot, then press e, type radeon.modeset=1 at the end of the line you are editing, then press <enter> or ctrl+X or something to boot. Then, if it works, you could later edit the config file to work every time you boot.

But I think radeon.modeset is enabled by default, because the radeon driver won't run if it's disabled.

I pressed "e" when the Grub4Dos menue came up. This took me to another page where I typed "o" to open a new line after the last. Here I pressed "e" to edit which took me to a third page with a "grub edit>" prompt. Here I typed "radeon.modeset=1" and then "esc" to return to the previous page where "radeon.modeset=1" now had been added. I pressed "esc" again to return to the Grub4Dos menue and "b" to boot.

Sadly, still no change.

williams2 wrote: ↑Tue Jul 20, 2021 6:45 pm

Downloading script.gz and running it would take less that 5 minutes. If I had that information I could write a simple script to add a modeline to xrandr and switch to it. Which might not work. If it does work, you would still be using the vesa driver.

I will try this next and report back when I'm done.

@williams2

williams2 wrote: ↑Tue Jul 20, 2021 1:21 am

I don't think you tried adding a modeline to xrandr (successfully.) If you want to try that, I've attached a script to give me some information. Just download the script named script.gz. It's not gzipped, just run it in a terminal (console) like this:
sh script.gz

Then upload the file /tmp/scriptout.gz to the forum.

I pressed "e" when the Grub4Dos menue came up. This took me to another page where I typed "o" to open a new line after the last. Here I pressed "e" to edit which took me to a third page with a "grub edit>" prompt. Here I typed "radeon.modeset=1" and then "esc" to return to the previous page where "radeon.modeset=1" now had been added. I pressed "esc" again to return to the Grub4Dos menue and "b" to boot.

That is not how you edit a menu entry.

When you see the boot menu.
Use arrow keys to highlight the entry you want to edit.
Press e key.
You are now in the edit screen and should be seeing all the different lines of commands that make up the entry.
Use arrow keys to move the highlight to the kernel line.
Press e key.
That says you want to edit that line of commands.
Use arrow key to move input prompt to end of the kernel line.
Press space bar to add a space at end.
Add the radeon.modeset=1
Press enter key to complete the edit.
Press b key to boot.

Can also try using radeon.modeset=0

@bigpup

bigpup wrote: ↑Wed Jul 21, 2021 12:02 am

That is not how you edit a menu entry.

When you see the boot menu.
Use arrow keys to highlight the entry you want to edit.
Press e key.
You are now in the edit screen and should be seeing all the different lines of commands that make up the entry.
Use arrow keys to move the highlight to the kernel line.
Press e key.
That says you want to edit that line of commands.
Use arrow key to move input prompt to end of the kernel line.
Press space bar to add a space at end.
Add the radeon.modeset=1
Press enter key to complete the edit.
Press b key to boot.

Can also try using radeon.modeset=0

Now, THIS is the kind of instructions needed in a section called "Beginners Help". Outstanding!

Unfortunately, I'm still stuck with 800x600. Something changed though, in the screen that flickers by briefly before the desktop appears. When I changed to radeon.modeset=0, I could now clearly read "acer acer", where it was earlier just a blur of colours. If that's of any use is a whole different question...

@williams2 @bigpup

Suddenly, and I have no idea which one of my actions caused it, the QuickSetup tells me I have a screen resolution of 1024x768, and that "The radeon video driver is currently being used."

Another thing I have noticed is that all other Puppy versions that I have tested changes the font size of the diagnostic output during the boot sequence about halfways. BionicPup32 stays with the larger font during the entire boot sequence.

other Puppy versions that I have tested changes the font size of the diagnostic output during the boot sequence about halfways. BionicPup32 stays with the larger font during the entire boot sequence

That would mean that the kernel is not changing the mode (resolution.)

If mode.setting is enabled, the kernel can set the mode (the video resolution) of your hardware, at boot time.
If mode.setting is disabled, the kernel can not set the mode.

When X starts, the video driver can just keep using the mode that the kernel already set (in your case, 1280x800)

Either way, the video driver can change to other resolutions.

I think with mode.setting disabled, the radeon driver will not run, because it needs kms, and kms needs mode.setting to be enabled (I read somewhere.) If it says the radeon driver is running, it may have tried to run but failed and is really using the vesa driver. Or the radeon driver may actually be running.

What do you see if you type xrandr in a terrminal? Is 800x600 listed? I wrote a couple of simple scripts. The scripts should work if 800x600 is in the xrandr resolutions. The scripts should work, whether the modelines work is another question.

The script x11.gz tries the modeline that worked in XenialPup.
The script x22.gz tries the modeline that was generated by cvt.

If you want to try them, download the scripts, copy them somewhere like /root/
If the scripts are in /root/ you could execute them by typing in a terminal like this:
sh x11.gz
and
sh x22.gz

You can rename the scripts if you want, they are not gzipped, the .gz extension tricks the forum to allow them to be uploaded to the forum. Which the forum probably should not allow to happen.

By the way, you should not execute scripts or applications that a stranger gives you in case it's malicious.

What the script does, is
1) adds a 1280x800 modeline, then
2) tries to change to that resolution, then
3) wait 5 seconds to see if it worked, then
4) changes back to 800x600 which hopefully should work.

If the video screen looks wrong, press ctrl+alt+backspace to kill X then type xwin to restart X
If ctrl+alt+backspace doesn't seem to work you can press and hold the power button for more than 5 seconds to poweroff.

@williams2

williams2 wrote: ↑Wed Jul 21, 2021 3:33 am

If mode.setting is enabled, the kernel can set the mode (the video resolution) of your hardware, at boot time.
If mode.setting is disabled, the kernel can not set the mode.

How can I find out if mode.settings is enabled or disabled?

williams2 wrote: ↑Wed Jul 21, 2021 3:33 am

What do you see if you type xrandr in a terrminal?

# xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 800 x 600, maximum 800 x 600
default connected 800x600+0+0 0mm x 0mm
   800x600       73.00* 
   640x480       73.00  
#

The scripts yielded the following output:

# sh x11.gz
xrandr: Gamma size is 0.
xrandr: Failed to get size of gamma for output default
xrandr: Failed to get size of gamma for output default
xrandr: Failed to get size of gamma for output default
xrandr: Failed to get size of gamma for output default
xrandr: Failed to get size of gamma for output default
xrandr: Gamma size is 0.
xrandr: Gamma size is 0.
# sh x22.gz
xrandr: Gamma size is 0.
xrandr: Failed to get size of gamma for output default
xrandr: Failed to get size of gamma for output default
xrandr: Failed to get size of gamma for output default
xrandr: Failed to get size of gamma for output default
xrandr: Failed to get size of gamma for output default
xrandr: Gamma size is 0.
xrandr: Gamma size is 0.
#

The screen resolution did not change while running either of the scripts. After running the scripts xrandr yielded a different output:

# xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 800 x 600, maximum 1280 x 800
default connected 800x600+0+0 0mm x 0mm
   800x600       73.00* 
   640x480       73.00  
   1280x800_60.00  59.97  
   1280x800_60.00_CVT  59.81  
#

How can I find out if mode.settings is enabled or disabled?

kms means Kernel Mode Setting.
In your case, the kernel, and Xorg, should set the resolution to 1280x800.

For my machine:

grep -i modeset /var/log/messages
kern.info kernel: [drm] radeon kernel modesetting enabled.
kern.info kernel: [drm] initializing kernel modesetting (PALM 0x1002:0x9802 0x103C:0x188B 0x00).

For my machine:

grep -i modeset /var/log/Xorg.0.log
[    35.258] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    35.274] (II) [KMS] Kernel modesetting enabled.
[    35.274] (WW) Falling back to old probe method for modesetting

Which seems to say that for my machine, the radeon driver is ignoring the resolution that the kernel set while it was booting, that is, when the resolution changed about half-way through the boot process.

What do you see if you type xrandr in a terrminal?

the QuickSetup tells me I have a screen resolution of 1024x768

I meant, when you got it to run at 1024x768, what other modes does xrandr list?
Or were you running at 1024x768? Or was it just listed in the QuickSetup window?
Usually you monitor can tell you what resolution it is displaying.

I read somewhere that if there is an error message about gamma, that if you explicitly set it, it fixes that error.
When I run those scripts, I don't get an error message.

Maybe if you added --gamma 1:1:1 to the line xrandr --addmode default "1280x800_60.00" like this:
xrandr --addmode default "1280x800_60.00" --gamma 1:1:1

Maybe even try adding --gamma 1:1:1 to xrandr --newmode "1280x800_60.00" 68.90 1280 1301 1333 1408 800 804 808 816 \-hsync \-vsync ?

@williams2

williams2 wrote: ↑Wed Jul 21, 2021 6:46 pm

I meant, when you got it to run at 1024x768, what other modes does xrandr list?

The 1024x768 seems to occur when I boot with radeon.modeset=0. In this case xrandr generates the following output:

# xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1024 x 768, maximum 1024 x 768
default connected 1024x768+0+0 0mm x 0mm
   1024x768      76.00* 
   800x600       73.00  
   640x480       73.00  
#

I also get the following:

# grep -i modeset /var/log/messages
Jul 21 19:36:36 puppypc23592 kern.notice kernel: Kernel command line: pmedia=usbflash  pfix=fsck radeon.modeset=0
#

# grep -i modeset /var/log/Xorg.0.log
[   666.889] Kernel command line: pmedia=usbflash  pfix=fsck radeon.modeset=0
[   667.023] (II) [KMS] drm report modesetting isn't supported.
[   667.023] (==) Matched modesetting as autoconfigured driver 1
[   667.151] (II) LoadModule: "modesetting"
[   667.151] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[   667.175] (II) Module modesetting: vendor="X.Org Foundation"
[   667.204] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[   667.204] (II) [KMS] drm report modesetting isn't supported.
[   667.204] (WW) Falling back to old probe method for modesetting
[   667.234] (II) UnloadModule: "modesetting"
#

Trying the modeline suggestions gives the following:

# xrandr --addmode default "1280x800_60.00" --gamma 1:1:1
xrandr: --gamma must be used after --output
Try 'xrandr --help' for more information.
# xrandr --newmode "1280x800_60.00" 68.90 1280 1301 1333 1408 800 804 808 816 \-hsync \-vsync --gamma 1:1:1
xrandr: unrecognized option '1:1:1'
Try 'xrandr --help' for more information.
#

Interesting, disabling kms gives you 1 more vesa mode.
Though the vert refresh rates are about 75hz. Flat screens usually prefer about 60hz.

According to xrandr --help, --gamma is an option for --output, which is why I put it on the --output line. I didn't think it would work on the --addmode line. And it doesn't.

When you run the scripts, does it seem to be trying to change the resolution? For example, does the screen go black for 5 seconds or so?

The standard advice is that newer Pups work better with newer hardware, and older Pups work better with older hardware.

It would be nice to find a way to add a modeline that matches the native resolution of the monitor, for anyone in a similar situation (older hardware and a newer Puppy.)

Xorg is using the vesa driver, so a modeline added to xrandr might not work but it might work added to xorg.conf with the ati driver.

@williams2

williams2 wrote: ↑Wed Jul 21, 2021 8:50 pm

When you run the scripts, does it seem to be trying to change the resolution? For example, does the screen go black for 5 seconds or so?

No, no change, no black screen.

williams2 wrote: ↑Wed Jul 21, 2021 8:50 pm

The standard advice is that newer Pups work better with newer hardware, and older Pups work better with older hardware.

That sounds reasonable, however the FocalPup32 that I have choosen for continuous testing was uploaded on 24-June-2021, so it's not particularly old, but handles the screen resolution without any problems. Some of the others I tested are also fairly new. BionicPup32 is the only one of the 9 that acts this way.

williams2 wrote: ↑Wed Jul 21, 2021 8:50 pm

Xorg is using the vesa driver, so a modeline added to xrandr might not work but it might work added to xorg.conf with the ati driver.

Does this mean editing the existing xorg.conf file?