Sugar needs support for the SW_LID event

[JordanCrouse]

Starting with the B2 hardware, we can detect and act on the lid closing and opening. The experimental tree currently has support for this - it sends a SW_LID event to the OLPC PM input event device (the same one that gets power button events).

Sugar should grab this event, and do something useful with it. Until more advanced power management capabilities are in place, I recommend putting the DCON into sleep mode (DCON + display turns off) when the LID is down:

echo "1" > /sys/devices/platform/dcon/sleep

(Support for this is also in the experimental tree). This will save almost 2 watts of power over the full on / BL at maximum state. The sleep mode may also be useful in other situations, so investigation should be done to that end as well.

[dcbw]

What _exact_ hardware switch generates SW_LID? Does SW_LID get sent when the display is flipped and rotated (ie, ebook mode)? Or is it just when the laptop is all the way closed? Where is that switch located?

[JordanCrouse]

SW_LID is triggered from input events GPIO26. On B2, GPIO26 is connected to the PWR_BUT_in line which is driven by S1, which is a hall effect sensor (part # APX9132ATI-TRL). Put simply, hall effect sensors detect the presence of a magnetic field. S1 is physically located on the "back" (side w/o the CPU) of the board, just above the audio input switch. When the lid is lowered, that side of the board comes into proximity to the left corner of the base, which is presumably where the magnet is located. On the OLPC, the line is high when the LID is open (no magnetic field) and low when it is closed. We are able to detect this event in B2, because PWR_BUT_in was moved from a GPIO on the EC, to a GPIO on the 5536, where we can directly access it from the Linux kernel.

There is an identical hall effect sensor (S2) on the opposite side ("front" of the board, just above the horizontal USB port on the left hand side). The positioning is such that when the screen is turned and placed into ebook mode, this sensor could detect the same magnetic field used for the LID event. Unfortunately, on B2, the line from this sensor is still connected to the EC, and we don't yet have an infrastructure for reading it (see #224). Also note that this sensor only detects proximity, there isn't any way to tell if the screen is physically rotated or not.

[dcbw]

We could likely hook the ebook mode up to SW_TABLET_MODE too when that starts working.

[warp]

Currently xf86-input-evdev does not actually handle SW_* events, before Sugar can support them we need to figure out how to report them through X, and that's actually a, fairly good question.

If xf86-input-evdev could assume a post 7.2 X server (which we're not using currently, for various reasons) then they could be handled as oddly done keyboard keys, but prior to that I'm scratching my head trying to figure out where to shoe horn these events.

[jg]

We're going to need to start updating to X.org 7.3 in April.

[marco]

Reassigning to X11 per warp comment.

[cjb]

This bug's out of date; we *have* hooked up SW_LID and SW_TABLET_MODE, but in HAL rather than X, so sugar can listen for them on the HAL bus (or wait for the hardware-manager to forward them) and act.

[marco]

What can we do on those events? Can we suspend/unsuspend yet?

[cjb]

Replying to marco:

What can we do on those events? Can we suspend/unsuspend yet?

The plan is for HAL/ohm to take care of suspending while idle, so that part will happen automatically -- for sugar, we just need to turn the screen off/on on lid close/open, and xrandr -o left/normal on tablet_mode=1/0.

If ohm isn't ready soon, we might also end up asking sugar to suspend manually on lid close for now..

[marco]

Couldn't ohm also take care of screen on/off? Richard how much of the above can ohm do right now? In any case we should probably submit the ohm package to Fedora review soon, so that it's ready when it has to go in.

[cjb]

Yes, this is all OHM territory. The bug was opened five months ago before we had a plan. Last time I talked to Richard he said he'd start the process of pushing OHM into Fedora.

[marco]

Review in progress:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246748

[cjb]

SW_LID is handled by OHM, and OHM is in our build. Closing, reopen if you disagree.

[gnu]

Build 536 does not suspend on lid-close on a B1. I can see the backlight on, through the left USB port. When running dbus-monitor for both system and session events, no event is seen when the lid is closed, opened, nor when flipped to or from ebook mode. It isn't clear to me whether B1 lacks the hardware for these switches, or whether we lack the software support for reading them on B1. Commentary above talks about B2 moving these signals from the EC to the CPU support chip, indicating that the signals likely existed before B2, but perhaps require an EC command to enable or read them.

[kimquirk]

Changing the name on this bug to OHM needs to support lid event. I think everything is available for this to work; now we need the policy.

[cjb]

Is done and turned on in 703 and above.