Steps to reproduce: In some terminal, type "urxvt -name URxvtDbg -bl" to start a borderless rxvt-unicode window with default settings for everything else. Expected result: Terminal window displayed without border, but otherwise like any ordinary top level application window. Actual result: Window displayed unfocused in the upper left corner of the screen, even above a KDE panel at the top of the screen. No application icon in KDE task bar. Window won't receive focus when clicked. Selecting text from the window with the mouse seems to work. Trying to drag the window using Alt+Left mouse button as configured with KDE won't work but instead result in a strage rectangular selection. rxvt-unicode worked all right yesterday. Since then I did a bunch of updates, the most likely one to cause such issues seems to be the update to x11-base/xorg-server-1.5.0. I also recompiled all its drivers. There were no packages from any of the KDE categories involved in the update. I did a bit of debugging and found it interesting to notice that the check if (XInternAtom (dpy, "_MOTIF_WM_INFO", True) == None) in init.C was true, i.e. urxvt seems to believe KDE incapable of dealing with borderless windows and just enables Override Redirect to do it himself. So while this might not be the reaosn that triggered the issue for me, it might be a path to solve it. There are other bugs out there which look similar: http://bugzilla.xfce.org/show_bug.cgi?id=1877 https://bugs.launchpad.net/ubuntu/+source/eterm/+bug/36051 I'll try to turn the latter one into a patch for rxvt-unicode. Let's see. I'll attach my emerge --info and try to provide any other useful information you might request.
Please post your `emerge --info' too.
Created attachment 165085 [details, diff] Disable check for _MOTIF_WM_INFO This patch solves the issue for me, as it disables automatic enabling of override-redirect mode. As a result, the window manager (kwin) can handle both focusing behaviour and borderless display. I added a verbose comment to the head of the patch and would suggest keeping that in place, so people whose window manager won't honour decoration hints can find out that they would have to enable override-redirect to get the old behaviour. As the patch changes the runtime behaviour of rxvt-unicode, I think it should be applied in a revision bump.
Created attachment 165086 [details] emerge --info
Suggested patch to upstream mailing list as well: http://thread.gmane.org/gmane.comp.terminal-emulators.rxvt-unicode.general/243
Thanks.
(In reply to comment #4) > Suggested patch to upstream mailing list as well: > http://thread.gmane.org/gmane.comp.terminal-emulators.rxvt-unicode.general/243 Patch rejected upstream. Possible solutions: 1. Fix kwin, i.e. have it provide _MOTIF_WM_INFO. I haven't found a bug report about this in the upstream kde bugzilla. Haven't opened one myself, as I would like to know an authoritative document describing the use of _MOTIF_WM_INFO and MWM_HINTS_DECORATIONS first. 2. Fix xorg-server-1.5.0 and "urxvt --override-redirect". While having the window manager take care of omitting borders seems a nice and viable solution, the fact remains that an urxvt window with override-redirect mode enabled won't behave as it did with previous versions. This in itself is an issue which should be fixed. 3. Configure borderless window in kwin instead of urxvt. Using "kcmshell kwinrules" one can create a rule for urxvt windows to be displayed borderless. After doing so, users can drop the borderLess setting for urxvt and thus prevent the automatic activation of override-redirect mode.
I don't think this is a urxvt issue. When I start urxvt in 1.5, I get "Failed to initialize TTM buffer manager. Falling back to classic." Also, glxgears performance has dropped from ~800fps to ~60fps. I get the same thing when I run glxgears. I suspect this is a deeper issue...
(In reply to comment #7) > I get the same thing when I run glxgears. I suspect this is a deeper issue... I couldn't reproduce this with glxgears. Here it's a normally decorated window which can be focused and moved like any other. Could you reproduce the issue with urxvt? When you use xwininfo to get info about the glxgears window, does it say "Override Redirect State: yes" for you? It's "no" here. According to command line display, glxgears runs at about 800 FPS here. I noticed that sometimes updating my nvidia glx drivers resulted in the xorg-x11 driver getting selected. So maybe you might want to check "eselect opengl list". I would assume that the glxgears performance at least is unrelated to the urxvt override-redirect problem. But I'm not sure.
No. I mean I get the same warning ("Failed to initialize TTM buffer manager. Falling back to classic.") with glxgears. Perhaps this is a different issue. I'm on intel. Could you please check if you get this warning when running urxvt and/or glxgears? If not, I'll open another bug.
(In reply to comment #9) > Could you please check if you get this warning when running urxvt and/or > glxgears? If not, I'll open another bug. I see no such warning from either program. Different issue, I think. I'm on intel prescott CPU, nvidia GeForce 8400 GS GPU.
I have this issue as well with rxvt-unicode-9.05 and openbox-3.4.7.2. I can confirm that it's caused by xorg-server-1.5.0. However, I don't get any warnings when starting urxvt and I get a solid 7500 FPS in glxgears, so I suspect you have a separate OpenGL issue. It doesn't look like this issue is restricted to KDE, though.
I'd like to just add that this affects GNOME as well on my ~amd64.
Did you try to compile with vanilla? I've xorg-server 1.5.0 here with rxvt-unicode (but vanilla, because 256color and the other are not really supported) and I've no problem with -bl.
(In reply to comment #13) > Did you try to compile with vanilla? Tried that just now, with the new 1.5.0-r1 ebuild. Problem still reproducible. > I've xorg-server 1.5.0 here with rxvt-unicode (but vanilla, because 256color > and the other are not really supported) and I've no problem with -bl. How about "urxvt -name URxvtDbg --override-redirect"? Just to make sure it's not because of your window manager cooperating better with urxvt.
Created attachment 166956 [details] emerge --info
Comment on attachment 166956 [details] emerge --info > > Did you try to compile with vanilla? borderless=false makes urxvt work normally. otherwise confirm bug filer's experience. Use flag 'vanilla' does not make any difference for me with window mgr xmonad-0.7 or xmonad-0.8. Setting borderless results in the urxvt or urxvtc window being ignored by xmonad with xorg-server 1.5.1 and rxvt-unicode-9.05 or rxvt-unicode-9.05-r1 (i.e. built with use flags "afterimage perl truetype {vanilla | -vanilla}" did not try with vanilla only) emerge--info attached
(In reply to comment #6) > 1. Fix kwin, i.e. have it provide _MOTIF_WM_INFO. > I haven't found a bug report about this in the upstream kde bugzilla. Haven't > opened one myself, as I would like to know an authoritative document > describing the use of _MOTIF_WM_INFO and MWM_HINTS_DECORATIONS first. Filed upstream bug report: https://bugs.kde.org/show_bug.cgi?id=172028 Still no authoritative document for the mwm_hints protocol, though.
Sorry, for taking so long. Finally I was able to reproduce, and I can confirm this. And we're not the only distribution which is affected by this. I tested this on a Fedora 9 as it also has xorg-server 1.5 and they have the same problem. I'm not sure if this is caused by an internal change of xorg-server 1.5. I tinkering of adding the patch nevertheless upstream does not support it, but combine with a useflag and clear statement it's not supported by any parties if you run into any problems with the patch enabled. Any comments?
(In reply to comment #18) > Sorry, for taking so long. Finally I was able to reproduce, and I can confirm > this. And we're not the only distribution which is affected by this. I tested > this on a Fedora 9 as it also has xorg-server 1.5 and they have the same > problem. I'm not sure if this is caused by an internal change of xorg-server > 1.5. > > I tinkering of adding the patch nevertheless upstream does not support it, but > combine with a useflag and clear statement it's not supported by any parties if > you run into any problems with the patch enabled. Any comments? > That would be great if you could add a use flag that would fix this problem, as I also suffer from it.
I used this patch but it did not work for me. This problem persists after the patch with Xorg 1.5.
(In reply to comment #20) > I used this patch but it did not work for me. This problem persists after the > patch with Xorg 1.5. > I applied this patch to rxvt-unicode. Should it be applied to Xorg or my window manager(Compiz fusion)?
(In reply to comment #21) > (In reply to comment #20) > > I used this patch but it did not work for me. This problem persists after the > > patch with Xorg 1.5. > > > > I applied this patch to rxvt-unicode. Should it be applied to Xorg or my window > manager(Compiz fusion)? > UPDATE: Upon reboot it works now. But is not a true bordless window. The wallpaper sticks to some parts of the edge of the window...always on the bottom and on the left side. and the bottom right corner of the urxvt window looks messed up.
(In reply to comment #17) > Filed upstream bug report: https://bugs.kde.org/show_bug.cgi?id=172028 Fix for Kwin comitted to 3.5 branch and trunk: http://websvn.kde.org/?view=rev&revision=867241 http://websvn.kde.org/?view=rev&revision=871250 Kwin is only one of the affected WMs, though, so I still would prefer a solution in rxvt-unicode and/or xorg. I'm not even sure if xorg is behaving wrong now, or fixed some previous incorrect behaviour. After all, a window manager not handling a window with override-redirect at all seems to fit the description of override-redirect that I found somewhere, which stated that an OR-window would assume temporary windowmanager duties. So maybe xorg was broken before, I don't know. (In reply to comment #18) > I tinkering of adding the patch nevertheless upstream does not support it, > but combine with a useflag and clear statement it's not supported by any > parties if you run into any problems with the patch enabled. Any comments? +1 in favor of this approach. I still believe that patch to be the best solution. Up to you if you want a separate USE flag, or only a single "vanilla" USE flag to disable all patches, in order to avoid too many such patches. Personally I think the patch should be enabled by default.
(In reply to comment #22) > But is not a true bordless window. The > wallpaper sticks to some parts of the edge of the window...always on the bottom > and on the left side. and the bottom right corner of the urxvt window looks > messed up. Sounds like an issue with your Window manager or maybe even your window decorations engine. Separate bug, I'd say.
This is fixed in 9.05-r3. If you don't want the patch just activate the vanilla USE flag.
I wish this comment will be noticed even if the bug is now closed but I just switched to xorg-server 1.5.3-r2 and I encountered this problem too, but with the newest ebuild : rxvt-unicode 9.06 (#246275) which doesn't include the patch. Happens to me with fluxbox 1.1.1. I'm still curious about what is faulty, fluxbox not compliant with spec or rxvt-unicode which is a bit too forward. (emerge --info following)
Created attachment 181208 [details] emerge --info
(In reply to comment #26) > I encountered this problem too, but with > the newest ebuild : rxvt-unicode 9.06 (bug #246275) which doesn't include the > patch. Strange taht this patch was removed. I'll reopen this bug here, and ask for the patch to be re-added. I'll also comment on bug #246275.
(In reply to comment #28) > (In reply to comment #26) > > I encountered this problem too, but with > > the newest ebuild : rxvt-unicode 9.06 (bug #246275) which doesn't include the > > patch. > > Strange taht this patch was removed. I'll reopen this bug here, and ask for the > patch to be re-added. I'll also comment on bug #246275. Strange indeed. Please consider re-adding the patch to version 9.06. BTW, this isn't only a kwin bug. I'm a Gnome user and Metacity is affected as well (but only with xorg-server-1.5.0, not with earlier Xserver versions).
I can confirm this problem as well with x11-terms/rxvt-unicode-9.05 within x11-wm/fluxbox-1.1.1-r1 and x11-base/xorg-server-1.5.3-r6. I can't say if it was an issue with prior xorg-servers versions as I never tried it. I created a custom ebuild or rvxt-unicide (same version) that applies rxvt-unicode-9.05_no-MOTIF-WM-INFO.patch it does in fact correct the problem.
Ouch...of all the bizarre things: I just discovered that when I use my patched version of urxvt described above and actually launch a borderless session, the "ls -a" command add entries . and .. but doesn't show _any_ other hidden files(??). If I launch it with borders it works fine. That may be the strangest behavior I've ever seen.
(In reply to comment #30) > I can confirm this problem as well with x11-terms/rxvt-unicode-9.05. > I created a custom ebuild or rvxt-unicide (same version) that applies > rxvt-unicode-9.05_no-MOTIF-WM-INFO.patch (In reply to comment #31) > Ouch...of all the bizarre things: I just discovered that when I use my > patched version of urxvt described above and actually launch a borderless > session, the "ls -a" command add entries . and .. but doesn't show _any_ > other hidden files(??). If I launch it with borders it works fine. To rule out the possibility of some strangeness introduced by your ebuild, can you emerge rxvt-unicode-9.05-r3 which does include the patch? Can you reproduce your issue with this version? Can you attach the ls.strace generated by strace -f -o ls.strace -s 1024 ls -a
(In reply to comment #32) > To rule out the possibility of some strangeness introduced by your ebuild, can > you emerge rxvt-unicode-9.05-r3 which does include the patch? Can you reproduce > your issue with this version? Can you attach the ls.strace generated by > strace -f -o ls.strace -s 1024 ls -a I wasn't aware the patch was in rxvt-unicode-9.05-r3, or I just would have used that. The ls -a does in fact work fine in that version. I don't know what else is different in that version...mine was simply the rxvt-unicode-9.05 ebuild with that patch added...a seriously strange one for sure...and it only occurred in borderless sessions. Thanks!
(In reply to comment #33) > ...mine was simply the rxvt-unicode-9.05 > ebuild with that patch added...a seriously strange one for sure...and it only > occurred in borderless sessions. Thanks! > I have no idea what happened with that ebuild. I just recreated it and can't reproduce that ls behavior. No clue what that was about. Another note for anyone looking to get borderless urxvt windows under fluxbox without this patch...you can simply add this to your ~/.fluxbox/apps file: [app] (name=urxvt) (class=URxvt) [Deco] {NONE} [end] This works as long as you want all urxvt windows to be borderless.
(In reply to comment #34) > I have no idea what happened with that ebuild. I just recreated it and can't > reproduce that ls behavior. No clue what that was about. Maybe the directory in question /was/ in fact empty? Maybe because it got deleted and recreated, so a different shell showing the same current path was in fact using some other current directory? > [app] (name=urxvt) (class=URxvt) > This works as long as you want all urxvt windows to be borderless. Otherwise you might try to specify a class name using the -name argument to urxvt. Not using fluxbox here, haven't tried, but it should work.
(In reply to comment #35) > (In reply to comment #34) > > I have no idea what happened with that ebuild. I just recreated it and can't > > reproduce that ls behavior. No clue what that was about. > > Maybe the directory in question /was/ in fact empty? Maybe because it got > deleted and recreated, so a different shell showing the same current path was > in fact using some other current directory? > Nope...it was my home directory, full of hidden files and directories. I could do a urxvt -bl, and then ls -a which showed no hidden files except , and .., immediately follows my urxvt, and ls -a which did. For the life of me I can't duplicate it though...not a clue.
Had the same problem. (Brutally) applied proposed patch to =x11-terms/rxvt-unicode-9.06. Solved it. Thanks (even if this is not the cleanest fix we've seen ^^ ) As for upstream accepting a patch from us: http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#I_use_Gentoo_and_I_have_a_problem ... looks like they don't like us (url looks weird, you say? ;-° )
Jeroen, you may want to set vanilla to auto-enabled (USE="[..]. +vanilla") if you think users shouldn't disable this flag (you are warning the user when vanilla is disabled).
(In reply to comment #38) > Jeroen, you may want to set vanilla to auto-enabled (USE="[..]. +vanilla") if > you think users shouldn't disable this flag (you are warning the user when > vanilla is disabled). Good idea. I've just gone and done that. I have applied the patch to =x11-terms/rxvt-unicode-9.06-r2, and bug #260199 calls for stabilisation of =x11-terms/rxvt-unicode-9.05-r3 for now, so I can probably safely say now that this bug is fixed. Just reopen it if you do not agree.
