Bug#650291: xterm -bg/-fg doesn't choose nearest colour the hardware supports
Package: xterm Version: 261-1 Severity: minor When specifying colours not supported by the hardware, xterm does not choose the nearest hardware colour. For example: xterm -bg '#9c009c009c00' On a standard 24 bit colour server, the nearest colour is #9b9b9b9b9b9b, but xterm chooses #9c9c9c9c9c9c. Likewise, for e.g. -bg '#ff00ff00ff00', xterm chooses #fff, which is much farther then the nearest colour supported by the display (#fefefefefefe) - xterm's chosen colour has a difference of 255 units per component to the requested colour, while the nearest colour the display supports only has a difference of only 2 units, which is a considerable difference). -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xterm depends on: hi libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libfontconfig12.8.0-2.1 generic font configuration library ii libice6 2:1.0.6-2 X11 Inter-Client Exchange library ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libutempter0 1.1.5-3A privileged helper for utmp/wtmp ii libx11-6 2:1.3.3-4 X11 client-side library ii libxaw7 2:1.0.7-1 X11 Athena Widget library ii libxft2 2.1.14-2 FreeType-based font drawing librar ii libxmu6 2:1.0.5-2 X11 miscellaneous utility library ii libxt61:1.0.7-1 X11 toolkit intrinsics library ii xbitmaps 1.1.0-1Base X bitmaps Versions of packages xterm recommends: ii x11-utils 7.5+4 X11 utilities ii xutils1:7.5+8X Window System utility programs m Versions of packages xterm suggests: ii xfonts-cyrillic 1:1.0.1Cyrillic fonts for X -- no debconf information -- 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/2028160758.5494.35961.reportbug@cerebro.laendle
Bug#611232: Acknowledgement (libx11-6: XrmSetDatabase is documented to not free the database, but frees it, causing crashes)
Further info: This problem is related to, but not the same, as this one: https://bugs.freedesktop.org//show_bug.cgi?id=21974 http://osdir.com/ml/bug-gnu-emacs-gnu/2009-05/msg00653.html And apparently, the faulty code was introduced by this commit: http://lists.freedesktop.org/archives/xorg-commit-diffs/2004-March/000239.html It also shows that XrmSetDatabase is broken in any case, as the flag is not reset in all cases. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ -- 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/20110127021340.ga...@schmorp.de
Bug#611232: libx11-6: XrmSetDatabase is documented to not free the database, but frees it, causing crashes
Package: libx11-6
Version: 2:1.3.3-4
Severity: normal
The documentation for XrmSetDatabase says:
"The database previously associated with the display (if any) is not
destroyed."
Consequently, to avoid memory leaks, rxvt-unicode uses this to replace it:
XrmDestroyDatabase (XrmGetDatabase (dpy));
XrmSetDatabase (dpy, get_resources (true));
This works almost always. However, sometimes, some third-party library
calls XGetDefault itself, and this causes the undocumented behaviour of
freeing the resource database in XrmSetDatabase.
LockDisplay(display);
/* destroy database if set up imlicitely by XGetDefault() */
if (display->db && (display->flags & XlibDisplayDfltRMDB)) {
XrmDestroyDatabase(display->db);
display->flags &= ~XlibDisplayDfltRMDB;
}
display->db = database;
UnlockDisplay(display);
This makes it basically impossible to both avoid a memory leak AND not
crashing on a double free.
And either the manpage is wrong (which claims the database isn't freed) or
the code.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.37-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libx11-6 depends on:
hi libc6 2.11.2-7 Embedded GNU C Library: Shared lib
ii libx11-data 2:1.3.3-4 X11 client-side library
ii libxcb1 1.6-1 X C Binding
libx11-6 recommends no packages.
libx11-6 suggests no packages.
-- debconf information excluded
--
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/20110127013134.31968.55853.reportbug@cerebro.laendle
Bug#541453: xtrapin: ../../src/xcb_lock.c:77: _XGetXCBBuffer: Assertion failed
Package: x11-xserver-utils Version: 7.3+5 Severity: normal simply starting xtrapin gives me: Display: cerebro:0.0 Available Information: Release: 3.4-0 Platform: Other (0x00) Major Opcode: 145 Flags: Timestamps CmdKey CmdKeyMod Requests Events MaxPkt Statistics WinXY GrabServer (0xbf41) Max Packet Size: 65535 Current (x,y): (0,0) Flags: (0x) xtrapin: ../../src/xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy->request)) >= 0)' failed. Aborted [Exit 134 (SIGABRT)] This is with libx11-6 2:1.1.5-2 and similar xlibs form unstable. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages x11-xserver-utils depends on: ii cpp 4:4.3.2-2 The GNU C preprocessor (cpp) hi libc6 2.7-18 GNU C Library: Shared libraries ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libsm62:1.0.3-2 X11 Session Management library ii libx11-6 2:1.2.1-1 X11 client-side library ii libxau6 1:1.0.3-3 X11 authorisation library ii libxaw7 2:1.0.4-2 X11 Athena Widget library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxi62:1.1.4-1 X11 Input extension library ii libxmu6 2:1.0.4-1 X11 miscellaneous utility library ii libxmuu1 2:1.0.4-1 X11 miscellaneous micro-utility li ii libxrandr22:1.2.3-1 X11 RandR extension library ii libxrender1 1:0.9.4-2 X Rendering Extension client libra ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii libxtrap6 2:1.0.0-5 X11 event trapping extension libra ii libxxf86misc1 1:1.0.1-3 X11 XFree86 miscellaneous extensio ii libxxf86vm1 1:1.0.2-1 X11 XFree86 video mode extension l ii x11-common1:7.3+19 X Window System (X.Org) infrastruc x11-xserver-utils recommends no packages. x11-xserver-utils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#541212: xserver-xorg-input-evdev: xserver resets xkb configuration on first keypress
Package: xserver-xorg-input-evdev Version: 1:2.0.8-1 Severity: normal I recently was forced to switch to the evdev driver from the kbd driver (the kbd driver generates spurious repeat events under load due to the lack of event timestamps, evdev fixes that as the kernel delivers timestamps). Since evdev uses different keycodes, the default keymap at server start does not work evry well (arrow keys, window keys etc. have different keycodes), which made the problem obvious. It might be a problem with the kbd driver, too, but since keycodes don't change, it is hard to tell. So here is what hapens: 1. the server starts, using it's built-in us keyboard map with keycodes matching the kbd drivers keycodes. 2. applications start, download xkb info. for example, my window manager binds itself on Super_L (windows key) for some action. 3. on first keypress (no matter if it comes minutes later or during x startup), the x-server simply resets the xkb configurtion, but doesn't tell applications. 4. at this point, all applications get wrong keycodes (for example, my End key acts as if it were Super_L), until they are either restarted, or setxkbmap or xkbcomp set a new keymap (which tells all running apps by sending an event). Or in short, the x-server changes the xkb config on first keypress, without telling applications about the change. This is not very visible when using e.g. xdm - the first keypress is usually a printable character which has the same keycode no matter what, and xdm etc. ensures that all applicaitons get restarted after some keypress. It is also not very visible issue when running setxkbmap afetr a keypress, as that forces apps (or xlib...) to reload xkb info. It is also not visible when using the normal kbd driver, as that one uses the same keycodes as the server, so switching from that set to the identical one causes no issues. The only workaround I found was to start a terminal with "please press return to continue" and a read, i.e. force a keypress before starting further apps. -- Package-specific info: Contents of /var/lib/x11/X.roster: xserver-xorg /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Mar 5 2008 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1901136 Jun 11 12:07 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8800 GTX (G80) (rev a2) /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw--- 1 root root 7408 Aug 12 15:53 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: Section "Files" FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" #FontPath "/usr/X11R6/lib/X11/fonts/vtx/:unscaled" #FontPath"unix/:7100" EndSection Section "ServerFlags" #NoTrapSignals #DontZap #DontZoom Option "Pixmap" "32" Option "Xinerama" "off" Option "NoPM" "yes" Option "AllowDeactivateGrab" "yes" Option "AllowClosedownGrabs" "yes" #Option "XkbDisable" "true" EndSection Section "Extensions" Option "Composite" "Enable" Option "DAMAGE" "Enable" Option "RENDER" "Enable" EndSection Section "Module" #Load "v4l" Load "glx" #Load "drm" #Load "dri" #Load "/usr/X11/lib/modules/extensions/libglx.so" Load "extmod" Load "record" Load "dbe" Load "wacom" Load "xtrap" Load "freetype" #Load "speedo" #Load "type1" #Load "int10" #SubSection "extmod" # Option"omit SHAPE" # Option"omit MIT-SUNDRY-NONSTANDARD" # Option"omit BIG-REQUESTS" # Option"omit SYNC" # Option"omit MIT-SCREEN-SAVER" # Option"omit XC-MISC" # Option"omit XFree86-VidModeExtension" # Option"omit XFree86-Misc" # Option"omit XFree86-DGA" # Option"omit DPMS" # Option"omit FontCache" # Option"omit TOG-CUP" # Option"omit Extended-Visual-Information" # Option"omit XVideo" # Option"omit XVideo-MotionCompensation" # Option"omit X-Resource" #EndSubSection EndSection Section "DRI" Mode 0600 Group 0 EndSection Section "InputDevice" Identifier "Keyboard" Driver "evdev" Option "Device" "/dev/input/by-path/platform-i8042-serio-0-event-kbd" Option "CoreKeyboard" Option "AutoRepeat""250 30" Option "GrabDevice""on" Option "XkbRules" "xfree86" Option "XkbLayout""de(nodeadkeys)+compose(caps)" #Option "XkbOptions" "compose:caps" Option "XkbModel" "pc105" Option "XkbKeycodes" "evdev" EndSection Section "InputDevice" Identifier "Mouse" Driver
Bug#462262: libxft-dev: XftDrawRect buggy behaviour whens erver doesn't support xrender
Package: libxft-dev
Version: 2.1.8.2-8
Severity: normal
XftDrawRect works differently when the alpha channel is < 32768 depending
on wether the server supports the xrender extension or not.
First of all, it is documented to "fill a solid rectangle". This is
the actual behaviour when the server supports xrender: the pixel value
(including alpha channel) is taken as it is and the destination rectangle will
be filled with the value:
XRenderFillRectangle (draw->dpy, PictOpSrc, draw->render.pict,
&color->color, x, y, width, height);
(pictopsrc is documented to just copy all four channels (rgba) from source to
destination).
However, when the xrender extension is not supported by the x-server,
the behaviour is different: when the alpha value is >= 32768, then the
rectangle will be filled with the pixel value as-is (which is the correct
behaviour), otherwise _NOTHING_ will be done:
if (color->color.alpha >= 0x8000)
{
XSetForeground (draw->dpy, draw->core.gc, color->pixel);
XFillRectangle (draw->dpy, draw->drawable, draw->core.gc,
x, y, width, height);
}
This makes xftdrawrect unsuitable for the purpose it was actually created
for: filling the background to some defined value. Regardless of what
the purpose behind xftdrawrect, this is completely different behaviour
depending on wether the server supports xrender or not.
(for example, when xftdrawrect'ing a 100% transparent red over a newly
allocated and uncleared pixmap will result in that pixmap being filled
with 100% transparent red when the server supports xrender, and with
retaining the garbage it contained when the server doesn't support
xrender).
The fix is to always call xfillrectangle even for partly transparent
colours, resulting in the same behaviour regardless of the availability of
xrender.
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.23-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libxft-dev depends on:
hi libc6-dev [libc-dev] 2.7-5 GNU C Library: Development Librari
ii libfontconfig1-dev 2.4.2-1.2 generic font configuration library
hi libfreetype6-dev 2.3.5-1+b1FreeType 2 font engine, developmen
ii libx11-dev 2:1.0.3-7 X11 client-side library (developme
ii libxft22.1.8.2-8 FreeType-based font drawing librar
ii libxrender-dev 1:0.9.1-3 X Rendering Extension client libra
ii x11-common 1:7.3+10 X Window System (X.Org) infrastruc
ii zlib1g-dev [libz-dev] 1:1.2.3.3.dfsg-10 compression library - development
libxft-dev recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401956: libx11-6: contents of .XCompose file are leaked to subprocesses (possibly unprivileged)
Package: libx11-6 Version: 2:1.0.3-4 Severity: critical Tags: security Justification: root security hole First of all, I tagged this bug as critical because the description in reportbug fit, but as the issue is relatively harmless and not directly caused by libx11, feel free to reprioritise, I will know in the future. I hope I did the right thing. Thanks - and possibly sorry! Anyways, libx11 leaks the contents of .XCompose to subprocess, because it does not close the file descriptor nor does it set the cloexec flag on the filehandle. Such leaks are usually very pervasive as few programs care for fds they did not open. For example, under a urxvtd terminal window running bash: cerebro ~# ls -l /proc/self/fd total 5 lrwx-- 1 root root 64 Dec 7 00:26 0 -> /dev/pts/6 lrwx-- 1 root root 64 Dec 7 00:26 1 -> /dev/pts/6 lrwx-- 1 root root 64 Dec 7 00:26 2 -> /dev/pts/6 lr-x-- 1 root root 64 Dec 7 00:26 3 -> /proc/5984/fd lr-x-- 1 root root 64 Dec 7 00:26 10 -> /localvol/root/.XCompose from an xterm started from the above window, using bash: lr-x-- 1 root root 64 Dec 7 00:11 5 -> /localvol/root/.XCompose lr-x-- 1 root root 64 Dec 7 00:11 10 -> /localvol/root/.XCompose and so on, I get one .XCompose fd per nesting level. from "su nobody" started in above xterm: lrwx-- 1 nobody nogroup 64 Dec 7 00:27 0 -> /dev/pts/9 lrwx-- 1 nobody nogroup 64 Dec 7 00:27 1 -> /dev/pts/9 lr-x-- 1 nobody nogroup 64 Dec 7 00:27 10 -> /localvol/root/.XCompose lrwx-- 1 nobody nogroup 64 Dec 7 00:27 2 -> /dev/pts/9 lr-x-- 1 nobody nogroup 64 Dec 7 00:27 3 -> /proc/6012/fd lr-x-- 1 nobody nogroup 64 Dec 7 00:27 5 -> /localvol/root/.XCompose It is very likely that many programs that change the uid will not care for the extra fd, as it should not be there in the first place. The file is fortunately only opened read-only, and the contents of .XCompose files are usually not very private. The actual contents of the .XCompose file do not matter, as long as it exists, libx11 (likely the code in modules/im/ximcp/imLcIm.c) leaks the fd. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.6 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages libx11-6 depends on: hi libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libx11-data 2:1.0.3-2 X11 client-side library ii libxau6 1:1.0.1-2 X11 authorisation library ii libxdmcp61:1.0.1-2 X11 Display Manager Control Protoc ii x11-common 1:7.1.0-6 X Window System (X.Org) infrastruc libx11-6 recommends no packages. -- debconf information: libx11-6/migrate_xkb_dir: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358907: libxvmc-dev: libXvMCW.so missing in package
Package: libxvmc-dev Version: 6.9.0.dfsg.1-4 Severity: important The package doesn't contain libXvMCW.so, so all programs trying to link against it will try to use the static version, in general excluding use of libXvMCW in shared libraries. Adding the link to libXvMCW.so.1 manually makes it work. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.15.1 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages libxvmc-dev depends on: ii libxv-dev 6.9.0.dfsg.1-4 X Window System video extension li ii libxvmc1 6.9.0.dfsg.1-4 X Window System video motion compe ii x-dev 6.9.0.dfsg.1-4 X protocol development files libxvmc-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291137: /usr/X11R6/bin/luit: luit sometimes doesn't restore terminal settings or hangs
Package: xutils Version: 4.3.0.dfsg.1-10 Severity: normal File: /usr/X11R6/bin/luit luit sometimes doesn't restore terminal settings corretcly, which results in echo and other flags being turned off. example: luit echo foo results in echo turned off (no typed input being seen). It doesn't happen deterministically and seems to be completely independent of the locale and the program. The following script demonstrates it on my system: #!/usr/bin/bash stty sane for((i=0;i<1;i++)); do stty -a >/tmp/a luit echo -n stty -a >/tmp/b stty sane diff -u a b done This shows a difference in roughly 33 of 1 tries on my system, but statistics vary. The diff is like this: --- a 2005-01-19 00:08:00.806405713 +0100 +++ b 2005-01-19 00:08:00.810404774 +0100 @@ -1,10 +1,11 @@ speed 38400 baud; rows 35; columns 142; line = 208; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; -lnext = ^V; flush = ^O; min = 1; time = 0; +lnext = ^V; flush = ^O; min = 0; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts --ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff +-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany imaxbel -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt +opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 +ff0 +-isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke Sometimes, luit will hang completely. Attaching strace to luit in this case gives the following output: Process 14230 attached - interrupt to quit write(2, "Couldn\'t copy terminal settings\n", 32) = 32 exit_group(1) = ? Process 14230 detached and exits. It looks like there is a race condition inside luit. It is likely an upstream issue because similar behaviour can be demonstrated ona fedora 3 system. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (700, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages xutils depends on: ii cpp 4:3.3.5-1 The GNU C preprocessor (cpp) hi libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libncurses5 5.4-4 Shared libraries for terminal hand ii xfree86-common 4.3.0.dfsg.1-10 X Window System (XFree86) infrastr ii zlib1g 1:1.2.2-3 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#246091: libxft-dev: xft-config doesn't output version
Package: libxft-dev Version: 2.1.2-6 Severity: important xft-config --version outputs nothing (an empty line). the reason eems to be that the xft-config ascript has this line: version="" this means that most packages will not detect the presence of xft-config properly, or at all. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (700, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.5 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 Versions of packages libxft-dev depends on: hi libc6-dev [libc-dev]2.3.2.ds1-11 GNU C Library: Development Librari ii libfontconfig1-dev 2.2.2-2 generic font configuration library hi libfreetype6-dev2.1.7-2 FreeType 2 font engine, developmen ii libx11-dev 4.3.0-7 X Window System protocol client li ii libxft2 2.1.2-6 FreeType-based font drawing librar ii libxrender-dev 0.8.3-7 X Rendering Extension client libra ii x-dev 4.3.0-7 X protocol development files ii zlib1g-dev [libz-dev] 1:1.2.1-5compression library - development -- no debconf information
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
t is in a somewhat detrimental state and the (much worse) konsole and gnome-terminals come "standard" on most dekstops). > Well, the Linux framebuffer console driver uses a shade of blue very > similar to the one I made color4 use for the corresponding color, and > *that's* a VT100 (technically VT220) emulator. I can't reproduce that at all. I just booted a knoppix, which uses fb, and looked at the 2.4.25 source. The shade of blue used for the framebuffer looks identical and (by code) seems to be even darker than colours the majority of terminals use (i.e. "dark" blue, although it's quite a light blue in fact). framebuffer: #aa (standard vga actually, and real vt100 AFAICR) gnome-terminal#aa Eterm:#cc rxvt: #cd mlterm: #e6 pterm:#eb konsole: #1818b2 (quite different, but still mostly the same blue) xterm-debian: #1e90ff (drastically different colour, especially with regards to contrast) That clearly disagrees with what you claim. As you can see, they vary considerably in the exact colour used, but it's always a real blue. The only exception is xterm on debian that drastically changed at least that colour to something not really blue either, but _much_ lighter and giving a much lower contrast. Maybe the kernel you used was especially patched to use another colour? Or you use some user-space program that resets the colours after boot? > It is this behavior of fbcon that inspiried me to change xterm's > default, as I found that brighter blue much easier to read against the > black background, and wanted xterm to be easy to read too. Whatever inspired you, it's not the standard fbcon that is part of the linux kernel (2.4.25 at least). Please note that I don't say that change is inherently bad (if somehting is broken for 20 years it should still be fixed), but that change brings more bad than good, as all the other terminals mostly agree on the shade of blue used and programs wil need to make exceptions to look good/readable/as expected on xterm only (which they might well do and look bad on most other terminals). I think one mustn't change too lightly something that is such a widely used de-facto standard. It took me only a minute or so to find out that something is bad about xterm: I couldn't use alsamixer. And later some other apps, but then I stopped trying. Alsamixer is a good example. It assumes (not without good indication) that blue contrasts good with red. However, xterm replaced that blue with something resembling a light cyan (you can disagree with that description, after all, my colour vision is not _that_ good and describing colours is not the easiest thing for me :). As a result, alsamixer is readable _everywhere_ except on debians xterm. I think what needs to be changed is programs using bad colour combinations, not the standard vt100 colour palette. Consider a similar change in the TCP/IP protocol suite: some web-server is misbehaving and breaking the http protocol. The "xterm solution" would be to use another port number for the working servers, while I would propose to leave working servers as they are and instead fix the one web server that is causing the trouble. The obvious (to me) reason is that changing the colour palette affects all the "good" applications, while fixing the few apps that use bad colours (colour-ls for example I would put into that group, at least with a thin font. I sit in front of an LCD screen and don't have problems, but I guess on CRTs the dark blue for directories might be annoying). > > text on xterm while the same tetx looks readable everywhere else. > > Well, as I said above, this has precedent in fbcon, and is now the > default upstream. Well, as I said above, there seems to be no precedent and it makes it very hard to use for visually impaired users, and disagrees with the _whole_ rest of the world. > I agree that the manpage should be patched for Debian. That solution is fine with me, if you ask me. > > colours should be set to the same set of colours that every other terminal > > displays, otherwise programs have no chance to use colours portably. > > I think you are overstating your case. Please adjust it in light of the > facts I have now brought to your attention. I honestly have no idea what you mean by that. I am not making fun of you or anything, I just brought that to your attention, and you can fix it in any way or like, either compatible with the rest of the world or not. Regarding the facts, the only verifiable fact I see is that debians xterm uses a vastly different colour than everybody else seems to. I completely agree wiht that, but that's what I am talking about, too. I think I have now clearly and in every possible detail explained what I wanted to expla
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
ctually displayed is the outline of this cursor. It does not resemble the originally intended apearance. I assume that this is a just an oversight or a omission on part of the debian maintainer, nothing more, and not intended behaviour. The changed colours, OTOH, are obviously intended behaviour, but most combinations are much harder to read to me (I have a very common form of red-green blindness). The standard (vt100) colours are more-or-less standard among all terminal emulators (some might use not-quite-white for white, but the general brightness and look is extremely similar). Debians xterm (and only debains xterm AFAICS) changed at least one of these colours (maybe more). The problem is that programs assume the vt100 colour set and due to the drastically changed brightness (apart from appearance) of the changed colour(s), programs often output hard-to-read text on xterm while the same tetx looks readable everywhere else. In addition, this colour change *is* a bug as the manpage documents the colours clearly, but the displayed colours are not in according to the manpage. To resolve this, either the manpage needs to be updated to conform to the debian "standard", or (preferably as this is a usability issue), the colours should be set to the same set of colours that every other terminal displays, otherwise programs have no chance to use colours portably. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Package: xterm Version: 4.3.0-7 Severity: minor The xterm mouse cursor is a thin line, under debians xterm, it's much thicker. Specifying -rv restores the original cursor (but does not do reverse video, see bug #239510, which is probably related). It seems that debians xterm does not set mouse cursor colours correctly and defaults to white background and black foreground, while the default config specifies black background on white foreground, which is probably why -rv fixes this as it correctly swaps background and foreground for all items. Another colour problem: debian also changed default colours of xterm, which makes coloured text very hard to read, especially for colour-impaired people like me (it's very difficult for me to decipher e.g. the alsamixer labels in xterm, other shells work fine). The original xterm colours are much easier on my eyes, due to the much increased contrast. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (700, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.4 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 Versions of packages xterm depends on: hi libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an hi libexpat1 1.95.6-4 XML parsing C library - runtime li ii libfontconfig1 2.2.1-8 generic font configuration library hi libfreetype62.1.5-2 FreeType 2 font engine, shared lib ii libice6 4.3.0-7 Inter-Client Exchange library ii libncurses5 5.4-2Shared libraries for terminal hand ii libsm6 4.3.0-7 X Window System Session Management ii libxaw7 4.3.0-7 X Athena widget set library ii libxext64.3.0-7 X Window System miscellaneous exte ii libxft2 2.1.2-6 FreeType-based font drawing librar ii libxmu6 4.3.0-7 X Window System miscellaneous util ii libxpm4 4.3.0-7 X pixmap library ii libxrender1 0.8.3-7 X Rendering Extension client libra ii libxt6 4.3.0-7 X Toolkit Intrinsics ii xlibs 4.3.0-7 X Window System client libraries m ii xlibs-data 4.3.0-7 X Window System client data -- no debconf information
Bug#232133: libx11-dev: mismatch between docs and header (XRegisterIMInstantiateCallback)
Package: libx11-dev Version: 4.3.0-0pre1v5 Severity: normal The manpage for XRegisterIMInstantiateCallback (and XUnregisterIMInstantiateCallback) shows the fifth argument as type "XIMProc". The Xlib.h header, however, uses a XIDProc as fifth argument and the xfree code indeed passes a display as first argument (i.e. uses it like a XIDProc). Further, the sixth argument is documented to be a XPointer * (and actually takes a XPointer * on other X11 imps), whereas xfree86 wants a XPointer there. Either xfree86 has wrong code, or wrong manpages. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux cerebro 2.4.24 #1 SMP Wed Jan 14 01:35:15 CET 2004 i686 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 Versions of packages libx11-dev depends on: hi libc6-dev [libc-dev] 2.3.2.ds1-10 GNU C Library: Development Librari ii libx11-6 4.3.0-0pre1v5 X Window System protocol client li ii x-dev 4.3.0-0pre1v5 X protocol development files -- no debconf information
