aste race.
I think xterm should buffer the input until the selection arrives.
There should be a timeout which should be configurable.
If the timeout occurs, I guess the buffered input should be discarded
and the bell should be rung.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.o
Package: xserver-xorg
Version: 1:7.7+3~deb7u1
$ xlsclients -display :0 t
Maximum number of clients reachedxlsclients: unable to open display
:0
$
I have lots and lots of windows open (including around 213 xterms) -
this is not a client connection leak in some application.
Michel Dänzer writes (Re: Bug#617184: xorg -depth 8 fails (colourmap broken)
on Thinkpad R50p):
http://lists.x.org/archives/xorg-devel/2011-February/019092.html
Thanks for the reference.
In my quick testing, the radeon driver seems to have further
pseudocolour issues at least with KMS
Package: xserver-xorg
Version: 1:7.5+8
To reproduce:
cp .Xauthority private/tmpfile
xauth -f private/tmpfile generate $DISPLAY . untrusted timeout 10
Actual behaviour:
My X server died. The log message was:
X: ../../Xext/security.c:323: SecurityAuthorizationExpired: Assertion
Cyril Brulebois writes (Re: Bug#616667: X server crash due to xauth generate
with large timeout):
With 2:1.9.99.903-1, I'm getting:
| -(cyril@talisker)-(/tmp)-()
| $ xauth -f private generate $DISPLAY . untrusted timeout 10
| xauth: (argv):1: couldn't query Security extension on
Package: xserver-xorg-video-radeon
Version: 1:6.13.1-2+squeeze1
If I say
X vt9 -dpi 100 -nolisten tcp -retro -depth 8 :3
I get an X server whose colour map seems entirely broken. The initial
startup screen is entirely black (the weave requested by -retro is
missing), although the mouse cursor
Carl Schaefer writes (Bug#582566: X values lost):
using Ubuntu 10.04 I see a similar problem with keyboard mouse values
configured by xset being lost after a resume or chvt. I've worked
around that lossage by using the desktop Preferences menu to get the
behavior I want, so maybe this set of
Package: xserver-xorg
Version: 1:7.3+20
My laptop has a synaptics touchpad. I recently switched to using a
non-ancient X server and I wanted to restore the behaviour I had with
the ancient X server, so I decided to arrange for the X server not to
load the synaptics module which seemed to be
Julien Cristau writes (Re: Bug#597564: Hard to stop X server loading module
synaptics):
On Mon, Sep 20, 2010 at 23:53:38 +0200, Julien Cristau wrote:
On Mon, Sep 20, 2010 at 22:18:30 +0100, Ian Jackson wrote:
Package: xserver-xorg
Version: 1:7.3+20
Oh wait, lenny. What I said applies
Russell Adams writes (Bug#541388: Xmodmap loss):
I too am having this issue. Is there a workaround?
I recently had a similar symptoms. I have reported mine in #596775
since I wasn't sure the causes were the same. Also related are
probably:
#568868 key repeat for caps lock goes away after
Package: xserver-xorg
Version: 1:7.3+20
On my system, I run an xmodmap which contains
pointer = 1 3 2
This swaps right and middle button which I find useful.
If I do this
rmmod psmouse
modprobe psmouse
then when the X server regains its ability to use the mouse, the
pointer setting has
Ian Jackson writes (Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier map,
broken Shift):
Julien Cristau writes (Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier
map, broken Shift):
14:08 daniels jcristau: getting an empty modmap is a symptom of running
Julien Cristau writes (Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier
map, broken Shift):
On Mon, Aug 25, 2008 at 17:00:08 +0100, Ian Jackson wrote:
* When xmodmap -pm is run in Xsetup, it prints an empty modifier
map. That is, there are no modifiers set.
14:08 daniels
Julien Cristau writes (Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier
map, broken Shift):
Hrm. Why is dpkg unpacking xkb-data before removing -legacy? Looks
like some Conflicts/Replaces are missing there.
Because that's what an in-place replacement looks like. That's
precisely
Ian Jackson writes (Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier map,
broken Shift):
Julien Cristau writes (Re: Bug#496548: xmodmap in xdm Xsetup, empty modifier
map, broken Shift):
Hrm. Why is dpkg unpacking xkb-data before removing -legacy? Looks
like some Conflicts
Package: xkb-data, xkb-data-legacy
Version: 1.3-2, 1.0.1-4
[EMAIL PROTECTED]:~ dpkg -i
/export/mirror/debian-ftp/pool/main/x/xkeyboard-config/xkb-data_1.3-2_all.deb
dpkg: considering removing xkb-data-legacy in favour of xkb-data ...
dpkg: yes, will remove xkb-data-legacy in favour of xkb-data.
Package: xserver-xorg-core
Version: 2:1.4.2-3
I'm suffering a problem with xmodmap. Since at least July 1997 I have
swapped control and capslock on my displays, and made certain other
changes to the keymap, by using xmodmap in the xdm Xsetup script.
This no longer works properly. (I do it like
Ian Jackson writes (Re: Bug#375667: x11-common and xserver-xorg unupgradeable
due to mutual deathgrip):
Daniel Stone writes (Re: Bug#375667: x11-common and xserver-xorg
unupgradeable due to mutual deathgrip):
On Wed, Jun 28, 2006 at 05:41:28PM +0100, Ian Jackson wrote:
/usr/bin/X11
Daniel Stone writes (Re: Bug#375667: x11-common and xserver-xorg unupgradeable
due to mutual deathgrip):
Some people have hardcoded /usr/bin/X11/xauth, et al. As I'm reading
the FHS, it must continue to work.
Just xauth (or a handful of other things) ? We could have a symlink
(managed by the
Ian Jackson writes (Re: Bug#375667: x11-common and xserver-xorg unupgradeable
due to mutual deathgrip):
Just xauth (or a handful of other things) ? We could have a symlink
(managed by the postinst to avoid dpkg accidentally replacing xauth
with a link to itself) for the transition.
I mean
Daniel Stone writes (Re: Bug#375667: x11-common and xserver-xorg unupgradeable
due to mutual deathgrip):
crap [in] /usr/X11R6 [and] hardcoded paths into /usr/X11R6.
Right, so we have to make those paths keep working.
On Wed, Jun 28, 2006 at 05:41:28PM +0100, Ian Jackson wrote:
/usr/bin/X11
Daniel Stone writes (Re: Bug#375667: x11-common and xserver-xorg unupgradeable
due to mutual deathgrip):
Patches welcome. If you know of a better way to do this transition, I'm
all ears.
Almost certainly there is a better way. I'd be happy to help.
I think I'll need rather a lot of the
Ian Jackson writes (Re: Bug#375667: x11-common and xserver-xorg unupgradeable
due to mutual deathgrip):
So
before /usr/{lib,include}/X11 - /usr/X11R6/{lib,include}
after /usr/{lib,include}/X11 - /usr/X11R6/{lib,include}
and
before /usr/bin/X11 - /usr/X11R6/bin (real dir)
after
Julien Cristau writes (Re: Bug#375667: x11-common and xserver-xorg
unupgradeable due to mutual deathgrip):
Before X11R7, lots of things were installed in
/usr/X11R6/{bin,lib,include}. There were symlinks
/usr/bin/X11 - ../X11R6/bin, /usr/include/X11 - ../X11R6/include/X11
and /usr/lib/X11 -
Package: x11-common
Version: 7.0.22
anarres# dpkg -i pool/main/x/xorg/xserver-xorg_7.0.22_all.deb
dpkg: regarding .../xserver-xorg_7.0.22_all.deb containing xserver-xorg,
pre-dependency problem:
xserver-xorg pre-depends on x11-common (= 7.0.0-0ubuntu3)
x11-common is installed, but is version
Package: x11-common, xserver-xorg
Version: 7.0.22, 7.0.22
anarres# dpkg -i pool/main/x/xorg/x11-common_7.0.22_i386.deb
dpkg: considering removing xserver-common in favour of x11-common ...
dpkg: no, cannot remove xserver-common (--auto-deconfigure will help):
xnest depends on xserver-common
Julien Cristau writes (Re: Bug#375667: x11-common and xserver-xorg
unupgradeable due to mutual deathgrip):
(c) using aptitude (or maybe apt-get) which can upgrade these packages
without problems.
apt* just `cope' with this problem by running dpkg with --force
options. Ie, they decide that you
Package: xterm
Version: 6.8.2.dfsg.1-7
Part of my session arrangements include running this command:
xterm -e .configs/rxprofile
from in my home directory (/u/ian in this case).
/u/ian/.configs/rxprofile exists and is an executable shell script.
This no longer works (!)
In
strace -Ffot xterm
Package: xserver-xorg
Version: 6.8.2.dfsg.1-6
In the config script I see:
DRIVER_DIR=/usr/X11R6/lib/modules/drivers
# Build list of available video drivers, omitting the atimisc, r128, and
# radeon sub-modules (the ati driver knows when and how to load these).
# v4l is not a display
Thomas Dickey writes (Bug#89887: Bug#19538: marked as done (xterm: resize not
handled by both primary and alternate screens)):
On Sat, Aug 21, 2004 at 01:18:49AM -0500, Branden Robinson wrote:
What reason is there for not changing it ?
Thomas, meet Ian Jackson. ;-)
I've already had
Thomas Dickey writes (Bug#89887: Bug#19538: marked as done (xterm: resize not
handled by both primary and alternate screens)):
I'll update the manpage to reflect the bug report (taking into account the
caveat regarding Secure keyboard. But given that this topic comes up
very rarely, I don't
31 matches
Mail list logo
