Comment 75 for bug 604635
Revision history for this message
|
|
#75 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
eee2d0b
(Get the code!)
I don't see the need for inventing a notion of rings. Apps can be entrusted with particular permissions. They're trusted to the extent of the permissions granted. There are some privileges like telephony that we may only grant to apps pre-installed on the device, up to vendors.
> Only platform privilege (ring 0) code can set |screen.enabled = false|. Nothing other than the power manager should touch screen.enabled, and we trust that other modules won't step on the power manager's toes. (We do this through code review, just as we would in Gecko.)
If I read this as, "only apps with screen-management permission", then I agree. But I don't follow the rest. Are you saying that there should only be one application given screen-management permissions? That could be a pre-install-only permission, but the discussion seems orthogonal. If there's a use case for multiple apps having screen-management perms (maybe there isn't), then we should consider how they're supposed to interact. I can't think of one so I'm happy punting that.
> The power manager will ask Gecko to call it back when there's been X seconds of inactivity. This means exposing an API similar to Gecko's idle service to ring 0.
> This sounds like suggesting that we eliminate ring 0 and push that functionality into gecko.
> In general, this kind of approach limits extensibility. One can extend the functionality only at the points we define.
It all boils down to trade-offs. Extensibility means new APIs, which means a lot of design and spec work. Implementing something mostly internal to gecko with small touch points to content is easier. If there are other use cases for apis we want to add, consiliating with "userspace screen manager", then that argues more strongly for adding a new API.
An idle notification sounds like a generally useful thing. Has anyone proposed this before? It sounds easy to spec and implement.
Now, along with that, if we specify what happens if an app with screen-management permissions tries to set screen.enabled = false when there are active screen-on wakelocks, or tries to change brightness when there's a screen-brightness lock, then you've convinced me we've got all we need to implement this entirely in "userspace".