#10190 closed defect (fixed)
suspend during Record activity results in wackier behaviour than before
| Reported by: | dsd | Owned by: | dsd |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | kernel | Version: | Development build as of this date |
| Keywords: | Cc: | corbet | |
| Blocked By: | Blocking: | ||
| Deployments affected: | Action Needed: | no action | |
| Verified: | no |
Description
On XO1, when suspending while displaying video from the camera in previous OS release (8.2), upon resume the colours were psychadelic. Moving the mouse returned things to normal.
On the F11 images we have regressed, moving the mouse results in the colours going pink/blue and the real colours can only be restored by stopping and restarting recording. (or changing vt)
I suspect the lxfb driver is not saving/restoring a certain register correctly.
Chris suggests dumping the VGA CRT/SEQ space either side of the vt switch.
Change History (5)
comment:1 Changed 7 years ago by dsd
comment:2 Changed 7 years ago by dsd
- Cc corbet added
- Summary changed from suspend during Record activity results in wacky colours to suspend during Record activity results in wackier behaviour than before
OK, I got sidetracked with looking at the video driver. There are 2 bugs at hand:
The psychadelic colours after resume is a bug in lxfb or something. Xv video goes funky if you suspend/resume while it happens. Filed as #10200
The regression to this bug, in that on F11 images the colours do not return to normal even after moving the mouse is due to a bug in cafe_ccic (the colours go from psychadelic to pinky/bluey). Simple test case to reproduce, avoiding the Xv bug by using regular X11 rendering:
stop prefdm xinit /usr/bin/gst-launch v4l2src ! ffmpegcolorspace ! ximagesink
With the camera feed on-screen, close the lid to suspend the laptop. Open it again, and observe pinky/bluey colours.
The cause of this regression is that this commit was never sent upstream or carried forward: http://dev.laptop.org/git/olpc-2.6/commit/?h=testing&id=6db90c293d78cfa7bbbcc6fc035e856a491eaec3 "cafe_ccic: fix up locking during suspend (hopefully..)"
I suspect the core part of the commit is the fact that we don't temporarily power down the camera during resume if someone is using it.
I'm going to forward port the commit to the 2.6.31 kernel. Jon, is this suitable for upstream, or can you suggest an alternate version?
comment:3 Changed 7 years ago by dsd
- Resolution set to fixed
- Status changed from new to closed
Regression fixed with the forward-port of that patch, tested in a local build using olpc kernel.
We're back to the less-wacky behaviour of 8.2 (move the mouse to fix the colours). Jon, still interested in your comments w.r.t. upstreaming this fix.
comment:4 Changed 7 years ago by Quozl
- Action Needed changed from diagnose to no action
- Milestone changed from 1.0-software-update to 10.1.2
- Version changed from not specified to Development build as of this date
Switching VT isn't the key. This causes Record to stop and then later resume the video feed, avoiding the issue.
Switching the VT alone is not enough to restore good colours. And the kernel seems to back up huge ranges of registers already during S/R.
The only way to restore colours is to stop the feed and start it again. I'm investigating which part of that sequence is the key.