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!
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...
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...
So the menus being cut off on the right and the bottom is on purpose?
No, I don't think so:
1156 ? Ssl 0: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...
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...
Hmmm.... 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
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. 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)
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. 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)
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-policykit----4*[{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).
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-policykit----4*[{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).
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 <other-user>@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 ? RLl 0: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").
I expect that the answer is "no". (this is in the area of "X server", though admittedly "add-ons").