1.0.7a: update for xorgwizard

[BarryK]

For Pup 1.0.7alpha testers:

Download xorgwizard.gz and gunzip then place in /usr/sbin/.

This has various bugfixes.

1. should eliminate the bogus HorizSync line
2. dialog box with list of resolutions should now have more
accurate "card", "monitor", "supported" notation.
3. more fixes that I can't remember right now.

[Lobster]

Had to use MtoolsFM to gunzip (could not click to open)
then moved to sbin (did nothing to the file)
it warned me that I would be overwriting so I did
restarted jwm
started xserver wizard and clicked on xorg

Nothing happend?

[Guest]

Lobster,
get out of X (kill it, see Exit to prompt in Shutdown menu),
then type "xorgwizard"

[BarryK-not-logged-in]

That was me above.

Okay, just after posting the "fixed" xorgwizard, I read a email from Ed Jason. His /tmp/xorg.conf.new file is more screwed up.
He has a bogus HorizSync line, that is above the correct one, and the VertRefresh line is totally wrong.

So, the fixed xorgwizard is probably fixed for most cases, except for Ed.
Xorg's autoprobe comes up with bogus very large numbers.
...okay, I'll work on it this arvo.

In the meantime, can you guys who get bogus entries for HorizSync and VertRrefresh, especially Ed, try the attached programs.
Run them like this:

# get-edid | parse-edid

...let me know if they come up with correct HorizSync and
VertRefresh lines.

Umm, can't attach it to this msg as I'm not logged in.

[BarryK]

okay, here it is...

But, you only need this package if running 1.0.6., as 1.0.7a
has it already.

[Marv]

The modified Xorgwizard now gives the correct vert and horiz synch lines for my NEC LCD1512 on an ATI Rage Pro 128 PCI video card. My extra line was after the correct horizontal sync line before.

The get-id | parse-id programs also give the exact same and correct vert and horiz synch lines on this hardware.

Xorgwizard is still giving a line in the "Server Layout" section which results in an error.

The line follows the correct Screen 0 line and is:
Screen 1 "Screen1" Right Of "Screen0"

Leaving this line in results in an undefined Screen 1 error.
Tweaking it out works fine.

I don't think this is a bug. It may be due to the onboard video card being detected even though it is turned off in the bios.
I actually can output to both cards in Xorg and think if I learn a bit more about Xorg.conf I could set it up correctly as a dual monitor setup.

A friend looked at this system now running Xorg and said "You fixed it". 1.0.7 and Xorg is quite a combo.

Thanks

[BarryK]

The line follows the correct Screen 0 line and is:
Screen 1 "Screen1" Right Of "Screen0"

Leaving this line in results in an undefined Screen 1 error.
Tweaking it out works fine.

Marv,
Does X run though, with that line left in?

[Lobster]

Lobster,
get out of X (kill it, see Exit to prompt in Shutdown menu),
then type "xorgwizard"

for this I get:

-sh: xorgwizard: Permission denied

changed file to executible and was able to run but still getting massive line numbers for horizontal refresh (I think it is)

. . . so will now try the other suggestion/test . . .

here it is:

Code: Select all

# get-edid | parse-edid 
get-edid: get-edid version 1.4.1

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

        VBE version 300
        VBE string at 0xc0df0 "S3 Incorporated. Savage4"

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
parse-edid: parse-edid version 1.4.1
        Function supported
        Call successful

parse-edid: EDID checksum passed.

        # EDID version 1 revision 3
Section "Monitor"
        # Block type: 2:0 3:ff
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
        Identifier "LM-700"
        VendorName "AOC"
        ModelName "LM-700"
        # Block type: 2:0 3:ff
        # Block type: 2:0 3:fd
        HorizSync 30-80
        VertRefresh 55-75
        # Max dot clock (video bandwidth) 130 MHz
        # Block type: 2:0 3:fc
        # DPMS capabilities: Active off:yes  Suspend:no  Standby:no

        Mode    "1280x1024"     # vfreq 75.025Hz, hfreq 79.976kHz
                DotClock        135.000000
                HTimings        1280 1296 1440 1688
                VTimings        1024 1025 1028 1066
                Flags   "-HSync" "-VSync"
        EndMode
        # Block type: 2:0 3:ff
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
EndSection
# 

[Guest]

HorizSync 30-80
VertRefresh 55-75

Lobster, thanks for that report.
it looks like edid works well.

I'll work on xorgwizard tonight, will make it much better, plan to include easier option for people who may be intimidated by having to edit the xorg.conf file.

[GuestToo]

i just noticed, busybox's ash shell now has a history file (up/down arrow keys)

sorry, posted to the wrong thread

[Marv]

Marv,
Does X run though, with that line left in?

No, X will not start til I comment out that line.

[pakt]

Dell Inspiron 510m laptop with 852GM/855GM Chipset (i810 family)
External 17" TFT screen (1280x1024 native resolution)

Output extract from get-edid | parse-edid

• HorizSync 31-81
  VertRefresh 56-75
  # Max dot clock (video bandwidth) 140 MHz
  # Block type: 2:0 3:fc
  # DPMS capabilities: Active off:yes Suspend:yes Standby:yes
  
  Mode "1280x1024" # vfreq 60.020Hz, hfreq 63.981kHz
  DotClock 108.000000
  HTimings 1280 1328 1440 1688
  VTimings 1024 1025 1028 1066
  Flags "+HSync" "+VSync"
  EndMode
  Mode "640x350" # vfreq 70.072Hz, hfreq 31.462kHz
  DotClock 25.170000
  HTimings 640 656 752 800
  VTimings 350 387 389 449
  Flags "-HSync" "+VSync"
  EndMode

The screen section of xorg.conf now has correct setting: 1280x1024 at depth 16

Bugs in wizard left:

"testing X" gives (didn't get all text, only 40s to write it down):
Current Resolution: 1280x1024
Horz ... : nan KHz
Vert ... : nan Hz

then

"Report on X test: Refresh freq nan Hz, Success"

Also: That ~20 sec delay when rebooting is quite irritating. It follows this message:

"Shutting down PCMCIA services:"

Didn't have that delay in 1.0.6

[Flash - not logged in]

...That ~20 sec delay when rebooting is quite irritating. It follows this message:

"Shutting down PCMCIA services:"

Didn't have that delay in 1.0.6

So I'm not the only one to have this happen. Is there anything I can do to help figure out what's going on?

[BarryK]

...That ~20 sec delay when rebooting is quite irritating. It follows this message:

"Shutting down PCMCIA services:"

Didn't have that delay in 1.0.6

So I'm not the only one to have this happen. Is there anything I can do to help figure out what's going on?

At this stage, I haven't got a clue. I haven't changed anything to do with PCMCIA, but maybe one of the Busybox applets is behaving differently, maybe having some effect either in the startup code for pcmcia or the shutdown.
Startup: /etc/rc.d/rc.modules
Shutdown: /tmp/rc.reboot

You could try putting some "echo" lines into /tmp/rc.reboot, to find exactly what line it gets to before the delay occurs.
Note, /tmp/rc.reboot gets overwritten at next boot.

[pakt]

...That ~20 sec delay when rebooting is quite irritating. It follows this message:

"Shutting down PCMCIA services:"

Didn't have that delay in 1.0.6

So I'm not the only one to have this happen. Is there anything I can do to help figure out what's going on?

At this stage, I haven't got a clue. I haven't changed anything to do with PCMCIA, but maybe one of the Busybox applets is behaving differently, maybe having some effect either in the startup code for pcmcia or the shutdown.
Startup: /etc/rc.d/rc.modules
Shutdown: /tmp/rc.reboot

You could try putting some "echo" lines into /tmp/rc.reboot, to find exactly what line it gets to before the delay occurs.
Note, /tmp/rc.reboot gets overwritten at next boot.

Barry, I seem to have narrowed it down to this code in /tmp/rc.reboot:

• # Give cardmgr a few seconds to handle the signal
  for N in 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 ; do
  kill -0 $PID 2>/dev/null || break
  sleep 2
  done

"sleep 2" gets repeated 15 times!
Paul

[Flash]

I haven't had time to try this, but the last time I shut Puppy down I thought I noticed that there was no delay and the CD tray was open. I only run Puppy from the CD and I've been running Puppy 1.0.7(a) with boot option 4 for testing.

Edit: As usual, I was wrong. Still stops for ~30 seconds at pcmcia even with tray open.

[GuestToo]

knowing nothing about this other than a quick glance at the code:

Code: Select all

kill -0 $PID 2>/dev/null || break

it seems to me it should break out of the loop if kill succeeds, not if kill fails

should it be?:

Code: Select all

kill -0 $PID 2>/dev/null && break

[pakt]

should it be?:

Code: Select all

kill -0 $PID 2>/dev/null && break

Yes, that certainly made a difference. Now there is no noticeble delay.
Paul