Index | Thread | Search

From:
Walter Alejandro Iglesias <wai@roquesor.com>
Subject:
Re: urvt vs xterm
To:
Marc Espie <marc.espie.openbsd@gmail.com>
Cc:
ports@openbsd.org
Date:
Thu, 11 Jun 2026 14:21:57 +0200

Download raw body.

Thread
    • Walter Alejandro Iglesias:

      urvt vs xterm

      • Marc Espie:

        urvt vs xterm

        • Walter Alejandro Iglesias:

          urvt vs xterm

        • Jan Stary:

          urvt vs xterm

  • Stuart Henderson:

    urvt vs xterm

  • On Thu, Jun 11, 2026 at 11:08:29AM +0200, Marc Espie wrote:
    > On Wed, Jun 10, 2026 at 04:13:30PM +0200, Walter Alejandro Iglesias wrote:
    > > On Wed, Jun 10, 2026 at 08:41:46AM +0200, Marc Espie wrote:
    > > > On Wed, Jun 10, 2026 at 12:39:50AM +0200, Kirill A. Korinsky wrote:
    > > > > On Tue, 09 Jun 2026 22:09:00 +0200,
    > > > > Marc Espie <marc.espie.openbsd@gmail.com> wrote:
    > > > > > 
    > > > > > I've recently started using urxvt instead of xterm everywhere,
    > > > > > in major part because xterm was losing glyphs, and after a few months
    > > > > > of not figuring out why (and asking the guys in charge of X11 and drm
    > > > > > I didn't get any useful answer for my setup) I decided to switch.
    > > > > >
    > > > > 
    > > > > I not completley understand what do you mean as "losing glyphs" but if you
    > > > > mean text on resize of screen...
    > > > 
    > > > No, it's just some glyphs on my xterm that would randomly not show. With
    > > > absolutely zero error messages and randomness. And it would happen after
    > > > a while, that could be some random e that would not show. Quite infuriating.
    > > 
    > > I also don't understand the problem you explain.  Some questions:
    > > 
    > >   - Does it happen with unicode only or also with ascii?
    > 
    > Basic ascii letters.
    > 
    > >   - Does it happen using TrueType or bitmap fonts?
    > 
    > My xterm resources are as follow:
    > 
    > XTerm*saveLines:        1500
    > *VT100.popOnBell:       true
    > *VT100.colorBD:         white
    > *VT100.colorUL:         yellow
    > XTerm*VT100.backarrowKey:       true
    > *SimpleMenu.background: gray75
    > *SimpleMenu.foreground: black
    > *VT100.background:      black
    > *VT100.foreground:      white
    > *VT100*color12: SteelBlue1
    > *VT100*color4: RoyalBlue2
    > XTerm*cursorColor:      red
    > *VT100.scrollbar.foreground: cornflowerblue
    > *VT100.scrollbar.background: gray20
    > *VT100.scrollBar:       true
    > *.VT100.faceName: LucidaConsole:rgba=rgb
    > *.VT100.faceSize: 12.0
    > *.VT100.faceSize1: 4.0
    > *.VT100.faceSize2: 6.0
    > *.VT100.faceSize3: 8.0
    > *.VT100.faceSize4: 10.0
    > *.VT100.faceSize5: 14.0
    > *.VT100.faceSize6: 16.0
    > 
    > so this is an xft font.
    > 
    > >   - As TrueType, do you use DejaVu Sans Mono?
    > Not as far as I know.
    > 
    > >   - Have you tried to reproduce the bug with another window manager?
    > >     I remember many times, occasionally, and this is not recent, to
    > >     notice strange behaviors with xterm in fvwm2, I never stopped to
    > >     investigate why.
    > 
    > I use fvwm2 from ports because of the xinerama support (dual-screen display)
    > along with xcompmgr, added when chromium starting doing crap with expose
    > events, so I don't think that's quite the issue.
    
    Not using xcompmgr will probably improve the situation.  Using bitmap
    fonts will also help.
    
    > 
    > >   - Do you use custom settings in ~/.Xdefaults or ~/.fonts.conf?
    > Yes, you got my defaults.
    > 
    > "Lucida Console" comes form 30-lucida-aliases.conf
    
    In that file, Lucida Console is aliased to DejaVu Sans Mono.  If you're
    not using a custom ~/.fonts.conf then you're using DejaVu Sans Mono,
    which is the default (and the less problematic.)
    
    > 
    > >   - Which graphics do you use?  Does it happen with other machines?
    > 
    > No, it only happens on my home machine.
    > 
    > inteldrm0 at pci0 dev 2 function 0 "Intel UHD Graphics 630" rev 0x03
    > drm0 at inteldrm0
    > inteldrm0: msi, COMETLAKE, gen 9
    
    Does this machine use modesetting or falls back to the legacy intel
    driver?
    
    > 
    > The symptom is that after a while of gfx use (lots of mpv running here),
    > some terminals would randomly lose letters... Some ascii glyphs would
    > stop rendering, a bit like there was a fixed size memory buffer, and it
    > would silently overflow without erroring out.
    > 
    > Opening another xterm would restore normalcy for a bit of time.
    > 
    > After a day or two, I had to reboot the machine because the problem
    > would happen quicker and quicker.
    > 
    > 
    > Never got any idea how to debug it... perfectly silent error, no message
    > in any log, and couldn't figure out what to set to make it emit actual
    > errors.
    > 
    > 
    > Of course, drm would emit all kinds of warning messages, as it does all
    > the time. Right now, my dmesg is full of
    > i915_gem_userptr_ioctl: stub
    > 
    > with apparently zero ill effect.
    
    Not an expert here but taking a look to the code, seems that what that
    message warns is that that function is not been used?
    
    On sys/dev/pci/drm/i915/gem/i915_gem_userptr.c:510:
    
    
            if (args->flags & I915_USERPTR_PROBE) {
                    /*
                     * Check that the range pointed to represents real struct
                     * pages and not iomappings (at this moment in time!)
                     */
    #ifdef notyet
                    ret = probe_range(current->mm, args->user_ptr, args->user_size);
                    if (ret)
                            return ret;
    #else
                    STUB();
                    return -ENOSYS;
    #endif
            }
    
    
    Someone who really understands about this (not me :-)) might be able to
    say if this is related to the problem.
    
    
    -- 
    Walter
    
    
  • Stuart Henderson:

    urvt vs xterm