VirtualBox

Opened 14 years ago

Closed 8 years ago

Last modified 8 years ago

#6479 closed defect (obsolete)

XMonad active border does not work with guest additions (Ubuntu 9.10 64-bit, Win 7 host)

Reported by: crankydillo Owned by:
Component: guest additions Version: VirtualBox 4.0.4
Keywords: XMonad vboxdriver active border Cc:
Guest type: Linux Host type: Windows

Description

XMonad is a tiling window manager. By default, it paints a different color around the active window. When I use the vesa driver, the active border works perfectly. However, when I use guest additions with the vboxdriver, the active border color gets messed up. The only way I can tell which window is active is by the cursor. I would attach a screenshot, but the screenshot comes out fine.

Change History (14)

comment:1 by crankydillo, 14 years ago

I didn't mean for this to be major. For the most part, it's just an annoyance.

comment:2 by Michael Thayer, 14 years ago

Reproducible on a Fedora 13 guest. I added a bit of logging, and it seems that the X server doesn't send update notifications to the driver for those window borders. Not sure if this is a server bug or our driver doing something wrong, I will post to xorg-devel to ask.

comment:3 by Michael Thayer, 14 years ago

Once I have checked what XMonad is actually doing when it draws those borders that is.

comment:4 by Michael Thayer, 14 years ago

No need. XMonad uses windowSetBorder(), which in turn calls ChangeWindowAttributes() which calls FillPolyRect() inside the X server. We use the shadowfb server extension for getting notified that something has changed onscreen, and shadowfb doesn't monitor (potentially) accelerated operations like FillPolyRect(). Don't know why, but it probably wouldn't help much anyway. So the long and the short of this is that it will probably stay broken until I have time to add 2D accelerated operations to vboxvideo, I'm afraid.

comment:5 by lannm, 14 years ago

Using a compositing manager like xcompmgr seems to be an effective workaround for this, although it of course comes with its own problems, like an ugly background color for workspaces without windows (which can be fixed with hsetroot), and a small but noticeable performance hit switching workspaces.

comment:6 by Lex, 14 years ago

Reproducible on an Arch 2.6.34 guest in VirtualBox 3.2.6 under OS X. *Not* reproducible on a Debian Lenny (stable) guest under the same conditions. I am happy to help by providing more information if I can to fix this annoying bug.

comment:7 by poims, 13 years ago

I experience the same problems with a Mac OS X host and a Ubuntu 10.10 guest running scrotwm on Virtualbox 4.0.4.

comment:8 by Michael Thayer, 13 years ago

You might actually want to ask the X.Org people whether this is a bug in the server (see comment 4 for the details). I don't know whether this is working as intended, or whether it is an oversight in the server code.

comment:9 by Michael Thayer, 13 years ago

priority: majorminor
Version: VirtualBox 3.1.6VirtualBox 4.0.4

comment:10 by Keshav Kini, 12 years ago

CCing myself

in reply to:  description comment:11 by L29Ah, 11 years ago

cc

comment:12 by Tuzik, 10 years ago

Workround that worked for freshly installed Arch Linux- with XMonad startup script also run:

hsetroot -solid "#000000"
xcompmgr 
Last edited 10 years ago by Tuzik (previous) (diff)

comment:13 by aeichner, 8 years ago

Resolution: obsolete
Status: newclosed

Please reopen if still relevant with a recent VirtualBox release.

comment:14 by Michael Thayer, 8 years ago

Actually I think this was fixed in the upstream X.Org X server some time ago.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use