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

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