User:DanielDrake/Kernel upstream implications: Difference between revisions
DanielDrake (talk | contribs) |
DanielDrake (talk | contribs) |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 26: | Line 26: | ||
=== rfkill === |
=== 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.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. |
For XO-1, a XO1_RFKILL x86 platform driver was merged upstream. |
||
| Line 44: | Line 44: | ||
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. |
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. |
|||
=== synaptics disable tap-to-click === |
|||
== 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. It may make sense to hack in the old wakeup reason patches for now. |
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 === |
|||
[http://dev.laptop.org/git/olpc-2.6/commit/?h=olpc-2.6.35&id=2ad89c259b64c4fd3a7ada2de0c2331527e4d719 This] needs to go upstream. My [http://marc.info/?l=linux-kernel&m=131643082232579&w=2 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). |
|||
Latest revision as of 17:38, 12 April 2012
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).