Ticket #263 (Fixed)Thu Jan 20 07:34:17 UTC 2011
Screen slow cyclic shimmering when unblanking after DPMS (Touch Book)
| Reported by: | Trevor Johnson (329) | Severity: | Minor |
| Part: | RISC OS: General | Release: | |
| Milestone: | Status | Fixed |
Details by Trevor Johnson (329):
System
- ROOL ROM build 2010-12-05
- Touch Book v.1
- Not yet investigated on BeagleBoard
- Standard ROOL boot sequence, with addition of BeagleModes MDF (Touch Book mode setup) and KeyMapper module
- Will try again with standard 640×480 resolution when able to
- Initially categorised under ‘RISC OS:General’ – please move if that’s inappropriate
Issue
Screen slow cyclic shimmering on first try at unblanking:
- Under Configuration->Screen, set screensaver type to DPMS
- Tap Try
- After a second or so, unblank the screen – with the merest swipe of the touchpad.
- Desktop display returns but with some corruption, then fading/cycling by changing pixel colours1, including cycling through all white / all black
- With a blanking time configured, DPMS screensaver is invoked again correctly
- Another touchpad swipe correctly returns the desktop display
1 A screengrab doesn’t capture the effect – maybe Paint/RISC OS unblanks the screen again before the diaolgue box appears. I can arrange to take a few photos if this effect cannot be reproduced by anyone else.
Changelog:
Modified by Trevor Johnson (329) Thu, January 20 2011 - 13:15:29 GMT
Will try again with standard 640×480 resolution when able to
Setting the Monitor type to Auto reproduces the same effect. The 640×480 screen (huddling in the top left of the display) shimmers. Additionally:
- There’s wraparound from the top to the bottom
- No wraparound left to right
Note that the shimmering includes some squahsed aspects and ragged edges, not just colour cycling à la VDU 19.
Modified by Trevor Johnson (329) Fri, January 21 2011 - 14:39:21 GMT
A few more notes on this one:
- It may be useful to sneakily move the pointer away from the Try button after clicking on it (in the split second you have before the display is actually blanked), in order that the subsequent swipe doesn’t try to click on it.
- Note that the cyclic shimmering can remain for an extended period on ‘almost black’ although banding is visible – the coloured screen cycling returns after waiting long enough.
- With DPMS blanking configured with a timer, it can be invoked when an Edit window has the input focus. Again using the merest touchpad swipe to get the shimmer, keypresses are then visibly passed to Edit (although delayed), which displays them. The shimmer isn’t stopped by the keypresses, so RISC OS obviously thinks the display is functioning correctly.
- Ctrl-Shift-F12 shuts down the system as normal during a shimmer, although the message isn’t visibly rendered on the screen (both complete shutdown and <Return> for a restart).
- In attempting the above, I somehow executed the ‘Exit Desktop’ command via keypresses (dunno what the key combination was). The
*Supervisor prompt appeared at the top of a black screen as normal (display correctly restored). - <F12> correctly restores the display with a
*prompt beneath the desktop as normal.
Modified by Trevor Johnson (329) Mon, January 24 2011 - 10:43:32 GMT
Here’s the relevant CVS log.
Perhaps inserting a screen refresh after
<code>
+ (hwconfig->lcd_configs[current_lcd].power)(dev,65536);
</code>
in bsd/RiscOS/Sources/Video/HWSupport/OMAPVideo/c/dispc would do it. (That may be obviously right/wrong to any coders reading this… anyway, something for me to experiment with when I get the build environment set up again.)
Modified by Trevor Johnson (329) Mon, January 24 2011 - 10:49:00 GMT
<small>Re: Textile formatting in the bug tracker, how about entering a space?
<code>code </code></small>
Modified by Trevor Johnson (329) Mon, January 24 2011 - 10:49:54 GMT
i.e.
" + (hwconfig->lcd_configs[current_lcd].power)(dev,65536);"
Modified by Trevor Johnson (329) Mon, January 24 2011 - 10:50:16 GMT
Modified by Trevor Johnson (329) Mon, January 24 2011 - 12:49:18 GMT
A further attempt, using XML <notextile> tags …
<notextile>
+ (hwconfig->lcd_configs[current_lcd].power)(dev,65536);
</notextile>
i.e. "<notextile>
+ (hwconfig->lcd_configs[current_lcd].power)(dev,65536);
</notextile>"
Modified by Trevor Johnson (329) Mon, January 24 2011 - 12:51:31 GMT
<notextile>
<pre>
code
</pre>
</notextile>
Modified by Trevor Johnson (329) Mon, January 24 2011 - 21:28:26 GMT
- Attachment added: filer600px_noscrollbar.png
Modified by Trevor Johnson (329) Mon, January 24 2011 - 21:39:23 GMT
Well done, Trevor: that attachment was for Ticket #264. Sorry, everyone!
Modified by Jeffrey Lee (213) Sat, March 19 2011 - 18:50:46 GMT
- Status changed from Open to Fixed
This bug should be fixed now. It looks like the problem was that the pixel clocks weren’t being turned on/off until the next overlay update. So when you gently nudge the mouse to re-enable the display, the backlight would turn back on, but the change in position of the cursor overlay would cause the pixel clocks would turn off, leading to the shimmering effect. Moving the mouse again would then cause the delayed ‘turn clocks on’ request to be processed and everything would go back to normal.
