Hi,
Xterm is still *really* slow for me when background colors are set;
it's if jump-scrolling is disabled. For example:
$ time xterm -geometry 80x25 -e 'for i in `seq 1 1`; do echo -e "This is
line \e[40;31;01m$i\e[0m" ; done'
real0m23.052s
user0m1.396s
sys 0m1.148s
$ time xt
I'm seeing the same problem here. I don't think this is related to
that upstream bug, because that bug deals with having no bell
(for me, "echo -e '\a'" is also silent ... I presume it's fixed by
that upstream patch).
Anyway, this bug also means that "xset b off" doesn't work either.
But apparent
tags 507916 patch
thanks
The latest version (2:1.7.5-1) still has this bug.
-jim
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100301002336.ga13...@psychosis.jim.sh
Hi,
I ran into a similar crash in xf86_reload_cursors and this patch
worked for me.
-jim
Index: xorg-server-1.6.5/hw/xfree86/modes/xf86Cursors.c
===
--- xorg-server-1.6.5.orig/hw/xfree86/modes/xf86Cursors.c 2009-11-29
15:16:2
severity 365602 normal
tags 365602 + patch
thanks
Hi,
I think this is more than just a minor bug, as it very much reduces
the usefulness of font size changes. In return for inflating the
severity, I offer a patch :)
With this applied, you can maximize an xterm, fire up a program like
emacs, hit
I've run into this bug for a very long time, usually when starting
something like the Linux "make menuconfig". If this isn't a problem
with xterm, could it be reassigned to the proper package (libxinerama?
xfs?) so it can be properly addressed?
-jim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
Tracking down the source of large slowdowns on my system led me to
this problem. Indeed, xfonts-75dpi and xfonts-100dpi still don't run
fc-cache after installation, and running it manually as root fixed
everything. Should this bug be reassigned to those packages? Or is
there a better solution --
Michel Dänzer wrote:
> On Fri, 2006-02-17 at 18:00 -0500, Paul Donohue wrote:
> > I grabbed the 12/20/05 version of the driver from cvs (I think this should
> > correspond to 6.9.0):
> > 'cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -D "2005-12-20"
> > driver/xf86-video-ati'
The buggy change
Package: xlibmesa-gl
Version: 4.3.0.dfsg.1-8
Severity: serious
Justification: Policy 3.5
Anything that uses libGL does not run due to the missing libXxf86vm.so.1:
$ dpkg -S /usr/lib/libGL.so.1
xlibmesa-gl: /usr/lib/libGL.so.1
$ ldd /usr/lib/libGL.so.1
libX11.so.6 => /usr/X11R6/li
> > Is it your opinion that this is a bug in the Linux kernel, then?
>
> neither - I did read that this behavior is changed in the next version
> of the kernel, but it's something that xterm should (in principle) handle.
>
> But if it's really changed as reported, then I may not have to fix anyth
Package: xterm
Version: 4.3.0.dfsg.1-5
Severity: normal
Later Linux 2.6 kernels do not recycle pseudo TTYs, so ptys like
/dev/pts/1234 are not uncommon.
xterm does not seem to handle this well at all. In particular, it
relies on the 4-digit ut_id field in utmp, which would look like
"p123" in t
Package: xserver-xfree86
Version: 4.3.0-7jim
Severity: normal
Tags: patch
The "Rotate" option of the siliconmotion driver is broken in 4.3 due
to RandR. Attached patch disables RandR when Rotate is used; this
seems to be the solution used by other drivers and it works.
-- Package-specific info:
> > That may be the case, although it's not my particular problem, as
> > I'm not using a PS/2 mouse.
>
> But your XF86Config-4 contains a Device section for /dev/psaux (did you
> choose that in debconf?). If CONFIG_INPUT_MOUSEDEV_PSAUX is enabled in
> your kernel, mouse events will appear there a
> > I think this is a problem with the Debian-generated configuration.
> > For /dev/input/mice, it specifies SendCoreEvents _and_ also
> > includes it in the ServerLayout as an InputDevice. Commenting
> > out the SendCoreEvents line fixes the problem and each event
> > is only received once.
>
>
> I had heard rumors that Linux kernel 2.6 demultiplexes PS/2 mouse
> devices into /dev/input/mice, and not just USB mouse devices as 2.4
> does.
That may be the case, although it's not my particular problem, as
I'm not using a PS/2 mouse.
-jim
Package: xserver-xfree86
Version: 4.3.0-0pre1v5
Severity: normal
I spent a while trying to figure out why my USB mouse would always
move the cursor by at least two pixels at a time, even when
acceleration was fully disabled (with e.g. "xset m 1 1").
With a little extra debugging added in xf86Xinp
16 matches
Mail list logo
