Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 229778 - Whole screen goes white on Beryl start-up
Summary: Whole screen goes white on Beryl start-up
Alias: None
Product: Fedora
Classification: Fedora
Component: beryl-core
Version: 6
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jarod Wilson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-23 14:22 UTC by Michael Cronenworth
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-02-23 19:07:24 UTC

Attachments (Terms of Use)

Description Michael Cronenworth 2007-02-23 14:22:48 UTC
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.

Everything you need to know to fix it is in that bug.

Comment 1 Jarod Wilson 2007-02-23 15:09:43 UTC
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 19:07:24 UTC
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 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.