[Meego-architecture] MCE or MCE-like component in 1.3, Re: [meego-packaging] why does meegotouch-compositor rely on mce?

[Carsten Munk]

Hi,

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

BR
Carsten Munk


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
> session......
> (including on/off and events for that)
>
>
> we need to fix this properly.
>
> _______________________________________________
> MeeGo-packaging mailing list
> MeeGo-packaging at meego.com
> http://lists.meego.com/listinfo/meego-packaging
>