Chihuahua Alpha6 plus Lassie_Office

[HairyWill]

aj
You don't say what resolution you are trying to achieve?
I think that 3.0? worked with my 830m card at 1024x768 (native screen size), I think it was using the i810 driver. Dingo only works with the vesa driver. I think I've reported before that I got it working with the i810 or i830 driver. I am not currently able to reproduce that so I may have made a mistake.

Will

[prehistoric]

@alienjeff,

Just saw a comment in the readme.txt for Xorg pointing to 7 Sept 2007 as the fateful date when changes took place, with the change to Xorg 7.2. Part of the trouble here may be that programs like xvidtune were written for Xfree86 4.3. Licensing restrictions on Xfree 4.4 forced the change to Xorg even though most people were happy with Xfree.

What dates do you find on files in 2.17.1 and your last working X system? This could narrow the search.

[alienjeff]

@HairyWill

Attempted resolution: 1024x768x16 and/or x24

@prehistoric

Let me get my first cup of coffee down the hatch and I'll extract from 2.17.1 to get that info you want. Thanks!

[alienjeff]

Just saw a comment in the readme.txt for Xorg pointing to 7 Sept 2007 as the fateful date when changes took place, with the change to Xorg 7.2.

That date coincides with my historical forensic work:

Puppy 2.17.1 released Saturday, August 4, 2007, 02:44 AM

Puppy version 2.20-alpha available for testing Monday, September 3, 2007, 03:17 AM

Related excerpt from above:

"Xorg upgraded to version 7.2
Tuesday, August 28, 2007, 11:02 PM
Well, there was I lot of messing around, but I got there. Slackware 12 has the Xorg package installed in the /usr path prefix, so it mingles with everything else, which I'm personally not entirely happy with. But, some Puppy scripts and perhaps some apps expect it to be in /usr/X11R7. I did try using the Slackware Xorg in it's default /usr location, but ran into many problems. So I relocated it in /usr/X11R7 and fixed various problems with Xorg not being able to find stuff by creating symlinks -- not many symlinks were needed. One example, is the Xorg server runs 'xkbcomp' at startup and looks for it in /usr/bin, and there does not seem to be anyway to tell the Xorg server to look for executables in /usr/X11R7/bin -- which is odd, as other paths, such as the path to the modules, can be specified. Anyway, a symlink fixed it."


Puppy 3.00 BETA with 2.6.18.1 kernel Sunday, September 16, 2007, 11:35 PM

Puppy 3.00 released Tuesday, October 2, 2007, 11:07 AM - > Xorg 7.2 mentioned in release notes summary

What dates do you find on files in 2.17.1 and your last working X system? This could narrow the search.

Puppy v2.17.1 is the last version with a working X system on this box. I'm not certain exactly which files you're referring to, so until I hear from you, I offer this:

/usr/X11R7/bin/xvidtune 39K 13:03:58 10 Sep 2003

/urr/X11R7/bin/xorgconfig 47K 17:41:23 07 Aug 2006

The only files in this directory with 2007 dates are xwin, startx (symbolic link to xwin); and xterm (symbolic link to /usr/bin/xterm).

-aj

[prehistoric]

@alienjeff,

Excellent! I had misunderstood, thinking that 2.17.1 did not work, because you were using 2.12. This pinpoints the changes. I've kept 2.17.1 around, because it was reliable.

[prehistoric]

@jonyo,

Oh, damn, I've just put another dent in my forehead. While reading .xinitrc to find the cause of other video problems, I suddenly realized no one had asked you if you had checked for a file /etc/mousehide. I now think your mouse cursor times out and gets hidden when you leave the machine alone for some time. You might also look at the mouse wizard to see if the autohide box is checked. A bug in that code could have the effect of a more serious bug in the video driver.

[jonyo]

Didn't check it out yet (forgot about it) but it came up when I had the prob in 2.15 & all was set ok.

[prehistoric]

@tronkel, ttuuxxx,

Here are some files which have worked to solve the problems I've experienced on exits from the X window system on two problem machines. It also works on at least one machine w/o the problem, but needs more testing.

I have deliberately made this a tar.gz instead of something easier to use, to keep people from applying it indiscriminately. You will know where the scripts I've altered belong.

The hangs and black/frozen screens on exit from X were caused by subtle concurrency problems with scripts for starting and stopping X. I have moved the "killall -9 X" to the beginning of xwin, to make sure we have only one set of X processes running at a time. Ditto, the syncs which should be used for every change to a file used to communicate between processes. Both xwin and .xinitrc now perform a sync before they use any files.

I've rewritten some code at the end of xwin, simply because I wasn't sure I could tell exactly what it was doing. This may not be necessary, but I can understand it better.

I'm still not sure about all the purposes xwin is used for. This could break something elsewhere.

This doesn't solve all concurrency problems I've detected. Strange things can still happen at WM startup. There are also cases where Icewm has unreasonable delays on bringing up the main menu, or shows an incomplete main menu. The processes for essential functions of the WM itself should run at with higher priority than various tasks spawned by the WM. It may also help to set the "sticky" bit on some files and programs.

However, I hope this is the end of the show stoppers.

Added: I've updated the xfix.tar.gz. One change was not needed and another small change in xwin gets rid of a potential problem. I've also tried corresponding changes in the scripts for NOP 3.01r6 and Muppy 008.3b, without any obvious disasters.
Note: the first time you run xwin after changing scripts you may see a message caused by leftover files or variables from the previous version. After that it should run without error messages, but, remember, this is still experimental.

prehistoric

[prehistoric]

Just wanted to notify tronkel and ttuuxxx that the previous post has been edited and the attached hack has been changed.

[prehistoric]

@tronkel, ttuuxxx,

After the issues with X were resolved, it was simple to find where our startup concurrency problems originate. The line in .xinitrc which launches conky:

Code: Select all

exec conky -d &

Creates a concurrent process. Icewm assumes it controls all these. Solution: remove that line and launch conky from the Startup folder.

Code: Select all

#!/bin/sh
# autostart system monitor display, choose at most one.

exec conky -d
#exec gkrellm

I've named this sysmon.sh and made it executable.

Conky was set up with an interval of 5 seconds on this 350 MHz machine. Even here I can tolerate an interval of 0.5 seconds. (Is that what was intended above?)

I tried an interval of 0.25 seconds, which works, but consumes about 1/3 of CPU cycles. On slower machines this would be a problem. Using gkrellm, the overhead is almost negligible.

If conky runs with double buffering, the distraction from blinking is tolerable. When using xvesa, which doesn't support double buffering, on a slow machine it is awful.

I have restarted X repeatedly on this slow machine without getting that pile up of icons or weird problems with window labels. This appears to eliminate the biggest of our concurrency problems.

Added: When I went to try this fix on Muppy 083b, I found MU was ahead of me, (if only I had known). He also launches HotPup and the Icewm desklets this way, keeping them under the control of Icewm.

[prehistoric]

I now think I know why people had not been reporting this problem, even though I was able to reproduce it on two machines and four puplets. If you succeed in configuring X on the first try you are generally O.K. If you try something and fail, and then try again without rebooting, you may have more than one X launched.

It's hard to see how this happens; the logic of xwin is convoluted. My solution was to kill any running X processes whenever you enter xwin, to make absolutely sure you never launch two. Because the cause was at the beginning of a session and the symptoms don't show up until you exit it was hard to get meaningful bug reports.

For someone like AJ, who has been having ongoing struggles with video, this kind of mess could kill interest in recent releases. For newcomers to Puppy, a bad experience with video configuration could prevent them from coming to this forum to report problems and ask questions. Like the guy counting bullet holes in airplanes, the ones you don't see bias the results against reports of certain problems.

[prehistoric]

@jonyo,

The invisible cursor problem you saw was not specific to the 3.xx series. It turned up on 4.00, when I left it running for a couple of hours.

[tronkel]

@prehistoric

Thanks for all the hard work you're doing on bug-squashing.

I haven't had much chance in the last week to follow it all, due to visiting a Linux show here and installing Ubuntu on the wife's laptop. Puppy played its part here as well. That will get installed on the home partition as well - just in case Ubuntu decides to do naughties - something which I believe it is well capable of on occasions.

I'm not likely to get much time to work on Chihuahua until nearer the weekend. If you get the time, could you make a short summary of the things that you have found that work OK?

I'll then test and merge these items into Chihuahua for the next build.

[ttuuxxx]

@prehistoric

installing Ubuntu on the wife's laptop.build.

Shame Shame should of installed Linux "Mint" same stuff, way smaller, and looks way better, Plus has the Ubuntu repository

ttuuxxx

[jonyo]

Ya but then he might be messin with the boss!

[alienjeff]

"Ubuntu" repository?

[jonyo]

http://www.google.ca/search?q=mint+ubun ... =firefox-a

[ttuuxxx]

"Ubuntu" repository?

Linux Mint is based on Ubuntu and both distributions have a lot in common. Both distributions use the same software repositories. For instance, release 2.2 (“Bianca

[prehistoric]

@alienjeff,

Welcome back. While you were off, no doubt doing important things, I saw this thread appear. Is this relevant to your problem child? Would a similar hack affect results on Chihuahua?

[alienjeff]

@prehistoric
Thanks! I read that thread before, however it is based on i810 video working when running Puppy v3.xx, which in my case is not.

My new endeavor is/was to install Puppy to my HP Kayak: a nice box with dual-800 MHz processors and a gig of RAM! Yum! However, there isn't support for installing to SCSI, so I am left with teasing myself with booting from a Wake Up Pup floppy and USB stick. Grrr.

At least I have a box to test any new alphas/betas/RCs that may venture into the land of SCSI HD support.