Bug 38823 - [uxa ilk] transparent terminals have no border under some window managers
Summary: [uxa ilk] transparent terminals have no border under some window managers
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-30 08:06 UTC by David J. Haines
Modified: 2012-11-20 18:28 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
X.org log. (32.96 KB, text/plain)
2011-06-30 08:35 UTC, David J. Haines
no flags Details
lspci output (1.33 KB, text/plain)
2011-06-30 08:36 UTC, David J. Haines
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David J. Haines 2011-06-30 08:06:28 UTC
I think I've traced it down to the intel driver, as it works correctly with Option "Shadow" "True" or if you use the vesa driver, so I'm reporting it here.

Bug description:

The use of true transparency on terminals that support it (e.g. urxvt, XFCE's Terminal, and gnome-terminal) causes certain window managers (e.g. Xmonad and awesome) to not display a border around the terminals as they should. When you use the VESA driver, everything works, albeit slowly, so I'm 99% sure it's the intel driver's issue.

System environment: 
-- chipset: i915
-- system architecture: 64-bit
-- xf86-video-intel: 2.15.0
-- xserver: xorg 1.10.2
-- mesa: 7.10.3
-- libdrm: 2.4.25
-- kernel: 2.6.39
-- Linux distribution: Arch
-- Machine or mobo model: HP Compaq 8100 Elite Small Form Factor Business PC
-- Display connector: VGA

Reproducing steps:

Install xmonad, xmonad-contrib, dmenu, xterm, and rxvt-unicode.
Bring up X with Xmonad as your window manager.
Add the following to ~/.Xresources:
    URxvt.depth: 32
    URxvt.foreground:White
    URxvt.background:[50]Black
run xrdb -merge ~/.Xresources
Run (alt-p, assuming dmenu is installed) xterm; note the border and how it activates on mouse-over.
Run urxvt -depth 24; note the same border.
Run urxvt (with -depth 32 if you really want to confirm the default); note the lack of such border.

Additional info:
Comment 1 David J. Haines 2011-06-30 08:08:20 UTC
I forgot to mention: if you set a client's opacity with the xprop tool (e.g. "xprop -frame -f _NET_WM_WINDOW_OPACITY 32c -set _NET_WM_WINDOW_OPACITY 0x80000000"), both the window and its border are there, just fainter both.
Comment 2 Chris Wilson 2011-06-30 08:24:23 UTC
Can you attach Xorg.log and/or lspci so that I can confirm the graphics chipset?
Comment 3 David J. Haines 2011-06-30 08:34:45 UTC
(In reply to comment #2)
> Can you attach Xorg.log and/or lspci so that I can confirm the graphics
> chipset?

Yeah, I can't read, it's an i965. My bad. I'm attaching both in a few.
Comment 4 David J. Haines 2011-06-30 08:35:58 UTC
Created attachment 48597 [details]
X.org log.
Comment 5 David J. Haines 2011-06-30 08:36:22 UTC
Created attachment 48598 [details]
lspci output
Comment 6 Chris Wilson 2011-06-30 08:49:50 UTC
Hmm, using awesome on my i5 atm, and urxvt -depth 32 does generate a terminal with a differently coloured border. Now I'm pretty sure the code is just doing what's asked... So time to check what the code is being asked to do. :)
Comment 7 David J. Haines 2011-06-30 08:52:16 UTC
(In reply to comment #6)
> Hmm, using awesome on my i5 atm, and urxvt -depth 32 does generate a terminal
> with a differently coloured border. Now I'm pretty sure the code is just doing
> what's asked... So time to check what the code is being asked to do. :)

The oddest bit is that VESA draws everything right, so I can only think that it's somewhere in the acceleration code. Then again, I didn't finish my CE/EE major, so I'm not an expert. ;)
Comment 8 Chris Wilson 2011-07-10 08:01:21 UTC
I can no longer reproduce with an updated awesome + sna.
Comment 9 David J. Haines 2011-07-10 14:06:11 UTC
(In reply to comment #8)
> I can no longer reproduce with an updated awesome + sna.

Would that be available if I were to build the driver off of git?
Comment 10 Chris Wilson 2011-07-12 04:02:59 UTC
Yes, sna is a compile-time feature in xf86-video-intel.git (./configure --enable-sna). It would be nice if you could check for the sake of my sanity.
Comment 11 David J. Haines 2011-07-12 07:31:52 UTC
(In reply to comment #10)
> Yes, sna is a compile-time feature in xf86-video-intel.git (./configure
> --enable-sna). It would be nice if you could check for the sake of my sanity.

It works on my system as well under Xmonad. Your sanity can remain intact.
Comment 12 Paweł Rumian 2012-03-22 05:53:03 UTC
I am facing probably the same problem, but it does not look like it is connected with intel driver, but rather the compositing. In my case it happens both with the open source radeon driver on r600 and with intel driver on i915, both 32 and 64 bit. When compositor is not running, the borders are OK.

This is a strange thing, as the author of rxvt-unicode claims it is probably WMs fault, and the WM maintainers say it cannot be theirs. So maybe it's a server-side problem?

Three links:
http://lists.schmorp.de/pipermail/rxvt-unicode/2009q1/000906.html (also the following post)
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=490
https://bbs.archlinux.org/viewtopic.php?id=101669
Comment 13 Chris Wilson 2012-03-22 05:59:40 UTC
Hi Pawel, the conclusion we came to here was that it was a driver bug.
Comment 14 Paweł Rumian 2012-03-22 06:06:10 UTC
Hmm, OK, then sorry for the mess.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.