User:DanielDrake/Kernel upstream implications

This page lists the pending tasks for restoring all functionality when moving to new the x86-3.1 branch of olpc-kernel. This is a new branch based on the upstreaming work that has happened over the last year or so.

Patches merged, userspace work needed

Button/switch state files

Previously, we represented ebook and lid switches as input devices, and additionally created custom sysfs device attributes so that the button state could be read with a simple cat.

These attributes were removed during the upstream process on the basis that they duplicate input device functionality. Button/switch state should now be queried with evtest. powerd (and switchd?) need to be modified.

No AC status input device

We used to have an input device that monitored AC adapter presence. We don't any more, since that seemed redundant - the power supply device has this role. kbdshim should start using uevents to monitor state changes from the power supply device.

hgpk mode selection

The method for switching between mouse and pentablet mode has changed. The evdev packets produced in pentablet mode are now absolute (not relative) coordinates. kbdshim will need to intercept this device and perform the absolute-to-relative conversions. olpc-utils needs to be modified to mark the right file as writable, and sugar needs to be modified to use the sysfs interface that went upstream.

Enabling wakeups

Instead of a global wakeup mask, we now have to start selecting individual wakeup sources using linux's new wakeup events architecture.

• mouse/keyboard as i8042 wakeup
• battery/AC as olpc_battery wakeup
• and more

rfkill

For XO-1.5, runtime power management is now used to cut power to the card. Simply bringing the interface down (which NetworkManager does when you ask it to disable wireless) will power down the card transparently. However, this was disabled upstream as it caused some problems with other SD8686 users. Need to check this again.

For XO-1, a XO1_RFKILL x86 platform driver was merged upstream.

Non-upstream patches that we merged anyway

Keyboard/mouse wakeups

The upstream kernel needs to be modified to not mess with keyboard/mouse state during suspend/resume in our case. This proposition has been difficult so far. Here is a problem statement.

I have merged the recent proposed patches even though they have not been accepted yet. However, I have enabled wakeups on the relevant devices by default; userspace does not need to do anything. This is because the userspace interface to this functionality has not yet been agreed upon; by coding this into the kernel we avoid dragging powerd through multiple userspace interface changes before one gets settled on.

Once the work gets merged upstream, we should go with the upstream version and modify powerd to use the interface that went upstream.

VIA video suspend/resume

Our kernel adds viafb suspend/resume code that is big and incompatible with "standard" X11 video drivers such as openchrome. Not upstreamable, the switch to KMS needs to be made.

DCON driver

The DCON driver is in the staging tree and is usable. However it needs to be improved, cleaned up and moved into drivers/video or something like that. Otherwise it will be deleted from the upstream kernel tree.

Pending work

wakeup reason

sysfs nodes that explain the reason for system wakeup won't be upstreamed right now. Firstly, the XO-1.5 one is complex (unless you include nasty hacks) and could maybe be done by ACPI in a nicer way. Secondly, upstream seem to be heading in the direction that "wakeup events" are considered regardless of system state (asleep or awake). Therefore there should be no need for this. The system should wake up and see that the mouse was moved via regular userspace events, therefore know not to sleep for a while. This idea needs more exploration and discussion. It may make sense to hack in the old wakeup reason patches for now.

XO-1.5 bad RTC reads

This needs to go upstream. My first effort didn't generate much noise - next step is to submit the patch with Andrew Morton's suggestions (which will probably be rejected, but hopefully rejected with guidance on in which form it would be acceptable).