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:
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.
Can you attach Xorg.log and/or lspci so that I can confirm the graphics chipset?
(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.
Created attachment 48597 [details] X.org log.
Created attachment 48598 [details] lspci output
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. :)
(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. ;)
I can no longer reproduce with an updated awesome + sna.
(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?
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.
(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.
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
Hi Pawel, the conclusion we came to here was that it was a driver bug.
Hmm, OK, then sorry for the mess.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/8.
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.