User:DanielDrake/Kernel upstream implications: Difference between revisions
DanielDrake (talk | contribs) No edit summary |
|||
| Line 1: | Line 1: | ||
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. |
|||
This page lists the userspace-visible changes that have occurred during the process of getting OLPC's kernel patches upstream. |
|||
== |
== 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 <tt>cat</tt>. |
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 <tt>cat</tt>. |
||
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 <tt>evtest</tt>. powerd (and switchd?) need to be modified. |
|||
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 [http://dev.laptop.org/~dsd/20110702/evstate.c 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. |
|||
| ⚫ | 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. |
||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
=== 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. |
|||
| ⚫ | |||
For XO-1, a XO1_RFKILL x86 platform driver was merged upstream. |
|||
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). |
|||
== Non-upstream patches that we merged anyway == |
|||
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. |
|||
== |
=== 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. [http://article.gmane.org/gmane.linux.kernel.input/21932 Here] is a problem statement. |
|||
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. |
|||
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. |
|||
This needs us to diagnose why runtime power management can't bring the card online again. |
|||
Once the work gets merged upstream, we should go with the upstream version and modify powerd to use the interface that went upstream. |
|||
| ⚫ | |||
== Pending work == |
|||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
We want to disable tap-to-click on the synaptics touchpad. We have a hack patch in olpc-2.6.35 for this, but we should continue hammering at the upstreamable approach: the Absolute mode enabled by the synaptics driver has been deemed unsuitable (it generates huge amounts of traffic, by design, and actually overloads the EC). So we should [http://article.gmane.org/gmane.linux.kernel.input/21900 enable relative mode] as an option in the synaptics driver, at the same time exposing tap-to-click control. After that gets accepted, the synaptics driver will need to be modified to remove the XO-1.5 blacklist entry (which was added due to the EC overload). |
|||
== wakeup reason == |
== 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. |
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. |
||
Revision as of 09:26, 17 October 2011
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.
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.
Pending work
synaptics disable tap-to-click
We want to disable tap-to-click on the synaptics touchpad. We have a hack patch in olpc-2.6.35 for this, but we should continue hammering at the upstreamable approach: the Absolute mode enabled by the synaptics driver has been deemed unsuitable (it generates huge amounts of traffic, by design, and actually overloads the EC). So we should enable relative mode as an option in the synaptics driver, at the same time exposing tap-to-click control. After that gets accepted, the synaptics driver will need to be modified to remove the XO-1.5 blacklist entry (which was added due to the EC overload).
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.