Messages

46

Zaurus - pdaXrom / Swap File Problem

« on: October 03, 2006, 12:30:18 am »

As far as I know, you want to keep the file as small as you can. This will cause more RAM to be used (there is a larger amount of RAM available than swap, so more is available for use and will be used) and will wear on your card less. It will also decrease the effect on speed that swap has.

Once again, corrections are welcome.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142920\"][{POST_SNAPBACK}][/a][/div]

Actually, any modern OS should utilise swap correctly regardless. Often forcing programs to use RAM can degrade performance and proper use of swap/virtual mem is much better. It shouldn't put something needed fast on slow swap, but it will significantly increase the amount of available memory.

Now someone much more knowledgeable will come along and tell me I'm wrong

47

Zaurus - pdaXrom / Swap File Problem

« on: October 01, 2006, 10:37:49 pm »

Hmmmm - what have I done!

What I seem to have done is turn my entire sd card into a swap file.

So you have...

You did this:

Code: [Select]

# mkswap /dev/mmcda1
But this is what you should have done (and what the linked thread told you to):

Code: [Select]

# mkswap swapfile
So you've trashed everything on the card and you need to reformat the card as FAT again and try the file idea again... sorry...

Edit: Capn_Fish beat me to it!

48

Zaurus - pdaXrom / Gpe Pim Apps

« on: September 28, 2006, 11:50:22 pm »

Ya! It works! thanks!
I'm using /usr/bin/mpg123 instead of /usr/bin/play and an mp3 file instead of a wav file, but other that that I didn't change anything.

P.S. I think I fixed my time issue by using desertrat's script:
https://www.oesf.org/forums/index.php?showt...ndpost&p=137824
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142622\"][{POST_SNAPBACK}][/a][/div]

Cool - I think that desertrat's script implements one of my suggestions above - does this fix the suspend when resuming problem too?

This is why Linux suits me so well - don't even need to be able to program to fix broken apps!

49

Zaurus - pdaXrom / Gpe Pim Apps

« on: September 27, 2006, 06:34:04 pm »

Here is my rough wrapper script:

Code: [Select]

#!/bin/sh

CALENDAR_CMD=/usr/bin/gpe-calendar
ALERT_SND=/opt/kdepim-2.2.7/kdepim/korganizer/koalarm.wav
PLAY_CMD=/usr/bin/play
PLAY_REPEAT=3
REPEAT_PAUSE=3
AT_SPOOL=/var/spool/at
CALL_CALENDAR=$(pwd)/$0

$CALENDAR_CMD

COUNTER=1
ALERT_CMD="$PLAY_CMD $ALERT_SND"
while [ $COUNTER -lt $PLAY_REPEAT ]; do
        ALERT_CMD="$ALERT_CMD && sleep $REPEAT_PAUSE && $PLAY_CMD $ALERT_SND"
        let COUNTER=COUNTER+1
done

ATFILES=$(find $AT_SPOOL/ -name "*-0")
for FN in $ATFILES; do
        if [ -n "$(cat $FN | grep gpe-calendar)" ]; then
                AFN=$(echo $FN | awk '{ print substr($1,0,length($1)-2); }')
                echo "#!/bin/sh" > $AFN
                echo "" >> $AFN
                echo "export DISPLAY=:0" >> $AFN
                echo "$ALERT_CMD &> /dev/null &" >> $AFN
                echo "sleep 3" >> $AFN
                echo "$CALL_CALENDAR &> /dev/null &" >> $AFN
                echo "" >> $AFN
                echo 'rm -f $0' >> $AFN
                rm $FN
                chmod 755 $AFN
                echo >$AT_SPOOL/trigger
        fi
done
Just adjust the settings at top to suit yourself, and run this instead of gpe-calendar directly, and you have alarms!

What it does: runs gpe-calendar, then when finished, tidies up any atd scripts created (that are incomplete and won't work). It replaces these with ones that play a sound and open the calendar. Obviously you can change this to do something else if you prefer. Watch out as I discovered atd silently fails unless output is redirected and commands are disconnected (' &> /dev/null &' works every time).

Disclaimer: only tested with latest gpe-calendar in Xromer's feed (oldbetas), probably won't work with other versions, use at your own risk, etc. Although the worst that can happen is that alarms still don't work...  

Edit: added an extra sleep line which seems to help when running calendar on wakeup from suspend...

50

Zaurus - pdaXrom / Gpe Pim Apps

« on: September 27, 2006, 03:46:38 pm »

Before I read your post, I did a NAND restore, because uninstalling atd didn't help.

Do you have a copy of the at script before you edited it?
I'll consider trying your suggestion if you don't have a copy.
I may just have to be content without alarms.

Man... IMO pdaXrom needs a speedy PIM suite with working alarms (right out of the box), like Sharp, Cacko, and OZ. Just my 2 cents.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142453\"][{POST_SNAPBACK}][/a][/div]

My suggestions above are just an attempt to stop your suspend/resume problem.

The at script before I edited it is the default one that comes in the atd package (it's not a real program in the stripped down version, just a script to put files in the right directory). It turns out this isn't the problem anyway; gpe-calendar is definitely at fault as it doesn't even call at directly any more! It gets 99% of the way there, so I'm working on a script to wrap gpe-calendar - it just cleans up the atd spool files each time the calendar is closed (almost works, and guarantee I'll get it right soon).

If you wanted to go back to kopi (I don't, it's too slow) I believe there is a package in one of the contrib feeds that does a similar thing with atd scripts. I figure I may as well do the same thing with gpe-calendar as it'll be plenty reliable enough.

If we could convince Xromer to jump back to beta1/beta3 and recompile gpe-calendar so it works again, we would have a nice out of the box solution, as atd and gpe-calendar work nicely together. Please Xromer?

51

Zaurus - pdaXrom / Gpe Pim Apps

« on: September 26, 2006, 03:39:16 pm »

Thanks for the reply.

#1

Code: [Select]

ls -R /etc/apm

/etc/apm/resume.d:
100carfctl  110hwclock  110openbox

/etc/apm/scripts.d:
cardctl  hwclock  openbox  smbfs  template

/etc/apm/suspend.d:
110hwclock  500smbfs  900cardctl  910openbox

/etc/apm/wakeup.d:
readmeI'm new to working with apm, so please let me know if the above looks ok.

I installed gpe-calendar from the oldbeta's folder. Is this the one you speak of (without working alarms) or are you talking about the beta4 folder? Or are you saying that there are olfer copies (that have since been removed from the contrib feed) that have alarms working? Sorry I'm a little confused.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142341\"][{POST_SNAPBACK}][/a][/div]

As far as the working alarms go - do they? Mine don't, but I have just realised that it could be the changes I made to the 'at' script, so that might be my fault...

Suspend problems - earlier versions of pdaXrom (or some hardware versions?) had problems resuming from suspend with the time being wrong which stuffed everything up - when apm and atd are heavily time-reliant, we see why. I've never had a problem on my SL6000 though, so I don't use any of those fixes. Try one of two things:

1) Remove the 110hwclock (just make /etc/apm/scripts/hwclock not executable) so it doesn't try to set the time on suspend and resume - it can't because atd has the clock locked.

2) If the above doesn't work or your clock is suddenly wrong, try adding another script to stop atd on suspend and start it on resume. Have a look at the other scripts for an idea on how to do this (they're pretty basic).

52

Zaurus - pdaXrom / Gpe Pim Apps

« on: September 25, 2006, 07:34:08 pm »

I've done an:

Code: [Select]

ipgk install atd...because the alarm wasn't going off.
Now my pdaxrom beta 3 exhibits the tiresome power on -> screen flickers -> power off (on it's own).

My alarms go off now (without sound) if gpe-calendar is running in the background.

Questions:
#1: Is there an atd (that works with gpe-calendar) that doesn't cause this anoying power off issue?
#2: Sound was working in gpe-calendar but now is not. any clues?

thanks.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142291\"][{POST_SNAPBACK}][/a][/div]

1) I have never experienced issues with atd itself. The latest gpe-calendar seems to be broken (see above), but that's not related to this either. The only thing I can think of that would cause your problem would be any old apm scripts that are fighting with atd (e.g. with atd running sltime doesn't work because it can't access the rtc - check /etc/apm/ stuff)

Have you got a backup of the working gpe-calendar version? The new one is nicer, but without working alarms...

2) Sound is the domain of gpe-announce, which is only involved when using atd for alarms. The latest gpe-calendar has its own little inbuilt notification which doesn't seem to use sound at all (and as you've noticed, only works when gpe-calendar is running)

53

Zaurus - pdaXrom / Icewm, Power Management - Screen Still Shuts Off

« on: September 25, 2006, 04:11:52 pm »

Works beautifully :-)

That's it.

Thanks karlto!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142270\"][{POST_SNAPBACK}][/a][/div]

Don't thank me - pelrun came up with the correct answer!

Maybe the lightnpower.py applet should manage the screensaver too...?

54

Zaurus - pdaXrom / Gpe Pim Apps

« on: September 22, 2006, 10:16:27 pm »

I'm trying to get the gpe-pim apps working under pdaxrom Beta3. I've installed gpe-calendar and all of the dependencies that it installed automagically and asked for at run time. But when I try to run gpe-calendar it gives the error:
"error while loading shared libraries: libsqlite.so.0 can not open shared object file: no such file or directory"
Anyone have advice? grog?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142091\"][{POST_SNAPBACK}][/a][/div]

I think there are a couple of different versions of the sqlite package floating around and you need to get the correct one for gpe apps to work - they may even install side by side, but you'll definitely need the one from Xromer's feed.

55

Zaurus - pdaXrom / Icewm, Power Management - Screen Still Shuts Off

« on: September 20, 2006, 05:37:26 pm »

Hmm everything looks normal.  However when running top I did see the following three processes that seemed interesting.  I can't find anything else about them on the system, or even google for that matter (other than that they appear in some source code).

Anyone have any idea what these are?

battchrgon

battchrgoff

sharpsl_bat

Thanks,
Frank
[div align=\"right\"][a href=\"index.php?act=findpost&pid=141905\"][{POST_SNAPBACK}][/a][/div]

That's normal - these are kernel processes managing the apm stuff. They don't go into the userland area of power management.

As far as I know, the lightnpower.py applet is the only thing that is involved with the power management settings - what it says should stick.

56

Zaurus - pdaXrom / Problem With Inodes At The Boot Time. [solved]

« on: September 20, 2006, 03:57:31 pm »

Thanks, for the replies. Well, if my understanding is good:
- no problem with the hardware;
- nothing will be done by the system, except if there is too many errors.

I'm right or not ?

1) Yes, there is no problem with the hardware
2) Just to clarify, what you posted above didn't show any errors at all - it was just letting you know that everything it planned to do is now done

(although tune2fs gave an error because it's built for ext2 and you tried to use it on jffs2)

57

Zaurus - pdaXrom / Icewm, Power Management - Screen Still Shuts Off

« on: September 20, 2006, 03:50:10 pm »

Hi Karlto,

I am running lightandpower.py at startup with the A/C plugged in but even then the screen goes off after a few minutes.   In lightandpower.py I have the settings set for it to stay on indefinitely.

I'm thinking about using atd to constantly call lightandpower.py -loadandexit but that seems like overkill....

Again, I'm NOT running the IceWM apm applet or mb-applet-battery (or xscreensaver for that matter).  To me nothing should be turning the screen off...

Any other ideas?

Thanks,
Frank
[div align=\"right\"][a href=\"index.php?act=findpost&pid=141817\"][{POST_SNAPBACK}][/a][/div]

That's quite odd... I haven't any experience with iceWM, but I use xfce4 and have worked through power problems. Provided your saved settings (via the lightnpower applet) never turn the screen off, it should be fine. In my experience the settings stay the same after calling lightnpower.py until you call it the next time (no matter what changes happen in between). This seems ideal for your requirements; the battery applet wouldn't help if something else is interfering anyway, because it doesn't do anything unless you change power source (ditto for using atd to run the applet if it's on power anyway).

Have you timed it to see if it appears to be using the battery power settings or if it perhaps could be something else? Have you tried setting the battery settings to never turn off also?

Maybe check the apm scripts in /etc/apm to see if things are happening behind your back when suspending and resuming (or maybe add something here to make sure it works as you intend?)

58

Zaurus - pdaXrom / Icewm, Power Management - Screen Still Shuts Off

« on: September 19, 2006, 04:32:11 pm »

In order for the screen to stay on, you have several options:

1) Run '/usr/bin/lightnpower.py --loadandquit' while plugged in. This will change the settings to AC power mode. Note that this is (normally) done when you start X, so if it is plugged in then, AC mode will be set.

2) Run the battery applet which takes care of the above.

3) Change the settings for on battery in the lightnpower applet to the same as on AC.

Obviously with your various scripts when closing the lid etc you could build in something to do the right thing there too. The lightnpower applet keeps a simple text file with settings in ~/Choices/, which allows a much larger number of different settings simply by swapping the files over in a script and running the applet as in 1) above. (I use it to set an always on mode for listening to music on batteries for example)

59

Zaurus - pdaXrom / Problem With Inodes At The Boot Time. [solved]

« on: September 19, 2006, 03:45:15 pm »

Are these correctly unmounted at shutdown (especially the second one)?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=141743\"][{POST_SNAPBACK}][/a][/div]

No   , a HARD RESET was done... But I've the same message without the CF (/dev/hd2) or SD (/dev/mmcda1).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=141773\"][{POST_SNAPBACK}][/a][/div]

Sorry, disregard that comment - as pelrun said above, there is nothing wrong. The filesystem leaves all that stuff to clean up later to save too many writes to memory.

60

Zaurus - pdaXrom / How Do I Print To A Networked Printer?

« on: September 18, 2006, 10:56:06 pm »

I don't see anything obviously wrong with the cupsd.conf file. CUPS seems to be running OK (#.../cups status indicates that the scheduler is running). Any other ideas? You may want to note that I have almost no clue as to what to look for in the conf file. If you think there's something wrong with it, I can attach it.

Thanks for your help!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=141755\"][{POST_SNAPBACK}][/a][/div]

It should just work then...  

I guess you should see at least these lines in cupsd.conf:

Code: [Select]

Port 631and

Code: [Select]

Allow From 127.0.0.1The second one in particular is important, and contained in the security section at the bottom of the config file. I'm pretty sure the default settings are good though.

What you have now is not at all a pdaXrom-specific issue, so you could skim any cups documentation for some hints if we can't help you.