You are not logged in.
The issue described in this thread is still outstanding for a number of users.
It seems to boil down to this: when using rxvt-unicode with xcompmgr and an Xft font (Liberation Mono, DejaVu Sans Mono, and Terminus were among those tested), the terminal cursor will disappear. Typing some text and pressing backspace will cause it to reappear.
Furthermore, the entire window sometimes disappears when switching workspaces in Openbox. Repeated workspace switches or minimizing / restoring the window (via a panel, such as tint2) can make it reappear.
A workaround is to set URxvt*cursorUnderline in ~/.Xdefaults, but some users prefer a block cursor.
Offline
Are there others who still experience this fault?
I run rxvt-unicode 9.12-1 with xcompmgr-dana 20091025-4 (and of course without compositing) and these font settings without any such problems in Openbox since more than a year:
URxvt*font: xft:DejaVu Sans Mono:antialias=true:pixelsize=11
URxvt*boldFont: xft:DejaVu Sans Mono:style=bold:antialias=true:pixelsize=11
URxvt*italicFont: xft:DejaVu Sans Mono:style=italic:antialias=true:pixelsize=11
URxvt*boldItalicFont: xft:DejaVu Sans Mono:style=bolditalic:antialias=true:pixelsize=11
To know or not to know ...
... the questions remain forever.
Offline
The problem is with the Intel video drivers only if I remember correctly. I know on my desktop (nvidia) my setup works just fine, but on my netbook (intel) the cursor disappears.
#binarii @ irc.binarii.net
Matrix Server: https://matrix.binarii.net
-------------
Allan -> ArchBang is not supported because it is stupid.
Offline
The suggestion of installing libxft-lcd was made. I did so, commented-out the URxvt*cursorUnderline line in ~/.Xdefaults, logged out of X, and restarted slim from tty1.
% ldd /usr/bin/urxvt | grep Xft
libXft.so.2 => /usr/lib/libXft.so.2 (0x00007fd35f179000)
% pacman -Qo /usr/lib/libXft.so.2
/usr/lib/libXft.so.2 is owned by libxft-lcd 2.2.0-1
After restarting slim, the problem persists. After rebooting, the problem still persists.
xterm does not exhibit this problem, nor does emacs. I use both programs with libxft and blinking block cursors, and they both work as expected. This seems to be an issue with running rxvt-unicode in combination with xcompmgr. From my POV, it doesn't seem that intel drivers are to blame, but I suppose I wouldn't rule them out.
Last edited by hexadecagram (2011-10-09 21:23:43)
Offline
same here, cursor still disapear
Offline
I change xft to regular font
!URxvt.font: xft:Consolas:pixelsize=14:autohint=true:antialias=true
URxvt.font:-*-Terminus-medium-*-*-*-14-*-*-*-*-*-*-r
And it works like charm
Last edited by peterkosov (2011-10-27 20:15:17)
Offline
The problem persists on my laptop (Intel video driver) with with urxvt+xcompmgr+xft font, as mentioned in the title.
Though, after playing a while with gcompmgr, I think the "-s" option ("Draw server-side shadows with sharp edges") may be involved with the cursor loss (when enabled, I get a cursor indication, seems more or less buggy, but indicates cursor position).
configs files on github -- keep up the good work, arch devs
Offline
I just tried urxvt again and had this same problem with xft:Inconsolata both with antialias on or off while using xcompmgr-dana.
Back to xterm again.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Oops, scratch that - the libxft-lcd fix worked for me.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I asked on the rxvt-unicode mailing list about this issue, and this is the response I got:
Both xcompmgr and (especially) the intel driver have numerous bugs which are far more likely to cause these issues than rxvt-unicode. You should try to reproduce this problem with a non-intel driver and without xcompmgr (i.e. use another driver and another compositing manager).
I am unable to do this at this time, as (purely by coincidence) all of my machines currently have Intel graphics chipsets. I have a few machines that I could test with a LiveCD, but don't expect I'll be able to do that very soon, as my plate is very full at the moment.
Figured it would be worth at least passing the message along.
Offline
It has been repeated many times, you can fix it by rebuilding xorg-server with the following changes (commenting one line, that is):
--- b/damageext/damageext.c.bak
+++ b/damageext/damageext.c
@@ -217,6 +217,6 @@ ProcDamageCreate (ClientPtr, client)
if (!AddResource (stuff->damage, DamageExtType, (pointer) pDamageExt))
return BadAlloc;
- DamageSetReportAfterOp (pDamageExt->pDamage, TRUE);
+// DamageSetReportAfterOp (pDamageExt->pDamage, TRUE);
DamageRegister (pDamageExt->pDrawable, pDamageExt->pDamage);
Offline