User:DanielDrake/Kernel upstream implications

This page lists the userspace-visible changes that have occurred during the process of getting OLPC's kernel patches upstream.

No button 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.

However, during the upstreaming process, Dmitry Torokhov said:

No, instead of adding yet another kernel attribute just use ioctl to get current switch state. Or write a general purpose utility to query switch/key state and contribute it to consoletools project - many people have asked for it ;)

The ioctl approach is a little more complex, but not much. Based on his suggestion I wrote evstate and plan to submit it to util-linux (as consoletools seems like a dead project).

In summary, these devices should continue to be represented as input devices, but we can not add custom device attributes which duplicate information which the input layer already makes available. evstate can be used to query button state.

No AC status input device

We used to have an input device that monitored AC adapter presence. We don't any more. kbdshim should start using uevents to monitor this.

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.

synaptics disable tap-to-click

We want to disable tap-to-click on the synaptics touchpad. The solution to this was going to be to adopt the synaptics driver and use its standard functionality to control this, but a patch has been accepted upstream that disables the synaptics driver unconditionally on OLPC. Andres found it to be totally unusable after a few seconds (pad become super sensitive).

Assuming Andres' findings can be verified, we need a new approach to fixing this. One method may be exposing a debugfs node allowing us to send PS2 commands from userspace.

XO-1.5 rfkill

The rfkill approach to cut power to the wifi card was shot down by upstream, on the basis that we should use runtime power management to ensure that card power is cut when the interface is down.

This needs us to diagnose why runtime power management can't bring the card online again.

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

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.