Bug#988315: xterm menu display garbled
On Thu, May 13, 2021 at 09:12:01AM +0200, Philipp Marek wrote: > > > > If that's the case, trying a different window manager (xfce4 for > > > > instance) > > > > would show if the window manager is the appropriate place to go. > > > > > > Sorry I'm running LXQT, which uses xfce4 by default: > > > > > >1755 ?Sl 0:00 \_ > > > /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd > > > > Those are utilities -- but the window manager defaults to openbox. > > Here's a slice from the output of pstree showing that: > > Ah yeah, right, sorry. > > $ wmctrl -m > Name: Xfwm4 > Class: xfwm4 > PID: 1728 > Window manager's "showing the desktop" mode: N/A > > apt tells me > > xfwm4 - window manager of the Xfce project > > and > > $ ps fax | grep openbox >389565 pts/15 S+ 0:00 | \_ grep openbox > $ > > so it looks like the window manager is not at fault. > > If I "ssh -X @localhost xterm", so that my personal > ~/.Xresources > don't apply, I can reproduce the blinking pixels; with "xpra" I still don't > have the right or bottom borders, but the blinking pixels do not appear. > >390309 ?RLl0:04 /usr/bin/python3 /usr/bin/xpra start > --ssh=ssh > -l ard --start=xterm >390310 ?Sl 0:01 \_ Xvfb-for-Xpra-S390306 +extension GLX > +extension Composite -scre >390452 ?S 0:00 \_ xterm >390511 pts/20 Ss 0:00 \_ sh >390519 pts/20 R+ 0:00 \_ ps fax > > xpra says "Client OpenGL: disabled", "window rendering: GTK3: Cairo (1)". > > glxinfo says (abbreviated): > > name of display: :0 > display: :0 screen: 0 > direct rendering: Yes > server glx vendor string: SGI > server glx version string: 1.4 > server glx extensions: > ... > client glx vendor string: Mesa Project and SGI > client glx version string: 1.4 > client glx extensions: > ... > GLX version: 1.4 > GLX extensions: > ... > Extended renderer info (GLX_MESA_query_renderer): > Vendor: Intel (0x8086) > Device: Mesa Intel(R) UHD Graphics 620 (KBL GT2) (0x5917) > Version: 20.3.4 > Accelerated: yes > Video memory: 3072MB > Unified memory: yes > Preferred profile: core (0x1) > Max core profile version: 4.6 > Max compat profile version: 4.6 > Max GLES1 profile version: 1.1 > Max GLES[23] profile version: 3.2 > OpenGL vendor string: Intel > OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2) > OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.3.4 > OpenGL core profile shading language version string: 4.60 > OpenGL core profile context flags: (none) > OpenGL core profile profile mask: core profile > OpenGL core profile extensions: > ... > OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.3.4 > OpenGL shading language version string: 4.60 > OpenGL context flags: (none) > OpenGL profile mask: compatibility profile > OpenGL extensions: > ... > OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.4 > OpenGL ES profile shading language version string: OpenGL ES GLSL ES > 3.20 > OpenGL ES profile extensions: > ... > 122 GLX Visuals > ... > > > Can I disable OpenGL for a single application or a single window, perhaps? I expect that the answer is "no". (this is in the area of "X server", though admittedly "add-ons"). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#988315: xterm menu display garbled
On Wed, May 12, 2021 at 08:38:03AM +0200, Philipp Marek wrote:
> > If that's the case, trying a different window manager (xfce4 for
> > instance)
> > would show if the window manager is the appropriate place to go.
>
> Sorry I'm running LXQT, which uses xfce4 by default:
>
>1755 ?Sl 0:00 \_
> /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
Those are utilities -- but the window manager defaults to openbox.
Here's a slice from the output of pstree showing that:
|-gdm3-+-gdm-session-wor-+-gdm-x-session-+-Xorg---5*[{Xorg}]
| | |
|-lxqt-session-+-lxqt-globalkeys---3*[{lxqt-globalkeys}]
| | | |
|-lxqt-notificati---10*[{lxqt-notificati}]
| | | |
|-lxqt-panel---11*[{lxqt-panel}]
| | | |
|-lxqt-policykit4*[{lxqt-policykit-}]
| | | |
|-lxqt-powermanag---2*[{lxqt-powermanag}]
| | | |
|-lxqt-runner---2*[{lxqt-runner}]
| | | | |-openbox
| | | |
|-pcmanfm-qt-+-dragon---15*[{dragon}]
| | | | |
`-12*[{pcmanfm-qt}]
| | | | |-ssh-agent
| | | | |-xmessage
| | | |
`-10*[{lxqt-session}]
| | | `-2*[{gdm-x-session}]
| | `-2*[{gdm-session-wor}]
| `-2*[{gdm3}]
I set up LXQT this morning, but none of the window managers which it offered
me as a choice were related to XFCE4, so I chose openbox. xterm seems to
run properly in that (see screenshot).
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Bug#988315: xterm menu display garbled
On Tue, May 11, 2021 at 10:59:16AM +0200, Philipp Marek wrote: > > It's possible that you have some font resource (such as a proportional > > font) which confuses it, causing it to write outside its window. > > XTerm*faceName: DejaVu Sans Mono actually Xaw uses only bitmap fonts (though some versions of fontconfig can be told to offer those fonts...) Thinking that locale might be a clue, I tried setting it to de_AT.UTF-8, without seeing any problems. > > But that would be apparent in xterm (thinking that a wildcard font > > resource which affects one would affect both). > > > > Given that, I'm expecting that the answer is that the X server > > (for some less-used device) is not handling the window properly. > > Hmmm > > 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev > 07) I can't tell :-( That gets into hardware dependencies. In your first comment, you mentioned "the few existing pixels blink". That makes it sound like the X server (since the contents of the window from xterm's point of view are generally static, unless programmed to blink using an escape sequence). If this had been simply a missing border, I'd ask about the window manager (noting that on a couple of machines, I see the gnome stuff overriding the resource-settings, while most window managers leave that alone). Then again (one of those was Fedora34, whose effect was apparent because it took about a second to _redraw_ the menu border), you might be using some version of gnome-session/-shell/-whatever, which has bugs in its attempt to redraw the border. If that's the case, trying a different window manager (xfce4 for instance) would show if the window manager is the appropriate place to go. (xterm has had its own problems with drawing, but so far this doesn't match any of the situations where I would assume xterm's at fault) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#988315: xterm menu display garbled
On Tue, May 11, 2021 at 08:00:24AM +0200, Philipp Marek wrote:
> > That's more likely a problem with the X server than xterm
> > (the menus are via Xaw, which is pretty stable).
>
> So the menus being cut off on the right and the bottom is on purpose?
>
>
> > For instance,
> > you might be using Wayland...
>
> No, I don't think so:
>
>1156 ?Ssl0:17 /usr/bin/sddm
>1199 tty7 Ssl+ 161:33 \_ /usr/lib/xorg/Xorg -nolisten tcp -auth
> /var/run/sddm/{ef674451-7b94-4f32-8c33-3e49df7fdecc} -background none
> -noreset -displayfd 17 -seat seat0 vt7
>
> And I don't have any other garbage on the display either...
Xaw (e.g,. libxaw7:amd64) draws the menus, but uses X resources.
In a quick check (looking at the debugging trace), I suppose that
xterm's event-loop may handle exposure events for the menus(*), but
xterm doesn't know what's in the menus, in that level of detail.
It's possible that you have some font resource (such as a proportional
font) which confuses it, causing it to write outside its window.
But that would be apparent in xterm (thinking that a wildcard font
resource which affects one would affect both).
Given that, I'm expecting that the answer is that the X server
(for some less-used device) is not handling the window properly.
(*) the debugging trace shows me the window-id, but not the creator...
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Bug#988315: xterm menu display garbled
On Mon, May 10, 2021 at 12:53:44PM +0200, Philipp Marek wrote: > Package: xterm > Version: 367-1 > Severity: minor > X-Debbugs-Cc: phil...@marek.priv.at > > Please see the attached screenshot. > > It doesn't matter which menu I open (Ctrl+left, Ctrl+right, ctrl+middle > mouse button) - the right and bottom borders are always missing. That's more likely a problem with the X server than xterm (the menus are via Xaw, which is pretty stable). For instance, you might be using Wayland... -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#988315: xterm menu display garbled
Package: xterm Version: 367-1 Severity: minor X-Debbugs-Cc: phil...@marek.priv.at Please see the attached screenshot. It doesn't matter which menu I open (Ctrl+left, Ctrl+right, ctrl+middle mouse button) - the right and bottom borders are always missing. I can't be sure there aren't menu entries missing at the end. Depending on the pixel position the right border sometimes partly exists (but the few existing pixels blink!). Thanks for your patience! -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de_AT:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xterm depends on: ii libc6 2.31-11 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.4+dfsg-1 ii libice6 2:1.0.10-1 ii libtinfo6 6.2+20201114-2 ii libutempter01.2.1-2 ii libx11-62:1.7.0-2 ii libxaw7 2:1.0.13-1.1 ii libxext62:1.3.3-1.1 ii libxft2 2.3.2-2 ii libxinerama12:1.1.4-2 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii libxt6 1:1.2.0-1 ii xbitmaps1.1.1-2.1 Versions of packages xterm recommends: ii x11-utils 7.7+5 Versions of packages xterm suggests: pn xfonts-cyrillic -- no debconf information
