Htc Universal

[Cagnulein]

after a test day and after 2 complete cycles of battery recharge i could say that i need an urgent script: something that after X minutes of inactivty suspends automatically the phone. How could i do this? crond? Ideas?

[p3t3r]

I have got that time problem as well.

And I have got a gprs/umts problem: I don't know how to authenticate, as my provider requires authentication.


BTW: I use JWM now as window manager and dillo as default browser (i have midori, minimo and icehamster as well, but they aren't that fast  ) and I think of building SIAG Office, as it has a small footprint and good features.

[This post was written on HTC Universal running Debian]

Datathief, question regarding time. Are you able to preserve system time between linux reboots?

I have to set the time via date and hwclock -w every reboot.

[datathief]

Datathief, question regarding time. Are you able to preserve system time between linux reboots?

I have to set the time via date and hwclock -w every reboot.

No, I don't know how to do this.  I don't reboot very often, though, so I haven't noticed the problem.  

When you reboot, does Windows Mobile have the correct time?  If it does, maybe we can access that information somehow.  Perhaps the modem knows the time (I've seen AT commands to query this  -  I'll look them up).

[datathief]

And I have got a gprs/umts problem: I don't know how to authenticate, as my provider requires authentication.

I think you need to add your username to the pppd command line (or /etc/ppp/options) and add the password to /etc/ppp/chap-secrets.

You can follow the instructions at http://www.xs4all.nl/~ernstagn/GPRS-HOWTO/GPRS-HOWTO-6.html  -  but use:

Code: [Select]

pty 'socat - tcp:127.0.0.1:1702'instead of

Code: [Select]

connect 'chat -f /etc/ppp/chat/gprs'and you don't need a chat script.

[datathief]

after a test day and after 2 complete cycles of battery recharge i could say that i need an urgent script: something that after X minutes of inactivty suspends automatically the phone. How could i do this? crond? Ideas?

Alright, here is a really simple bash script to do this.

Edit: Updated the script to work with the dash shell, which uses much less RAM than bash.

Edit2: Created a package, including scripts to make sure the phone doesn't suspend during a call.

[ShiroiKuma]

No, I don't know how to do this.  I don't reboot very often, though, so I haven't noticed the problem.  

Lucky you. I keep messing with X and end up doing lots of rebooting ( However, I've already set up a good security system, whereby I can mount the encrypted second partition on the SD, which mounts to home. Therefore even if the device gets stolen, none of your data is compromised.

When you reboot, does Windows Mobile have the correct time?  If it does, maybe we can access that information somehow.  Perhaps the modem knows the time (I've seen AT commands to query this  -  I'll look them up).

Yes, WM keeps the correct time. But perhaps it's as you say, since I've set the "automatically get time from network" or whatever that is...

[datathief]

Yes, WM keeps the correct time. But perhaps it's as you say, since I've set the "automatically get time from network" or whatever that is...

There's a command get the time from the modem, but it doesn't return the date.  

It's possible that we could create some awful hack, like:

• Write the date to a file
• Reboot
• Read date from file
• Retrieve time from modem

This would only work if you restart Linux on the same day you reboot...

[ShiroiKuma]

Regarding xserver-titchy installation, it really is much simpler than the way full of hacks seen on my page.

I'm currently experiencing difficulties with my X setup, so would like to reinstall it using xserver-titchy, however I'm worried about the inability to start X as a regular user. Is this really not a problem for anyone, or is there a workaround to start it as non-root? I've been trying various tidbits to get it going as regular user, but without xdm cannot, and with xdm the X don't start with a working touchscreen etc.

Anyone able to use xserver-titchy and startx as a regular user?

[ShiroiKuma]

It's possible that we could create some awful hack, like:

• Write the date to a file
• Reboot
• Read date from file
• Retrieve time from modem

This would only work if you restart Linux on the same day you reboot...

I think this is a workable approach, since you usually reboot on the same day. And if you can get the time from the modem, then that would be fine. Much better anyway than to set the datetime by hand every reboot.

[webdork]

Has anyone else been successful in getting icewm in landscape mode? Every time I change the screen +/- 90 degrees it crashes X

[datathief]

htcunid 0.9 is available.  Some bug fixes, and network and signal functions.  To get network info:

Code: [Select]

htcunid networkTo get a list of networks (you'll have to look the codes up somewhere):

Code: [Select]

htcunid network listTo connect to a specific network:

Code: [Select]

htcunid network
htcuni-autosuspend 0.3 is available.  Fixes a bug where multiple copies of the daemon could be started.

htcuni-keypress 0.1 is available.  Handles the backlight, power, etc. buttons, in X and console.

[ShiroiKuma]

htcuni-autosuspend 0.3 is available.  Fixes a bug where multiple copies of the daemon could be started.

I'm experience some issues of a moderately severe kind after installing and running htcuni-autosuspend, whereby after suspend if plugging in-out the AC adapter, the system wakes up half-way, to the suspend console, says a new USB device AC adapter was attached, then X need to be killed and the htcunid daemon stops responding and can't be restarted.

This even occurs when killing the autosuspend process before suspending by hand. I've seen some errors generated by the init.d htcuni-suspend daemon, but couldn't write them down, need to check what's going on.

Or it's potentially connected with swap. Should it be disabled before suspend and enabled afterwards? Didn't have suspend problems with it enabled before?

EDIT1: I think I've determined the problems are originated when suspend is initiated while disk activity is occurring. I've witnessed an instance of this while upgrading in aptitude. Therefore, the modification proposed in the following post is all the more needed. Obviously, you can stop the daemon by hand, but then if you forget, it leads to problems in critical cases like mine above.

EDIT2: Even when the suspend daemon is stopped, there are still random errors after some time associated with it or something hanging the htcunid. I've been able to log some error messages, I've gotten this a couple of times:
[div class=\'codetop\']CODE[/div][div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']htcuni:~# /etc/rcS.d/S99htcuni-autosuspend: line 21: 2187 Terminated
   setsid $DAEMON > /dev/null 2> /dev/null
/etc/rcS.d/S41htcunid: line 19:  2051 Illegal instruction    setsid $DAEMON > /dev/null 2> /dev/null[/div]

[ShiroiKuma]

I'd recommend few changes, my problems aside, to the autosuspend scripts.

There should be a conf file, where the user would set among others the following things:

Suspend delay while on battery, 0 for no suspend
Suspend delay while on AC, 0 for no suspend
Applications, which when running no suspend

This is similar to not suspending the phone while in a call, but there are times when there is no keyboard activity and you don't want to suspend. Mplayer playing being the obvious choice, however also for instance aptitude or agt-get running, i.e. you're upgrading the system or installing packages, you don't need suspend. I'm sure there's others, so the user should be able to select when not to suspend.

[datathief]

I'm experience some issues of a moderately severe kind after installing and running htcuni-autosuspend

I don't know what could be causing these problems.  I haven't experienced them.

The errors you quoted include references to setsid.  I moved to using setsid instead of start-stop-daemon because it's a simpler command  -  I can't imagine how it could be causing problems, but you could try:

Code: [Select]

sed -i "s/sedsid/start-stop-daemon --start --background --exec/" /etc/init.d/htcunid /etc/init.d/htcuni-autosuspendand restart both daemons.  If it helps, I'll make the same changes when I upload new versions.

[ShiroiKuma]

I don't know what could be causing these problems.  I haven't experienced them.

The errors you quoted include references to setsid.  I moved to using setsid instead of start-stop-daemon because it's a simpler command  -  I can't imagine how it could be causing problems, but you could try:

Code: [Select]

sed -i "s/sedsid/start-stop-daemon --start --background --exec/" /etc/init.d/htcunid /etc/init.d/htcuni-autosuspendand restart both daemons.  If it helps, I'll make the same changes when I upload new versions.

I'm gonna wait a while, maybe it was linked to the fact that I left the U compiling stuff while away, so will see.

I do get however the "Unknown Hz value" bug. Do you experience that too? Is it related with procps?