- From: Raphael Kubo da Costa via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Oct 2021 16:07:23 +0000
- To: public-device-apis-log@w3.org
In preparation for our upcoming meeting at TPAC, I find it useful to try to summarize what's happened so far and lay out the issues I see so that we can try to reach some consensus more quickly. Apologies in advance if I've missed in these 3 years worth of issue comments. @willmorgan also provided a description of where we're at in https://github.com/w3c/screen-wake-lock/issues/129#issuecomment-817151517 back in April. What I think we're in agreement with so far: * It does look like there's demand from web developers working in different areas for _some_ form of brightness control, which is a good starting point. * As far as I can see, nobody seems to be particularly interested in lowering the brightness level: the use cases listed so far all seem to benefit from raising the brightness level, temporarily or not. * `getUserMedia()` integration does not completely address the use cases described here and is not a very good fit for this feature. What still needs to be discussed: * Does it make sense to allow web developers to increase the brightness level without entering fullscreen? In other words, should this be tied to `requestFullscreen()` or not? * While granular brightness control in e.g. `<video>` tags looks somewhat orthogonal to the issue at hand, it does raise the issue of how granular the brightness control should be and whether there should be a way to change the brightness level once a lock is acquired. * Permission model: is it enough to require user activation in `WakeLock.request()` when there's a request to change the brightness level or should the spec require UAs to display some UI to inform users about the request? * How bright is too bright? Should this API be allowed to increase the brightness level to the highest possible value? Should this be a platform decision and irrelevant to the spec itself? In other words, is it enough for `WakeLock.request()` be a best effort action that _may_ increase the brightness level by _some_ %? * Should the brightness level remain up for as long as the lock is held or should there be a timeout? Finally, there's the question of how this would be implemented in different platforms. My impression is that a lot of people immediately think of a mobile device when they think of this feature. In fact, it's not clear to me what this API should do on a desktop/laptop connected to an external display or when there are multiple screens on at the same time, for example. I took a quick look at what APIs seem to be offered by different platforms, and the situation looks like this: * Android: we currently use [`KEEP_SCREEN_ON`](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#FLAG_KEEP_SCREEN_ON) which doesn't change the brightness level, but as mentioned earlier in this issue I guess we could use [`BRIGHTNESS_OVERRIDE_FULL`](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#BRIGHTNESS_OVERRIDE_FULL), but this means using the highest brightness value rather than something that may be high enough (see "how bright is too bright" above). * ChromeOS: I _think_ it's possible to change the screen brightness based on what I can see in [this file](https://source.chromium.org/chromium/chromium/src/+/main:chromeos/dbus/power/power_policy_controller.h;l=88;drc=d1c3fe7bce37feabb6bf0699bc58d071fe9e62c1). * Linux: KDE and GNOME seem to provide some D-Bus interfaces to change the screen brightness, but I don't think there's anything standardized in freedesktop.org. * OS X: There doesn't seem to be any API for changing the screen brightness. * Windows: There's a [`SetMonitorBrightness`](https://docs.microsoft.com/en-us/windows/win32/api/highlevelmonitorconfigurationapi/nf-highlevelmonitorconfigurationapi-setmonitorbrightness) function that might do it, but I am not sure. -- GitHub Notification of comment by rakuco Please view or discuss this issue at https://github.com/w3c/screen-wake-lock/issues/129#issuecomment-951078201 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 25 October 2021 16:07:25 UTC