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

Active Topics

TLS 1.2 for N9 is ready (29)
to MeeGo / Harmattan by smatkovi - 7 hrs, 12 mins ago
Error after installing Leste on sdcard (12)
to Maemo 7 / Leste by teroyk - 7 hrs, 59 mins ago
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 3 days, 16 hrs ago
Maemo repository (3)
to Community by torsen - 4 days, 9 hrs ago
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 6 days, 13 hrs ago
more...

Page 32 of 105

Thread Tools

	tso	2011-02-04 , 09:26
	Posts: 4,783 \| Thanked: 1,253 times \| Joined on Aug 2007 @ norway	#311

works fine on this N800 now

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

Quote & Reply |

mcow	2011-02-04 , 19:03
Posts: 86 \| Thanked: 8 times \| Joined on May 2010	#312

I've never used the Lock function. I'm not sure if I ever set the unlocking code number. In the Lock control panel, trying to change the code prompts for the current code, but the number I should have used is not accepted.

I am running with the SSU, which I think means it's been reflashed - would that have cleared a previous unlocking code? I definitely have not set a code since installing the SSU.

The Nokia help says "If you have not set the lock code, you are asked to do so" -- does ASUI's Lock feature do the same?

I'm also curious if all the recent research on dsme, mce and dbus has maybe possibly revealed a way to force the screen to go blank while charging with "never blank while charging" is set.

Quote & Reply |

auouymous	2011-02-04 , 19:36
Posts: 875 \| Thanked: 918 times \| Joined on Sep 2010	#313

I've never used the Lock function. I'm not sure if I ever set the unlocking code number. In the Lock control panel, trying to change the code prompts for the current code, but the number I should have used is not accepted.

I am running with the SSU, which I think means it's been reflashed - would that have cleared a previous unlocking code? I definitely have not set a code since installing the SSU.

The unlock code is only changed when you change it in the control panel, flashing never resets it. Have you tried 12345? You could also search for the getlockcode program on these forums to find out your code.

The Nokia help says "If you have not set the lock code, you are asked to do so" -- does ASUI's Lock feature do the same?

The device always has a lock code, the default is 12345. ASUI just reads the lock code each time the keypad appears and then compares what you type with it.

I'm also curious if all the recent research on dsme, mce and dbus has maybe possibly revealed a way to force the screen to go blank while charging with "never blank while charging" is set.

Nope, I actually looked into that again yesterday.

Quote & Reply |

mcow	2011-02-04 , 22:20
Posts: 86 \| Thanked: 8 times \| Joined on May 2010	#314

Thanks, it was still at 12345.

Nope, I actually looked into [forcing the screen to go blank] again yesterday.

When you first looked in to this, you said something about not wanting to mess with user settings to control this. I think you meant, that you could dynamically change the stay-lit setting from "when charging" to "never".

Are you still uncomfortable with that approach? I could definitely live with it, myself; after all, if the setting somehow got left the wrong way, I could always change it back manually. I'm sure there are several paths from forced-blank state to lit state where that setting should be reset, but that ought to be manageable.

Quote & Reply |

auouymous	2011-02-05 , 02:38
Posts: 875 \| Thanked: 918 times \| Joined on Sep 2010	#315

I think you meant, that you could dynamically change the stay-lit setting from "when charging" to "never".

I could definitely live with it, myself; after all, if the setting somehow got left the wrong way, I could always change it back manually. I'm sure there are several paths from forced-blank state to lit state where that setting should be reset, but that ought to be manageable.

I could save the stay-lit-when-charging and autolock-screen settings, modify the system settings when using the lock button and restore when the screen comes back on. If ASUI crashes, it can check the saved settings and get itself and the system back to the correct state. This would allow lock, blank and lock&blank to be used while on or off charger and no matter what the auto-tklock setting is at.

I will probably redo the lock and secure buttons and allow the user to define the short and long press for each one, choosing from the four actions: lock, blank, lock&blank, secure. I'll even render the buttons and display the short and long press actions in each button so you know what you set them to. The dpad center short and long press could also be user-defined with two of the four actions. Will add this after 0.4.7 is released in a few days.

Quote & Reply |

auouymous	2011-02-05 , 03:58
Posts: 875 \| Thanked: 918 times \| Joined on Sep 2010	#316

New test binary, should be the last unless bugs are found.

brightness and volume can't be changed with hardware keys in widget edit mode
escape key now exits widget edit mode instead of hiding ASUI
keypad code is cleared if not unlocked within 60 seconds
ASUI will hide after unlocked if manually secured and lock-and-close is enabled
ASUI will hide after unlocked if it was hidden when secure autolocked

Quote & Reply |

maacruz	2011-02-07 , 22:27
Posts: 1,101 \| Thanked: 1,185 times \| Joined on Aug 2008 @ Spain	#317

@auouymous:
I've been working on the mce issue.
The diablo DBus version doesn't support eavesdropping reply messages, so it is quite useless to reverse engineer the mce/systemui relationship, so I had to add such support and improve dbus-monitor. Then, enabling eavesdropping exposed a bug in GConf which caused it to spam dbus with error messages and break the diablo UI. So, I had to fix GConf too. Once GConf was updated, everything worked fine AND the mce bug which prevented the N810 from blanking the screen and showing the systemui menu was gone too.
Please, try installing these packages and tell me if they fix the bug for you too.

Now, back to mce/systemui:
Using this little script and starting mce with "--verbose" 5 times I have got a quite clear picture of how they interact.

Code:

#!/bin/sh
/etc/init.d/mce stop
/etc/init.d/osso-systemui stop
dbus-monitor --system --monitor|awk '!/^\ /{"date +\"%b %_d %T\""|getline date;c
lose("date +\"%b %_d %T\""); print date, $0}; /^\ /' >dbus-mce.log &
dbus-spy.py -b system -c dbus-mce.map&
sleep 5
/etc/init.d/mce start
sleep 5
/etc/init.d/osso-systemui start
sleep 5
echo Press the power button
sleep 2
echo Touch Cancel
sleep 5
killall dbus-monitor
killall dbus-spy.py

mce startup:

mce gets a bus name (1.100 in this case, subject to change)
Registers its well known dbus name "com.nokia.mce" (for 1.100)
Registers com.nokia.mce.request get_version method
Listens to com.nokia.icd signals
Asks com.nokia.icd for current connection state (get_state method, reply is a uint32, 0 for flight mode), then sets the mode by sending a signal (path=/com/nokia/mce/signal; interface.member=com.nokia.mce.signal.sig_device_m ode_ind; string value "flight")
Registers com.nokia.mce.request req_device_mode_change, get_device_mode methods
Listens to com.nokia.system_ui.signal.system_ui_started signal. This signal will be sent by systemui when it finishes starting much later.
Then the GConf library in mce will continue initialization, registering a new bus name (1.101), and will use method calls to org.gnome.GConf to read /system/osso/dsm/display/ config values. It will then communicate with dsme to send those values to it using the dsme protocol.
It then will register a bunch of related methods: get_display_status, req_display_state_on, req_display_state_dim, req_display_state_off, req_display_blanking_pause, and req_powerup, req_reboot, req_shutdown
Listens to signals of bus name changes for hildon-desktop
Listens to signal com.nokia.startup.signal.init_done (sent by the last sysvinit script: zzinitdone)
Calls com.nokia.system_ui.request.powerkeymenu_close method, although it hasn't been registered yet. This call will fail and return an error. I guess it does this to make sure the menu is closed if mce is restarted for whatever reason when systemui is running and showing the menu.
Opens /dev/input/event* devices and identifies each one (keyboard, retu-pwrbutton, retu-headset, touchscreen). I guess it will keep reading for input from those device file descriptors, at least for the powerkey one, to send the method call to systemui when the key is pressed.
Finds the /sys/devices/platform/*/disable_* entries for keypad and touchscreen, to be used for locking/unlocking keypad and touchscreen
Then reads more config values from gconf (/system/osso/dsm/locks values), and sends a signal with the current lock mode (path=/com/nokia/mce/signal; interface.member=com.nokia.mce.signal.devicelock_m ode_ind; string value "unlocked")
Registers a bunch of related methods, powerkey methods are registered now: validate_devicelock_code, change_devicelock_code, get_devicelock_mode, devlock_callback, req_trigger_powerkey_event, powerkey_callback, modechange_callback
Sends a signal to unlock touchscreen and keyboard (path=/com/nokia/mce/signal; interface.member=com.nokia.mce.signal.tklock_mode_ ind
string value "unlocked"), reads GConf config values and registers related methods: get_tklock_mode, req_tklock_mode_change, tklock_callback
Then goes on with the leds (reads gconf values and registers related methods)
Then adds signal listeners for battery status changes (com.nokia.bme.signal)
Reads alarm mode gconf value (/system/osso/dsm/display/als_enabled), registers get_inactivity_status and set_alarm_mode
Finally sends signal path=/com/nokia/mce/signal; interface.signal=com.nokia.mce.signal.display_stat us_ind; string value "on"

SystemUI startup:

Starts with GConf initialization (bus 1.102) and reads /system/systemui/WINDOW_PRIORITY_MAX config value
Gets a bus name (1.103) and registers its well known name com.nokia.system_ui
Listens to locale change signals
Reads GConf configuration values for plugins, then for powerkey menu window, then for lock code window, splash images, alarm window. Loads plugins.
That's all, sends the com.nokia.system_ui.signal.system_ui_started signal to the bus.

Pressing powerkey interaction (see dbus log at 13:22:38)

mce detects key has been pressed
mce calls com.nokia.system_ui.request.powerkeymenu_open method.
systemui does reply -3
After pressing "Cancel" in the menu, systemui calls com.nokia.mce.request.powerkey_callback with value int32 -6
mce calls com.nokia.system_ui.request.powerkeymenu_close method.
systemui calls com.nokia.mce.request.powerkey_callback with value int32 -4
mce repeats powerkeymenu_close
systemui does reply uint32 0 to both previous powerkeymenu_close method calls.

Attached Files

	logs.tar.gz (33.5 KB, 82 views)
	libgconf2-6_2.16.0-1osso15_armel.deb (158.2 KB, 84 views)
	gconf2_2.16.0-1osso15_armel.deb (130.6 KB, 96 views)
	dbus_1.0.2-0osso14-2_armel.deb (332.0 KB, 116 views)
	dbus-1-utils_1.0.2-0osso14-2_armel.deb (180.2 KB, 96 views)

Quote & Reply |

The Following User Says Thank You to maacruz For This Useful Post:
tso

auouymous	2011-02-08 , 00:42
Posts: 875 \| Thanked: 918 times \| Joined on Sep 2010	#318

I just found a couple nasty bugs that I have no fix for yet, but do have work arounds for.

Some of the widgets and buttons might stop responding to taps. I think there is a bug in the code that prevents the widgets from being accidentally tapped twice causing the action to be undone by executing it twice. If this happens just open the process viewer and kill ASUI. This probably exists in the release version as well.

If the ambient light sensor on the n810 causes the theme to change while the secure keypad is visible it triggers a bug making the keypad jump around the screen and you won't be able to enter your code. Just open and close the clock or flashlight and the keypad will work fine again.

@ maacruz

Please, try installing these packages and tell me if they fix the bug for you too.

I don't normally run ASUI and systemui together, only for testing purposes but I'll test it out soon. (that is the bug you are refering to right?)

Not sure if I missed it but did you test the sequence between systemui and mce when locking the device?

Quote & Reply |

auouymous	2011-02-08 , 04:20
Posts: 875 \| Thanked: 918 times \| Joined on Sep 2010	#319

New test binary.

asui-settings stub, config button and testing support in asui convenience script
merged secure keypad battery code with battery widget code
fix: screen could be rotated from fullscreen clock while in secure mode, not any more
fix: an ALS theme change would screw up the secure keypad
battery widget on secure keypad will manually change theme when tapped
fix: tap throttling wasn't using the correct throttle period
fix: added a 60 second limit for tap throttling to prevent unresponsive buttons

Let me know if the tap throttling changes cause any problems.

Certain daylight conditions and brightness settings make it extremely difficult to see the keypad when using the black theme. The light level might not be enough to trigger ALS theming and the n800 doesn't support it at all so I decided to make tapping the battery widget change the theme, even if ALS theming is enabled.