[Announce] advanced-systemui (ASUI) - Page 22 - maemo.org

auouymous | # 211 | 2010-12-13, 14:04 | Report

Originally Posted by yukop4 View Post

would it be possible to have one box that could be solely configured by the user to link to any app or area as one chooses

A widget to launch a user-defined app? What do you mean by "area"?

mcow | # 212 | 2010-12-13, 15:59 | Report

Originally Posted by auouymous View Post

Could you elaborate? ASUI doesn't open when you press the power button? Are any menus open while you're trying to open ASUI? Is the ASUI service running?

I no longer have it installed. When I press the power button, there was no response: no ASUI window, no regular menu. I had no menus or even any apps running.

When turned off and the charger plugged in, at least twice it seemed to get to the point where the screen goes all white but no progress beyond that; at least once, it got to the point of ASUI's charging screen. Because of the latter, I assume the service was running. It could be that the CPU-hogging behavior you described earlier was responsible for not progressing beyond the white screen, and I just didn't wait long enough.

DataPath | # 213 | 2010-12-14, 16:57 | Report

Originally Posted by mcow View Post

I no longer have it installed. When I press the power button, there was no response: no ASUI window, no regular menu. I had no menus or even any apps running.

When turned off and the charger plugged in, at least twice it seemed to get to the point where the screen goes all white but no progress beyond that; at least once, it got to the point of ASUI's charging screen. Because of the latter, I assume the service was running. It could be that the CPU-hogging behavior you described earlier was responsible for not progressing beyond the white screen, and I just didn't wait long enough.

I had a similar experience, and consequently uninstalled it.

auouymous | # 214 | 2010-12-14, 23:15 | Report

advanced-systemui (0.4.3)

fix: all dbus method calls with return values were leaking memory (7kB/minute)
fix: the blank window will no longer open when a menu is open
fix: ASUI sleeps until system settles down after booting, keeps ASUI from using all cpu and memory
fix: disable pointer/keyboard grabbing and focus events in charging runlevel, fixes the crash
refactored battery state/percentage display code
refactored shutdown_in_progress code
removed continuous battery query when fully charged in the charging runlevel
removed service polling and most hardware polling in the charging runlevel
query battery idle time when shutting down to charging runlevel
replaced /etc/asui-svc:ASUI_CHARGING with a charging runlevel button on secondary widget page

Underlined entries are new since last test binary.

ASUI was receiving an endless stream of focus in/out events causing it to loop forever without updating (frozen clock and no active/idle battery time) the interface and finally crashing. It no longer listens for focus events and doesn't grab the pointer and keyboard so the problem should be fixed.

There is a new "charging runlevel" button on the secondary widget page. One red slash means ASUI will not appear in the boot charging runlevel but will when shutdown on the charger. A double red slash also keeps ASUI from appearing when shutting down on the charger.

You can remove the ASUI_CHARGING line and the two comment lines above it from /etc/asui-svc to reduce the size of that file.

The Following 2 Users Say Thank You to auouymous For This Useful Post:
maacruz, tso

tso | # 215 | 2010-12-15, 02:44 | Report

i am seeing a spike of cpu and then a seg fault here when trying to start asui after the latest update.

auouymous | # 216 | 2010-12-15, 04:11 | Report

Originally Posted by tso View Post

i am seeing a spike of cpu and then a seg fault here when trying to start asui after the latest update.

Can you reproduce it with the test binary and give me the output from /root/asui-debug-2 ?

Edit: Better yet, try out the new test binary which should finally fix the problem. If not, use the debug binary to generate the /root/asui-debug-2 file.

I was being greedy and grabbing both pointer and keyboard even though I only needed the keyboard to get the home key. Seems that grabbing the pointer causes an endless focus in/out loop.

Edit: @mcow and @DataPath, could one of you download the test binary and see if it fixes your problem?

Last edited by auouymous; 2010-12-15 at 07:30.

tso | # 217 | 2010-12-15, 11:19 | Report

hate to say it but i still got a crash.

Code:

[0]  DEBUG FILE READY
[0] [0.000000]  select() inf=1 time=2.000000 (0.1073870864)
[0] [1.031678]  wake from select()
[0] [1.031678]  any X events?
[0] [1.031678]  any dbus messages?
[0] [1.031678]  	YES
[0] [1.031678]  	dbus: wakeup
[0] [1.031678]  any dbus messages?
[0] [1.031678]  select() inf=1 time=2.000000 (0.1073870864)

thing is tho that this is after i had a 0.4.3 crash. Any chance that there was something stuck in dbus? after a reboot the test binary seems to behave ok.

hrmf, after closing down the test binary cleanly (at least as cleanly as a ctrl-c can be) and running -debug, i got a seg fault with much the same as above (just a bunch of "malloc in cpu_get_all_governors_callback()" between the first "select()" and "wake from select()"), and now -test also seg faults. Not at all sure what is going on here...

Last edited by tso; 2010-12-15 at 11:26.

auouymous | # 218 | 2010-12-15, 17:18 | Report

The [0] at the beginning of each line indicates there was a problem getting the runlevel. What does the runlevel command output? I've fixed a minor problem acquiring the runlevel if you came from the charging runlevel but it won't help with the crashing.

The "inf=1" after the select() means ASUI is not mapped or the screen is off so the select won't timeout and sleeps until X or dbus wakes it. This means it could be crashing in the dbus thread so I put up a new debug binary to log dbus signals and callbacks, could you run that and give me the output?

tso | # 219 | 2010-12-15, 20:11 | Report

Code:

[2] runlevel = N 2

[2] [0.000000]  [DBUS] thread starting...
[2] [0.000000]  [DBUS] filters ready
[2] [0.000000]  [DBUS] signal: com.nokia.bme.signal.charger_charging_off
[2] [0.000000]  [DBUS] callback: mce_get_display_callback
[2] [0.000000]  [DBUS] callback: mce_get_display_callback (visible = 1)
[2] [0.000000]  [DBUS] callback: mce_get_tklock_callback
[2] [0.000000]  [DBUS] callback: mce_get_flight_callback
[2] [0.000000]  [DBUS] signal: flush calls
[2] [0.000000]  [DBUS] callback: bme_get_max_callback
[2] [0.000000]  [DBUS] callback: bme_get_active_callback
[2] [0.000000]  [DBUS] callback: bluez_get_mode_callback

tso | # 220 | 2010-12-15, 20:13 | Report

ah, i had bluetooth set as visible.