[Meego-architecture] MCE or MCE-like component in 1.3, Re: [meego-packaging] why does meegotouch-compositor rely on mce?
carsten at maemo.org
Thu Mar 17 23:17:55 PDT 2011
Just forking this discussion into an architecture discussion on mce's
role in 1.3 or if we need to design a new component for this that is
more architecture independent. And less of a kitchen sink.
Current roles of mce:
1) Display dimming, display blanking (also preventing) and state
(screen off implies no need for applications to draw on screen, saving
2) Button/switches state: camera lens, keypad slide, proximity sensor,
camera focus, lid cover, USB cable, back cover, etc..
3) LED patterns
4) Touchscreen locking
5) ALS, audio routing(??), call state (emergency vs not)
6) Thermal triggers, proximity sensor handling
and the list probably goes on.
Now, how do you architects see these functions handled in 1.3?
I'd like to motivate a more hardware adaptation independent method -
current behaviour is very hardcoded. Maybe policy framework would be a
good place for some of these things. But we need to have this
discussion early on.
2011/3/17 Arjan van de Ven <arjan at linux.intel.com>:
> On 3/17/2011 7:32 AM, fathi.boudra at nokia.com wrote:
>> It's used in MDeviceState. mcompositor uses mce to get display status.
> that does not make sense at all.
> display is an X level property, and MCE does not run inside the X
> (including on/off and events for that)
> we need to fix this properly.
> MeeGo-packaging mailing list
> MeeGo-packaging at meego.com
More information about the MeeGo-architecture