Saluki

[Karl Godt]

First impression is that the difference is one mount less in the "return to X-Desktop" mount output .

This could indicate, that the part to unmount stray partitions once did run, and detecting a zombie process killed the parent of the zombie ...

So this might occur randomly, with one Puppy 511 and one racy-5.x i have jwm zombies .. probably by the jwm -restart|-reload command(s) that killing would normally not affect X, pup_event_frontend_d, delayedrun, xinitrc and that likes anymore because they should have been killed already by /usr/bin/wmreboot||/usr/bin/wmpoweroff ...

since the removal of /tmp directory occurs just before umount ing the stray partitions ..

and yes, i have confused Pupmode 6 and 7 ..

it might be, that somehow gettext or eval_gettext could have left a zombie process, maybe because of a typo ..

[mavrothal]

It would appear that retrovol-saluki is broken in 020+. Specifically the icon does not show in the tray, though it works fine (eg responds to right-click etc).
Maybe related to the recent icon dir changes?
Any symlink that could solve this?
BTW where is the source? Barry's source for 0.10 and 0.12 does not compile (without "magic") in 021.

[Marv]

It would appear that retrovol-saluki is broken in 020+. Specifically the icon does not show in the tray, though it works fine (eg responds to right-click etc).
Maybe related to the recent icon dir changes?
Any symlink that could solve this?

I had the same problem starting roughly around 020. Removing the Saluki Retrovol and installing retrovol-Lucid-0.5 ( I believe from the repository) got me back the icon and all works fine.

[jakfish]

I'm trying out luki 021 on a Lenovo S10-3t netbook/tablet.

Looks like a great success (incredibly fast shut down, for starters), but before I get to all the good things, I'm having trouble with xorg.conf and the Lenovo touch screen.

I have a working xorg in dpup exprimo which allows initial calibration and touch screen driver setup (which is needed before using calibration tool):

Section "ServerLayout"
InputDevice "Synaptics Mouse" "AlwaysCore" #serverlayoutsynaptics
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "touchscreen" "SendCoreEvents"
EndSection

Section "InputDevice"
Identifier "touchscreen"
Driver "evtouch"
Option "Device" "/dev/input/event10"
Option "DeviceName" "touchscreen"
Option "MinX" "80"
Option "MinY" "80"
Option "MaxX" "4095"
Option "MaxY" "4095"
Option "ReportingMode" "Raw"
#Option "MaxTapTime" "220"
#Option "MaxTapMove" "220"
#Option "moving_action" "down"
#Option "moving_button" "1"
#Option "maybetapped_action" "click"
#Option "maybetapped_button" "3"
# Option "longtouched_action" "click"
# Option "longtouched_button" "3"
# Option "touched_action" "click"
# Option "touched_button" "1"
Option "Emulate3Buttons"
Option "Emulate3Timeout" "50"
Option "SendCoreEvents" "On"
EndSection

I've put the above in xorg.conf and I don't believe xorg is reading it upon reboot or X restart.

I do the modprobe hid-multitouch, modprobe evdev in rc.local, and while those commands give me a touchscreen, I'm unable to get calibration or any other of the touch commands that an edited xorg should give me.

Jake

[jemimah]

First impression is that the difference is one mount less in the "return to X-Desktop" mount output .

This could indicate, that the part to unmount stray partitions once did run, and detecting a zombie process killed the parent of the zombie ...

So this might occur randomly, with one Puppy 511 and one racy-5.x i have jwm zombies .. probably by the jwm -restart|-reload command(s) that killing would normally not affect X, pup_event_frontend_d, delayedrun, xinitrc and that likes anymore because they should have been killed already by /usr/bin/wmreboot||/usr/bin/wmpoweroff ...

since the removal of /tmp directory occurs just before umount ing the stray partitions ..

and yes, i have confused Pupmode 6 and 7 ..

it might be, that somehow gettext or eval_gettext could have left a zombie process, maybe because of a typo ..

This is good detective work.

The question is, why are we getting these reports now. It must be something that changed recently or it could be a coincidence I guess.

Here is the relevant section of the diff:

Code: Select all

 killzombies() {
  #ZOMBIES="`ps -H -A | grep '<defunct>' | sed -e 's/  /|/g' | grep -v '|||' | cut -f 1 -d ' ' | tr '\n' ' '`"
- ZOMBIES="`ps -H -A | grep '<defunct>' | sed 's/^[[:blank:]]*//g' | grep -v '|||' | cut -f 1 -d ' ' | tr '\n' ' '`" #120103 karl godt: because i was getting a bunch of "killall no such process must be either pid or name" on the screen by the killzombies function.
+ #ZOMBIES="`ps -H -A | grep '<defunct>' | sed 's/^[[:blank:]]*//g' | grep -v '|||' | cut -f 1 -d ' ' | tr '\n' ' '`" #120103 karl godt: because i was getting a bunch of "killall no such process must be either pid or name" on the screen by the killzombies function.
+ ZOMBIES="`ps -H -A | grep '<defunct>' | sed 's/^[[:blank:]]*//g' | cut -f 1 -d ' ' | sort -gr | tr '\n' ' '`" #120129 karl godt: improved, see http://www.murga-linux.com/puppy/viewtopic.php?t=73122
  for ONEZOMBIE in $ZOMBIES
  do
   echo "Killing parentless zombie process $ONEZOMBIE"
   kill $ONEZOMBIE
  done
 }

Should I roll the zombie killing code back?

[jemimah]

I'm trying out luki 021 on a Lenovo S10-3t netbook/tablet.

Looks like a great success (incredibly fast shut down, for starters), but before I get to all the good things, I'm having trouble with xorg.conf and the Lenovo touch screen.

I have a working xorg in dpup exprimo which allows initial calibration and touch screen driver setup (which is needed before using calibration tool):

Section "ServerLayout"
InputDevice "Synaptics Mouse" "AlwaysCore" #serverlayoutsynaptics
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "touchscreen" "SendCoreEvents"
EndSection

Section "InputDevice"
Identifier "touchscreen"
Driver "evtouch"
Option "Device" "/dev/input/event10"
Option "DeviceName" "touchscreen"
Option "MinX" "80"
Option "MinY" "80"
Option "MaxX" "4095"
Option "MaxY" "4095"
Option "ReportingMode" "Raw"
#Option "MaxTapTime" "220"
#Option "MaxTapMove" "220"
#Option "moving_action" "down"
#Option "moving_button" "1"
#Option "maybetapped_action" "click"
#Option "maybetapped_button" "3"
# Option "longtouched_action" "click"
# Option "longtouched_button" "3"
# Option "touched_action" "click"
# Option "touched_button" "1"
Option "Emulate3Buttons"
Option "Emulate3Timeout" "50"
Option "SendCoreEvents" "On"
EndSection

I've put the above in xorg.conf and I don't believe xorg is reading it upon reboot or X restart.

I do the modprobe hid-multitouch, modprobe evdev in rc.local, and while those commands give me a touchscreen, I'm unable to get calibration or any other of the touch commands that an edited xorg should give me.

Jake

If you could, run Sysinfo from the System menu and post the results.

[jemimah]

It would appear that retrovol-saluki is broken in 020+. Specifically the icon does not show in the tray, though it works fine (eg responds to right-click etc).
Maybe related to the recent icon dir changes?
Any symlink that could solve this?
BTW where is the source? Barry's source for 0.10 and 0.12 does not compile (without "magic") in 021.

I've fixed retrovol in the repo.

[jakfish]

Thanks for your quick response, jemimah. Attached is the sysinfo.

[jemimah]

Thanks for your quick response, jemimah. Attached is the sysinfo.

The reason it fails is that the evtouch driver is not there. I tried building it but it won't build against this version of xorg. I get the impression you are supposed to use the "evdev" driver instead. I'm not sure how different the syntax for evdev is.

[jakfish]

Hi, jemimah,

Thanks again for a speedy response. Odd, I'm just trying to replicate my successful steps in dpup exprimo. Is Saluki using a different xorg than pemasu's dpups?

As for the evdev name, again, I was just following steps that I found from googling the S10-3t and Linux (especially the remastered snowpup and cando driver thread in the puppy forum).

Jake

[jemimah]

Saluki has Xorg 7.6 - Debian Squeeze is Xorg 7.5, I believe.

Recent versions of Ubuntu don't have the evtouch driver either.

[jakfish]

In dpup exprimo, I find:

/usr/lib/xorg/modules/input/evtouch_drv.so

Can we assume that is not anywhere in saluki? I wish I knew of an alternative driiver, but I'm too new to this touchscreen stuff.


Jake

[Sage]

This is good detective work.

Yes that has to be the conclusion if both rc.shutdown & rc.shutdown.pupdev are text files, and one works, but the other doesn't.

The question is, why are we getting these reports now. It must be something that changed recently or it could be a coincidence I guess.

Looking down the thread a little, the comment 'shutdown is incredibly fast', which I notice using rc.shutdown.pupdev, and earlier comments about timing seem to be self-consistent.

Strange that a couple of pages back, myself and a couple of other (non-coding users?) were being branded as basket cases and labelled with inappropriate acronyms! As PD observes 'it goes with the territory'. One needs clever coders and a plethora of bog std. users to pick up these bizarre events. My earlier comments about not releasing to gold until polish was gleaming were never intended as a personal snub. Check my previous comments about our beloved instigator, even back as far as Pupeee and my personal accolades by way of nickname, we all think she's wonderful. Code writing and debugging is no different to any other branch of scientific research and development - painful, extended, sometimes subject to disbelief, even ridicule, but it generally all comes out smelling of roses in the fullness of time. Just need to keep going...

[jakfish]

In dpup exprimo, I find:

/usr/lib/xorg/modules/input/evtouch_drv.so

Can we assume that is not anywhere in saluki? I wish I knew of an alternative driiver, but I'm too new to this touchscreen stuff.

Jake

[jemimah]

In dpup exprimo, I find:

/usr/lib/xorg/modules/input/evtouch_drv.so

Can we assume that is not anywhere in saluki? I wish I knew of an alternative driiver, but I'm too new to this touchscreen stuff.

Jake

The alternative driver is evdev. The documentation is here:
http://www.x.org/releases/X11R7.6/doc/m ... ev.4.xhtml

It should be pretty similar.

[jemimah]

If you want to be taken seriously - it's best to avoid ranting, trolling, and posting flamebait. Bug reports carry no weight from people whom I question their sanity.

This is good detective work.

Yes that has to be the conclusion if both rc.shutdown & rc.shutdown.pupdev are text files, and one works, but the other doesn't.

The question is, why are we getting these reports now. It must be something that changed recently or it could be a coincidence I guess.

Looking down the thread a little, the comment 'shutdown is incredibly fast', which I notice using rc.shutdown.pupdev, and earlier comments about timing seem to be self-consistent.

Strange that a couple of pages back, myself and a couple of other (non-coding users?) were being branded as basket cases and labelled with inappropriate acronyms! As PD observes 'it goes with the territory'. One needs clever coders and a plethora of bog std. users to pick up these bizarre events. My earlier comments about not releasing to gold until polish was gleaming were never intended as a personal snub. Check my previous comments about our beloved instigator, even back as far as Pupeee and my personal accolades by way of nickname, we all think she's wonderful. Code writing and debugging is no different to any other branch of scientific research and development - painful, extended, sometimes subject to disbelief, even ridicule, but it generally all comes out smelling of roses in the fullness of time. Just need to keep going...

[Sage]

Apology accepted!

[shinobar]

Well, I reproduced the greengeek's case (USB flash install, save the session to the partition). Used the firstrun-debug-shutdown, and foud that the rc.shutdown kills its parent 'reboot'(or 'poweroff') and itself at the last stage. I don't know why, but maybe woof bug. It occurs PUPMODE=7 on saluki-21 but maybe all recent Puppies. I don't know about PUPMODE=6 (save the session in the internal HDD partition). I am not sure if it is related with PUPMODE=2 (Sage's case).
I also suspect that similar case can occur under PUPMODE=5 and/or under other cases, somewhere in the script rc.shutdown.

I think PUPMODE=7 is special case. But similar problem may occur under other mode by chance.
Now I suspect the code 'fuser -k' and the equivalent code. Hopefully i will offer its fix in a couple of days.

[jakfish]

As usual, jemimah, you did it. Replacing evtouch with evdev in xorg.conf does the trick.

The touchscreen does need more calibration, so I've installed the pet xinput_calibrator. Installs fine, but:

xinput_calibrator: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by xinput_calibrator)

I looked through this thread and saw that a Bible program also needed this lib. I haven't yet found it--any place in particular I should look?

Thanks again for the evdev/evtouch help,
Jake

[jim3630]

Strange that a couple of pages back, myself and a couple of other (non-coding users?) were being branded as basket cases and labelled with inappropriate acronyms! As PD observes 'it goes with the territory'...

read again... it was just you. don't flatter yourself your not in the same territory as PD.

others worked with shinobar and Karl but you played dumb
and would not work with shinobar who just 4 posts before yours posted a pet tool.

http://murga-linux.com/puppy/viewtopic. ... 793#623793

-------

"apology accepted" what world are you in?