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.
Contents
No XO-1.5 ebook state file
Upstream aren't accepting more button-state files in sysfs. We have to use evdev to query button state for:
- Ebook switch
- Lid switch
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.
