Reply
Thread Tools
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#741
Originally Posted by mcow View Post
1) Restarting alarmd is not necessary; resetting MCE does the trick, partway. After that reset, the tablet dims after 90 seconds, blanks after 120; thing is, my control panel is set for 10/30. Opening the control panel and just pressing OK is enough to get it to where it's supposed to be -- maybe. If I apply the C.P. immediately after resetting MCE, I get a 10/120 cycle, but a second application of the C.P. gets it right.
2) Each time I restart MCE, the screen brightens (my default level is 40). When I map ASUI, my "40" is shown in white, but below it is a "76" in blue. As soon as I touch a level control, brightness drops down to the expected level. This 40-over-76 state persists across dim/blank cycles.
MCE resets all of these settings when it is restarted. The brightness problem is even mentioned on the asui-settings brightness page. ASUI will only set the brightness when you explicitly tell it to, it reads the current brightness and can see that is doesn't match the set value. The n810's ambient light sensor is the main reason ASUI doesn't change the value, because ASUI would reset the brightness everytime ALS changed it and it became a constant cycle of ASUI and ALS fighting over the brightness. Another problem is the dim state, there can be a slight lag between the screen dimming and ASUI receiving the signal. If ASUI were to check brightness during this period it would effectively undo the dim.


Originally Posted by mcow View Post
Perhaps unrelated to the blanking failure: I have twice seen ASUI's power meter pegged at 100% and staying there; mapping to ASUI shows normal CPU activity of just a couple percent, but back the desktop and the meter continues to be pegged. May be related to rebooting with WiFi enabled, rather than in Flight mode, but I haven't figured out a sequence of steps that makes this happen for sure.
Was the rest of the applet working correctly (does it map ASUI when pressed)? Were other applets working or was the statusbar frozen? When BME code (new drain indicator) was having problems it would block hildon-desktop indefinitely and all applets on statusbar and desktop would freeze. If the applet isn't frozen try opening asui-settings and toggle cpu overlay off and on to see if it does anything. Could be a race condition that caused the cpu refresh timer to be destroyed.

--

I will be leaving today and won't be able to work on ASUI for the rest of the year, unless I come back early. I have given maacruz access to the project so if anyone wants to write patches that add new features or fix problems then he can apply them.
 

The Following 2 Users Say Thank You to auouymous For This Useful Post:
tso's Avatar
Posts: 4,783 | Thanked: 1,253 times | Joined on Aug 2007 @ norway
#742
Ah, now i see. After restarting MCE the blanking timeout is reset, and ASUI have no way to change said timeout via its ui. That was what i had to poke the display settings for. Silly me for not thinking about that before.

And on that note, how is the display settings saved and restored between reboots or powerdowns?
__________________
Be warned, posts are often line of thoughts at highway speeds...
 
tso's Avatar
Posts: 4,783 | Thanked: 1,253 times | Joined on Aug 2007 @ norway
#743
Odd. In a fit of experimentation i set Systemui to start on boot, and notice that MCE defaults to ignoring the power button after a reboot even tho i had it set to menu before rebooting. This tho via ASUI-settings so i do not know how reliable a info source it is. This in particular as a MCE restart results in Systemui working even tho the setting reads ignore in ASUI-settings.

Edit: Bah, in 1 of 3 reboots after enabling Systemui, MCE behaved itself. But after the 4th it does not.
__________________
Be warned, posts are often line of thoughts at highway speeds...

Last edited by tso; 2011-06-07 at 16:10.
 

The Following User Says Thank You to tso For This Useful Post:
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#744
Originally Posted by tso View Post
And on that note, how is the display settings saved and restored between reboots or powerdowns?
Gconf keys, there is another thread from Addison about MCE stop/starting with the keys but we've had no success getting them automatically restored after a restart. I did write a little program to restore brightness and should probably call it when asui-setting's MCE restart button is pressed. Added a note on the TODO page for when I get back, unless one of you wants to do it.


Originally Posted by tso View Post
Odd. In a fit of experimentation i set Systemui to start on boot, and notice that MCE defaults to ignoring the power button after a reboot even tho i had it set to menu before rebooting. This tho via ASUI-settings so i do not know how reliable a info source it is. This in particular as a MCE restart results in Systemui working even tho the setting reads ignore in ASUI-settings.
I've actually seen SystemUI not respond to power button, try restarting it from asui-settings instead of rebooting. Although, it could also be a problem with MCE not sending the method call to SystemUI, try restarting MCE.

The button actions on the MCE page are read from /etc/mce/mce.ini each time the page is opened and changing the action writes to that file. It does require a restart of MCE for the changes to take effect.

All these MCE troubles is probably why powerlaunch has its own MCE clone. Maybe when I get back someone will have written Advanced MCE.
 

The Following User Says Thank You to auouymous For This Useful Post:
Posts: 86 | Thanked: 8 times | Joined on May 2010
#745
Originally Posted by auouymous View Post
The n810's ambient light sensor is the main reason ASUI doesn't change the value, because ASUI would reset the brightness everytime ALS changed it
But I've got an N800! Could it be automated for that case?

Originally Posted by auouymous View Post
Was the rest of the applet working correctly (does it map ASUI when pressed)? Were other applets working or was the statusbar frozen? When BME code (new drain indicator) was having problems it would block hildon-desktop indefinitely and all applets on statusbar and desktop would freeze.
It was definitely mapping—that's how I could check what the actual CPU percentage was, vs. the meter display. And my recollection is the battery and drain colors were changing; if I see this state again, I'll confirm. The only other applet was the system WiFi-connected indicator.

Originally Posted by auouymous View Post
If the applet isn't frozen try opening asui-settings and toggle cpu overlay off and on to see if it does anything. Could be a race condition that caused the cpu refresh timer to be destroyed.
Will do.

Originally Posted by auouymous View Post
I will be leaving today and won't be able to work on ASUI for the rest of the year, unless I come back early. I have given maacruz access to the project so if anyone wants to write patches that add new features or fix problems then he can apply them.
Oh no! Well, I hope whatever you're off to is fabulous.
 
Posts: 86 | Thanked: 8 times | Joined on May 2010
#746
Originally Posted by auouymous View Post
The brightness problem is even mentioned on the asui-settings brightness page.
It is? You mean the web page about the screen-brightness/blanking management (which I can't find anymore), or the Brightness page in the ASUI settings app?

edit: oh, wait: you are talking about a reset from 0-127 to 1-5, which I do not see happening. (That is mentioned on the Settings App's page for Brightness.) I don't think changing the actual level from 40 to 76 is the same thing, nor is the failure to adjust the brightness back down to 40, which ASUI should be able to do (on the N800, at least).


I can't find anything on the website about the Services or MCE settings pages. The existing docs for Settings stop after Alarm.

Last edited by mcow; 2011-06-07 at 17:44.
 

The Following User Says Thank You to mcow For This Useful Post:
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#747
Originally Posted by mcow View Post
But I've got an N800! Could it be automated for that case?
Originally Posted by mcow View Post
edit: oh, wait: you are talking about a reset from 0-127 to 1-5, which I do not see happening. (That is mentioned on the Settings App's page for Brightness.) I don't think changing the actual level from 40 to 76 is the same thing, nor is the failure to adjust the brightness back down to 40, which ASUI should be able to do (on the N800, at least).
When MCE is started/restarted it sets brightness to the 1-5 value.

When I mentioned the ALS problem I also mentioned this:
Another problem is the dim state, there can be a slight lag between the screen dimming and ASUI receiving the signal. If ASUI were to check brightness during this period it would effectively undo the dim.

Another problem is that ASUI only checks brightness when it is mapped, so you'd have to actually map ASUI for it to correct the brightness. This is only a problem when restarting MCE and would be better handled with a button to correct the brightness in asui-settings. And also by fixing any issues that cause MCE to require a restart.


Originally Posted by mcow View Post
I can't find anything on the website about the Services or MCE settings pages. The existing docs for Settings stop after Alarm.
That section only documents the gconf keys that ASUI declares and there are no keys used by the Services and MCE pages. That section was important before the GTK app existed, now it just serves as good documentation of ASUI's internals. The first group was also outdated so thank you for mentioning it. I've also added a note to document the Services and MCE sections when I get back.
 

The Following User Says Thank You to auouymous For This Useful Post:
tso's Avatar
Posts: 4,783 | Thanked: 1,253 times | Joined on Aug 2007 @ norway
#748
found this in dmesg today:

lcd_mipid spi1.1: performing LCD ESD recovery

The trigger was me putting the N800 on charge after it powered down from lack of battery. When then it powered back on in charging mode, and idled enough for the backlight to turn off, i found it flickering. Pressed the power button to get it into full Maemo, and it was still flickering. Took a look at dmesg and found the line above repeated ever so often.
__________________
Be warned, posts are often line of thoughts at highway speeds...
 
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#749
Originally Posted by tso View Post
found this in dmesg today:

lcd_mipid spi1.1: performing LCD ESD recovery

The trigger was me putting the N800 on charge after it powered down from lack of battery. When then it powered back on in charging mode, and idled enough for the backlight to turn off, i found it flickering. Pressed the power button to get it into full Maemo, and it was still flickering. Took a look at dmesg and found the line above repeated ever so often.
That smells like hardware failure
 
tso's Avatar
Posts: 4,783 | Thanked: 1,253 times | Joined on Aug 2007 @ norway
#750
A reboot removed the issue, so who knows. Still, now you got me worried as i have a 770 here that died from a blown controller chip...
__________________
Be warned, posts are often line of thoughts at highway speeds...
 
Reply

Tags
bada blows, bada rox


 
Forum Jump


All times are GMT. The time now is 05:45.