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 mach

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 unstable-

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#640464: xterm: rendering problems (pixels not erased?)

found 640464 276-1 thanks Similar problem after doing a next search in "less", while an Emacs window was partially covering the xterm window. The part above the Emacs window was drawn with incorrect characters. Moving the Emacs window over the xterm window (without touching xterm) made the display

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2011-12-28 20:14:41 +0100, Vincent Lefevre wrote: > Similar problem after doing a next search in "less", while an Emacs > window was partially covering the xterm window. The part above the > Emacs window was drawn with incorrect characters. Moving the Emacs > window

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2011-12-30 20:16:43 -0500, Thomas Dickey wrote: > Which window manager are you using? fvwm -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) --

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2012-01-04 21:04:45 -0500, Thomas Dickey wrote: > In my initial response, I had in mind that perhaps the optimization that I did > in #274/#275 to discard extra configure-events, and extra exposures (due to > rapid scrolling) was the problem. If I could reproduce it, I'd do that with > the debu

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2012-01-05 14:09:36 +0100, Vincent Lefevre wrote: > On 2012-01-04 21:04:45 -0500, Thomas Dickey wrote: > > In my initial response, I had in mind that perhaps the optimization that I > > did > > in #274/#275 to discard extra configure-events, and extra exposures (due to >

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2012-01-05 14:13:22 +0100, Vincent Lefevre wrote: > So, I'm starting to think that the problem comes from the nouveau > driver. No, downgrading *nouveau* and the X server to old versions doesn't make the problem disappear. However the problem disappeared after downgrading

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2012-01-05 17:41:37 +0100, Vincent Lefevre wrote: > No, downgrading *nouveau* and the X server to old versions doesn't > make the problem disappear. However the problem disappeared after > downgrading libx11* packages. I'll try to investigate more later. After doing tests

Bug#640464: xterm: rendering problems (pixels not erased?)

reassign 640464 xserver-xorg-video-nouveau found 640464 1:0.0.16+git20101210+8bb8231-2 found 640464 1:0.0.16+git20111201+b5534a1-1 thanks On 2012-01-05 23:36:44 +0100, Vincent Lefevre wrote: > After doing tests on another machine, this is not related to the > libx11* packages (in some case

Bug#640464: xterm: rendering problems (pixels not erased?)

tags 640464 - moreinfo thanks On 2011-09-05 20:41:01 +0200, Julien Cristau wrote: > If this is new, when did it start occurring? According to my tests, it doesn't occur with xorg 1:7.5+8 xserver-xorg-video-nouveau 1:0.0.15+git20100329+7858345-4 and occurs with xorg 1:7.6+4 xserver-xorg

Bug#658124: x11-common: Xsession should not start ssh-agent (should be a user-level choice)

Package: x11-common Version: 1:7.6+11 Severity: normal By default, due to use-ssh-agent in /etc/X11/Xsession.options and /etc/X11/Xsession.d/90x11-common_ssh-agent, Xsession starts ssh-agent (as a user process). However this may clash with the user settings[*] and even not, it may be a useless pro

Bug#658124: x11-common: Xsession should not start ssh-agent (should be a user-level choice)

On 2012-02-01 21:27:43 +0100, Julien Cristau wrote: > On Tue, Jan 31, 2012 at 15:46:28 +0100, Vincent Lefevre wrote: > > Note: /etc/X11/Xsession.d/90x11-common_ssh-agent does some checks > > e.g. by testing whether $SSH_AUTH_SOCK is set, but unfortunately it > > is sourced be

Bug#633849: xserver-xorg: XKB settings lost after suspend (hibernate) / resume

retitle 633849 xserver-xorg: XKB settings lost after suspend (hibernate) / resume or USB keyboard plugged in found 633849 1:7.6+11 thanks On 2011-07-14 13:45:49 +0200, Vincent Lefevre wrote: > I have personal XKB settings. From my .initrc file: > > xkbcomp -w0 -I$HOME/.xkb -R$HOME/.x

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

Package: libx11-6 Version: 2:1.4.4-4 Severity: important 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 (or worse, see below). New X applications (i.e. those started

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

I forgot to give my XKB config. It is attached. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) xkb.tar.xz Description: Binary data

Bug#637001: allow xterm to run a user-specified command on some event (e.g. to open a URL)

Package: xterm Version: 271-1 Severity: wishlist xterm should have a way to run a user-specified shell command on some event. For instance, xterm could define a new action run-command(command [, ...?]). The command would get context information, either as an argument or in standard input, such as

Bug#637001: allow xterm to run a user-specified command on some event (e.g. to open a URL)

On 2011-08-07 13:11:50 -0400, Thomas Dickey wrote: > On Sun, 7 Aug 2011, Vincent Lefevre wrote: > >xterm should have a way to run a user-specified shell command > >on some event. For instance, xterm could define a new action > >run-command(command [, ...?]). The comm

Bug#609060: xterm should repeat most commands passed, with arrow up

On 2011-01-05 22:50:53 +0100, yellow wrote: > Package: xterm > Version: 261-1 > Severity: wishlist > > $ scanimage --format=tiff -batch >image.tiff > > scanimage: invalid option -- 'a' > fruly@debian:~$ > > the entered command is not prompted when I press onto arrow up key > on keyboard. If

Bug#637001: allow xterm to run a user-specified command on some event (e.g. to open a URL)

On 2011-08-09 07:00:32 -0400, Thomas Dickey wrote: > It falls into the same category as the other "allow" items - > something where there's a potential for outsiders (e.g., > send-events) to manipulate it. Not really. Events sent by process output to the terminal should be disabled, whether or not

Bug#640464: xterm: rendering problems (pixels not erased?)

Package: xterm Version: 271-1 Severity: normal xterm has some rendering problems. Some pixels are not erased or something like that. I don't know how to reproduce this. When this occurred (twice), there was an emacs window partly covering the xterm one. See attached snapshot as an example: there'

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2011-09-05 14:48:15 -0400, Thomas Dickey wrote: > On Mon, 5 Sep 2011, Julien Cristau wrote: > >If this is new, when did it start occurring? Just before reporting the bug. I couldn't reproduce the bug yet. > > Could also be a driver or X issue. Hmm... perhaps. When I moved a window over the xt

Bug#648706: libx11-doc should be in Section doc, not libdevel

Package: libx11-doc Version: 2:1.4.4-4 Severity: minor $ dpkg -s libx11-doc Package: libx11-doc Status: install ok installed Priority: optional Section: libdevel [...] It should be in Section doc, not libdevel. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy

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

Package: x11-utils Version: 7.7~1 Severity: normal xprop assumes that WM_ICON_NAME and WM_NAME are encoded in ISO-8859-1. For instance, when running /usr/bin/xterm -e 'printf "\e]1;my_icon€\x07\e]2;my_title€\x07"; sleep 999' under UTF-8 locales, I get: [...] WM_LOCALE_NAME(STRING) = "en_US.UT

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2012-01-05 23:36:44 +0100, Vincent Lefevre wrote: > To reproduce the bug, I've attached a file "text", obtained from > xterm logging (md5sum: e522fe4b2a4e45e39761550e8a5426f7). The steps > are the following: > > 1. Type: xterm -geometry 80x60 -e 'sleep

Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

retitle 677173 after some time, some keyboard no longer works in the current X session thanks The same problem occurred with my laptop keyboard, suddenly, without doing anything special. This time, I hadn't had any USB keyboard attached since the last boot. However the laptop had been put into sl

Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

Something interesting occurred with the USB keyboard. I was using Iceweasel, and suddenly it behaved as if both the Shift and Ctrl keys were pressed: left-clicks were extending the selection, and a left-click on a link was opening it in a background tab. After hitting various keys, this no longer o

Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

On 2012-07-14 21:38:05 +0200, Vincent Lefevre wrote: > So, it seems that when the problem occurs, the keyboard modifiers may > still be working with clicks (to be confirmed). Forget that. The problem is the following: a keypress is taken into account only if the key is kept pressed for abou

Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

On 2012-07-20 08:31:19 +0200, Julien Cristau wrote: > Sounds like you have slowkeys enabled. > http://who-t.blogspot.fr/2012/06/xkb-slowkeys.html So, it would seem that some part of the system would enable SlowKeys in my back for one of the keyboards (I recall that when this happens while I'm usin

Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

On 2012-07-20 08:58:57 +0200, Vincent Lefevre wrote: > So, it would seem that some part of the system would enable SlowKeys > in my back for one of the keyboards (I recall that when this happens > while I'm using the USB keyboard, only the USB keyboard is affected, > not th

Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

On 2012-07-26 21:31:44 +0200, Bjørn Mork wrote: > BTW, is it only me, or do you have to hold down the key significantly > longer to turn the "feature" off than to turn it on? It certainly feels > like it. No, it seems 10 seconds in both cases. > > * When the bug occurred in my case, I don't thin

Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

On 2012-07-28 00:11:13 +0200, Julien Cristau wrote: > As explained in the blog post I linked to, you have to disable AccessX. But the blog post doesn't explain *how* to do that. Well, it explains it only for GNOME 3 users. But not everyone uses GNOME. "man -k accessx" gives nothing interesting.

Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

On 2012-07-28 01:00:11 +0200, Vincent Lefevre wrote: > But the blog post doesn't explain *how* to do that. Well, it explains > it only for GNOME 3 users. But not everyone uses GNOME. > > "man -k accessx" gives nothing interesting. > > http://tldp.org/HOWTO/Keyboa

Bug#633849: xserver-xorg: XKB settings lost after suspend (hibernate) / resume

On 2012-02-26 01:30:06 +0100, Vincent Lefevre wrote: > On 2011-07-14 13:45:49 +0200, Vincent Lefevre wrote: > > I have personal XKB settings. From my .initrc file: > > > > xkbcomp -w0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY > > > > They are lost a

Bug#633849: xserver-xorg: XKB settings lost after suspend (hibernate) / resume

On 2012-08-04 03:40:11 +0200, Vincent Lefevre wrote: > Actually when I suspend and resume the laptop, the USB keyboard > is unaffected. Only when unplug it and plug it in again. A few hours ago, as I did a suspend/resume of my laptop, with only its builtin keyboard, I noticed that t

Bug#677173: keyboard switched to slowkeys mode today for me as well

On 2012-08-06 16:46:40 -0400, Daniel Kahn Gillmor wrote: > My X11 session switched to slowkeys mode today without my having held > the shift key down for 10 consecutive seconds, as far as i know. Same for me. The system suddenly switched to SlowKeys while I didn't even touch the Shift key! Note:

Bug#691642: xterm: outputting the mc5 sequence (prtr_on / turn on printer) makes xterm crash

Package: xterm Version: 278-2 Severity: grave Tags: security Justification: causes non-serious data loss When cat'ing some binary file, my xterm crashed. I've managed to find the cause: the mc5 terminfo sequence (prtr_on / turn on printer). The problem can be reproduced with: 1. Run xterm from an

Bug#691642: xterm: outputting the mc5 sequence (prtr_on / turn on printer) makes xterm crash

On 2012-10-27 18:34:11 -0400, Thomas Dickey wrote: > The documentation is correct; there is an error in your report. > The rules for X resource syntax are different from your expectation. > This is an empty string: > > *printerCommand: > > This is the two double-quote characters (literally): > >

Bug#691642: xterm: outputting the mc5 sequence (prtr_on / turn on printer) makes xterm crash

On 2012-10-28 11:37:58 +0100, Nico Golde wrote: > I can't reproduce this with xterm 278-2 on amd64. A bug in xrdb introduced a confusion. The problem occurs with non-default *printerCommand value, e.g. in my case this was: xterm -xrm '*printerCommand: ""' (AFAIK, there was no problem with that

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2012-01-05 23:36:44 +0100, Vincent Lefevre wrote: > In case this is due to the driver, I use the nouveau driver (both > machines have a NVIDIA card). Information given by lshw run as root: *-display description: VGA compatible controller p

Bug#714527: xterm: word-selection bug on last word of lines ending at the last column

Package: xterm Version: 293-1 Severity: normal In a 80-column xterm: $ echo `seq 9997 10010` 9997 9998 1 10001 10002 10003 10004 10005 10006 10007 10008 10009 10010 If I double-click on "10010", the last character of the word is not selected. -- System Information: Debian Release: jess

Bug#640464: xterm: rendering problems (pixels not erased?)

Control: tags -1 upstream On 2013-06-07 12:53:40 +0200, Vincent Lefevre wrote: > A more automatic way to run this test: just run the attached > fdbug49786.sh script (this is a standalone testcase) and wait > for 4 seconds. It just needs xterm and base64 (to output some > content

Bug#760207: xterm: segmentation fault when selecting a non-existing font

Package: xterm Version: 310-1 Severity: important To reproduce the crash: 1. Run: xterm -xrm '*allowFontOps: true' 2. Select the word "fixed" (PRIMARY selection). 3. Ctrl-right click, and choose "Selection". 4. Select the word "foo" (PRIMARY selection). 5. Ctrl-right click, and choose "Selection".

Bug#760208: xterm: the set-vt-font(e) action doesn't work / menu item grayed out

Package: xterm Version: 310-1 Severity: minor If I run xterm -xrm '*allowFontOps: true' and change the font with the Set Font escape sequence, such as printf "\e]50;#+1\a" (after changing the font via the menu), the set-vt-font(e) action doesn't work and the "Escape Sequence" menu item rem

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

I can no longer reproduce this bug after the upgrade to xserver-xorg-video-nouveau 1:1.0.11-1; I'll try to do some more tests. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC

Bug#700235: xserver-xorg-video-nouveau: uninitialized video memory or garbled images on login screen (lightdm)

On 2014-09-25 11:27:12 +0300, Andrei POPESCU wrote: > On Jo, 14 feb 13, 23:24:33, Sven Joachim wrote: > > If the problem still persists, file an > > upstream bug on freedesktop bugzilla, see > > http://nouveau.freedesktop.org/wiki/Bugs for instructions. > > It's still on my TODO list, but... I ha

Bug#762820: xserver-xorg: Ctrl-Alt-F1 doesn't work as expected when coming from VT1

Package: xserver-xorg Version: 1:7.7+7 Severity: minor Ctrl-Alt-F1 normally means: switch to VT1. But it doesn't always work: press Ctrl-Alt, then without releasing these keys, type F1, then F7, then F1 again. This switches to VT1, then to X again, but the second F1 doesn't switch to VT1: it is re

Bug#466704: xterm: pointer color is always white with some drivers, like vesa - closing

Control: reopen -1 Control: found -1 2:1.6.2-1 On 2013-10-08 02:05:54 +, Solveig wrote: > Hi! I'm closing this bug, since it was tagged "moreinfo" for years > without answer. If you still encounter this problem, please feel free > to re-open it. Same problem. > Also, Glenn McIntosh mentionne

Bug#466704: xterm: pointer color is always white with some drivers, like vesa - closing

Control: retitle -1 xterm: pointer color is always white by default due to default theme Control: tags -1 - moreinfo On 2013-10-08 08:14:03 +0200, Vincent Lefevre wrote: > On 2013-10-08 02:05:54 +, Solveig wrote: > > Also, Glenn McIntosh mentionned it's not a bug, it's

Bug#726765: xserver-xorg-core: Crash after opening some URL with Iceweasel

On 2013-10-19 11:58:27 +0200, Julien Cristau wrote: > On Fri, Oct 18, 2013 at 22:04:40 +0200, Vincent Lefevre wrote: > > Just after opening some URL[*] with Iceweasel, the system froze > > for several seconds (I assume that it was constantly swapping), > > then the X server

Bug#633849: Me too

On 2013-10-31 05:02:45 +0100, Eugen Dedu wrote: > On 30/10/13 22:44, Eugen Dedu wrote: > >I have the same bug and I would really love to have it fixed. Since > >about 2 years (before, it worked) I have been forced to execute xmodmap > >~/.xmodmap after each resume, since the key bindings I use in

Bug#633849: Me too

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=71168 On 2013-11-02 09:22:02 +0100, Eugen Dedu wrote: > Do you know if the upstream is informed about all these bugs? I've just reported this bug upstream. -- Vincent Lefèvre - Web: 100% accessible vali

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2013-08-21 17:00:43 +0200, Vincent Lefevre wrote: > I've attached a new version of my script, as the behavior may depend > on a non-default config. It should be better now. > > The bug has been confirmed with this script on the upstream BTS: > > Ilia Mirkin

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2013-11-15 16:56:26 +0100, Vincent Lefevre wrote: > This bug seems to be fixed in xserver-xorg-video-nouveau 1:1.0.10-1. > > I'll try to do more tests on a machine where I haven't upgraded yet, > e.g. by recompiling xserver-xorg-video-nouveau alone in order to make >

Bug#640464: xterm: rendering problems (pixels not erased?)

On 2013-11-15 17:32:42 +0100, Vincent Lefevre wrote: > On 2013-11-15 16:56:26 +0100, Vincent Lefevre wrote: > > This bug seems to be fixed in xserver-xorg-video-nouveau 1:1.0.10-1. > > > > I'll try to do more tests on a machine where I haven't upgraded yet, >

Bug#466704: fixed in xterm 298-1

Control: reopen -1 Control: found -1 298-1 On 2013-12-01 09:20:11 +, Sven Joachim wrote: > Source: xterm > Source-Version: 298-1 [...] > - work around Xcursor library to make pointerColor resource work as >documented (Closes: #466704). The bug still occurs with xterm 298-1. --

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

On 2013-12-22 18:42:16 +0100, Yves-Alexis Perez wrote: > Looks like your graphics driver (most likely nvidia/nouveau) doesn't > clean the video memory. Definitely not a lightdm issue. Yes, I use the nouveau driver. -- Vincent Lefèvre - Web: 100% accessible validated (X)

Bug#732854: [Pkg-xfce-devel] Bug#732854: lightdm shows a part of my desktop screen as a part of the background of the login screen

Control: found -1 1:1.0.10-1 Control: severity -1 grave On 2013-12-22 18:49:50 +0100, Yves-Alexis Perez wrote: > control: reassign -1 xserver-xorg-video-nouveau > control: forcemerge 700235 -1 The grave severity has been lost in the merge, and I think it should really be grave, as an external use

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

Control: found -1 2:1.6.2-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

Bug#737692: xterm: incorrect pathname in /usr/share/doc/xterm/xterm.faq.gz

Package: xterm Version: 301-1 Severity: minor /usr/share/doc/xterm/xterm.faq.gz contains: -- You can override this by specifying your own translations in your resource file. Use the translations in /usr/lib/X11/app-defaults/XTerm as a guide. The relevant section of the app-default

Bug#737692: xterm: incorrect pathname in /usr/share/doc/xterm/xterm.faq.gz

On 2014-02-04 20:11:25 -0500, Thomas Dickey wrote: > On Wed, Feb 05, 2014 at 01:25:38AM +0100, Vincent Lefevre wrote: > > Package: xterm > > Version: 301-1 > > Severity: minor > > > > /usr/share/doc/xterm/xterm.faq.gz contains: > > > > -- > &

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

Package: xterm Version: 301-1 Severity: minor The right part of the window is not always erased. This happened with font "fixed". See attached screenshot. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (

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

On 2014-02-13 06:55:05 -0500, Thomas Dickey wrote: > On Thu, Feb 13, 2014 at 01:04:09AM +0100, Vincent Lefevre wrote: > > The right part of the window is not always erased. This happened > > with font "fixed". See attached screenshot. > > There's no

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

On 2014-02-13 13:59:03 +0100, Vincent Lefevre wrote: > On 2014-02-13 06:55:05 -0500, Thomas Dickey wrote: > > c) from running some particular application > > It was a colored "svn diff". I think I now know what triggered the problem: in the "svn diff", the

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

On 2014-02-14 16:43:34 -0500, Thomas Dickey wrote: > If it's a continuing nuisance for Vincent, there's the feature I > added ten years ago: > >-k8 This option sets the allowC1Printable resource. When > allowC1Printable is set, xterm overrides >the mapping of C1 contr

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

On 2014-02-15 07:57:23 -0500, Thomas Dickey wrote: > is there an accessible pdf file that I could use to reproduce the problem? For instance: https://www.vinc17.net/research/slides/arith17.pdf The bug is reproducible with the default options and xterm -geometry 80x76 (it seems that the siz

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

On 2014-02-16 17:55:37 -0500, Thomas Dickey wrote: > The likely explanation for the problem in clearing is from setting the > top/bottom scrolling margins (done in CASE_HP_MEM_LOCK), and prevents the > portion above the top-margin from being cleared. Either a soft- or > full-reset (which you can d

Bug#737692: xterm: incorrect pathname in /usr/share/doc/xterm/xterm.faq.gz

On 2014-02-17 19:36:53 -0500, Thomas Dickey wrote: > I did some investigation, found only Sun which had done this. > There's an updated FAQ for your enjoyment, in the usual place: > > http://invisible-island.net/xterm/xterm.faq.html OK. Thanks, -- Vincent Lefèvre - Web:

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

On 2012-02-26 02:54:45 +0100, Vincent Lefevre wrote: > * With fvwm, Ctrl-Meta-arrows have no effect. This is actually quite strange: Ctrl-Meta-arrows were initially working, but after a few dozens of seconds (or some particular event?), they were no longer working. -- Vincent Lefèvre -

Bug#752047: latter half of Chinese lines now injured suddenly

On 2014-06-19 13:14:36 +0800, 積丹尼 Dan Jacobson wrote: > Do this: > while sleep 1; do echo 歡迎收看「小姐愛魔術」; done > Notice how only half of the chars appear? On my machine, I see no differences with xterm 306-1, and it looks OK. -- Vincent Lefèvre - Web: 100% accessible vali

Bug#432011: xserver-xorg: X server doesn't honour some xmodmap settings

On 2014-07-13 14:42:30 +0200, Julien Cristau wrote: > This was forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=11822 > and apparently fixed ages ago. Closing. I now use XKB instead of xmodmap, and I confirm that everything is fine. -- Vincent Lefèvre - Web:

Bug#755090: xserver-xorg-input-synaptics: AlpsPS/2 ALPS DualPoint TouchPad is extremely slow

On 2014-07-17 18:48:25 +0200, Vincent Lefevre wrote: > I haven't tried to downgrade yet. The problem disappeared after the following downgrade: -ii xserver-xephyr2:1.15.99.904-1 amd64nested X server -ii xserver-xorg-core

Bug#756268: x11-xkb-utils: xkbcomp to :0 sometimes succeeds with no effect

Package: x11-xkb-utils Version: 7.7+1 Severity: normal To restore the XKB settings automatically after suspend/resume, I use the following /etc/pm/sleep.d/xkb-save-restore script: #!/bin/sh set -e dir=/run/pm-xkb mkdir -p $dir display

Bug#756268: x11-xkb-utils: xkbcomp to :0 sometimes succeeds with no effect

Additional information: I have "xhost +si:localuser:root" in my .xsession file (otherwise xkbcomp immediately fails). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (

Bug#633849: Me too

On 2013-10-30 22:44:45 +0100, Eugen Dedu wrote: > I have the same bug and I would really love to have it fixed. Since about 2 > years (before, it worked) I have been forced to execute xmodmap ~/.xmodmap > after each resume, since the key bindings I use in that file are lost at > suspend. There's

Bug#673027: xkbcomp bad parsing of -w option

Control: tags -1 patch On 2012-05-15 15:14:17 +0100, Zefram wrote: > xkbcomp's warning-level option only works if the numeric argument comes > in a separate command-line argument from the "-w". E.g., "xkbcomp -w 3 > t0.xkb" and "xkbcomp -w 4 t0.xkb" work, and produce different degrees > of verbos

Bug#758633: xterm: exec-formatted, exec-selectable, insert-formatted, insert-selectable do not work correctly

Package: xterm Version: 308-1 Severity: normal The exec-formatted, exec-selectable, insert-formatted, insert-selectable features do not work correctly. Well, with: Meta: exec-formatted("browser %s", PRIMARY) works correctly when the PRIMARY selection belongs to the current xterm, but if it be

Bug#759734: xterm: the cursor hides the underneath character when in reverse video with xterm -bg black -fg white

Package: xterm Version: 308-1 Severity: normal The cursor hides the underneath character when it is in reverse video with "xterm -bg black -fg white". To reproduce this, select the beginning of a command line and move the cursor backward to the selected part. This also occurs with links, links2 an

Bug#167495: xterm: /etc/X11/app-defaults/XTerm-color shouldn't define unnecessary resources

Package: xterm Version: 4.1.0-17 Severity: normal /etc/X11/app-defaults/XTerm-color shouldn't define unnecessary resources, like how the scrollbar looks like, as the user can't always override them. -- System Information Debian Release: testing/unstable Kernel Version: Linux ay 2.4.18-newpmac #1

Bug#167495: acknowledged by developer (Re: Bug#167495: xterm: /etc/X11/app-defaults/XTerm-color shouldn't define unnecessary resources)

On Sun, Nov 03, 2002 at 14:48:26 -0600, Debian Bug Tracking System wrote: > You are mistaken. The user can always override them with X resource > settings. No, I use *Scrollbar.thickness: 10 *Scrollbar.background: grey *Scrollbar.foreground: black and this doesn't ov

Bug#167495: xterm: /etc/X11/app-defaults/XTerm-color shouldn't define unnecessary resources

On Sun, Nov 03, 2002 at 23:37:50 -0500, Branden Robinson wrote: > On Sun, Nov 03, 2002 at 11:37:25PM +0100, Eduard Bloch wrote: > > Btw, please remove this color definition: > > > > *VT100*color4: DodgerBlue1 > > > > Color4 is used by many applications as foreground color, and I do not > > know a

Bug#167495: acknowledged by developer (Re: Bug#167495: xterm: /etc/X11/app-defaults/XTerm-color shouldn't define unnecessary resources)

On Mon, Nov 04, 2002 at 12:12:26 -0500, Branden Robinson wrote: > I got the latter two to work by saying the following: > > *VT100.Scrollbar.background: grey > *VT100.Scrollbar.foreground: black This is not surprising, but this is not an acceptable solution for me, just a hack.

Bug#278897: xterm: insert-selection(...) action breaks selection insertion

On 2004-11-04 12:29:21 -0500, Branden Robinson wrote: > Is this not a bug, then, but rather a misunderstanding of how > translation table resources work? Well, this is a bug in the documentation, which doesn't provide enough information. It wasn't even clear that XtAugmentTranslations or XtOverrid

Bug#280364: xserver-common: X crashed (signal 7) while scrolling in Mozilla

Package: xserver-common Version: 4.3.0.dfsg.1-8 Severity: grave Justification: causes non-serious data loss While I was scrolling a Mozilla window, X crashed (signal 7). This is the first time this happens, but I usually don't use XFree86. I lost all the data that have not been saved by X applicat

Bug#280364: xserver-common: X crashed (signal 7) while scrolling in Mozilla

On 2004-11-09 06:31:42 +0100, Fabio Massimo Di Nitto wrote: > If X applications are not able to handle data properly on crash, > that's an application problem. Hmm... OK. I hope that their maintainers won't say that the X server shouldn't crash. However, it seems difficult to recover the session a

Bug#280457: xterm: Save terminal data when X connection is lost

Package: xterm Version: 4.3.0.dfsg.1-8 Severity: normal When the X connection is lost abnormally, e.g. when the X server has crashed as in bug#280364, xterm should save the terminal data (including the lines that are scrolled off the top of the window) in some way so that the user doesn't lose dat

Bug#280457: xterm: Save terminal data when X connection is lost

On 2004-12-10 03:45:11 -0500, Branden Robinson wrote: > > Severity: wishlist > > I agree. :) Well, I considered that losing data (as long as the program has the control of them) was a bug. > I get basically this functionality, plus a lot of other useful > features, by using GNU Screen, availa

Bug#257062: i915 support

Any news? FYI, I'm currently using the xserver-xfree86 package from , which has support for i915. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 100% accessible validated (X)HTML - Blog: Work: CR IN

Bug#277832: still not fixed...

reopen 277832 thanks I have xterm 4.3.0.dfsg.1-9, and the problem (as described in the first message) is still there. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmeti

Bug#280457: xterm: Save terminal data when X connection is lost

On 2004-12-15 14:59:14 -0500, Branden Robinson wrote: > Output streams from character devices are not the same sort of > "data" for the purpose of bug severities as the contents of a > filesystem. OK. > > The (only?) big problem with screen is that one cannot scrollback > > with the mouse. > > I

Bug#277832: #277832 xterm: copy/paste of non-ISO-8859-1 characters between uxterm windows

On 2004-12-16 17:55:47 -0500, Thomas Dickey wrote: > Actually I did fix the hard part. The remainder is user-preferences > which can be easily set with resources. How? I didn't see anything new in the man page. > In #197, I also added a section to the manpage describing the use of > the clipboard

Bug#277832: #277832 xterm: copy/paste of non-ISO-8859-1 characters between uxterm windows

On 2004-12-17 13:27:40 -0500, Thomas Dickey wrote: > There aren't that many choices - the primary selection is only owned by > one application at a time. I reduced(*) xterm's tendency to give it up, > but > > if another application asserts it, or > > you start a new selection, or

Bug#277832: #277832 xterm: copy/paste of non-ISO-8859-1 characters between uxterm windows

On 2004-12-17 19:22:15 -0500, Thomas Dickey wrote: > On Sat, 18 Dec 2004, Vincent Lefevre wrote: > >When I tried with the latest Debian version, neither of these > >conditions were satisfied (a click shouldn't be regarded as > >starting a selection). So, the bug is s

Bug#277832: #277832 xterm: copy/paste of non-ISO-8859-1 characters between uxterm windows

On 2004-12-19 06:50:34 -0500, Thomas Dickey wrote: > On Sat, 18 Dec 2004, Vincent Lefevre wrote: > >How should I change them? Does select-extend() work without a > >select-start() first? > > no - how would it know where the selection started? So, I don't see how to conf

Bug#280457: xterm: Save terminal data when X connection is lost

On 2004-12-23 18:53:17 -0500, Branden Robinson wrote: > On Wed, Dec 15, 2004 at 10:59:42PM +0100, Vincent Lefevre wrote: > > On 2004-12-15 14:59:14 -0500, Branden Robinson wrote: > > > If screen is linked against ncurses, it may be a "simple mattter of > > > progr

Bug#277832: still not fixed...

On 2004-12-31 04:34:13 -0500, Branden Robinson wrote: > Well, let's call this bug what it is, then. Note that gnome-terminal isn't the only application that keeps the primary selection when it is no longer highlighted. Mozilla, Opera and Emacs all have the same behavior. And I don't think this is

Bug#318092: xserver-xorg: Disabling 3-button mouse emulation doesn't work at reconfigure time.

On 2005-07-13 17:09:08 +0200, Vincent Lefevre wrote: > Attached, but the problem no longer occurs! Now is occurs again. I've attached the diff on the output.xorg file. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> 100% accessible validated (

Bug#318092: xserver-xorg: Disabling 3-button mouse emulation doesn't work at reconfigure time.

On 2005-07-13 18:29:25 +0200, David Martínez Moreno wrote: > Try the attached dexconf, and see if your problem vanishes. Yes, this solves the problem. Thanks. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 100% accessible validated (X)HTML - Blog:

Bug#319179: uxterm and utf-8 font selection

Package: xterm Version: 6.8.2.dfsg.1-3 Severity: normal The file /etc/X11/app-defaults/UXTerm says: ! The fonts here are duplicated in "XTerm" by "*VT100.utf8fonts", but are ! left here for compatibility: *VT100*font2: -misc-fixed-medium-r-normal--8-80-75-75-c-50-iso10646-1 *VT100*font:-mis

  1   2   3   4   5   >