I modified the menu.lst, as instructed, changed the initrd.gz, and installed the .pet. I got a beautiful, blue splash on bootup. But then, as I surfed away, suddenly two pinkish/purplish images appeared on my screen on top of everything. They couldn't be put in the background. On inspection, I saw that they were bizarre copies of the splash screen, with poor resolution. I could only get rid of them by reversing what I had done: reinstating my original initrd file and uninstalling the .pet.
Is what I have described possible, or does the phenomenon lie deep in my psyche? I have an old Nvidia Riva128 video card that doesn't support Xorg, so I use VESA; I hope that's the problem.

I thought I removed Pebble. There now is no splash screen on bootup, but no text either. I guess I can live with that, but is there any way to get back to normal short of deleting my pup_save.2fs file and starting over?

My previous post said:"I thought I removed Pebble. There now is no splash screen on bootup, but no text either. I guess I can live with that, but is there any way to get back to normal short of deleting my pup_save.2fs file and starting over?"

Easy. I removed "vga=791" from the kernel line in menu.lst. Everything is now just as it was before the fatal Pebble experiment.

Sorry for my absence. As my location-blurb says (for now, will change tomorrow) I have been in "limbo" all summer. I'm now back at my grandma's house and will be moving back into my dorm/apartment tomorrow. Then I can visit the forum more regularly (but I do plan to cut back a lot from what I've been doing the last several years - less time reading forum == more time to code).

Anyways, no you weren't imagining things Dave. It sounds like maybe Pebble didn't shut down properly. If it continues running after X is started it will sometimes draw garbled stuff over the screen (if the resolution and colordepth match what you set the vga option to, it shouldn't be garbled, but will still cover everything up).

Either there is some flaw in my work that causes it to not shut down Pebble in certain situations, the .pet didn't install properly, or the files it installed were overwritten.

Or another possibility is that Pebble was somehow started again after you were up and running. Not sure how that would happen, but it's possible.

Sometime after I get unpacked and settled in, I'll take a look at my code. Probably one of the /etc/rc.d/ files I modified has a section which runs in parallel that I didn't notice, which has Pebble code in it, so that it can happen that X is already up and running and Pebble shut down when the Pebble line in that code is finally run, which would restart Pebble. That would fit with how you said you were already surfing when the colors appeared.

Another possibility is that your graphics card and/or Xvesa are just being weird. I don't think so though. An error on my part is much more likely._________________Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Hi pizzasgood, just too let you know, still issue in Pebble with various hardware. have tested it more thoroughly now, and seems to be different depending on what medium I boot from. Usb flash often the splash won't disappear to show me the dialogue asking for a password, though this is never a problem with my usb hard drive. On my main computer the splash doesn't disappear properly with passwords, however it has worked on other machines....

So not perfect, though it's still the default for TigerPup. Not sure how to trouble shoot it. Any ideas? It is a real bug, even if you've been unable to reproduce it.
~dinky

The only thing I can think of at this point is to figure out exactly which commands aren't working properly and why. That will probably take a while. I think the easiest way to do this would be for me to break up the init script so that it drops out to the commandline before trying to load a save file, then have separate scripts to load the file and to finish booting. Then I could give you a list of things to experiment with and check to see what's working.

I'll probably start on that on the weekend._________________Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Sorry about taking a week longer than I expected. I've been in too lousy of a mood to mess with this, since rebooting over and over gets really annoying.

Anyways, I started splitting it up, but I noticed an error. Turns out there's a race condition between the pebble script and pebble-daemon. What happens is the script tells the daemon to pause or stop, then continues on it's merry way. Usually (with my tests anyways) the daemon finishes stopping before the script clears the screen. But on the occasions it doesn't, the screen will be cleared and the daemon will still go through another cycle, painting the image over the screen again.

Everything works just fine, except for the residual pixels.

So I fixed that by having the daemon create a file to act as an "I'm done now" flag, and the script waits for that before continuing.

I don't know if this is what was causing the bugs you've been getting or not, so I built a standard 3.01 initrd.gz file for you to test. In case it isn't, I also built two versions with the init script broken into three pieces. The 'yeti' version runs normally until just before it would ask for the password to decrypt the save file. Then it pauses Pebble (which is what it usually does), saves a bunch of variables, and drops out to the commandline.

At this stage you shouldn't see any images. ps should show that pebble-daemon and worm are still running. If there is still an image, see if it refreshes after you run clear. If so, the daemon didn't pause. If not, it paused but the script didn't clear the screen properly.

If things don't seem to be working right, you can play around with some commands. I left some warnings down at the bottom of the page.

Once you're done fiddling, run exec loadsave to run the part of the script that loads the save file. When that's done it dumps you back at the command line so you can fiddle some more.

When ready to finish booting, run exec finishboot. That resumes the bootsplash and completes the boot process (actually, I'm not sure if I ever bothered letting it complete with this command so there's a chance it will fail, but that's not really the point). If you played with the bootsplash prior to this you should probably make sure it's running but paused before executing this.

The 'sasquatch' version does the same thing, but instead of pausing the bootsplash before dropping out it stops it instead. Likewise, it starts it rather than resumes it when you use exec finishboot.

When on the commandline you can play around with bootsplash pause, bootsplash resume, bootsplash stop, and bootsplash start. But try not to run the wrong one - if it's paused, you should only use resume. If it's stopped, you should only use start. If it's running, you should only use pause or stop. Otherwise it can do weird stuff. Also be careful not to use start within two or three seconds of stop, because when it uses stop it runs a small subprocess in parallel that sleeps for a second, then makes sure everything has been shut down and deleted properly. If you start it while this subprocess is running Bad Things happen. I'm pretty sure I triggered several kernel panics his way.

Something that may be worth looking at if the daemon doesn't pause is /tmp/pebble-pipe. That should be a pipe file. I believe that running stat on it should show something like this on the permissions:
Access: (0644/prw-r--r--)
If it's a normal text file it would show something like this:
Access: (0644/-rw-r--r--)
(the 'p' is missing)
If it's not a pipe we'll have to find out why not, but I'll figure that out when we get there.
If it [i]is[/b] a pipe but bootsplash pause doesn't work, something is probably wrong with the script. Try this command to manually tell the daemon to pause:
echo 'p' > /tmp/pebble-pipe
Then you should be able to use clear to clear the screen and it shouldn't be repainted.

If that doesn't work, then probably the problem is in the daemon itself.

If the above stuff doesn't work to pause the daemon, then check if stopping it works. It should, because if the normal method it uses (sending a 'q' into the pipe) fails to work it will killall pebble-daemon which should almost certainly stop it.

Wow, awesome work pizzasgood. I won't have time to test it for a few days, but will get back to you when I do. one other thing. i notice that having Pebble enabled slows down my eeepc booting by 24 seconds... any thoughts on this? Haven't tiimed it on my desktop pc yet. I'm trying to get the eeepc booting as fast as possible in the version I'm building from unleashed, so it would be good to have it faster. Cheers,
~dinky

Well, an install that happened to use Pebble did seem to boot slowly, but I attributed that to it being a very old and heavily modified install. I also know that there were unresolved errors somewhere inside that save file. So it could have been anything.

I haven't noticed a slowdown on any other system using Pebble, but I never looked for one either. I'll play around with it this weekend and see how much effect it has. Shouldn't be much though, unless being run at a high speed on a slow computer.

Try switching the theme from paw_fade to paw, which would use a lower framerate (5 vs. 20). This can be done by editing /etc/pebble/theme in the initial ramdisk. You could modify the 'fps' line in /etc/pebble/<theme>/theme.conf instead, to set any framerate you want.

Oh, and I think I forgot to mention that when you're testing Pebble, it might make things easier if you set your framebuffer resolution to something higher than 640x480, because then if you drop out to the commandline without Pebble stopping/pausing, the entire screen won't keep getting overwritten as you try to type stuff. Only the center 640x480 pixels._________________Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

I get roughly a two-second difference in 4.00. P4 3.0gHz._________________Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Thanks matey, still working on it. no chance to test it out yet. really busy with my work, and my wife's due with our next baby in a bout a week...lol. Will let you know when I'm able to play around with it.
~dinky

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum