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

Active Topics

Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 6 hrs, 59 mins ago
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 11 hrs ago
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 23 hrs ago
n770 youtube video (0)
to General by nmdv - 5 days, 22 hrs ago
more...

Page 22 of 105

Thread Tools

auouymous	2010-12-13 , 14:04
Posts: 875 \| Thanked: 918 times \| Joined on Sep 2010	#211

Originally Posted by yukop4

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"?

Quote & Reply |

mcow	2010-12-13 , 15:59
Posts: 86 \| Thanked: 8 times \| Joined on May 2010	#212

Originally Posted by auouymous

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.

Quote & Reply |

	DataPath	2010-12-14 , 16:57
	Posts: 124 \| Thanked: 34 times \| Joined on Mar 2007	#213

Originally Posted by mcow

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.

Quote & Reply |

auouymous	2010-12-14 , 23:15
Posts: 875 \| Thanked: 918 times \| Joined on Sep 2010	#214

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.

Quote & Reply |

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

	tso	2010-12-15 , 02:44
	Posts: 4,783 \| Thanked: 1,253 times \| Joined on Aug 2007 @ norway	#215

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

Quote & Reply |

auouymous	2010-12-15 , 04:11
Posts: 875 \| Thanked: 918 times \| Joined on Sep 2010	#216

Originally Posted by tso

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.

Quote & Reply |

	tso	2010-12-15 , 11:19
	Posts: 4,783 \| Thanked: 1,253 times \| Joined on Aug 2007 @ norway	#217

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...

__________________
Be warned, posts are often line of thoughts at highway speeds...

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

Quote & Reply |

auouymous	2010-12-15 , 17:18
Posts: 875 \| Thanked: 918 times \| Joined on Sep 2010	#218

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?

Quote & Reply |

	tso	2010-12-15 , 20:11
	Posts: 4,783 \| Thanked: 1,253 times \| Joined on Aug 2007 @ norway	#219

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