Bug 503101 - Plymouth video resolution flicker from lower to higher just before default gdm login prompt
Plymouth video resolution flicker from lower to higher just before default gd...
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2009-05-28 16:53 EDT by Francis Shim
Modified: 2009-12-18 04:29 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-18 04:29:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log - X server log file (124.67 KB, text/plain)
2009-05-29 13:25 EDT, Francis Shim
no flags Details
Xorg.0.log of KMS boot with vga=323 and gdm switching to native resolution (75.77 KB, application/octet-stream)
2009-06-17 10:36 EDT, Ralf ter Veer
no flags Details

  None (edit)
Description Francis Shim 2009-05-28 16:53:14 EDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2009042708 Fedora/3.0.10-1.fc10 Firefox/3.0.10

The Plymouth graphical boot animation starts at a lower resolution (showing the default solar graphical animation) until it switches to the default gdm login prompt when it "flickers" to a higher resolution.  The initial graphics window contents (ie: default solar graphics) are reduced in size and placed in the upper left corner of the monitor screen with "striped" video garbage filling the rest of the monitor screen (right and bottom)... then the default gdm login prompt fades in and the video resolution remains steady at the higher resolution.

Ideally, Plymouth should simply start at the higher (ie: highest) resolution so that there would be no flicker in the transition to the default gdm login prompt.  This bug is probably due to incorrect detection and/or setting of the proper video mode (kernel mode setting problem) by Plymouth on start up and/or might indicate some confusion as to which X driver to use (ati, vesafb, radeonfb etc).  Another possible explanation could be that the graphics for the default solar animation can not be displayed at the highest resolution, in which case, it is simply a matter of adjusting the solar animation to be displayable at higher resolutions than it's current capability.

The relevant video card in use is an ATI Technologies Inc RV350 AS [Radeon 9550] card.  This video card is being used with a ViewSonic Professional Series P810 monitor which is capable of 1920x1440 @ 60 Hz resolution.

Reproducible: Always

Steps to Reproduce:
1. Boot up latest Fedora 10 with the video card and monitor configuration given
2. Carefully observe the default solar Plymouth animation until the default gdm login prompt
3. Note the "flicker"/change in video resolution
Actual Results:  
As described in the "Details" section... Plymouth flickers to the default gdm login prompt.

Expected Results:  
Plymouth should simply start at the highest resolution and stay "flicker-free"/steady throughout the entire graphical boot process and into the default gdm login prompt.

I believe the necessary hardware configuration should be with the

  * ATI Technologies Inc RV350 AS [Radeon 9550] video card
  * monitor capable of 1920x1440 @ 60 Hz resolution

running the latest Fedora 10 distribution.
Comment 1 Ray Strode [halfline] 2009-05-29 09:31:23 EDT
I believe the kernel driver and X both have heuristics for figuring out the initial resolution of the monitor, and the heuristics need to match.  Seems like they might not be matching here.

Mind attaching your Xorg.0.log ?
Comment 2 Francis Shim 2009-05-29 13:25:38 EDT
Created attachment 345933 [details]
Xorg.0.log - X server log file

As requested, please find attached a copy of the Xorg.0.log file for this bug report and hardware configuration.
Comment 3 Francis Shim 2009-06-15 01:08:47 EDT
I have not noticed any movement on this bug so instead of just the Xorg.0.log, I decided to look at the DRM related system messages on boot-up/initialization of the kernel.  Here is the result which shows that the "mis-match" of the Kernel Modesetting heuristics in the kernel driver (radeondrmfb) and via then the X server setting the mode (presumably through the KMS).

$ dmesg | grep drm
[drm] Initialized drm 1.1.0 20060810
[drm] Forcing AGP to PCI mode
[drm] Detected VRAM RAM=262144K, accessible=262144K, BAR=262144K
[drm] Default TV standard: NTSC
[drm] 27.000000000 MHz TV ref clk
[drm] DFP table revision: 3
fbcon: radeondrmfb (fb0) is primary device
[drm] DAC-6: set mode 1280x1024 13
fb0: radeondrmfb frame buffer device
[drm] Loading R300 Microcode
[drm] Num pipes: 1
[drm] writeback test succeeded in 2 usecs
[drm] Initialized radeon 1.29.0 20080528 on minor 0
[drm] DAC-6: set mode 1920x1440 1e

The question here is whether to assigned this bug to the kernel radeondrmfb driver instead of xorg-x11-drv-ati.  It would make sense that the two development efforts should have such common coding in a library to ensure consistent heuristics(?)
Comment 4 Ralf ter Veer 2009-06-17 10:34:09 EDT
I see the same issue on my ATI 3470 (RV620) Laptop.
The native resolution of my display is 1366x768 (which works fine using Xorg's radeon driver without xorg.conf)

Plymouth aka radeondrmfb doesn't use this resolution.
If I do not supply any vga=x line then I see the fallback boot animation.
Scanning for available mode lines  does just give me the (non widescreen) VESA resolutions. Therefore supplying vga=323 gives low-res Plymouth and the issue described by the bug opener.

s-c-d does not show the supported resolutions either and just gives 640/800/1024er choices.
Comment 5 Ralf ter Veer 2009-06-17 10:36:59 EDT
Created attachment 348262 [details]
Xorg.0.log of KMS boot with vga=323 and gdm switching to native resolution
Comment 6 Francis Shim 2009-06-18 15:54:32 EDT
(In reply to comment #4)
> I see the same issue on my ATI 3470 (RV620) Laptop.

just for completion and comparison, could you also include thee output from running the following command as root:

    dmesg | grep drm

I am curious as to whether you got similar DRM messages.
Comment 7 Ralf ter Veer 2009-06-18 17:26:45 EDT
Sorry, could only look it up from log backups:

[drm] Initialized drm 1.1.0 20060810
radeon 0000:06:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
radeon 0000:06:00.0: setting latency timer to 64
[drm] Initialized radeon 1.30.0 20080528 for 0000:06:00.0 on minor 0

Might not be of much help as it seems like KMS hasn't been active anymore on that system..
Comment 8 Jérôme Glisse 2009-10-15 10:32:17 EDT
Do you still have this issue with fedora 12 (you can test livecd from http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/) ?
Comment 9 Bug Zapper 2009-11-18 05:03:43 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 10 Bug Zapper 2009-12-18 04:29:58 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.