Bug 229778 - Whole screen goes white on Beryl start-up
Whole screen goes white on Beryl start-up
Product: Fedora
Classification: Fedora
Component: beryl-core (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-02-23 09:22 EST by Michael Cronenworth
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-23 14:07:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Cronenworth 2007-02-23 09:22:48 EST
Description of problem: If Beryl is your main Window Mananger and you login and
you have a nVidia card, the entire screen goes white when Beryl starts up. This
is 64-bit specific as 32-bit machines do not experience a white screen and work
just fine.

Version-Release number of selected component (if applicable): 0.1.9999.x

How reproducible: Always

Steps to Reproduce:
1. 64-bit machine, nVidia card and nVidia driver
2. Beryl set as Window manager
3. Login to desktop
Actual results: White screen

Expected results: Desktop screen

Additional info: This bug has already been deemed a Fedora packaging bug on the
Beryl bug tracking system. http://bugs.beryl-project.org/ticket/848

Everything you need to know to fix it is in that bug.
Comment 1 Jarod Wilson 2007-02-23 10:09:43 EST
Crap. You know, I noticed that a hard-coded rpath had snuck in there somehow at
some point, but hadn't made the connection and forgot about it. I'll get that
fixed shortly.
Comment 2 Jarod Wilson 2007-02-23 14:07:24 EST
Okay, so that ticket does NOT contain all the info needed to fix this properly,
since I'm using an already-generated configure, as provided by a "release"
tarball, rather than packaging the snapshot of the day that requires use of
autogen.sh. In theory, an autoreconf might have fixed the problem, but I went
with a different approach (sed'ing the libtool that results from ./configure) to
fix the problem, and new builds, sans-rpath, are on their way through the build
system now.

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