Bug#683942: #683942 xterm: alternate screen scrolling
I've applied a change for this which will appear in the #282 updates. Woo hoo, thanks! Andrew -- 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/1348670930-sup-4...@pimlott.net
Bug#683942: xterm: alternate screen scrolling
Excerpts from Thomas Dickey's message of Sun Aug 05 11:06:02 -0700 2012: On Sun, Aug 05, 2012 at 09:40:22AM -0700, Andrew Pimlott wrote: Is there another way for me to get this behavior? It's fairly simple as an addition to xterm, probably hard other ways... That sounds like a note that I made with reference to a comment about konsole early this year: 120207 if mouse-mode enabled, wheel mouse _does_ same. arch-user wants it to send up/down arrows, sez konsole does this. **120208 better, add a control sequence for switching between sets of mouse translations, including konsole's combination. (I'm currently working on complicated changes in vile and lynx, thinking I'll work on xterm next...) Awesome, I'll be glad if you get to this. Happy hacking, Andrew -- 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/1344272595-sup-1...@pimlott.net
Bug#683942: xterm: alternate screen scrolling
Package: xterm Version: 278-1 Severity: wishlist Dear Maintainer, I used gnome-terminal recently and noticed that using the mouse wheel caused scrolling within apps like vim. I thought that was strange, because I disabled mouse support in vim. It turns out gnome-terminal has a feature called alternate screen scrolling. When you are in the alternate screen, it translates the mouse wheel into three up or down arrow presses. This is obviously a hack, but I want it. (I don't like enabling mouse support in vim because it takes over the mouse entirely, and as far as I understand there is no way for it to only take the wheel.) I thought I might be able to set up my own translations, but I don't think there is a way to define translations that apply only in the alternate screen. Is there another way for me to get this behavior? Andrew -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xterm depends on: ii libc6 2.13-33 ii libfontconfig1 2.9.0-6 ii libice6 2:1.0.8-2 ii libtinfo5 5.9-10 ii libutempter01.1.5-4 ii libx11-62:1.5.0-1 ii libxaw7 2:1.0.10-2 ii libxft2 2.3.1-1 ii libxmu6 2:1.1.1-1 ii libxt6 1:1.1.3-1 ii xbitmaps1.1.1-1 Versions of packages xterm recommends: ii x11-utils 7.7~1 Versions of packages xterm suggests: pn xfonts-cyrillic none -- 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/20120805164022.ga9...@oinkpad.pimlott.net
Bug#566600: state of the bell
I'm having trouble with my X11 bell too (in current unstable), and I see a few bugs outstanding (564200, 564464, 566600). It seems to me that there are multiple issues, and they might be getting confused. I'll add my observations here and try to help sort things out. First, my .xsession has two calls to xset to control the bell: xset b 50 2000 50 xset b off (The first is there so if I do turn on the bell, it has the pitch I want.) But when I starts and I open an xterm and run xset q, I see bell percent: 50bell pitch: 400bell duration: 100 So something is resetting the bell. I haven't been able to figure out what. In fact, it even continues to happen after my X session is running. I run xset b off and a few minutes later, it is back on. I haven't figured out if there's a pattern to what I've been doing in between. Second, the xset b setting isn't even having an effect. Programs like gvim that ring the bell continue to sound, even when I've run xset b off and xset q shows it off. Nor does the pitch setting have any effect. I've read about xkbbell, but I'm not clear on the relationship to the old bell or moreover what setting will turn it off. Third, xterm isn't ringing the bell when it should. This seems to be acknowledged in 564200, though I don't see what the plan to fix it is. I'm pretty perplexed by these observations, both because it seem strange for all of them to be happening at once (this is all due to to upgrades within the last month), and because I can't imagine that everyone's bell started going loco or there would be more reports. Let me know what I can do to help track this down. Andrew -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541117: xserver-xorg-video-intel: high CPU usage after 2.7.1-1 - 2.8.0-1 upgrade
On Thu, Aug 20, 2009 at 08:56:16AM +0200, Brice Goglin wrote: According to errors in your log, something's going bad with DRM. Does this log come from a second X server while another X server was already using the DRM device? Damn, I don't know why I didn't notice that. No, it was the only X server running. But I took a look at my configuration and noticed that I had Disable dri because of bug 525123. I don't know what dri has to do with drm, but seeing that they have the first two letters I decided to comment that out and try running 2.8 again. Now, it performs well again! And, I don't see any of the issues from bug 525123 either (even though I can't remember quite what that looked like). In sum, on my X40: 2.7.1 2.8.0 empty configbug 525123 :-) Disable dri :-) bug 541117 I'm attaching two diffs of the log files. 2.7.1-2.8.0.diff compares 2.7.1 with 2.8.0, both with Disable dri. (I should have run this diff before I filed the bug, sorry.) enable_dri.diff compares 2.8.0 with Disable dri and without. Thanks for your help! Andrew --- /var/log/Xorg.0.log 2009-08-20 08:05:19.0 -0700 +++ /var/log/Xorg.0.log.old 2009-08-20 08:02:58.0 -0700 @@ -11,7 +11,7 @@ Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. -(==) Log file: /var/log/Xorg.0.log, Time: Thu Aug 20 08:05:15 2009 +(==) Log file: /var/log/Xorg.0.log, Time: Thu Aug 20 08:02:44 2009 (==) Using config file: /etc/X11/xorg.conf (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. @@ -111,7 +111,7 @@ (II) LoadModule: intel (II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so (II) Module intel: vendor=X.Org Foundation - compiled for 1.6.3, module version = 2.7.1 + compiled for 1.6.2.901, module version = 2.8.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, @@ -119,7 +119,8 @@ E7221 (i915), 915GM, 945G, 945GM, 945GME, IGD_GM, IGD_G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, Mobile Intel® GM45 Express Chipset, - Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41 + Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41, IGDNG_D, + IGDNG_M (II) Primary Device is: PCI 0...@00:02:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x - 0x (0x1) MX[B] @@ -149,6 +150,8 @@ (II) Loading sub module ramdac (II) LoadModule: ramdac (II) Module ramdac already built-in +(EE) intel(0): [drm] Failed to open DRM device for : No such file or directory +(EE) intel(0): Failed to become DRM master. (II) intel(0): Creating default Display subsection in Screen section Default Screen Section for depth/fbbpp 24/32 (==) intel(0): Depth 24, (--) framebuffer bpp 32 @@ -157,9 +160,9 @@ (II) intel(0): Integrated Graphics Chipset: Intel(R) 855GME (--) intel(0): Chipset: 852GM/855GM (--) intel(0): Linear framebuffer at 0xE000 -(--) intel(0): IO registers at addr 0xD000 +(--) intel(0): IO registers at addr 0xD000 size 524288 (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB -(==) intel(0): Using EXA for acceleration +(II) intel(0): No SDVO device is found in VBT (II) intel(0): 2 display pipes available. (II) Loading sub module ddc (II) LoadModule: ddc @@ -179,14 +182,14 @@ (II) LoadModule: sil164 (II) Loading /usr/lib/xorg/modules/drivers//sil164.so (II) Module sil164: vendor=X.Org Foundation - compiled for 1.6.3, module version = 1.0.0 + compiled for 1.6.2.901, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) intel(0): I2C bus DVOI2C_E initialized. (II) Loading sub module ch7xxx (II) LoadModule: ch7xxx (II) Loading /usr/lib/xorg/modules/drivers//ch7xxx.so (II) Module ch7xxx: vendor=X.Org Foundation - compiled for 1.6.3, module version = 1.0.0 + compiled for 1.6.2.901, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) intel(0): I2C bus DVOI2C_E removed. (II) intel(0): I2C bus DVOI2C_E initialized. @@ -194,7 +197,7 @@ (II) LoadModule: ivch (II) Loading /usr/lib/xorg/modules/drivers//ivch.so (II) Module ivch: vendor=X.Org Foundation - compiled for 1.6.3, module version = 1.0.0 + compiled for 1.6.2.901, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) intel(0): I2C bus DVOI2C_E removed. (II) intel(0): I2C bus DVOI2C_B initialized. @@ -202,7 +205,7 @@ (II) LoadModule: tfp410 (II) Loading /usr/lib/xorg/modules/drivers//tfp410.so (II) Module tfp410: vendor=X.Org Foundation - compiled for 1.6.3, module version = 1.0.0 + compiled for 1.6.2.901, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) intel(0): I2C bus DVOI2C_B removed. (II) intel(0): I2C bus DVOI2C_E initialized. @@ -210,13 +213,12 @@ (II)
Bug#525123: xserver-xorg-video-intel on Intel 82852/855GM: display corrupted
Following up on my message to this bug When I upgraded to driver version 2.8.0, I had terrible performance. I reported it as bug 541117. It turned out that I had to re-enable dri to fix that. Fortunately, I don't see this bug any more! Andrew -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541117: xserver-xorg-video-intel: high CPU usage after 2.7.1-1 - 2.8.0-1 upgrade
Package: xserver-xorg-video-intel Version: 2:2.8.0-1 Severity: important After upgrading from 2.7.1-1, firefox is terribly slow and causes xorg to pin the CPU for several seconds when (for example) switching tabs. I'm running kernel linux-image-2.6.30-1-686 on a Thinkpad X40. I've looked through the other bugs, and I don't think my problem matches any of them. I also observe that when I resume from suspend to ram, my background is corrupt. And I've had a couple crashes. None of this happened with 2.7.1-1. 2:2.8.0-2 has the same behavior. Finding a hint in bug 538283, I tried adding the i915 module with modeset=1. I made the changes in /etc/modules and /etc/modprobe.d/local.conf and rebooted. The effect on the text VCs was obvious, but when I tried to startx, it hung with a blank screen. BTW, the Xorg.0.log file included below is actually Xorg.0.log.old, since I'm running the downgraded X now. It is the log file that corresponds with the bad behavior. Any hints on where to look? Thanks, Andrew PS. How do you downgrade these days, since snapshot.debian.net is stale? I found a source package at Ubuntu launchpad, but it was a pain. -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 2008-10-22 10:53 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1689976 2009-08-06 09:55 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 865 2009-05-10 10:55 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Module # bugs.debian.org/525123 Disable dri EndSection Section Device Identifier Configured Video Device EndSection # Mouse wheel emulation now configured in # /etc/hal/fdi/policy/20thirdparty/10-x11-evdev.fdi # Progress! Xorg X server log files on system: -rw-rw-r-- 1 root root 67514 2006-01-12 14:22 /var/log/Xorg.2.log -rw-rw-r-- 1 root root 36581 2009-05-11 12:18 /var/log/Xorg.1.log -rw-rw-r-- 1 root root 53946 2009-08-11 11:00 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log.old: X.Org X Server 1.6.3 Release Date: 2009-7-31 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.30.4-dsa-ia32 i686 Debian Current Operating System: Linux apple 2.6.30-1-686 #1 SMP Mon Aug 3 16:18:30 UTC 2009 i686 Build Date: 06 August 2009 04:49:57PM xorg-server 2:1.6.3-1+b1 (bui...@murphy.debian.org) Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Tue Aug 11 10:21:00 2009 (==) Using config file: /etc/X11/xorg.conf (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |--Screen Default Screen Section (0) (**) | |--Monitor default monitor (==) No device specified for screen Default Screen Section. Using the first device section listed. (**) | |--Device Configured Video Device (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to /usr/lib/xorg/modules (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. (II) Loader magic: 0x6c0 (II) Module ABI
Bug#525123: xserver-xorg-video-intel on Intel 82852/855GM: display corrupted
I observe the same on my Thinkpad X40, and use the workaround of disabling DRI (thanks Joe!). This is the first version of the -intel driver I've tried; the -i810 driver worked fine. Andrew -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528261: xserver-xorg: new mouse configuration needs examples
Package: xserver-xorg Version: 1:7.4+1 Severity: wishlist I found out from NEWS.Debian about the changes to configuration of input devices in X. It all seems fine, except that it took me a while to figure out exactly how to port over my xorg.conf to HAL (file location, syntax, restarting hald). I think a template fdi file would go a long way towards helping users figure out where to put their options. For example, you could install the following as /etc/hal/fdi/policy/x11-mouse.fdi: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input.mouse match key=/org/freedesktop/Hal/devices/computer:system.kernel.name string=Linux !-- Add mouse options from xorg.conf here. For example, if you had Option EmulateWheel on, add merge key=input.x11_options.EmulateWheel type=stringon/merge Don't forget to run /etc/init.d/hal restart! -- /match /match /device /deviceinfo Andrew -- 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 2008-10-22 10:53 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1695356 2009-04-15 04:47 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 865 2009-05-10 10:55 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Module # bugs.debian.org/525123 Disable dri EndSection Section Device Identifier Configured Video Device EndSection # Mouse wheel emulation now configured in # /etc/hal/fdi/policy/20thirdparty/10-x11-evdev.fdi # Progress! Xorg X server log files on system: -rw-rw-r-- 1 root root 67514 2006-01-12 14:22 /var/log/Xorg.2.log -rw-rw-r-- 1 root root 36581 2009-05-10 10:54 /var/log/Xorg.1.log -rw-rw-r-- 1 root root 35864 2009-05-10 10:59 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.6.1 Release Date: 2009-4-14 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.26-1-amd64 x86_64 Package files: 100 /var/lib/dpkg/status release a=now 500 http://ftp.debian.org sid/main Packages release o=Debian,a=unstable,l=Debian,c=main origin ftp.debian.org Pinned packages: Current Operating System: Linux apple 2.6.29-1-686 #1 SMP Fri Apr 17 14:35:16 UTC 2009 i686 Build Date: 15 April 2009 11:46:22AM xorg-server 2:1.6.1-1 (bgog...@debian.org) Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun May 10 10:59:18 2009 (==) Using config file: /etc/X11/xorg.conf (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |--Screen Default Screen Section (0) (**) | |--Monitor default monitor (==) No device specified for screen Default Screen Section. Using the first device section listed. (**) | |--Device Configured Video Device (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to /usr/lib/xorg/modules (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available,
Bug#252214: /usr/X11R6/bin/xev: xev -id misses events
On Thu, Apr 12, 2007 at 10:15:01PM +0200, Brice Goglin wrote: About 3 years ago, you reported a bug to the Debian BTS regarding xev -id missing some events. Did you reproduce this problem recently? With Xorg/Etch? If not, I will close this bug in the next weeks. Thank you again for following up! On a current unstable system, the behavior is the same as indicated in the bug log. In case it helps, here are more explicit steps to reproduce: 1. Open an xterm. 2. Run xprop | grep -w id, click on the xterm, and note the id. 3. Run xev -id 0x, where the last argument is the id. 4. Play around in the xterm and note the mysterious behavior. This bug probable needs a NOBODYCARES tag. :-) Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#264016: fvwm: FvwmForm uses bad fonts in utf-8 locale
On Fri, Apr 13, 2007 at 03:49:40AM +0200, Brice Goglin wrote: About 3 years ago, you reported a bug to the Debian BTS regarding FvwmForm using bad fonts in utf8 locale. Do you still experience this problem today? No. It seems that fonts with the iso8859-1 encoding now display fine in a UTF-8 locale. Perhaps it was only a bug in X that made it break before. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#264017: iso8859-1 fonts work fine in a UTF-8 locale
In following up on bug 264016, I found that this bug no longer occurs (in unstable). A font with an iso8859-1 displays just fine in my UTF-8 locale. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241423: xserver-xfree86: [nv] fails for GeForce FX Go5200 rev 161
On Tue, Jan 16, 2007 at 08:40:32PM +0100, Brice Goglin wrote: About 2 years ago, you reported (or replied to) a bug in the Debian BTS regarding a failure of the X server on a nVidia GeForce RX Go2500 board. Did any of you guys reproduce this problem recently? This hardware is long gone for me. Thanks for following up though! Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#216161: xserver-xfree86: font resolution not following the rules
On Sun, Jan 14, 2007 at 02:59:38AM +0100, Brice Goglin wrote: About 3 years ago, you reported a bug to the Debian BTS regarding font resolution not following the rules. Did you reproduce this problem recently? If not, I will close this bug in the next weeks. Well, I can confirm the same behavior as I reported on a current unstable system. However, in the process of testing I noticed something I probably missed before. When I remove the gsfonts-x11 aliases, the font chosen when I run xfd -fn '-adobe-times-bold-r-normal--17-120-100-100-p-86-iso8859-1' is -adobe-times-bold-r-normal--17-120-100-100-p-87-iso8859-1 Note the 86 becomes 87. (This is the average width field, measured in tenths of pixels according to X(7).) This caused me to suspect that the bitmap font was being skipped according to the rule in /usr/share/X11/doc/fonts.txt: When matching fonts, the server makes two passes over the font path: during the first pass, it searches for an exact match; during the second, it searches for fonts suitable for scaling. But here's the wicked thing: If you look at /usr/share/fonts/X11/100dpi/fonts.dir, you find timB12-ISO8859-1.pcf.gz -adobe-times-bold-r-normal--17-120-100-100-p-88-iso8859-1 Note the width is 88! So where did the 87 come from? That I have no idea. Anyhow, if I restore the gsfonts-x11 aliases and ask for -adobe-times-bold-r-normal--17-120-100-100-p-88-iso8859-1 then I get the expected bitmap font. I have no idea anymore where the example font string came from; probably I changed it in some config file long ago. At this point, the issue doesn't matter to me, and based on the above investigation, the behavior in fact looks pretty sane. The only reason to keep this bug open, IMO, would be to understand the 86/87 quirk. But you can close it for all I care. Sorry for the long mail, and thanks again for following up. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366180: xkb-data: many files in /etc/X11/xkb (from xlibs) orphaned in X11R7 transition
Package: xkb-data Version: 0.8-5 Severity: normal When upgrading through the transition to X11R7, I purged the xlibs package and installed xkb-data. I got many warnings: dpkg - warning: while removing xlibs, directory `/etc/X11/xkb/symbols/pc' not empty so not removed. dpkg - warning: while removing xlibs, directory `/etc/X11/xkb/symbols' not empty so not removed. dpkg - warning: while removing xlibs, directory `/etc/X11/xkb/rules' not empty so not removed. dpkg - warning: while removing xlibs, directory `/etc/X11/xkb/geometry' not empty so not removed. dpkg - warning: while removing xlibs, directory `/etc/X11/xkb/compat' not empty so not removed. dpkg - warning: while removing xlibs, directory `/etc/X11/xkb' not empty so not removed. And in the end, many files were left under /etc/X11/xkb. (A full list is at the end.) No package claims ownership of these files (and dlocate confirms that the purged version of xlibs did not own them). I don't know how this happened, but this scenario was repeated exactly on two separate systems. On neither did I ever change any xkb conffiles. It's possible that this condition has existed for a long time, and that the bug is in an older version of xlibs. I'm filing this against xkb-data because 1) it now owns the xkb files and 2) people upgrading may remove xlibs, so there is no chance to fix the problem there. Here is the list of orphaned files under /etc/X11/xkb: geometry/omnibook compat/group_led compat/leds rules/xfree86-it.lst symbols/ru_yawerty symbols/pc/ar symbols/pc/ben symbols/pc/cz_qwerty symbols/pc/dev symbols/pc/dvorak symbols/pc/el symbols/pc/en_US symbols/pc/fr-latin9 symbols/pc/ge_la symbols/pc/ge_ru symbols/pc/guj symbols/pc/gur symbols/pc/il_phonetic symbols/pc/iu symbols/pc/kan symbols/pc/lo symbols/pc/mk symbols/pc/ml symbols/pc/mt_us symbols/pc/ogham symbols/pc/ori symbols/pc/pl2 symbols/pc/sapmi symbols/pc/sk_qwerty symbols/pc/sr symbols/pc/syr symbols/pc/syr_phonetic symbols/pc/tel symbols/pc/th_pat symbols/pc/th_tis symbols/pc/tml symbols/pc/yu symbols/pc/us_intl symbols/pc/se_FI symbols/pc/se_NO symbols/pc/se_SE symbols/pc/dz Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365984: xfonts-base: old font dirs in /usr/X11R6/lib/X11/fonts not removed
Package: xfonts-base Version: 1:1.0.0-3 Severity: minor I'm not sure if this is the right place to report this, and it's probably a known issue, but I couldn't find any mention of it. With the X transition, font directories under /usr/X11R6/lib/X11/fonts are not being removed because they still have fonts.dir, etc in them. Is there a plan for removing those files and thus the containing directories when there are no fonts left? Would it be sufficient to have update-fonts-dir, etc, delete the generated files in the postrm? Or will there be a special clean-up script when the transition is complete? Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xfonts-base depends on: ii x11-common1:7.0.16 X Window System (X.Org) infrastruc ii xfonts-utils 1:1.0.0-3 X Window System font utility progr xfonts-base recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359006: xterm: unicode glyph rendering glitch
Package: xterm Version: 210-2 Severity: minor Unicode characters generally render properly in my xterm, using LANG=en_US.UTF-8, however I just noticed a glitch. When U+2218 is rendered in some colors, it turns into the dashed box that usually denotes a bad character. To reproduce: - start vim in an xterm, with LANG=en_US.UTF - enter insert mode and type the sequence ctrl-V u2218 You should see a nice function composition symbol, U+2218: ∘ - Now colorise it by typing :set ft=mail and then entering before the symbol. When it changes color, it turns into a dashed box. If I cut and past it into another application, it shows up correctly as a function composition symbol, so xterm clearly still knows what it should be; it just doesn't render it properly. Also, I don't see the same problem with most other unicode characters, but it does seem to afflict others in the same range. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xterm depends on: ii libc6 2.3.6-4GNU C Library: Shared libraries an ii libfontconfig12.3.2-5generic font configuration library ii libice6 6.9.0.dfsg.1-5 Inter-Client Exchange library ii libncurses5 5.5-1 Shared libraries for terminal hand ii libsm66.9.0.dfsg.1-5 X Window System Session Management ii libx11-6 6.9.0.dfsg.1-5 X Window System protocol client li ii libxaw7 6.9.0.dfsg.1-5 X Athena widget set library ii libxext6 6.9.0.dfsg.1-5 X Window System miscellaneous exte ii libxft2 2.1.8.2-5.1FreeType-based font drawing librar ii libxmu6 6.9.0.dfsg.1-5 X Window System miscellaneous util ii libxt66.9.0.dfsg.1-5 X Toolkit Intrinsics ii xlibs-data6.9.0.dfsg.1-5 X Window System client data Versions of packages xterm recommends: ii xutils6.9.0.dfsg.1-5 X Window System utility programs -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346098: patch in 6.9.0.dfsg.1-4
On Fri, Mar 10, 2006 at 06:08:18PM +0100, Niko Ehrenfeuchter wrote: afaics, the above mentioned patch is included in 6.9.0.dfsg.1-4 (at least from what i've seen in the deb-sources), but unfortunately EmulateWheel still doesn't work for me with this version (up-to-date testing). I even tried to rebuild the package locally to make sure the patch is applied, but it didn't have any impact on the result... Sorry for the late reply. A better patch was checked in upstream. See https://bugs.freedesktop.org/show_bug.cgi?id=5071 I've lost track of when this might get into Debian. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348384: xterm: please restore default charClass
I want to strongly second the opinion of Kirk Hilliard [EMAIL PROTECTED]. I find that in fact the new behavior makes it harder to select URLs! When I read mail in mutt, the URL often wraps to a new line and in preceded by a '+' character. Double-clicking the URL selects the '+', so I must carefully select the start and end of the URL by character. With the old settings, I could double-click anywhere in HTTP and drag to the end by word (which is also useful to grab only part of the URL, by the way). The issue repeats itself in many other situations. For example, I used to be able to get a bug number out of a Debian changelog by double-clicking; now, I get #345477, instead. When I want a word from a document, I end up getting the surrounding punctuation as well. And so on. Moreover, xterm has had its default selection behavior forever, and with such a venerable program, the Debian package should be conservative in changing defaults. I was quite shocked by the new behavior. I even took care to keep my old xterm windows open so that I could enjoy the historical behavior until I had time to figure out what was going on! Last, if you are going to keep the change, you should not only mention it in README.Debian, but update the man page, which gives the default. In my view, the burden of maintaining the updated man page is reason enough not to make this change. ;-) Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320136: [patch] EmulateWheel button press broken
As reported in two Debian bug reports [1] [2], the ability for the
EmulateWheelButton to generate button events was broken shortly before
the 6.9 release. It is still broken in current Debian unstable package
6.9.0.dfsg.1-3, and I believe it is still broken in x.org CVS.
It was broken by version 1.15 of
xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c. The problem is the
removal of the truebuttons variable. The wheel emulation code in
MouseDoPostEvent modifies buttons to mask out EmulateWheelButton,
therefore the if condition
if (buttons != pMse-lastMappedButtons) {
(line 2256) was failing when the EmulateWheelButton was pressed,
therefore
pMse-lastMappedButtons = buttons;
(line 2359) was not being run, therefore when the EmulateWheelButton was
released,
change = buttons ^ pMse-lastMappedButtons;
(line 2162) thought there was no change, therefore the button press was
not generated.
The appended patch fixes this by restoring truebuttons (which I called
origbuttons to be slightly clearer). The logic is very similar to
before 1.15, and it does not appear to interfere with the mapping
changes in 1.15, so I don't think it will introduce any problems that
weren't already there. I tested that I can now generate a button press
with EmulateWheelButton.
The patch was generated against the latest Debian unstable sources, but
applies cleanly to the latest CVS.
Andrew
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320136
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346098
[3]
http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c?r1=1.14r2=1.15
--- mouse.c.orig2006-01-12 13:46:21.0 -0800
+++ mouse.c 2006-01-12 14:10:46.0 -0800
@@ -2076,7 +2076,7 @@
MouseDoPostEvent(InputInfoPtr pInfo, int buttons, int dx, int dy)
{
MouseDevPtr pMse;
-int emulateButtons;
+int origbuttons, emulateButtons;
int id, change;
int emuWheelDelta, emuWheelButton, emuWheelButtonMask;
int wheelButtonMask;
@@ -2084,6 +2084,8 @@
pMse = pInfo-private;
+origbuttons = buttons;
+
/* Do single button double click */
if (pMse-doubleClickSourceButtonMask) {
if (buttons pMse-doubleClickSourceButtonMask) {
@@ -2211,7 +2213,7 @@
if (dx || dy)
xf86PostMotionEvent(pInfo-dev, 0, 0, 2, dx, dy);
-if (buttons != pMse-lastMappedButtons) {
+if (origbuttons != pMse-lastMappedButtons) {
change = buttons ^ pMse-lastMappedButtons;
@@ -2314,7 +2316,7 @@
(buttons (1 (id - 1))), 0, 0);
}
-pMse-lastMappedButtons = buttons;
+pMse-lastMappedButtons = origbuttons;
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#258399: xlibs: dvorak keyboard layout is missing right alt key
On Tue, Aug 02, 2005 at 10:44:39PM +0200, Denis Barbier wrote: On Sun, Jul 24, 2005 at 09:11:39PM -0700, Andrew Pimlott wrote: Shouldn't the line include level3(ralt_switch_multikey) (line 64) simply be removed from pc/dvorak? You are fully right. As there have been various problems with other changes in XKB stuff, I for one was reluctant to push this change in before sarge release. I plan working on XKB very soon, and will then commit this change. Cool, thanks! Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#258399: xlibs: dvorak keyboard layout is missing right alt key
I'm another dvorak user who is annoyed by this behavior, and from reading this bug log, I can't figure out what the difficulty is. Shouldn't the line include level3(ralt_switch_multikey) (line 64) simply be removed from pc/dvorak? This is part of the basic definition, and does not seem to belong there. In pc/us, the basic definition does not include such a line, only the intl and alt-intl definitions. Do some people need an intl version of pc/dvorak (besides those already present, eg fr and pl_basic)? If so, let them provide it; or if I must, I'll provide it, and they can fix it if it's broken. Meanwhile, let's fix the definition for 90% of users who just want both alt keys to work. If this is not the solution, can someone explain the problem in small words, and I promise I'll work on it. Andrew PS. Thanks a lot Adam for putting that song in your sig that is now stuck in my head. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319099: /etc/init.d/xfree86-common exists during rc.d purge
Package: xfree86-common Version: 6.8.2.dfsg.1-2 Severity: minor Trying to purge xfree86-common: Removing xfree86-common ... Purging configuration files for xfree86-common ... update-rc.d: /etc/init.d/xfree86-common exists during rc.d purge (use -f to force) I have not touched /etc/init.d/xfree86-common, so I don't know why it didn't get removed. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xfree86-common depends on: ii x11-common6.8.2.dfsg.1-3 X Window System (X.Org) infrastruc xfree86-common recommends no packages. -- debconf information: xfree86-common/experimental_packages: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#288928: remove all traces of Speedo
I upgraded xfonts-scalable in unstable, and it seems that this request (to remove Speedo fonts) was granted. However, /etc/X11/fonts/Speedo is still in xfonts-scalable.list, and: Unpacking replacement xfonts-scalable ... dpkg: warning - unable to delete old file `/usr/X11R6/lib/X11/fonts/Speedo': Directory not empty % ls /usr/X11R6/lib/X11/fonts/Speedo encodings.dir fonts.cache-1 fonts.dir fonts.scale % ls /etc/X11/fonts/Speedo xfonts-scalable.scale Personally, I lament this change, because while I never knew what those fonts were good for, I always thought it was cool to have a directory called Speedo. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291787: xterm: selection is cleared by scrolling
Package: xterm Version: 4.1.0-16woody5 Severity: normal First, I want to say I couldn't be more pleased by the recent effort (bug 277832) to improve selection handling. The new behavior is generally quite pleasant. However, there appears to be a significant regression. Any time the terminal scrolls (by which I mean, a newline is received when the cursor is at the bottom, not scrolling of the view with shift-pgup), the selection is cleared. To reproduce: 1. Open an xterm. 2. Press enter enough times to get the cursor to the bottom of the screen. 3. Select something. 4. Press return to scroll one line. The selection is cleared. I'm not sure exactly which version introduced this behavior, but I'm guessing it was a side-effect of fixing bug 277832. I've verified that in 4.1.0-16woody5, the selection remains in step 4. Andrew -- System Information: Debian Release: 3.0 APT prefers unstable APT policy: (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-686-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xterm depends on: ii debconf 1.4.42 Debian configuration management sy ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libfreetype6 2.1.7-2.3 FreeType 2 font engine, shared lib ii libncurses5 5.4-4 Shared libraries for terminal hand ii libxaw7 4.1.0-16woody5 X Athena widget set library ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu -- debconf information: xterm/xterm_needs_devpts: xterm/clobber_xresource_file: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277890: xutils: file conflict with xbase-clients 4.3.0.dfsg.1-8
On Mon, Oct 25, 2004 at 01:46:30PM -0500, Branden Robinson wrote: On Sat, Oct 23, 2004 at 02:44:05AM -0400, Andrew Pimlott wrote: Package: xutils Version: 4.1.0-16woody3 Severity: minor When upgrading xutils on my mixed stable/unstable system, I got Preparing to replace xutils 4.1.0-16woody3 (using .../xutils_4.1.0-16woody4_i386.deb) ... Unpacking replacement xutils ... dpkg: error processing /var/cache/apt/archives/xutils_4.1.0-16woody4_i386.deb (--unpack): trying to overwrite `/usr/X11R6/bin/atobm', which is also in package xbase-clients This is evidently because I have xbase-clients 4.3.0.dfsg.1-8 installed. No worries if you don't want to support this configuration. This is not something I think I *can* fix. I don't think xutils Replaces: xbase-clients (= 4.3.0.dfsg.1-7) is something that makes sense to add to woody, nor do I think Martin Schulze would accept such a change. If there is a fix for this, it lies in dpkg. Every time even one package is upgraded, dpkg would have to rescan the Replaces: headers of all already-installed packages to see if this error would be suppressed by one of them. It could do this on a per-run basis, I suppose, so it would only be inefficient if you used dpkg a lot to upgrade only one package at a time. Ok, I see that my current xbase-clients has Replaces: xutils ( 4.3.0.dfsg.1-7) I had assumed that this (or something similar) was missing xbase-clients, so that there would be a simple resolution. I now understand why this isn't sufficient (though it was entirely non-obvious to me). The implicit assumption is that a Replaced package will not be upgraded to one that still contains the overwritten file. Interesting. I agree that you don't have any palatable option. However, I think dpkg could handle this without any performance hit. All it has to do is, after detecting an attempted overwrite, see whether the existing owner of the file Replaces the package being installed. (This won't handle a change of two Replaces, but ...) (Obviously, I should have filed the bug on xbase-clients if I had really thought this through.) Andrew [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
Bug#276447: xterm sometimes leaves some of the highlighted selection out of the X selection
On Fri, Oct 15, 2004 at 07:02:40AM -0400, Thomas Dickey wrote: On Fri, Oct 15, 2004 at 12:00:20AM +0200, Andrew Pimlott wrote: 2. cat a file that fills a few screens and has tabs (attached) right... was that a 24x80 screen? (it helps to know how large it was). yes
Bug#276447: xterm sometimes leaves some of the highlighted selection out of the X selection
Package: xterm Version: 4.3.0.dfsg.1-8 Severity: minor I have found a circumstance in which I paste a selection owned by xterm, but only part of the highlighted selection gets pasted. It seems to have to do with tabs and some other factors I haven't figured out. It seems to occur more readily in newly created xterms. I haven't narrowed it down any further, but I can give you steps that reproduce it for me. 1. open an xterm (80x24) 2. cat a file that fills a few screens and has tabs (attached) 3. triple-click select the last line of the file 4. scroll up until the first line in the file is visible 5. right-click on the first line 6. paste the selection somewhere You should see only lines 1-23. Note that line 23 was just off the bottom of the screen, and the next line had a tab. If I replace the tabs in the file with spaces, I don't see the problem. This is a fairly obscure bug that I'm sure won't bother most people, but it drove me batty as I chased after other presumed culprits. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages xterm depends on: ii libc6 2.3.2.ds1-17 GNU C Library: Shared libraries an ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libfontconfig12.2.3-1generic font configuration library ii libfreetype6 2.1.7-2.2 FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-8 Inter-Client Exchange library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libsm64.3.0.dfsg.1-8 X Window System Session Management ii libxaw7 4.3.0.dfsg.1-8 X Athena widget set library ii libxext6 4.3.0.dfsg.1-8 X Window System miscellaneous exte ii libxft2 2.1.2-6FreeType-based font drawing librar ii libxmu6 4.3.0.dfsg.1-8 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-8 X pixmap library ii libxrender1 0.8.3-7X Rendering Extension client libra ii libxt64.3.0.dfsg.1-8 X Toolkit Intrinsics ii xlibs 4.3.0.dfsg.1-8 X Window System client libraries m ii xlibs-data4.3.0.dfsg.1-8 X Window System client data -- no debconf information
Bug#276447: xterm sometimes leaves some of the highlighted selection out of the X selection
2. cat a file that fills a few screens and has tabs (attached)
right...
/*
dtach - A simple program that emulates the detach feature of screen.
Copyright (C) 2004 Ned T. Crigler
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include dtach.h
/* The pty struct - The pty information is stored here. */
struct pty
{
/* File descriptor of the pty */
int fd;
#ifdef BROKEN_MASTER
/* File descriptor of the slave side of the pty. For broken systems. */
int slave;
#endif
/* Process id of the child. */
pid_t pid;
/* The terminal parameters of the pty. Old and new for comparision
** purposes. */
struct termios term;
/* The current window size of the pty. */
struct winsize ws;
};
/* A connected client */
struct client
{
/* The next client in the linked list. */
struct client *next;
/* The previous client in the linked list. */
struct client **pprev;
/* File descriptor of the client. */
int fd;
/* Whether or not the client is attached. */
int attached;
};
/* The list of connected clients. */
static struct client *clients;
/* The pseudo-terminal created for the child process. */
static struct pty the_pty;
#ifndef HAVE_FORKPTY
pid_t forkpty(int *amaster, char *name, struct termios *termp,
struct winsize *winp);
#endif
/* Unlink the socket */
static void
unlink_socket(void)
{
unlink(sockname);
}
/* Signal */
static RETSIGTYPE
die(int sig)
{
/* Well, the child died. */
if (sig == SIGCHLD)
{
#ifdef BROKEN_MASTER
/* Damn you Solaris! */
close(the_pty.fd);
#endif
return;
}
exit(1);
}
/* Initialize the pty structure. */
static int
init_pty(char **argv)
{
/* Use the original terminal's settings. We don't have to set the
** window size here, because the attacher will send it in a packet. */
the_pty.term = orig_term;
memset(the_pty.ws, 0, sizeof(struct winsize));
/* Create the pty process */
the_pty.pid = forkpty(the_pty.fd, NULL, the_pty.term, NULL);
if (the_pty.pid 0)
return -1;
else if (the_pty.pid == 0)
{
/* Child.. Execute the program. */
execvp(*argv, argv);
exit(127);
}
/* Parent.. Finish up and return */
#ifdef BROKEN_MASTER
{
char *buf;
buf = ptsname(the_pty.fd);
the_pty.slave = open(buf, O_RDWR|O_NOCTTY);
}
#endif
return 0;
}
/* Creates a new unix domain socket. */
static int
create_socket(char *name)
{
int s;
struct sockaddr_un sockun;
s = socket(PF_UNIX, SOCK_STREAM, 0);
if (s 0)
return -1;
sockun.sun_family = AF_UNIX;
strcpy(sockun.sun_path, name);
if (bind(s, (struct sockaddr*)sockun, sizeof(sockun)) 0)
{
close(s);
return -1;
}
if (listen(s, 128) 0)
{
close(s);
return -1;
}
/* chmod it to prevent any suprises */
if (chmod(name, 0600) 0)
{
close(s);
return -1;
}
return s;
}
/* Sets a file descriptor to non-blocking mode. */
static int
setnonblocking(int fd)
{
int flags;
#if defined(O_NONBLOCK)
flags = fcntl(fd, F_GETFL);
if (flags 0 || fcntl(fd, F_SETFL, flags | O_NONBLOCK) 0)
return -1;
return 0;
#elif defined(FIONBIO)
flags = 1;
if (ioctl(fd, FIONBIO, flags) 0)
return -1;
return 0;
#else
#warning Do not know how to set non-blocking mode.
return 0;
#endif
}
/* Process activity on the pty - Input and terminal changes are sent out to
** the attached clients. If the pty goes away, we die. */
static void
pty_activity()
{
unsigned char buf[BUFSIZE];
struct client *p;
int len;
/* Read the pty activity */
len = read(the_pty.fd, buf, sizeof(buf));
/* Error - die */
if (len = 0)
exit(1);
#ifdef BROKEN_MASTER
/* Get the current terminal settings. */
if (tcgetattr(the_pty.slave, the_pty.term) 0)
exit(1);
#else
/* Get the current terminal settings. */
if (tcgetattr(the_pty.fd, the_pty.term) 0)
exit(1);
#endif
/* Send it out to the clients. */
for (p = clients; p; p = p-next)
{
int rc;
if (p-attached) {
rc = write(p-fd, buf, len);
if (rc == -1 errno == EAGAIN) {
int errfd = open(dtach.log, O_WRONLY|O_CREAT|O_APPEND, 0777);
write(errfd, EAGAIN\n, 7);
close(errfd);
}
}
}
}
/* Process activity on the control socket */
static void
control_activity(int s)
{
int fd;
struct client *p;
/* Accept the new client and link it in. */
fd =
Bug#237877: use DisplaySize to set dpi
On Mon, Sep 20, 2004 at 02:35:04PM -0500, Branden Robinson wrote: On Wed, Sep 01, 2004 at 04:39:17PM -0400, Andrew Pimlott wrote: On Wed, Sep 01, 2004 at 04:57:37AM -0500, Branden Robinson wrote: [Are you subscribed to this list?] Do you mean to this bug? No, I haven't learned how to do that yet. No, I mean to the debian-x mailing list no The patch by Gus (if you reverse the second half) looks like an expedient solution, unless you think it will confuse people. That just changes one hard-coded default for another. I think -softdpi would be superior to both. Choosing a specific dpi with no knowledge of the display is (finally) becoming an anachronism, so I don't see the harm in using a hard-coded hack for this purpose. IOW, I think it should be viewed as a last-ditch, can't possibly be right but better than nothing, fallback; and for that, hard-coding is fine. If anyone needs to override it, there is a much better mechanism: the DisplaySize parameter. Besides, I think we're close to being able to do a better job with debconf. I notice you already ask for screen size in some cases, and I'm guessing EDID gives it to you when it works. It seems that all you need to do is have dexconf set DisplaySize, and you can drop -dpi. What is the obstacle to that? (Well, for the sake of upgraders, you might want to change the hard-coded default in the X server, so they still have a fall-back.) Regardless, I'm sure the tide of progress will force you to remove -dpi soon enough. :-) Andrew
Bug#237877: use DisplaySize to set dpi
On Wed, Sep 01, 2004 at 04:57:37AM -0500, Branden Robinson wrote: [Are you subscribed to this list?] Do you mean to this bug? No, I haven't learned how to do that yet. On Fri, Aug 06, 2004 at 02:35:23PM -0400, Andrew Pimlott wrote: Also, has anyone asked the X developers for a soft version of -dpi or DisplaySize? It seems like a trivial feature. Sure; I've considered implementing it (-softdpi) myself. So far, not enough round tuits for it. The patch by Gus (if you reverse the second half) looks like an expedient solution, unless you think it will confuse people. Andrew
Bug#265133: xterm: horizontal scroll wheel causes beeps
On Thu, Aug 12, 2004 at 05:38:15AM -0400, Thomas Dickey wrote: It's easy enough to see if xterm is producing the beep (though a quick look through the source doesn't show me that it does). Changing the control/middle-mouse menu to use Visual Bell would modify this to a flash if xterm is producing it, not if the library is doing it. Boy, am I dumb. The answer is right in the man page: BtnUp:select-end(PRIMARY, CUT_BUFFER0) \\n\\ BtnDown:bell(0) I got thrown off because I had been trying to override this by binding Btn6Down, which as I discovered doesn't exist. But the binding for BtnDown does catch unknown buttons. Overriding this binding to ignore() fixes the beep as expected. I assume the idea was to use extra mouse buttons to copy the selection into a cut buffer, and the bell was just feedback that this had been done (maybe it was slow on old systems?). Given that the common meaning of buttons 3 seems to have changed over the years, perhaps those bindings should just be removed. Or as a compromise, the bell could be removed, since I doubt that copying to CUT_BUFFER0 does any harm, and I doubt the feedback is critical for the three users of this feature. :-) Andrew
Bug#264016: fvwm: FvwmForm uses bad fonts in utf-8 locale
On Wed, Aug 11, 2004 at 12:08:04PM -0500, Manoj Srivastava wrote: Indeed. The short forms are aliases provided by the system so that applications do not have to worry about font selection, or at least have a sane default to fall back upon. As such, the aliases should point to fonts that arte indeed sane; and this means there is only one place to change this setting, rather than requiring all applications do so. FYI, I also made this request in bug 264017. Andrew
Bug#265133: xterm: horizontal scroll wheel causes beeps
Package: xterm Version: 4.3.0.dfsg.1-6 Severity: wishlist If you accidentally use a horizontal scroll wheel (buttons 6 and 7) in an xterm, it beeps. I am using the EmulateWheel feature of XFree86 to simulate both the vertical and horizontal wheel, and when scrolling vertically, I inevitably cause a few horizontal wheel events. So this beep is rather bothersome. I tried to work around this by adding empty translations for buttons 6 and 7, but as far as I can tell, Xt only supports 5 buttons, so there is no hope of that. I presume that has something to do with the beeps, but I did not dig far enough to discover exactly what causes them. If it is simply the case that every bogus event causes a beep, maybe there can be an option to disable that. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages xterm depends on: ii libc6 2.3.2.ds1-15 GNU C Library: Shared libraries an ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libfontconfig12.2.3-1generic font configuration library ii libfreetype6 2.1.7-2.2 FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-6 Inter-Client Exchange library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libsm64.3.0.dfsg.1-6 X Window System Session Management ii libxaw7 4.3.0.dfsg.1-6 X Athena widget set library ii libxext6 4.3.0.dfsg.1-6 X Window System miscellaneous exte ii libxft2 2.1.2-6FreeType-based font drawing librar ii libxmu6 4.3.0.dfsg.1-6 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-6 X pixmap library ii libxrender1 0.8.3-7X Rendering Extension client libra ii libxt64.3.0.dfsg.1-6 X Toolkit Intrinsics ii xlibs 4.3.0.dfsg.1-6 X Window System client libraries m ii xlibs-data4.3.0.dfsg.1-6 X Window System client data -- no debconf information
Bug#265133: xterm: horizontal scroll wheel causes beeps
On Wed, Aug 11, 2004 at 08:41:34PM -0400, Thomas Dickey wrote: since it's an X library issue, it should be reported against the X libraries. (what fix do you suppose I could make to xterm to address this?) Although I inferred that Xt couldn't describe the event accurately, I didn't know who was responsible for the beep. It seems quite infelicious for a library to harrass end-users over its own shortcomings! I will pursue the problem in the librraies. Thanks, Andrew
Bug#237877: use DisplaySize to set dpi
The DPI can also be set using the DisplaySize parameter in XF86Config-4. Although this seems to be semantically equivalent to the -dpi option (none of my computers auto-detect it, so I can't tell if auto-detection overrides DisplaySize, but it seems unlikely), it would be 1) easier for users to find and change, and 2) easier to handle with dexconf. A simple 'I have a 14/15/17/21/custom/autodetect monitor' question would make this issue go away. This suggestion comes from the perspective of one who always enters DisplaySize manually, and removes the -dpi from xserverrc. Monitors differ enough in their resolutions these days that it's really worth getting it right. Also, has anyone asked the X developers for a soft version of -dpi or DisplaySize? It seems like a trivial feature. Andrew
Bug#264017: xfonts-base: don't hard-code iso8859-1 in short aliases, eg fixed
Package: xfonts-base Version: 4.3.0.dfsg.1-6 Severity: wishlist The traditional short font aliases such as fixed hard-code the iso8859-1 encoding. Thus, applications that use these aliases don't work in non iso-8859-1 locales. If the aliases were changed to use a * for the encoding, they would be useful in these locales. I realize there may be tradition or robustness rationales for leaving the encoding hard-coded, so I understand if you cannot take this suggestion. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages xfonts-base depends on: ii xutils4.3.0.dfsg.1-6 X Window System utility programs -- no debconf information
Bug#252214: /usr/X11R6/bin/xev: xev -id misses events
On Sun, Jun 06, 2004 at 09:09:07AM -0400, Thomas Dickey wrote: That's interesting. Comparing with rxvt, I see that rxvt does give ButtonPress events as well as the KeyRelease events that xterm gives. Perhaps the answer is that xev can only see the events that the application is listening to. It must be something along these lines (note that xterm also does not get motion events, which makes more sense), but in what sense is xterm not listening to button presses? Obviously, it reacts to the mouse buttons, so I presume it asks to receive these events. Or is it listening in some non-standard way? I'm guessing that something about the way it sets up its event filter is confusing xev, but I have no idea how. Andrew
Bug#252214: /usr/X11R6/bin/xev: xev -id misses events
On Sun, Jun 06, 2004 at 10:39:26AM -0400, Thomas Dickey wrote: Looking at the code, I think the answer is that in initializing the active-icon logic it modifies the flags there - affecting the regular widget as well. (This is from code dating back to before I started working on xterm). The relevant chunk is /* since only one client is permitted to select for Button * events, we have to let the window manager get 'em... */ values-event_mask = ~(ButtonPressMask | ButtonReleaseMask); values-border_pixel = term-misc.icon_border_pixel; Could you explain how xterm reacts to clicks if it has these events masked? What am I missing? Andrew
Bug#252214: /usr/X11R6/bin/xev: xev -id misses events
On Sun, Jun 06, 2004 at 10:00:51AM -0400, Andrew Pimlott wrote: It must be something along these lines (note that xterm also does not get motion events, which makes more sense) Doh, xev does see motion events in xterm, which seems even stranger. But it doesn't see them if I click and drag. Whatever is throwing off xev is exceedingly weird. It's not important, but I would be very curious if anyone figures it out. Andrew
Bug#252214: /usr/X11R6/bin/xev: xev -id misses events
On Sun, Jun 06, 2004 at 10:00:51AM -0400, Andrew Pimlott wrote: It must be something along these lines (note that xterm also does not get motion events, which makes more sense), but in what sense is xterm not listening to button presses? BTW, I only used xterm as an example. I originally observed the problem on mozilla, so I'm sure this is a systematic problem with xev (and whatever interfaces it uses). So I wouldn't waste your time looking for the answer in xterm. :-) Andrew
Bug#252214: /usr/X11R6/bin/xev: xev -id misses events
Package: xbase-clients Version: 4.3.0.dfsg.1-1 Severity: minor File: /usr/X11R6/bin/xev I discovered that xev has an -id option, which I hoped I could use to debug the behavior of an application by recording the exact events it received. However, when I run it on, say, an xterm, I don't get any ButtonPress or ButtonRelease events. When I press a button, I do get LeaveNotify, EnterNotify, and KeymapNotify events. There is probably some fundamental reason for this that can't be fixed, but I'm reporting it just in case. Maybe it should be documented. Also, I found that I can get the information I want from xtrapout. Andrew -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.4-s03nexplan Locale: LANG=C, LC_CTYPE=C Versions of packages xbase-clients depends on: ii cpp 4:3.3.3-2 The GNU C preprocessor (cpp) ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an ii libdps1 4.3.0.dfsg.1-1 Display PostScript (DPS) client li ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libfontconfig12.2.2-2generic font configuration library ii libfreetype6 2.1.7-2FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-1 Inter-Client Exchange library ii libncurses5 5.4-3 Shared libraries for terminal hand ii libpng12-01.2.5.0-6 PNG library - runtime ii libsm64.3.0.dfsg.1-1 X Window System Session Management ii libstdc++51:3.3.3-6 The GNU Standard C++ Library v3 ii libxaw7 4.3.0.dfsg.1-1 X Athena widget set library ii libxcursor1 1.1.3-1X cursor management library ii libxext6 4.3.0.dfsg.1-1 X Window System miscellaneous exte ii libxft2 2.1.2-6FreeType-based font drawing librar ii libxi64.3.0.dfsg.1-1 X Window System Input extension li ii libxmu6 4.3.0.dfsg.1-1 X Window System miscellaneous util ii libxmuu1 4.3.0.dfsg.1-1 lightweight X Window System miscel ii libxpm4 4.3.0.dfsg.1-1 X pixmap library ii libxrandr24.3.0.dfsg.1-1 X Window System Resize, Rotate and ii libxrender1 0.8.3-7X Rendering Extension client libra ii libxt64.3.0.dfsg.1-1 X Toolkit Intrinsics ii libxtrap6 4.3.0.dfsg.1-1 X Window System protocol-trapping ii libxtst6 4.3.0.dfsg.1-1 X Window System event recording an ii libxv14.3.0.dfsg.1-1 X Window System video extension li ii xlibmesa-gl [libgl1] 4.3.0.dfsg.1-1 Mesa 3D graphics library [XFree86] ii xlibmesa-glu [libglu1]4.3.0.dfsg.1-1 Mesa OpenGL utility library [XFree ii xlibs 4.3.0.dfsg.1-1 X Window System client libraries m ii xlibs-data4.3.0.dfsg.1-1 X Window System client data ii zlib1g1:1.2.1.1-3compression library - runtime -- no debconf information
Bug#241423: xserver-xfree86: [nv] fails for GeForce FX Go5200 rev 161
Package: xserver-xfree86 Version: 4.3.0-7 Severity: normal This card is identified as nVidia Corporation GeForce FX Go5200 rev 161, device ID 0324, on a Dell Inspiron 5150. The X server starts, but leaves me with a screen that looks like a text mode. It is mostly blank with some blocky garbage characters, and some of which may be blinking. Killing with ctrl-alt-backspace brings me back to a text console. The log (below) makes it seem that X thinks everything's ok. Upstream 4.4.0 works fine with the same XF86Config-4. I'm not using any third-party drivers. Andrew This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.0.1 (Debian 4.3.0-7 20040318043201 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.6.4 i686 [ELF] Build Date: 18 March 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.6.4s03nexplan ([EMAIL PROTECTED]) (gcc version 3.3.3 (Debian)) #1 Tue Mar 30 10:58:50 PST 2004 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.1.log, Time: Wed Mar 31 17:17:24 2004 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Monitor (**) | |--Device Video Card (**) |--Input Device Generic Keyboard (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc104 (**) XKB: model: pc104 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) |--Input Device Configured Mouse (**) |--Input Device Generic Mouse (WW) The directory /usr/lib/X11/fonts/cyrillic does not exist. Entry deleted from font path. (WW) The directory /usr/lib/X11/fonts/75dpi/ does not exist. Entry deleted from font path. (WW) The directory /usr/lib/X11/fonts/CID does not exist. Entry deleted from font path. (WW) The directory /usr/lib/X11/fonts/75dpi does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in /var/lib/defoma/x-ttcidfont-conf.d/dirs/CID. Entry deleted from font path. (Run 'mkfontdir' on /var/lib/defoma/x-ttcidfont-conf.d/dirs/CID). (**) FontPath set to unix/:7100,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/100dpi,/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType (==) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 8 (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.3.0.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.0.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,3580 card 1028,015f rev 02 class 06,00,00 hdr 80 (II) PCI: 00:00:1: chip 8086,3584 card 1028,015f rev 02 class 08,80,00 hdr 00 (II) PCI: 00:00:3: chip 8086,3585 card 1028,015f rev 02 class 08,80,00 hdr 80 (II) PCI: 00:01:0: chip 8086,3581 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,24c2 card 1028,015f rev 01 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,24c4 card 1028,015f rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,24c7 card 1028,015f rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,24cd card 1028,015f rev 01 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev 81 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,24cc card , rev 01 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,24ca card 1028,015f rev 01 class 01,01,8a hdr 00 (II) PCI: 00:1f:5: chip 8086,24c5 card 1028,015f rev 01 class 04,01,00 hdr 00
Bug#216161: xserver-xfree86: font resolution not following the rules (?)
Package: xserver-xfree86 Version: 4.2.1-12.1 Severity: normal I recently restarted my X server and was greeted with ugly fonts. I found it is an interaction between the gsfonts-x11 package and the X server. I am copying the gsfonts-x11 maintainer, however my investigation seems to point to xfree86. The problem can be reproduced with xfd -fn '-adobe-times-bold-r-normal--17-120-100-100-p-86-iso8859-1' which shows glyphs with obvious scaling artifacts. The actual name of the font shown by xfd is -urw-nimbus roman no9 l-medium-r-normal-medium-17-120-100-100-p-89-iso8859-1 If I edit Type1/gsfonts-x11.alias and remove the adobe-times aliases, then run update-fonts-* Type1, the expected 100dpi bitmap font shows up instead. I have a standard dexconf font path (below). The gsfonts-x11 aliases are of the form -adobe-times-bold-r-normal--0-0-0-0-p-0-iso8859-1 -urw-nimbus roman no9 l-medium-r-normal-medium-0-0-0-0-p-0-iso8859-1 ie, they correctly do not contain point sizes. According to README.fonts, this means they should never be preferred to a bitmap font of the requested size. However, it seems to me that X is wrongly choosing them before the bitmap font. My previous (working) X session was up for some months, so I cannot be sure what package upgrade started the problem. Looking at my aptitude logs, I find several upgrades from xserver-* 4.1.14 through 4.2.1-11, one upgrade from gsfonts 6.0-2 to 6.0-2.1, and one upgrade from gsfonts-x11 0.16 to 0.17, all on a mostly-testing system. The changelogs of the gsfonts don't have anything suspicious. I'm guessing some upgrade of X introduced a bug in font resolution. I am currently behind a modem line and cannot easily try different package versions. I also may not be able to follow up promptly until next week. I hope this gives you something to go on. Andrew -- Package-specific info: 01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/MX-MV (rev 11) 01:00.0 Class 0300: 5333:8c10 (rev 11) # XF86Config-4 (XFree86 X server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module LoadGLcore Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadspeedo Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/gpmdata Option Protocol IntelliMouse Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section Device Identifier S3 Savage/MX Driver savage EndSection Section Monitor Identifier LCD HorizSync 25-1000 VertRefresh 25-1000 Option DPMS EndSection Section Screen Identifier Default Screen Device S3 Savage/MX Monitor LCD DefaultDepth16 SubSection Display Depth 16 Modes 1024x768 800x600 640x480 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse EndSection Section DRI Mode0666 EndSection This is a
Bug#197058: xserver-xfree86: [savage] XVideo broken - blue window
On Wed, Jul 23, 2003 at 08:15:58PM -0500, Branden Robinson wrote: On Wed, Jul 23, 2003 at 07:50:51PM -0400, Andrew Pimlott wrote: I just want to confirm that this bites me with 4.2.1-9, with a Savage/MX (in a Toshiba Tecra 8100). When I run xine with xv output, I get a blue window (xshm output works fine). However, I'm almost sure I didn't have the problem with 4.2.1-8. This contradicts the original report. I don't know what to make of that. Well, there exists snapshot.debian.net, which will let you attempt to find out for sure. Broken in -8, so the original bug report was correct. I see 4.3 should fix it. Andrew
Bug#197058: xserver-xfree86: [savage] XVideo broken - blue window
I just want to confirm that this bites me with 4.2.1-9, with a Savage/MX (in a Toshiba Tecra 8100). When I run xine with xv output, I get a blue window (xshm output works fine). However, I'm almost sure I didn't have the problem with 4.2.1-8. This contradicts the original report. I don't know what to make of that. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#197058: xserver-xfree86: [savage] XVideo broken - blue window
I just want to confirm that this bites me with 4.2.1-9, with a Savage/MX (in a Toshiba Tecra 8100). When I run xine with xv output, I get a blue window (xshm output works fine). However, I'm almost sure I didn't have the problem with 4.2.1-8. This contradicts the original report. I don't know what to make of that. Andrew
Bug#156056: [savage] hang in miFillGeneralPoly() on Savage/MX-MV rev 17
I filed this bug a long time ago. I just checked my saved copy of the test page, and while it still gives mozilla fits, it doesn't cause X to crash. I am now using xserver-xfree86 4.2.1-8, with the same hardware, driver, and configuration. I can close the bug if you don't see any other reason to keep it open. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#156056: [savage] hang in miFillGeneralPoly() on Savage/MX-MV rev 17
I filed this bug a long time ago. I just checked my saved copy of the test page, and while it still gives mozilla fits, it doesn't cause X to crash. I am now using xserver-xfree86 4.2.1-8, with the same hardware, driver, and configuration. I can close the bug if you don't see any other reason to keep it open. Andrew
