Puppy Linux Discussion Forum

[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:

[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]

[jonyo]

Ya but then he might be messin with the boss!

[alienjeff]

"Ubuntu" repository?

[jonyo]

http://www.google.ca/search?q=mint+ubuntu+repository&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

[ttuuxxx]

[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.