Bug 1437 - SDL applications start transparently and can never be set to be fully opaque
Summary: SDL applications start transparently and can never be set to be fully opaque
Status: RESOLVED NOTOURBUG
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nVidia (proprietary) (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Andy Ritger
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-21 21:22 UTC by Mike MacCana
Modified: 2006-06-04 09:04 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
DOSBox window with XLIB_SKIP_ARGB_VISUALS=1 (8.03 KB, image/png)
2006-06-04 01:39 UTC, Paolo Basenghi
no flags Details
DOSBox window without XLIB_SKIP_ARGB_VISUALS=1 (89.59 KB, image/png)
2006-06-04 01:40 UTC, Paolo Basenghi
no flags Details

Description Mike MacCana 2004-09-21 21:22:55 UTC
Before I continue, its worth noting I'm using the proprietary nvidia driver.
Sorry, I don't have another video card or driver which supports accelerated
render needed to reproduce this bug.

With xcompmgr -cfC, QEmu (www.qemu.org) always starts with transparency set to
somewhere between 0.75 and 1.0. transset 1 doesn't make Qemu fully opaque,
though transset 0.75 makes it more transparent. 

Every other app on my system - I've tried about fifty or so - is fine. Just Qemu.

Fedora Rawhide, xorg 6.8, transset from CVS, qemu 0.6, proprietary nvidia driver
1.0.6111.

Am upgrading to 6.8.1 right now. Will let you know if the symptoms change.

PS. compmgr gives me a woody. good work guys.
Comment 1 Adam Jackson 2004-09-23 18:50:15 UTC
i suspect that QEMU is picking up the RGBA visual unintentionally.  try starting
qemu with XLIB_SKIP_ARGB_VISUALS=1
Comment 2 Mike MacCana 2004-09-27 21:12:51 UTC
Thanks for the quick response.

Setting the environment variable then runnign QEmu crashes the X server each time.
Comment 3 Adam Jackson 2004-09-27 21:34:40 UTC
freakish.  and i suppose since it's the nvidia driver you can't get a useful
backtrace...  i'll see if i can't reproduce this.
Comment 4 Mike MacCana 2004-09-30 21:01:21 UTC
This is an SDL issue.

SDL 1.2.7-7.1 from Rawhide.
Comment 5 Adam Jackson 2004-12-01 19:22:07 UTC
run 'xwininfo' on the SDL window and paste the output, please.  (assuming this
is still open.)
Comment 6 Adam Jackson 2005-01-11 23:03:17 UTC
mass component shift / reassign for proprietary nVidia driver bugs.
Comment 7 Aaron Plattner 2005-12-01 18:06:44 UTC
This is a bug in SDL.  It's choosing the 32-bit visual when it shouldn't, and
then not setting alpha to 1 in the pixels it produces.  I took a look at the
source and can't make much sense out of the visual selection code.  In
SDL_x11modes.c:X11_SupportedVisual, it compares the target depth against
this->hidden->visuals[i].bpp.  However, this is 32 for the all the visuals on my
system.  It looks like it should be looking at this->hidden->visuals[i].depth
instead.  You should probably take this up with the SDL maintainers.

XLIB_SKIP_ARGB_VISUALS=1 should work, and should not crash the X server.  If it
does crash the server even with X.org RC2, please get a backtrace.
Comment 8 Adam Jackson 2005-12-25 17:25:57 UTC
reporter, please verify that you can still crash the server, and attach a
backtrace if so.
Comment 9 Paolo Basenghi 2006-06-04 01:36:54 UTC
Same problem with DOSBox 0.65
My system is SuSE 10.1 on amd64, graphic card: NVidia FX5200 chipset with NVidia
accelerated driver installed (1.0-8762 x86_64), xgl and compiz from SuSE packages.

With XLIB_SKIP_ARGB_VISUALS=1 it appear to work well

I attach two DOSBox screenshot with and without XLIB_SKIP_ARGB_VISUALS=1

Bye
Comment 10 Paolo Basenghi 2006-06-04 01:39:14 UTC
Created attachment 5802 [details]
DOSBox window with XLIB_SKIP_ARGB_VISUALS=1
Comment 11 Paolo Basenghi 2006-06-04 01:40:11 UTC
Created attachment 5803 [details]
DOSBox window without XLIB_SKIP_ARGB_VISUALS=1
Comment 12 Adam Jackson 2006-06-04 09:04:07 UTC
ping timeout on the reported crash, and everything else indicates that this is a
bug in SDL.  NOTOURBUG.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.