I think that this is an oversight of the original design. Chrome currently asks powerd to force the display off when the power button is released after a tap. It doesn't undo that request unless it sees the power button pressed again or an input event (key, mouse, stylus) is received.

I think it should additionally stop forcing the display off when lid events are received. These can be observed via chromeos::PowerManagerClient::Observer::LidEventReceived(). It's probably safe to do this for both lid-closed and lid-opened events -- powerd should turn the display off anyway if the lid is closed, even without a force request from Chrome. Also, if Chrome only stops forcing off when it's notified about lid-open, there will probably be a longer delay before the screen turns back on when resuming.

We may also want to make Chrome stop forcing the display off when entering or exiting tablet mode, which can be observed via TabletModeEventReceived() in the same observer interface (or maybe this should be tied to maximize mode on the Chrome side).

Yes, lid-opened should definitely stop forcing off. For lid-closed, it may not hurt to stop forcing off, but may be not necessary?

For entering/exiting tablet mode to stop forcing display off, we may want UI confirmation.

tbuckley@, with display off on either clamshell/tablet mode, and then filp screen to tablet/clamshell mode, should we make display on?

I think it'd be good for Chrome to stop forcing off on lid-closed so that powerd can turn the display on immediately on lid-open without needing to wait for Chrome to stop forcing off.

OK, sorry I forget that comment. I agree. Thanks

I agree we should stop forcing the display off on lid close/open.

What's the rationale for turning on the display on the clamshell<->tablet transition? I wouldn't expect the display to change in that case.

Re clamshell <-> tablet, that could be interpreted as a signal that the user is about to interact with the device. But thinking about it some more, it'd be hard/impossible to distinguish between that and the case where the user is going from tablet to closed (and passing through clamshell along the way), and we wouldn't want to turn the display on then.

So yeah, just doing this for lid-closed and lid-opened seems fine to me.

Hey Dan and Tom,

It's been on my backburner : https://b.corp.google.com/issues/35586256#comment4

If we decide to allow a transition past 180-degrees to resume the system and turn the display on, it actually gives us the ability to enable the touchpad as a wake source again and manage it appropriately through all power states and tablet conversions.

#9: I'm not sure that waking on tablet mode transitions is relevant to this; it's just about Chrome forcing the display off while the system is awake. Maybe I'm misunderstanding, though.

This went out in M57, right? We should fix it (and Joe has a CL to do that) but ReleaseBlock-Stable probably isn't appropriate for existing bugs that aren't regressions.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1360898e06a4c3505237ccf3aa9425056e9e4af6

commit 1360898e06a4c3505237ccf3aa9425056e9e4af6
Author: warx <warx@chromium.org>
Date: Thu Apr 13 18:08:29 2017

cros: Stop forcing off display when lid events are received

Changes:
Stop forcing off display when lid events are received

BUG= 711033 
TEST=added test coverage, also manually test on device

Review-Url: https://codereview.chromium.org/2815453007
Cr-Commit-Position: refs/heads/master@{#464469}

[modify] https://crrev.com/1360898e06a4c3505237ccf3aa9425056e9e4af6/ash/system/power/tablet_power_button_controller.cc
[modify] https://crrev.com/1360898e06a4c3505237ccf3aa9425056e9e4af6/ash/system/power/tablet_power_button_controller.h
[modify] https://crrev.com/1360898e06a4c3505237ccf3aa9425056e9e4af6/ash/system/power/tablet_power_button_controller_unittest.cc
[modify] https://crrev.com/1360898e06a4c3505237ccf3aa9425056e9e4af6/chromeos/dbus/fake_power_manager_client.cc
[modify] https://crrev.com/1360898e06a4c3505237ccf3aa9425056e9e4af6/chromeos/dbus/fake_power_manager_client.h

Yes, this should be already broken on M-57.

I am marking it fixed for now. Please reopen it if we want the merge. Probably it doesn't need.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-59; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-59 label, otherwise remove Merge-TBD label. Thanks.

As long as it's in M59, it should be okay.

M-59 is not branched yet. Remove Merge-TBD.

Verified on Wizpig & Snappy with version 59.0.3071.8/9460.4.0