2

I am running Archlinux in a chroot alongside Chrome OS on a chromebook. The original project is there, my fork of it is here (mostly similar).

The issue is that the display power management of Chrome OS only takes touchpad and keyboard input made in Chrome OS's X on tty1 into account to reset the screen blanking countdown. So, if I am working in my chroot, on tty3 (console) or on tty4 (Arch's own X server), the backlight turns off after 5 minutes, whether I am idle or active. I have to then come back to tty1 to register some input there and get powerd to reactivate the backlight.

I don't want to deactivate powerd in Chrome OS, neither do I want to lengthen the default timeouts (which is what the original author or the chroot setup scripts did). I just want the screen backlight to turn off after a few minutes of inactivity, and to remain on when I am active in the chroot environment or in Chrome OS. Moreover, I want to minimally modify Chrome OS, as it's updated quite often and I want to keep the chroot reinstall script simple.

So, my idea is that I will program a couple of daemons. Daemon A runs in the chroot and detects whether I make keyboard or mouse inputs in Arch. Daemon C runs in chrome OS, checks the output of daemon A and does whatever is most appropriate to reset the screen blanking and power saving counters.

However, if user activity in the chroot can be figured out reading some /dev node, daemon A would not be necessary. Can the age of the last user activity in the chroot (on /dev/tty3 and /dev/tty4) be somehow deduced from reading some /dev file, or by any other way from without the chroot?

Secondly, commands such as setterm -blank poke seem to work from within the chroot, so daemon C may not be necessary if daemon A can alone reset the screen blanking countdown. Hence, the second question: Can the age of last user activity in the chroot (on /dev/tty3 and /dev/tty4) be somehow deduced from reading some /dev file, or by any other way from within the chroot?

If you think that resetting the counters requires daemon A and C to both exist and communicate: How is modern IPC done in GNU/Linux in practice? System V? POSIX? /proc files read and write? What would best work in my case?

Finally, do you know something else than setterm -blank poke, that the watchdog program should use to keep the backlight alive?

Sorry for the long question, I hope you didn't have to read it all :)

Improve this question

1 Answer 1

Reset to default
2

Just some pointers on how to (possibly) talk with the power daemon.

Have a look into the Chromium OS sources (no idea on how much this differs from Chrome OS), there you'll find the power_managers sources which might be helpful:

README explains what one can find there, among others:

  • powerd (powerd.cc) Upper power manager. Adjusts device status based on whether the user is idle and on video activity indicator from the window manager. This daemon is responsible for dimming the backlight or turning off the screen based on user idle, and it is responsible for adjusting backlight intensity based on user input and ambient light condition. The daemon also monitors plug state (on ac or on battery) and battery state-of-charge.
  • xidle-example (examples/xidle_example.cc) Prints console notifications when the user is and is not idle.

So maybe you could interfere via XIdle, xidle_example.cc could be helpful.

Another thing that might be useful is that RootPowerManager.conf tells you which D-Bus address it listens on, org.chromium.RootPowerManager...maybe you can poke around there and find something, I haven't found any interface specs (but D-Bus should be able to tell you).

(grep idle might be helpful, too, it made me look at activity_detector_interface.h, if this was D-Bus-exported, you could use it, i.e., disable Chrome OS's activity detection when your Arch system detects activity etc.)

Improve this answer
1
  • Thank you, I thought that Chrome OS' power daemon would be blind and deaf, but thanks to your findings, I will now try the less hackish method of actually talking to it :) Commented Mar 5, 2012 at 14:30

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.