Red Hat Bugzilla – Bug 503101
Plymouth video resolution flicker from lower to higher just before default gdm login prompt
Last modified: 2009-12-18 04:29:58 EST
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) 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.
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
As described in the "Details" section... Plymouth flickers to the default gdm login prompt.
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.
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 ?
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.
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(?)
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.
Created attachment 348262 [details]
Xorg.0.log of KMS boot with vga=323 and gdm switching to native resolution
(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.
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..
Do you still have this issue with fedora 12 (you can test livecd from http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/) ?
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:
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.