Bug#1070293: xkb-data: typo in URL in the copyright file

Package: xkb-data Version: 2.41-2 Severity: minor In /usr/share/doc/xkb-data/copyright the URL https://xorg.freedesktop.orgreleases/individual/data/xkeyboard-config is incorrect. A slash is missing before "releases". A trailing slash should also be added to avoid a redirection. Correct URL:

Bug#1060108: xbase-clients: should not depend (not even recommend) xinit

Package: xbase-clients Version: 1:7.7+23 Severity: normal The xbase-clients package is there to provide only X clients, not an X server. This package currently depends on xinit, which has the effect to install an X server. The goal of xinit is to start an X server; this utility is not an X

Bug#1055243: libinput10: invalid URL in Xorg logs due to incorrect HTTP_DOC_LINK value

Package: libinput10 Version: 1.22.1-1 Severity: minor In my Xorg logs (e.g. Keyb/var/log/Xorg.0.log), I get messages like [ 10491.518] (EE) event14 - VEN_04F3:00 04F3:311C Touchpad: kernel bug: Touch jump detected and discarded. See

Bug#1038939: xserver-xorg-core: Xorg crashed after a Ctrl-C in an xterm

Package: xserver-xorg-core Version: 2:21.1.7-3 Severity: important In the morning, shortly after a kernel upgrade (I hadn't rebooted yet), Xorg crashed immediately after I typed Ctrl-C in an xterm (because I ran a command with lots of output). An excerpt of the journalctl output, though this is

Bug#633849: Processed: [bts-link] source package xorg

[I should have Cc'd this to the bug. Sending a copy now.] tags 633849 wontfix - fixed-upstream thanks The upstream bug was closed because "there isn't enough maintainer time (or motivation) to ever fix this", not because it was fixed. IMHO, this limitation should be documented (probably in the

Bug#273194: xterm: characters from paste buffer lost at roughly 4kB intervals [kernel pty bug?]

On 2023-01-23 03:11:59 +0100, Vincent Lefevre wrote: > On 2006-10-14 15:56:10 -0400, Thomas Dickey wrote: > > On Sat, Oct 14, 2006 at 08:20:14PM +0200, Andrew Moise wrote: > > > I still see this misbehavior with xterm 210-3.1 and > > > linux-image-2.6.17-2-686 2.6.17-9.

Bug#273194: xterm: characters from paste buffer lost at roughly 4kB intervals [kernel pty bug?]

On 2006-10-14 15:56:10 -0400, Thomas Dickey wrote: > On Sat, Oct 14, 2006 at 08:20:14PM +0200, Andrew Moise wrote: > > I still see this misbehavior with xterm 210-3.1 and > > linux-image-2.6.17-2-686 2.6.17-9. > > I can see it (now) with a 2.6.15 kernel (814 lines copied). > I also note that

Bug#1026809: Xlib: sequence lost (0x10000 > 0x...) in reply type 0x... when running emacs

Control: affects -1 emacs-gtk mlterm This also affects mlterm, when I resize the terminal. In the upstream bug, someone says that it also affects xterm, but I cannot reproduce the issue with xterm. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Bug#1026809: Xlib: sequence lost (0x10000 > 0x...) in reply type 0x... when running emacs

On 2022-12-21 14:01:53 +0100, Vincent Lefevre wrote: > Not sure about the bug severity, but if such errors are output, > this means that they are really serious. Otherwise, the end user > shouldn't be bothered. In any case, this must be fixed before > the next Debian release

Bug#1026809: Xlib: sequence lost (0x10000 > 0x...) in reply type 0x... when running emacs

Package: libx11-6 Version: 2:1.8.3-2 Severity: grave Justification: renders package unusable or possible data loss? After the upgrade to libx11-6 2:1.8.3-2, I get the following errors when running emacs: e.g. Xlib: sequence lost (0x1 > 0x473) in reply type 0x21! Xlib: sequence lost

Bug#1018005: xfonts-base: missing U+2A7D (⩽) and U+2A7E (⩾) characters in 6x13

Package: xfonts-base Version: 1:1.0.5 Severity: normal Tags: patch I'm using the 6x13 font on some machine, and the following characters are missing: U+2A7D LESS-THAN OR SLANTED EQUAL TO U+2A7E GREATER-THAN OR SLANTED EQUAL TO I could create the glyphs with fontforge, based on U+2264 (≤) and

Bug#1017726: libx11-6:amd64: inconsistency in some KeySym definitions and string lookup

Package: libx11-6 Version: 2:1.8.1-2 Severity: normal While "infinity" and "approxeq" KeySym names work correctly, e.g. xev outputs for them state 0x81, keycode 31 (keysym 0x8c2, infinity), same_screen YES, XLookupString gives 3 bytes: (e2 88 9e) "∞" XmbLookupString gives 3 bytes:

Bug#1010084: x11-xkb-utils: xkbcomp outputs many warnings without "-w 0"

On 2022-04-23 23:57:24 +0200, Vincent Lefevre wrote: [...] > where .xkb/keymap/test contains > > xkb_keymap { > xkb_keycodes { include "evdev+aliases(qwerty)" }; > xkb_types { include "complete" }; >

Bug#1010084: x11-xkb-utils: xkbcomp outputs many warnings without "-w 0"

Package: x11-xkb-utils Version: 7.7+6 Severity: normal Without "-w 0", I get many warnings with xkbcomp: zira:~> xkbcomp -I$HOME/.xkb -R$HOME/.xkb keymap/test xkb.dump Keycodes above 256 (e.g. ) are not supported by X and are ignored Warning: Could not resolve keysym XF86EmojiPicker

Bug#1009995: x11-xkb-utils: xkbcomp gives a warning for keysym XF86EmojiPicker from symbols/inet

Package: x11-xkb-utils Version: 7.7+6 Severity: normal Consider zira:~> cat .xkb/keymap/test xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat{ include "complete" }; xkb_symbols {

Bug#1009994: xkbcomp: warnings with "-w 0" due to missing warningLevel test for some WARN() occurrences

Package: x11-xkb-utils Version: 7.7+6 Severity: normal Tags: upstream Forwarded: https://gitlab.freedesktop.org/xorg/app/xkbcomp/-/issues/20 The the xkbcomp(1) man page says: -w lvl Controls the reporting of warnings during compilation. A warning level of 0 disables all warnings; a

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

Control: reassign -1 less Control: found -1 487-0.1 Control: found -1 590-1 Control: retitle -1 less: with option -R, the escape sequences should be sent in an atomic way so that they are not broken by stderr Control: tags -1 upstream - wontfix On 2020-01-30 21:21:03 -0500, Thomas Dickey wrote:

Bug#699746: #699746 x11-utils: xprop assumes that WM_ICON_NAME and WM_NAME are encoded in ISO-8859-1

On 2022-02-13 18:44:28 -0500, Thomas Dickey wrote: > I was recently reminded of this one, and can see that it's no longer relevant: > > + The bug-report made incorrect assumptions about what xprop ought to be > doing. > So it's not relevant to xprop. Well, I initially thought that this was

Bug#968093: client bug: event processing lagging behind by ..ms, your system is too slow

Control: tags -1 upstream Control: forwarded -1 https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/46 I've reported the bug upstream. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR

Bug#968093: client bug: event processing lagging behind by ..ms, your system is too slow

Control: found -1 1.19.3-1 On 2020-08-08 20:24:28 +0800, 積丹尼 Dan Jacobson wrote: > /var/log/Xorg.0.log has > (EE) event2 - Logitech USB Keyboard: client bug: event processing lagging > behind by 11ms, your system is too slow Same kind of errors on my two machines: [86.305] (EE) event5 -

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

, Vincent Lefevre wrote: > Control: reassign -1 x11-xkb-utils 7.7+5 > Control: retitle -1 x11-xkb-utils: xkbcomp gives internal errors on unknown > keysyms (e.g. some XF86* with xkb-data 2.33-1) > Control: notforwarded -1 > Control: tags -1 fixed-upstream > > On 2021-09-10 19

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

Control: reassign -1 x11-xkb-utils 7.7+5 Control: retitle -1 x11-xkb-utils: xkbcomp gives internal errors on unknown keysyms (e.g. some XF86* with xkb-data 2.33-1) Control: notforwarded -1 Control: tags -1 fixed-upstream On 2021-09-10 19:08:59 +0200, Vincent Lefevre wrote: > This is apparen

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

Control: tags -1 upstream Control: forwarded -1 https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/282 This is apparently an upstream bug (which I have just reported), introduced in 2.33, as some commit added these unknown keysyms. -- Vincent Lefèvre - Web:

Bug#994037: xkb-data: TWO_LEVEL is not available

Control: reassign -1 x11-xkb-utils 7.7+5 Control: retitle -1 x11-xkb-utils: xkbcomp fails with "X Error of failed request: BadValue" for XkbSetMap on specific config On 2021-09-10 14:31:38 +0200, Vincent Lefevre wrote: > cventin:~> xkbcomp -w 0 -I$HOME/.xkb -R$HOME/.xkb keymap

Bug#994026: xkb-data: breaks Multi_key, a.k.a. Compose key

On 2021-09-10 04:09:52 +0200, Vincent Lefevre wrote: > Package: xkb-data > Version: 2.33-1 > Severity: important > > The upgrade from 2.29-2 to 2.33-1 silently breaks Multi_key. > > A diff of the xkbcomp dump gives in particular: > > key { > -type= &

Bug#994026: xkb-data: breaks Multi_key, a.k.a. Compose key

Control: retitle -1 The drop of Multi_key for gb in xkb-data 2.33 should be announced in NEWS.Debian following my comment: On 2021-09-10 15:06:40 +0200, Vincent Lefevre wrote: > This is apparently due to the following upstream change. But this is > the kind of thing that should be ann

Bug#994037: xkb-data: TWO_LEVEL is not available

Package: xkb-data Version: 2.33-1 Severity: important On one of my machines: cventin:~> cat .xkb/keymap/custom xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat{ include "complete" };

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

Package: xkb-data Version: 2.33-1 Severity: normal On one of my machines, with a default configuration: cventin:~> cat .xkb/keymap/custom xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat{ include

Bug#994026: xkb-data: breaks Multi_key, a.k.a. Compose key

Package: xkb-data Version: 2.33-1 Severity: important The upgrade from 2.29-2 to 2.33-1 silently breaks Multi_key. A diff of the xkbcomp dump gives in particular: key { -type= "TWO_LEVEL", -symbols[Group1]= [ ISO_Level3_Shift, Multi_key ] +type= "ONE_LEVEL",

Bug#977996: xserver-xorg-input-libinput: for the middle button, reports press only when the button is released

Package: xserver-xorg-input-libinput Version: 0.30.0-1 Severity: normal On my HP ZBook 15 G2 laptop, I have a pointstick with associated mouse buttons and a touchpad with associated mouse buttons. There is no issue with the touchpad buttons, but for the middle button associated with the

Bug#914949: [bts-link] source package libx11

Control: reassign -1 libxcb1 1.14-2 Control: tags -1 - fixed-upstream Control: forwarded -1 https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/34 On 2019-02-18 17:16:25 +, debian-bts-l...@lists.debian.org wrote: > # remote status report for #914949 (http://bugs.debian.org/914949) > # Bug

Bug#732854: lightdm shows a part of my desktop screen as a part of the background of the login screen

On 2013-12-22 16:54:12 +0100, Vincent Lefevre wrote: > Package: lightdm > Version: 1.8.5-2 > Severity: grave > Tags: security > Justification: user security hole > > Here's what I did: > 1. Quit me desktop session. > 2. In lightdm (whose screen appeared correctly)

Bug#949257: xserver-xorg-core: Segmentation fault w/ 1.20.7

On 2020-01-19 00:09:13 +, Jamie Heilman wrote: > Package: xserver-xorg-core > Version: 2:1.20.7-2 > Severity: grave > > Setup is a NVIDIA GF108GL [Quadro 600] driving two monitors in > portrait orientation. Kernel 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) > > xorg.conf is: > Section

Bug#880407: still occurs in xterm 352-1

On 2020-01-20 20:06:51 -0500, Thomas Dickey wrote: > The change that I used gave me the same result for the font which you > mentioned in the bug report. You may be using some different font. I'm using the following settings: /usr/bin/xterm -xrm "Xft.dpi: 132" -xrm "XTerm*faceName: DejaVu Sans

Bug#880407: still occurs in xterm 352-1

s (Closes: #880407, adapted from patch by Vincent Lefevre). The bug still occurs with 352-1. Note that my patch was still working with 351-1. What has been done in fontutils.c is: @@ -2912,6 +2921,17 @@ ascent = font->ascent; descent = font->descent; if (h

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

On 2020-01-18 00:02:46 +0100, Vincent Lefevre wrote: > On my machine, the problem is almost always reproducible with > > ll -R /run | less > > where > > zira:~> where ll > ll: aliased to ls -l > zira:~> where ls > ls: aliased to \ls -bFv --color

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

On 2020-01-17 23:45:20 +0100, Vincent Lefevre wrote: > This is not this issue. The problem is that xterm sets up some margin, > and the lines at the top can no longer be erased. I need to use the > "reset" command to fix things. On my machine, the problem is almost always repr

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

On 2020-01-17 17:12:48 -0500, Thomas Dickey wrote: > https://invisible-island.net/xterm/xterm.faq.html#vt100_wrapping This is not this issue. The problem is that xterm sets up some margin, and the lines at the top can no longer be erased. I need to use the "reset" command to fix things. --

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

On 2020-01-17 11:55:28 +0100, Vincent Lefevre wrote: > This is not reproducible only with xterm, not with other terminals, > such as rxvt and gnome-terminal (but perhaps the race occurs > differently). Grrr... I meant: "This is reproducible only with xterm, not with o

Bug#949139: xterm: ls --color with errors piped to less sometimes corrupts the xterm status (split escape sequences)

Package: xterm Version: 351-1 Severity: normal I've run the equivalent of ls with some options including --color piped to less with the -R option, and after quitting less, the xterm status sometimes get corrupt, apparently due to some margin set up. I've attached the xterm output log, but I can

Bug#948516: xterm: displays incorrect text when one scrolls backward while output is ongoing

On 2020-01-10 03:22:05 +0100, Vincent Lefevre wrote: > On 2020-01-09 20:54:15 -0500, Thomas Dickey wrote: > > maybe - but without a typescript which would show me what went to the > > terminal, I'm missing most of the information needed to investigate it. > > What do you me

Bug#948516: xterm: displays incorrect text when one scrolls backward while output is ongoing

On 2020-01-09 20:54:15 -0500, Thomas Dickey wrote: > maybe - but without a typescript which would show me what went to the > terminal, I'm missing most of the information needed to investigate it. What do you mean exactly? Note that the bug is reproducible with almost anything that generates

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

Control: found -1 347-1 Control: tags -1 patch Patch at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880407#100 On 2019-05-20 15:54:42 +0200, Vincent Lefevre wrote: > The attached patch, which decreasing both ascent and descent by 1 when > height < ascent + descent, avoids this fo

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2019-05-20 15:54:42 +0200, Vincent Lefevre wrote: > Things have changed again with FreeType 2.9 (libfreetype6 2.9.1-3). [...] Sorry, I think that the change was just due to a different Xft.dpi value (as I did the test on a different machine): 132 instead of 88. Anyway, the problem is the s

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

Control: found -1 344-1 Control: found -1 345-1 Things have changed again with FreeType 2.9 (libfreetype6 2.9.1-3). I now get with "DejaVu Sans Mono" and size 10 (-fs 10): Xft metrics screen->renderFontNorm[0] = 21 (18,5)* advance 11, actual 11 Xft metrics screen->renderFontBold[0] = 21 (18,5)*

Bug#916349: xterm: X error (BadLength) with GNU screen

Control: retitle -1 xterm: X error (BadLength) when trying to display some glyphs On 2018-12-13 18:35:43 -0500, Thomas Dickey wrote: > On Thu, Dec 13, 2018 at 06:25:42PM -0500, Thomas Dickey wrote: > > On Thu, Dec 13, 2018 at 02:11:28PM +0100, Vincent Lefevre wrote: > > &

Bug#916349: xterm: X error (BadLength) with GNU screen

On 2018-12-13 14:51:26 +0100, Vincent Lefevre wrote: > After downgrading xterm to 337-1, then reupgrading to 338-1, I can > no longer reproduce the bug (for the moment). The error occurs again. So, it seems to occur only after some time. I don't know what triggers it. -- Vincent Lefèvre

Bug#916349: xterm: X error (BadLength) with GNU screen

On 2018-12-13 14:17:48 +0100, Julien Cristau wrote: > Please share your xterm config. Here's the "appres XTerm" output: *tek4014*fontLarge: 9x15 *tek4014*font2: 8x13 *tek4014*font3: 6x13 *tek4014*fontSmall: 6x10 *MenuButton*borderWidth:0 *Scrollbar.thickness: 8

Bug#916349: xterm: X error (BadLength) with GNU screen

Package: xterm Version: 338-1 Severity: grave Justification: renders package unusable After upgrading xterm to 338-1, I get X errors when using GNU screen: zira% xterm -e screen -r /usr/bin/xterm: warning, error event received: X Error of failed request: BadLength (poly request too large or

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-05 14:12:32 +0100, Vincent Lefevre wrote: > I suspect a bug in doSelectionFormat() in button.c that makes xterm > think that there was a bracketed paste, whose consequence is to > generate the "ESC [ 2 0 1 ~ .". > > If I remove > > #if OPT_READLI

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-05 13:33:41 +0100, Vincent Lefevre wrote: > Note also that for a bracketed paste, > > > https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-Paste-Mode > > says: > > When bracketed paste mode is set, the program will receive: > E

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-05 11:30:03 +0100, Vincent Lefevre wrote: > On 2018-12-05 05:03:46 -0500, Thomas Dickey wrote: > > On Wed, Dec 05, 2018 at 10:13:35AM +0100, Vincent Lefevre wrote: > > > According to strace, it is xterm: > > > > sure: xterm replies to the application for

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-05 05:03:46 -0500, Thomas Dickey wrote: > On Wed, Dec 05, 2018 at 10:13:35AM +0100, Vincent Lefevre wrote: > > According to strace, it is xterm: > > sure: xterm replies to the application for bracketed paste. You mean that it is zsh that does the paste? Why isn't t

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-05 09:58:21 +0100, Vincent Lefevre wrote: > On 2018-12-04 21:50:47 -0500, Thomas Dickey wrote: > > That looks as expected, if you've got two different things writing to > > the terminal at the same time: > > > > https://invisible-island.net/xterm/ctlseqs/ctls

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-12-04 21:50:47 -0500, Thomas Dickey wrote: > That looks as expected, if you've got two different things writing to > the terminal at the same time: > > https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-Paste-Mode So, perhaps I can see something with zsh (without Ctrl-V

Bug#914949: Issues with error message "Invalid MIT-MAGIC-COOKIE-1 key"

Control: forwarded -1 https://gitlab.freedesktop.org/xorg/lib/libx11/issues/80 On 2018-11-29 01:10:06 +0100, Vincent Lefevre wrote: > 2. As seen above, the error message does not end with a newline > character. This breaks the parsing of the output (at least when > both the standa

Issues with error message "Invalid MIT-MAGIC-COOKIE-1 key"

ollowed by a newline character On 2018-11-28 18:19:46 +0100, Vincent Lefevre wrote: > The output is actually present, but was filtered out later by > the script due to an unexpected error message without a \n. > > The tests/tversion.log starts with: > > Invalid MIT-MAGIC

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-11-26 20:38:37 -0500, Thomas Dickey wrote: > On Sun, Nov 25, 2018 at 12:08:03AM +0100, Vincent Lefevre wrote: > > With zsh, one can reproduce the issue with: > > > > $ xterm -e zsh -f > > If you added a "-l" option, that would turn on xterm's logging

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

On 2018-11-21 19:02:33 -0500, Thomas Dickey wrote: > I don't see how this could happen unless you combined the action with > some pasting (such as bracketed-paste). I paste nothing. > xterm's formatting of the string is shell-agnostic, and the exec'd > "browser" command would only depend on what

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

Package: xterm Version: 337-1 Severity: normal In my XTerm configuration, I have: *VT100*translations:#override \n\ Meta: exec-formatted("browser %s", PRIMARY) The problem is that when exec-formatted is invoked from zsh or emacs (when run in xterm, e.g. with "emacs

Bug#906934: libxcb1-dbgsym is not available for amd64

On 2018-08-22 16:32:29 +0200, Vincent Lefevre wrote: > libxcb1-dbgsym is not available for amd64, while it is available > for some other architectures: > > https://packages.debian.org/sid/libxcb1-dbgsym Hmm... It seems that this page is just for ports. But http://debug.mirror

Bug#906934: libxcb1-dbgsym is not available for amd64

Source: libxcb Version: 1.13-2 Severity: normal libxcb1-dbgsym is not available for amd64, while it is available for some other architectures: https://packages.debian.org/sid/libxcb1-dbgsym Version 1.13-1 was available. -- System Information: Debian Release: buster/sid APT prefers

Bug#892362: xserver-xorg-core: black screen when the nvidia driver fails instead of fallback to fbdev

Package: xserver-xorg-core Version: 2:1.19.6-1 Severity: normal After a major upgrade of the NVIDIA drivers and restart of the X server (e.g. package upgrade + logout, so that the display manager restart the X server), the NVIDIA drivers no longer work (which can be regarded as normal, as the

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2018-01-05 05:21:32 -0500, Thomas Dickey wrote: > On Fri, Jan 05, 2018 at 10:26:11AM +0100, Vincent Lefevre wrote: > > Sorry, I don't understand what you mean. Can you reproduce the problem > > with that? > > only for the case that I made xterm detect/workaround. >

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2018-01-05 04:13:56 -0500, Thomas Dickey wrote: > - Original Message - > | On 2018-01-05 03:59:42 -0500, Thomas Dickey wrote: > | > Then you should provide more information allowing this to be > | > reproduced. > | > | I can reproduce this with the default config and: > | > | xterm

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2018-01-05 03:59:42 -0500, Thomas Dickey wrote: > Then you should provide more information allowing this to be reproduced. I can reproduce this with the default config and: xterm -fa Monospace -fs 10 -xrm "Xft.dpi: 132" (the "Xft.dpi: 132" is important). -- Vincent Lefèvre

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

Control: reopen -1 Control: found -1 331-1 Control: tags -1 - fixed-upstream On 2017-12-30 14:53:27 -0500, Thomas Dickey wrote: > I investigated, found that it is a defect in FreeType. > None of the comments in > > https://savannah.nongnu.org/bugs/?52165 > > were helpful (some of the

Bug#862042: xterm: if the faceName resource is defined, the -fn (-font) option is ignored

On 2017-12-30 10:24:24 -0500, Thomas Dickey wrote: > On Sun, May 07, 2017 at 07:12:44PM -0400, Thomas Dickey wrote: > > - Original Message - > > | The behavior is not what is described in this section. I would agree > > | if renderFont were "true". But the manual says: > > | > > | The

Bug#880407: xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2017-10-31 16:21:58 -0400, Thomas Dickey wrote: > On Tue, Oct 31, 2017 at 10:39:28AM +0100, Vincent Lefevre wrote: > > Package: xterm > > Version: 330-1 > > Severity: important > > wishlist or normal. Don't soapbox, if you want to have a constructive > d

Bug#880407: xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

On 2017-10-31 10:39:28 +0100, Vincent Lefevre wrote: > FreeType 2.8 uses different rounding rules for ascender and descender, [...] Well, for TrueType fonts (as it was mentioned later). But this seems to be the most common fonts from FreeType on Debian, and the default ones. -- Vincent Lefè

Bug#880407: xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

Package: xterm Version: 330-1 Severity: important FreeType 2.8 uses different rounding rules for ascender and descender, so that one can now have (src->ascent + src->descent) > src->height in CACHE_XFT from fontutils.c (only because of rounding), which yields a spurious blank line between

Bug#855206: fixed in xorg-server 2:1.19.4-1

On 2017-10-09 21:49:53 +, Timo Aaltonen wrote: > Source: xorg-server > Source-Version: 2:1.19.4-1 > > We believe that the bug you reported is fixed in the latest version of > xorg-server, which is due to be installed in the Debian FTP archive. I confirm that the bug is fixed: I've run my

Bug#661295: libx11-6 based applications are confused by new xkb settings (possible crash in XkbTranslateKeyCode)

Control: found -1 327-2 On 2015-11-15 15:11:45 +0100, Vincent Lefevre wrote: > On 2012-02-26 02:54:45 +0100, Vincent Lefevre wrote: > > When changing the xkb settings with: Actually, not "changing", but "restoring" (so that the settings are the same as whe

Bug#862042: xterm: if the faceName resource is defined, the -fn (-font) option is ignored

On 2017-05-07 17:24:43 -0400, Thomas Dickey wrote: > Perhaps you'll see it here: > > http://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:renderFont > > Most of xterm's options work by setting resource values (there are a > handful of special cases such as "-help",

Bug#847479: xterm: display issue with double-width character like ? on the last column via ncurses

On 2017-05-07 16:30:24 -0400, Thomas Dickey wrote: > a typescript (from "script") helps. After trying again. the problem seems to occur only when one resizes the terminal window. So, a typescript doesn't help. It seems to be a problem similar to what I had already reported under other conditions:

Bug#862042: xterm: if the faceName resource is defined, the -fn (-font) option is ignored

On 2017-05-07 16:29:35 -0400, Thomas Dickey wrote: > - Original Message - > | From: "Vincent Lefevre" <vinc...@vinc17.net> > | To: "Debian Bug Tracking System" <sub...@bugs.debian.org> > | Sent: Sunday, May 7, 2017 1:23:00 PM > | Subje

Bug#862042: xterm: if the faceName resource is defined, the -fn (-font) option is ignored

Package: xterm Version: 327-2 Severity: minor If I define the faceName resource, e.g. with XTerm*faceName: Monospace in the .Xresources file (read by xrdb), then the -fn (-font) option is ignored. For instance, xterm -fn 7x13 has no effect. Options normally override the default resources,

Bug#847479: xterm: display issue with double-width character like ? on the last column via ncurses

On 2017-05-07 10:53:24 -0400, Thomas Dickey wrote: > Attaching a script, for discussion. I don't see the problem, but noticed > that the character is "new", and for instance if you were running xterm > remotely so that the wcwidth wasn't known then you could get odd results. I can't reproduce

Re: Bug#855206: When a process quits, xorg sometimes leaves a zombie window

Control: found -1 2:1.19.1-4 And the bug still occurs after just the following downgrade: -ii xserver-common 2:1.19.3-1 all common files used by various X servers -ii xserver-xephyr 2:1.19.3-1

Bug#855206: When a process quits, xorg sometimes leaves a zombie window

Control: reassign -1 xserver-xorg-core 2:1.19.3-1 On 2017-04-27 23:06:06 +, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > > > reassign 855206 xserver-xorg > Bug #855206 [fvwm] fvwm: When an application quits, fvwm doesn't always > remove its window

Bug#855206: Sometimes windows remain after the process has died.

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=100863 I've reported a bug upstream (I've searched among open/closed bugs containing "window" and couldn't find one already reported): https://bugs.freedesktop.org/show_bug.cgi?id=100863 -- Vincent Lefèvre

Bug#847479: xterm: display issue with double-width character like  on the last column via ncurses

Notes: The character appears in the subject of this mail, so that you can use it as a test case. :) The problem doesn't appear with a shell and printf. Thus I assume that it may be related to margins and things like that. -- Vincent Lefèvre - Web:

Bug#847479: xterm: display issue with double-width character like  on the last column via ncurses

Package: xterm Version: 327-1 Severity: minor In Mutt, when a double-width character from the subject appears on the last column (in the Mutt index menu), then the left part of the second half of the character is visible. Something like that. For instance, if the character rendering would be

Bug#844325: xterm: display issue after sending zero-width characters to the terminal

Note that under Debian GNU/Linux 8 (jessie), xterm 312-2 is also affected, but not with U+00AD SOFT HYPHEN, whose wcwidth is 1 there (instead of 0 in the current glibc). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Bug#844325: xterm: display issue after sending zero-width characters to the terminal

Package: xterm Version: 327-1 Severity: normal The following command for i in $(seq 2 $(tput cols)); do printf .; done; printf "\u00adP\n" outputs a sequence of dots, then a soft hyphen, then the character "P" on the right of the last column (only the left part of the character is visible).

Bug#839220: xterm: Using allowC1Printable (-k8) can disable UTF-8 support

Package: xterm Version: 326-1 Severity: important If allowC1Printable (-k8 option) is used, then UTF-8 support can be disabled if some escape sequence (e.g. from a binary file) is sent, which can make the terminal unusable. Example: xterm -k8 -hold -e printf "\x1b\xa5@\xc3\xa9\n" which shows

Bug#738794: can still occur with some font/DPI

On 2016-09-28 10:37:05 +0200, Vincent Lefevre wrote: > I can still reproduce this bug with the script I gave on: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738794#108 > > using the default X resources. > > Note: if I decode the base64 contents and us

Bug#738794: can still occur with some font/DPI

Control: reopen -1 Control: found -1 326-1 I can still reproduce this bug with the script I gave on: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738794#108 using the default X resources. Note: if I decode the base64 contents and use "cat", then the bug is no longer reproducible, even

Bug#827905: Character U+2028 can yield file corruption when edited in xterm

On 2016-07-14 19:27:52 +0200, Sven Joachim wrote: > On 2016-07-13 18:24 -0700, Vincent Lefevre wrote: > > Could this depend on some library version or on the font? > > On the latter. With the default font I see no corruption, but with the > 9x15 font, for instance. See the a

Bug#827905: Character U+2028 can yield file corruption when edited in xterm

On 2016-07-13 20:15:49 -0400, Thomas Dickey wrote: > I don't see the behavior which is described, and haven't seen any > suitable justification for marking this as a "grave" issue, rather > than "normal". Keep in mind that this is a rarely used line-break > character. This is not common, but

Character U+2028 can yield file corruption when edited in xterm

. On 2016-06-22 12:48:46 +0200, Vincent Lefevre wrote: > When editing a file where a line started by the U+2028 character, > it got corrupted. Basically, what was stored is not what was > displayed. To reproduce the beginning of a corruption: 1. Type: printf "\u2028abcd\n" > file

Bug#738794: xterm: the right part of the window is not always erased

On 2016-06-09 15:54:09 +0200, Vincent Lefevre wrote: > xterm -geometry 80x10 -hold -T "$0" -e "base64 -d < G1sxbSAbW20gCBtbPzIwMDRsDQ0Ni+V+EIriKC0WiSm5gnc4wUFY7yBzOZvjMFtCoOC8Vo7JolJc > ZnBMnIWyC1HM7HW+H4dSvONIi+V+yKE4D47lnZIcl5WyXWefiKIZ5rDuF8MU98w35zV7nO/H4XZ4

Bug#738794: xterm: the right part of the window is not always erased

Control: reopen -1 Control: found -1 325-1 I can still see the problem with another example (based on a PDF file): #!/bin/sh xterm -geometry 80x10 -hold -T "$0" -e "base64 -d < - Web: 100%

Bug#738794: xterm: the right part of the window is not always erased

On 2016-05-02 15:40:54 +0200, Vincent Lefevre wrote: > xterm -fn 6x13 -geometry 43x24 -hold -e cat debbug738794.log > > See the dot on the right at line 17 ("I enjoyed ... at his house"). I've attached screenshots with my xterm config (a) and with the default xterm config

Bug#738794: xterm: the right part of the window is not always erased

Control: found -1 324-1 Hi, On 2014-02-16 20:55:46 -0500, Thomas Dickey wrote: > (I've seen this, but not often enough to have a scenario where it can > be reproduced...) Perhaps you can reproduce it with the attached log file. This seems to be exactly the same problem. xterm -fn 6x13

Bug#429432: 1152x768 can no longer be used on PowerBook, incorrect display [Rage Mobility M3, 4c46]

Control: tags -1 wontfix Tagging again without -done since "Control:" pseudo-headers are not taken into account with -done. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer

Bug#814902: xserver-xorg-core: clicks on the root window are not always reported

Control: reassign -1 unclutter 8-20 Control: retitle -1 unclutter: clicks are not reported for some apps when the mouse pointer is not visible On 2016-02-19 13:37:53 +0100, Vincent Lefevre wrote: > On 2016-02-16 12:38:15 +0100, Vincent Lefevre wrote: > > Clicks on the root window are n

Bug#814902: xserver-xorg-core: clicks on the root window are not always reported

On 2016-02-16 12:38:15 +0100, Vincent Lefevre wrote: > Clicks on the root window are not always reported. I think I've had > this problem for a few weeks (or months?). At least two Debian/sid > machines are concerned (so, this is not a hardware issue). > > More precisely, with my

Bug#814902: xserver-xorg-core: clicks on the root window are not always reported

Package: xserver-xorg-core Version: 2:1.18.1-1 Severity: normal Clicks on the root window are not always reported. I think I've had this problem for a few weeks (or months?). At least two Debian/sid machines are concerned (so, this is not a hardware issue). More precisely, with my window manager

Bug#661295: libx11-6 based applications are confused by new xkb settings (possible crash in XkbTranslateKeyCode)

Control: reassign -1 xterm 320-1 On 2012-02-26 02:54:45 +0100, Vincent Lefevre wrote: > When changing the xkb settings with: > > xkbcomp -w0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY > > not all these settings are taken into account by some running > X applications (o

  1   2   3   4   5   >