I can confirm this also reproduces on a USB keyboard and mouse.

Looks like presently we don't have any means to identify whether user input comes from built-in input devices (keyboard, touchpad) where enabling keyboard backlight is beneficial vs some other external input device (or internal ... touchscreen) where its not.

Dan what are your thoughts on differentiating these different input streams to change KB backlight behavior?

Hmm, this is a tricky one. Chrome's reporting of user input to powerd is quite primitive: when it sees an input event, it calls powerd's HandleUserActivity D-Bus method. We rate-limit these calls to one every five seconds, IIRC.

There's a "type" enum attached to the method call, but it largely corresponds to particular keys that we want to ignore for the purposes of turning the screen on:

enum UserActivityType {
  USER_ACTIVITY_OTHER = 0,
  USER_ACTIVITY_BRIGHTNESS_UP_KEY_PRESS = 1,
  USER_ACTIVITY_BRIGHTNESS_DOWN_KEY_PRESS = 2,
  USER_ACTIVITY_VOLUME_UP_KEY_PRESS = 3,
  USER_ACTIVITY_VOLUME_DOWN_KEY_PRESS = 4,
  USER_ACTIVITY_VOLUME_MUTE_KEY_PRESS = 5,
};

(Also note that we often don't even report these correctly: issue 599883)

One option might be to introduce another argument that describes the source of the user activity. Within powerd, KeyboardBacklightController::HandleUserActivity could inspect this and avoid treating events from external devices as activity.

The one downside is that if we see and report an event from an external device, and then see an event from the internal keyboard a second later, we won't turn the keyboard backlight on (due to the rate-limiting). As a workaround for this, Chrome could track the most-recently reported type and source and avoid rate-limiting the next event it sees with a different type or source.

I implemented most of this before realizing that it'll probably break upon moving to mash. :-(

Specifically, the UserActivityObserver interface defined in ui/public/interfaces/user_activity_monitor.mojom doesn't receive the event that triggered the activity report. aura::UserActivityForwarder calls ui::UserActivityDetector::HandleExternalUserActivity(), which just passes a null Event pointer to its observers. Issue 626899 has more details about the current implementation. I don't know if anyone's thought about passing additional event information from ws (would we need to serialize ui::Event?).

I don't know much about user activity, but we do have the ability to serialize events:
https://cs.chromium.org/chromium/src/ui/events/mojo/event.mojom?q=event.mojom&sq=package:chromium

Who would be receiving the event? If it's a privileged process (e.g. ash) that's probably OK. If it's every process (e.g. some random renderer) it's probably not OK for them to see events targeting other UI, for security reasons.

Hello, 

We are currently working on improving power management via ML and as part of this, we need to log user activity events via UserActivityObserver. Dan mentioned we would lose data once the sys is moved to mash. Would you have some estimate as to when the sys would be moved to mash? Would it be the upcoming M66? If so, we'd have no time to put in any solution to work around it.

Thanks,
Jia

Specifically, https://crrev.com/c/940724/3/chrome/browser/chromeos/power/ml/idle_event_notifier.cc#164 is the code in question.

mash is at least 9 months out

Hello,

Has this mash change gone out? It appears we have stopped receiving user event via UserActivityObserver as event pointer is null. We haven't got a chance to change the implementation as I thought mash would go out any time soon. If this change has indeed gone out, would you please let us know when it happened and if there's any quick fix for us? 

We have a new project that needs code to go into M67 (and we have an existing project that relies on this user event), and so we'll need to make changes in the next couple of days.

Thanks!
Jia

Scott, do you know if there's any reason why UserActivityObserver wouldn't be receiving raw events now? Is ws running in a separate process from Chrome now?

Jia, you might want to file a new bug for your issue since this one is tracking  an unrelated feature request.

Thanks Dan! I'll file another bug request.
Jia

Mash has not yet shipped, still > 9 months out.

sky turned on the window server on a background thread (--enable-features=Mus) a few weeks ago, but I don't know if that's related.