Bug 229778 - Whole screen goes white on Beryl start-up
Summary: Whole screen goes white on Beryl start-up
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: beryl-core   
(Show other bugs)
Version: 6
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jarod Wilson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
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:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-23 19:07:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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. 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 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
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.