ANNOUNCE: Diablo-Turbo first beta available - Page 57 - maemo.org

Active Topics

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

Page 57 of 62

Thread Tools

buurmas	2011-12-12 , 18:09
Posts: 670 \| Thanked: 367 times \| Joined on Mar 2009	#561

Originally Posted by tso

So your not using Advanced System UI, Buurmas?

That's right. I've delayed installing ASUI for this very reason -- to try to better isolate this problem.

Originally Posted by maacruz

Try restarting systemui after restarting mce

Doing "systemui" or "systemui restart" from the terminal gives me an error message. But see below:

Originally Posted by Addison

I don't think that I have ever experienced the non-dimming bug, but I have lost the power button a few times.

Try this instead next time to avoid rebooting.

sudo /etc/init.d/mce restart

Ahhhh... sudo make a sandwich. That did it. Call me stupid if you like. I'm going to add sudo to my Personal Menu item as well. Thanks all!

__________________
* n810 since Feb 2009
* Most-used apps: Opera, gPodder, Panucci, Tomiku, Canola, Quasar, MaemoMapper, ATI85, Maemopad+, AisleRiot Solitaire, Anagramarama, Rapier, Gnumeric, pyRDesktop
* Mobile-friendly URLs of popular sites

Quote & Reply |

The Following User Says Thank You to buurmas For This Useful Post:
Addison

	Addison	2011-12-12 , 18:26
	Posts: 3,811 \| Thanked: 1,151 times \| Joined on Oct 2007 @ East Lansing, MI	#562

^ You're a goof.

Thanks for the chuckle.

Quote & Reply |

	tso	2011-12-12 , 19:18
	Posts: 4,783 \| Thanked: 1,253 times \| Joined on Aug 2007 @ norway	#563

Ah yes, that. I recall noticing that MCE behaved differently depending on being restarted via user rights or root rights. And it was very damn subtle about it.

Still, that the dimming issue shows up for someone not using ASUI seems to indicate a turbo issue.

And on that note, i have not had the dimming issue the last couple of times my N800 have been booted using the charger and then entered the maemo desktop by way of a power button long press. Then again, i use ASUI.

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

Quote & Reply |

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

auouymous	2011-12-12 , 20:47
Posts: 875 \| Thanked: 918 times \| Joined on Sep 2010	#564

Originally Posted by buurmas

In these times, restarting mce has solved the screen dimming problem, but the power button still doesn't pull up the system ui menu. I have to reboot to get that back.

Have you ever had ASUI installed? The dimming problem was thought to be an issue between alarmd and ASUI which persists even if you revert back to SystemUI.

I know ASUI is incorrectly dismissing alarms because the interface I found was wrong and I also know that ASUI is telling alarmd that the system is booted up even when in the charging runlevel. Both of these problems have been fixed but haven't been tested and released yet.

This changes everything if you have never used ASUI as it becomes a problem between alarmd and DT which might be harder to find. Anyone out there have a device not running DT and experiencing the alarmd problem with ASUI?

Last edited by auouymous; 2011-12-12 at 20:50.

Quote & Reply |

The Following User Says Thank You to auouymous For This Useful Post:
Addison

buurmas	2011-12-13 , 13:20
Posts: 670 \| Thanked: 367 times \| Joined on Mar 2009	#565

Originally Posted by auouymous

Have you ever had ASUI installed? The dimming problem was thought to be an issue between alarmd and ASUI which persists even if you revert back to SystemUI.

I have certainly never had ASUI running on my machine. I'm pretty sure that I didn't start trying to install it & then stopped. (I'm just trying to be careful in my answer b/c I've thought about installing it many times.)

I have also had times where the alarm went off five minutes after it was supposed to, which is kind of odd. I think it only did that after installing DT. I've also had times where I've awakened on my own to find the alarm dialog sitting open but without making any alarm sound, although I am not certain that this wasn't because of my volume setting.

Quote & Reply |

maacruz	2011-12-13 , 17:28
Posts: 1,101 \| Thanked: 1,184 times \| Joined on Aug 2008 @ Spain	#566

It is a mce bug.
mce sends a signal to systemui when the power button is pressed, then systemui shows the power menu button. Also, mce is responsible for dimming, and mce is related to alarmd.
I've suffered this issue before installing ASUI, and I have done may be a hundred tests trying to find a workaround or a fix before finally giving up.
Since mce has nothing to do with the kernel, it is not caused by the kernel (or otherwise many programs would crash or exhibit other symptoms).
It is caused by a race condition (http://en.wikipedia.org/wiki/Race_condition) in mce, probably related to gconf. The relation of the kernel here is that, for the different timing caused by the different schedulers, this mce bug is exposed when using other schedulers than O1.
How do I know that?
I saw it appear with the first alpha kernels, with both CFS and the SD schedulers, preemption or not. So it happens with two different schedulers, and the only thing affected by a scheduler is timing.
With the new gconf packages (which also have increased performance) it disappeared for me.
So yes, DT may expose this bug, and I can do nothing to fix it, short of rewriting the whole mce thing because it is closed source.

Quote & Reply |

The Following 3 Users Say Thank You to maacruz For This Useful Post:
Addison, buurmas, lma

buurmas	2011-12-13 , 19:30
Posts: 670 \| Thanked: 367 times \| Joined on Mar 2009	#567

Well, that seems to put everything into perspective. Thanks, maacruz, for the additional detail into what I assume you have been telling us for some time now.

Originally Posted by maacruz

With the new gconf packages (which also have increased performance) it disappeared for me.

Which packages are those? Is it an option for the rest of us to install them to fix this problem?

Quote & Reply |

maacruz	2011-12-13 , 20:36
Posts: 1,101 \| Thanked: 1,184 times \| Joined on Aug 2008 @ Spain	#568

Originally Posted by buurmas

Well, that seems to put everything into perspective. Thanks, maacruz, for the additional detail into what I assume you have been telling us for some time now.

Which packages are those? Is it an option for the rest of us to install them to fix this problem?

gconf2_2.16.0-1osso15_armel.deb and libgconf2-6_2.16.0-1osso15_armel.deb
You already should have them installed just by following the first post instructions.
Since very few people has noticed this issue, I guess the probability of it happening may be increased by some other package, although I can't discard some other possible influence

Quote & Reply |

auouymous	2011-12-13 , 20:50
Posts: 875 \| Thanked: 918 times \| Joined on Sep 2010	#569

Originally Posted by maacruz

It is a mce bug. mce sends a signal to systemui when the power button is pressed, then systemui shows the power menu button. Also, mce is responsible for dimming, and mce is related to alarmd. So yes, DT may expose this bug, and I can do nothing to fix it, short of rewriting the whole mce thing because it is closed source.

So who has this problem and wants to try installing powerlaunch and only enabling its MCE replacement? We don't have to rewrite MCE when powerlaunch already does that, just need to fill in any incomplete areas. I can fork the MCE service into its own package if it fixes the problem and works well enough.

I should have some free time in the next week or two to finish up the current batch of ASUI fixes and will then play around with powerlaunch's MCE if no one else has. Although it would be better if someone who has the problem frequently tested powerlaunch's MCE since I have only ever had alarmd running when performing tests and can't properly test it under real world conditions.