(old)Puppy Linux Discussion Forum

The new 2.13 test beta works fine if I don't leave my pup_save.3fs in, but of course then it's a matter of starting from scratch. I wouldn't want to do that.

But if I try to start with pup_save.3fs (yes it's a good one, and without the old zdrv.sfs), it goes through the whole thing of updating, integrating the existing config etc, but then says it could not determine the video and I would have to manually do that with xorgwizard, etc. From then on we go round and round and nothing I can try will start X.

(Actually, if I choose "fix" apparently X does start, but if I confirm that by ticking the checkbox within the timeout, it's back to the old round and round . .)

I had earlier upgraded from 2.11 to 2.12 without incident. Maybe it doesn't like something in my config file, but 2.12 likes it fine.

Henry

Maybe you should have posted this in the Bugs section,

I don't understand what you mean by "round and round".
You chose "Fix" button and it worked ...what happened after that?

Good morning, Barry,

Happy Christmas eve. Trust you will take a bit of a holiday.

What I meant by round and round: Each time I entered xwin it said X did not start and I should try the xorg wizard or reboot or shutdown. If I selected fix, X would run (graphic screen) until I checking the confirming box, when I was again told X did not start, etc.

It's certainly beyond me. I went through this many times, checking md5, testing that the pup_sav.3fs used was good with 2.12, trying different resolutions, etc. I have used various versions of puppy (and muppy) without ever having a start problem.

I'll try this - I have a dozen or so previous configuration files. I'll try one or two of those and pass you the results (after Christmas

I'm very happy with and impressed with your puppy, using 2.12 daily, promoting it on my web site.

Kind regards,
Henry

To confirm:

I tried an earlier configuration - no change.

I reburnt the (md5 checked) iso - no change.

After failing to start and rebooting there is only the option to type xwin , not xorgwizard, over and over. (pup_save.3fs has obviously been modified.)

Henry

I tried 2.13 on a different computer. Same results.

Observation: 2.13beta does not work with any of mypup_sav.3fs files, all of which work with 2.12.

Note: These are 1G files. What is the limit on this?

Henry

Okay, after running Fix and seeing it work, you then go to the end of
the Wizard and exit. Before typing 'xwin', have a look at /etc/X11/xorg.conf, maybe something is obviously wrong with it, or, if you can't do that could you post it here for us to look at.

Here is what I see -

Xorg Video Wizard completed. Type 'xwin' to start X...

# /etc/X11/xorg.conf

-sh: /etc/X11/xorg.conf: Permission denied

#

xorg.conf is a text file, just typing its name at the console won't do anything.
You could view it with the 'mp' text editor:
# mp /etc/X11/xorg.conf

You could also post the file to us, but some commandline knowledge
is required to do that.

The file I think you requested is attached.

Henry

Well, the file looks basically allright.
I take it that it's an older monitor? Do you normally run at 1024x768 or
800x600? It's currently set to the former, but you could easily use
'mp' to change that.

But, that shouldn't have prevented X from starting.
This line:
Driver "nv" #card0driver
Try changing "nv" to "vesa", let us know if that works.

If it fails, use 'mp' to look at /var/log/Xorg.0.log
-- somewhere probably toward the end should be the report on why
X didn't start.
-- well, you could try this first, before making any changes to xorg.conf.

Thanks, Barry,

Monitor Name Senergy 560
Manufacturer Princeton Graphic Systems
Manufacture Date Week 5, Year 2002
Serial Number LXCC0500219
Product ID PGS0100
Display Size 15.2" (31cm x 23cm)
Display Type Analog, RGB Colour
Supported Features Standby, Suspend, Active-Off

It only goes to1024x768, which I've always used.

I have never used xorg, always vesa. I tried both with 2.13

Also tried changing nv to vesa.

Looked at /var/log/Xorg.0.log, but was unsuccessful in saving it to send you. Got an empty file, wh.Xorg.0.logtest (appended test in save as to mark it.)
Will go back and try again, time permitting.

Henry

OK, I did it right this time. The file is attached.

Henry

First off, this is a pretty Puppy, as most teens are (yes, this Puppy version is a teeny, 13). And fast on my Celeron 400, too!

I also had a first-boot problem with Xorg. This monitor has always been OK with 800x600x24, but now with the default Xorg option, it fails (the screen is garbled). If I try 1024x768x16 or 800x600x16, same garbled result appears (though the appearance is different each time).

The xorg.conf in attached.

I was able to run X successfully with the "Fix"/Xvesa button. I will try booting with "puppy pfix=ram" to check.

Addition: Same result with "pfix=ram". I explored the "Xorg" after "Fix" and kept tweaking the frequencies. Initially, the refresh frequencies were too high for the 1024x768x16 that the script is using (hey, I never chose that initially - I went for 800x600x24!). It's using 85x68 frequencies for that resolution when it should be for lower resolution (like 800x600x16). So there lies the mismatch: the script is using a higher resolution for the correct frequencies (that are right for a lower resolution). With two more frequency tweaks, the screen finally got to display at 1024x768x16 and 60x48 frequency.

More addition - a suggestion: Label the "Fix" button as "Test", or "Test and Tweak"?

Thanks, Raffy,

I am happily using 2.12, and am only providing beta version feedback here. I guess my problem is not unique, and eventually it should be possible to use a valid existing configuration with a new version. 2.13 beta works fine by itself - it's just incompatible with my existing pup_sav.3fs(s).

I think my problem is somewhat different than what you described. Just for a college try I pasted your xorg.conf over mine but oserved no difference in outcome.

Henry

Hi, Henry,

It must be an xorgwizard problem, that is why I added my situation to this thread. The xorg.conf that I submitted is for debugging and not for you as possible solution.

Based on my repeated tests, I saw some xoorgwizard problem - it starts with 1024x768x16 resolution if I chose a resolution above 640x480. So X will fail as the associated frequencies are too high for the given resolution (1024x768x16).

Some better monitors of course can tolerate that situation. I wish that my monitor can tolerate it, too, but it can't. There are newer CRTs, but less capable than this one am using. So the xorgwizard script needs to correct some frequency (or resolution) setting.

That sounds, right. Here's looking forward to the next beta!

Henry

raffy,
I'm curious about one thing. Open a terminal and type "ddcprobe"
and find out what range it reports for vertical frequency.

Here it is, Barry.

Most monitors I encounter here (maybe rather old) can only do 800x600x24 at 72 Mhz. At 1024x768x16, most of them can deliver only at 60 Mhz.

Am no good at scripts, but perhaps the user can be given the chance to tweak frequencies upward so that s/he would be seeing something at once (at less frequency).

Thanks!

Okay, here is a "new and improved" xorgwizard script!
Copy it to /usr/sbin to replace the previous version.
Let me know if it improves the autodetection or not.