Bug#835466: xserver-xorg-core: Xorg incorrectly switches vt when exiting Xspice
This issue is still present in xserver-xorg-core 2:1.20.3-1. The workaround is to specify the virtual console the current X server runs on. So if it is running on vt7, use a command line of the form: /usr/lib/xorg/Xorg -config myxspice.conf -noreset vt7 :1.0 I guess the reason it works is because it causes Xorg to switch to what is already the current virtual console. -- Francois Gouget http://fgouget.free.fr/ A black hole is just God dividing by zero.
Bug#835466: xserver-xorg-core: Xorg incorrectly switches vt when exiting Xspice
Package: xserver-xorg-core Version: 2:1.18.4-1 Severity: normal Dear Maintainer, To reproduce this bug: * Log in and start a terminal application of your choice * Run: Xspice :3 * Hit Ctrl-C to kill Xspice The screen switches to the Linux console instead of continuing to show the X server display. This then combines with what is most likely independent bugs that often make it impossible to switch back to the X console (one of the Ctrl-Fn shows the X mouse pointer and typing commands in the open terminal works but the screen remains all black and is thus not usable). Reminder Xspice is a virtual X server, akin to Xvnc. So starting Xspice does not involve allocating VTs. Also /usr/bin/Xspice is a wrapper script around Xorg that directs it to use /etc/X11/spiceqxl.xorg.conf. (see attached file) I tried debugging this but I did not get anywhere. I think it's related to xf86OpenConsole()/xf86CloseConsole()/switch_to() in hw/xfree86/os-support/linux/lnx_init.c but that's probably quite obvious. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jun 23 2008 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Jul 20 05:00 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.4-1 (2016-07-18) Xorg X server log files on system: -- -rw-r--r-- 1 root root 6324 Aug 26 02:39 /var/log/Xorg.1.log -rw-r--r-- 1 root root 39495 Aug 26 02:48 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 16658.534] (--) Log file renamed from "/var/log/Xorg.pid-22439.log" to "/var/log/Xorg.0.log" [ 16658.534] X.Org X Server 1.18.4 Release Date: 2016-07-19 [ 16658.534] X Protocol Version 11, Revision 0 [ 16658.534] Build Operating System: Linux 4.6.0-1-amd64 x86_64 Debian [ 16658.534] Current Operating System: Linux amboise 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64 [ 16658.534] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.6.0-1-amd64 root=UUID=53f2c596-2a9a-41f7-87c1-ac0aa103f57b ro acpi_enforce_resources=lax [ 16658.534] Build Date: 26 August 2016 02:34:30AM [ 16658.534] xorg-server 2:1.18.4-1 (http://www.debian.org/support) [ 16658.534] Current version of pixman: 0.33.6 [ 16658.534]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 16658.534] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 16658.534] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Aug 26 02:48:26 2016 [ 16658.534] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 16658.534] (==) No Layout section. Using the first Screen section. [ 16658.534] (==) No screen section available. Using defaults. [ 16658.534] (**) |-->Screen "Default Screen Section" (0) [ 16658.534] (**) | |-->Monitor "" [ 16658.534] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 16658.534] (==) Automatically adding devices [ 16658.534] (==) Automatically enabling devices [ 16658.534] (==) Automatically adding GPU devices [ 16658.534] (==) Max clients allowed: 256, resource mask: 0x1f [ 16658.534] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 16658.534]Entry deleted from font path. [ 16658.534] (==) 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, built-ins [ 16658.534] (==) ModulePath set to "/usr/lib/xorg/modules" [ 16658.534] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 16658.534] (II) Loader magic: 0x5651197b6dc0 [ 16658.534] (II) Module ABI versions: [ 16658.534]X.Org ANSI C Emulation: 0.4 [ 16658.534]X.Org Video Driver: 20.0 [ 16658.534]X.Org XInput driver : 22.1 [ 16658.534]X.Org Server Extension : 9.0 [ 16658.535] (++) using VT number 7 [ 16658.535] (II) systemd-logind: logind integration requires -keeptty an
Bug#833255: xserver-xorg-input-synaptics: Tap-to-click should be on by default
Package: xserver-xorg-input-synaptics Version: 1.8.3-2 Severity: important Dear Maintainer, Now that in their infinite wisdom GNOME decided to drop support for the synaptics driver, there is no GUI to set tap-to-click to on. Furthermore: * GNOME's favored driver, xserver-xorg-input-libinput, has tap-to-click turned on by default. * But xserver-xorg-input-libinput breaks right-clicks making it unusable for now. * The web only has obsolete or incorrect information on how to manually turn on tap-to-click in synaptics so that there is no simple command line fix either. The only thing that makes sense is to turn on tap-to-click by default in the xserver-xorg-input-synaptics package. This can be done either in the driver code itself or by installing /usr/share/X11/xorg.conf.d/70-synaptics.conf to /etc/X11/xorg.conf.d instead and add TapButton lines to the "Default clickpad buttons" section. This would make that section look something like this: # This option enables the bottom right corner to be a right button on clickpads # and the right and middle top areas to be right / middle buttons on clickpads # with a top button area. # This option is only interpreted by clickpads. Section "InputClass" Identifier "Default clickpad buttons" MatchDriver "synaptics" Option "SoftButtonAreas" "50% 0 82% 0 0 0 0 0" Option "SecondarySoftButtonAreas" "58% 0 0 15% 42% 58% 0 15%" Option "TapButton1" "1" Option "TapButton2" "2" Option "TapButton3" "3" EndSection -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Oct 31 2012 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Jul 20 05:00 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 4 -rw-r--r-- 1 root root 1849 Aug 2 10:00 70-synaptics.conf KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 Kernel version (/proc/version): --- Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.4-1 (2016-07-18) No Xorg X server log files found. udev information: - P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: NAME="Power Button" E: PHYS="LNXPWRBN/button/input0" E: PRODUCT=19/0/1/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=9644105 P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event5 N: input/event5 E: BACKSPACE=guess E: DEVNAME=/dev/input/event5 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event5 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: LIBINPUT_DEVICE_GROUP=19/0/1/0:LNXPWRBN/button E: MAJOR=13 E: MINOR=69 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=9962437 E: XKBLAYOUT=fr E: XKBMODEL=pc105 E: XKBVARIANT=latin9 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXVIDEO_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXVIDEO:00 E: ID_PATH_TAG=acpi-LNXVIDEO_00 E: KEY=3e000b 0 0 0 E: MODALIAS=input:b0019vp0006e-e0,1,kE0,E1,E3,F1,F2,F3,F4,F5,ramlsfw E: NAME="Video Bus" E: PHYS="LNXVIDEO/video/input0" E: PRODUCT=19/0/6/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=10072367 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13/event12 N: input/event12 E: BACKSPACE=guess E: DEVNAME=/dev/input/event12 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13/event12 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXVIDEO:00 E: ID_PATH_TAG=acpi-LNXVIDEO_00 E: LIBINPUT_DEVICE_GROUP=19/0/6/0:LNXVIDEO/video E: MAJOR=13 E: MINOR=76 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=10107029 E: XKBLAYOUT=fr E: XKBMODEL=pc105 E: XKBVARIANT=latin9 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0C:00/input/input3 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0C:00/input/input3 E: EV=3 E: ID_FOR_SEAT=input-acpi-PNP0C0C_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0C:00 E: ID_PATH_TAG=acpi-PNP0C0C_00 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: NAME="Power Button" E: PHYS="PNP0C0C/button/input0" E: PRODUCT=19/0/1/0 E: PROP=0 E: SUBSYSTEM=input E: T
Bug#830312: xserver-xorg-input-libinput lacks right-click support on touchpad!
Until xserver-xorg-input-libinput gets fixed a workaround is to
reinstall the xserver-xorg-input-synaptics driver and then adjust the
Xorg configuration to get tap-to-click to work..
To get tap-to-click with synatics, copy
/usr/share/X11/xorg.conf.d/70-synaptics.conf to /etc/X11/xorg.conf.d and
add TapButton lines to the "Default clickpad buttons" section. That
section will look something like this:
# This option enables the bottom right corner to be a right button on clickpads
# and the right and middle top areas to be right / middle buttons on clickpads
# with a top button area.
# This option is only interpreted by clickpads.
Section "InputClass"
Identifier "Default clickpad buttons"
MatchDriver "synaptics"
Option "SoftButtonAreas" "50% 0 82% 0 0 0 0 0"
Option "SecondarySoftButtonAreas" "58% 0 0 15% 42% 58% 0 15%"
Option "TapButton1" "1"
Option "TapButton2" "2"
Option "TapButton3" "3"
EndSection
This should get you both tap-to-click and (regular) right-clicks.
--
Francois Gouget http://fgouget.free.fr/
You can have my guns when you pry them from my kids cold, dead hands.
Bug#823843: cinnamon-common: Touchpad setting "tap to click" stopped working
Package: xserver-xorg-input-synaptics Version: 1.8.3-2 Followup-For: Bug #823843 Dear Maintainer, Tap-to-click is no longer working in GNOME with xserver-xorg-input-synaptics. As was reported for Cinnamon there is no option to enable the feature in GNOME's configuration panel. In fact there is no configuration option at all except switching the left and right buttons. I was advised on debian-users [1] to switch to xserver-xorg-input-libinput but while this does restore tap-to-click, it breaks right-clicks! [2] So currently this is not a viable solution. Furthermore the 50-synaptics.conf workaround mentioned in a previous message does not work: * First xserver-xorg-input-synaptics 1.8.3-2 does not have the /usr/share/X11/xorg.conf.D/50-synaptics.conf file. * Second, getting that file from version 1.8.1 of that package and putting it in /etc/X11/xorg.conf.d has no effect. So currently the touchpad is broken and there is no fix. [1] https://lists.debian.org/debian-user/2016/06/msg00048.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830312 lrwxrwxrwx 1 root root 13 Oct 31 2012 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Apr 5 09:05 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 4 -rw-r--r-- 1 root root 1753 Jul 8 10:14 50-synaptics.conf KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 Kernel version (/proc/version): --- Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-4) ) #1 SMP Debian 4.6.2-2 (2016-06-25) No Xorg X server log files found. udev information: - P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: NAME="Power Button" E: PHYS="LNXPWRBN/button/input0" E: PRODUCT=19/0/1/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=10474204 P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event5 N: input/event5 E: BACKSPACE=guess E: DEVNAME=/dev/input/event5 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event5 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: LIBINPUT_DEVICE_GROUP=19/0/1/0:LNXPWRBN/button E: MAJOR=13 E: MINOR=69 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=10822107 E: XKBLAYOUT=fr E: XKBMODEL=pc105 E: XKBVARIANT=latin9 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXVIDEO_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXVIDEO:00 E: ID_PATH_TAG=acpi-LNXVIDEO_00 E: KEY=3e000b 0 0 0 E: MODALIAS=input:b0019vp0006e-e0,1,kE0,E1,E3,F1,F2,F3,F4,F5,ramlsfw E: NAME="Video Bus" E: PHYS="LNXVIDEO/video/input0" E: PRODUCT=19/0/6/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=10840054 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13/event12 N: input/event12 E: BACKSPACE=guess E: DEVNAME=/dev/input/event12 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13/event12 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXVIDEO:00 E: ID_PATH_TAG=acpi-LNXVIDEO_00 E: LIBINPUT_DEVICE_GROUP=19/0/6/0:LNXVIDEO/video E: MAJOR=13 E: MINOR=76 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=10894102 E: XKBLAYOUT=fr E: XKBMODEL=pc105 E: XKBVARIANT=latin9 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0C:00/input/input3 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0C:00/input/input3 E: EV=3 E: ID_FOR_SEAT=input-acpi-PNP0C0C_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0C:00 E: ID_PATH_TAG=acpi-PNP0C0C_00 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: NAME="Power Button" E: PHYS="PNP0C0C/button/input0" E: PRODUCT=19/0/1/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=10470703 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0C:00/input/input3/event2 N: input/event2 E: BACKSPACE=guess E: DEVNAME=/dev/input/event2 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0C:00/input/input3/event2 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0C:00 E: ID_PATH_TAG=acpi-PNP0C0C_00 E: LIBINPUT_DEVICE_GROUP=19/0/1/0:PNP0C0C/button E: MAJOR=13 E: MINOR=66 E: SUBSYSTEM=input E: TAGS=:power-switch: E:
Bug#830312: xserver-xorg-input-libinput lacks right-click support on touchpad!
Package: xserver-xorg-input-libinput Version: 0.19.0-1 Severity: important Dear Maintainer, I was told to remove xserver-xorg-input-synaptics as a way to regain tap-to-click support in GNOME [1] so xserver-xorg-input-libinput is now managing my touchpad. I did regain tap-to-click support but I lost right-click support! More precisely, pressing the right side of the touchpad until it makes an audible click has no effect. If a workaround exist it would be nice to document it here. However right-click is a basic functionality which should work by default. I did not find any information about the touchpad in either lsusb or lspci but Linux seems to identify it as an "ETPS/2 Elantech Touchpad". It's the touchpad of an Acer Aspire V5-171. [1] https://lists.debian.org/debian-user/2016/06/msg00048.html -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Oct 31 2012 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Apr 5 09:05 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 Kernel version (/proc/version): --- Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-4) ) #1 SMP Debian 4.6.2-2 (2016-06-25) No Xorg X server log files found. udev information: - P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: NAME="Power Button" E: PHYS="LNXPWRBN/button/input0" E: PRODUCT=19/0/1/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=8112323 P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event5 N: input/event5 E: BACKSPACE=guess E: DEVNAME=/dev/input/event5 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event5 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: LIBINPUT_DEVICE_GROUP=19/0/1/0:LNXPWRBN/button E: MAJOR=13 E: MINOR=69 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=8447410 E: XKBLAYOUT=fr E: XKBMODEL=pc105 E: XKBVARIANT=latin9 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXVIDEO_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXVIDEO:00 E: ID_PATH_TAG=acpi-LNXVIDEO_00 E: KEY=3e000b 0 0 0 E: MODALIAS=input:b0019vp0006e-e0,1,kE0,E1,E3,F1,F2,F3,F4,F5,ramlsfw E: NAME="Video Bus" E: PHYS="LNXVIDEO/video/input0" E: PRODUCT=19/0/6/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=8519184 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13/event12 N: input/event12 E: BACKSPACE=guess E: DEVNAME=/dev/input/event12 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input13/event12 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXVIDEO:00 E: ID_PATH_TAG=acpi-LNXVIDEO_00 E: LIBINPUT_DEVICE_GROUP=19/0/6/0:LNXVIDEO/video E: MAJOR=13 E: MINOR=76 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=8553670 E: XKBLAYOUT=fr E: XKBMODEL=pc105 E: XKBVARIANT=latin9 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0C:00/input/input3 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0C:00/input/input3 E: EV=3 E: ID_FOR_SEAT=input-acpi-PNP0C0C_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0C:00 E: ID_PATH_TAG=acpi-PNP0C0C_00 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: NAME="Power Button" E: PHYS="PNP0C0C/button/input0" E: PRODUCT=19/0/1/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=8109901 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0C:00/input/input3/event2 N: input/event2 E: BACKSPACE=guess E: DEVNAME=/dev/input/event2 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0C:00/input/input3/event2 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0C:00 E: ID_PATH_TAG=acpi-PNP0C0C_00 E: LIBINPUT_DEVICE_GROUP=19/0/1/0:PNP0C0C/button E: MAJOR=13 E: MINOR=66 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=8449090 E: XKBLAYOUT=fr E: XKBMODEL=pc105 E: XKBVARIANT=latin9 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0D:00/input/input4 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0D:00/input/input4 E: EV=21 E: ID_FOR_SEAT=input-acpi-PNP0C0D_00 E: ID_INPUT=1 E: ID_P
Bug#689082: libxcomposite-dev is not Multi-Arch compatible
Package: libxcomposite-dev Version: 1:0.4.4-1 Followup-For: Bug #689082 Dear Maintainer, This bug is sitll present. Any progress on this? Does the proposed patch need to be modified? -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libxcomposite-dev depends on: ii libx11-dev 2:1.6.3-1 ii libxcomposite1 1:0.4.4-1 ii libxext-dev 2:1.3.3-1 ii libxfixes-dev 1:5.0.1-2+b2 ii x11proto-composite-dev 1:0.4.2-2 ii x11proto-core-dev 7.0.27-1 libxcomposite-dev recommends no packages. libxcomposite-dev suggests no packages. -- no debconf information
Bug#782090: xserver-xspice: Xspice broken due to missing spiceqxl driver
Package: xserver-xspice Version: 0.0.17-2+b1 Severity: grave Justification: renders package unusable Dear Maintainer, Running Xspice fails with an error indicating that the spiceqxl driver is missing. To test this, do the following: $ sudo cp /usr/share/doc/xserver-xspice/spiceqxl.xorg.conf.example /etc/X11/spiceqxl.xorg.conf $ Xspice --disable-ticketing --port 5903 :3.0 In the Xorg.3.0.log file you will find: [452982.994] (II) LoadModule: "spiceqxl" [452982.994] (WW) Warning, couldn't open module spiceqxl [452982.994] (II) UnloadModule: "spiceqxl" [452982.994] (II) Unloading spiceqxl [452982.994] (EE) Failed to load module "spiceqxl" (module does not exist, 0) In Debian 7.0 the spiceqxl driver used to be shipped as part of the xserver-xorg-video-qxl package which was probably wrong as this driver seems to only be needed for Xspice. But in Debian Testing no package ships this file which is worse. Compiling the driver by hand and placing it in /usr/lib/xorg/modules/drivers/spiceqxl_drv.so fixes this and makes Xspice usable. It would also be nice if copying spiceqxl.xorg.conf.example into place manually was not necessary. After all no such step is needed to use vncserver. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xserver-xspice depends on: ii libpython2.7-stdlib [python-argparse] 2.7.9-2 ii python 2.7.9-1 ii xserver-xorg 1:7.7+7 ii xserver-xorg-video-qxl 0.1.1-2+b1 xserver-xspice recommends no packages. xserver-xspice 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 Archive: https://lists.debian.org/20150407164707.28653.12521.reportbug@amboise
Bug#689089: libglu1-mesa-dev is not Multi-Arch compatible
Package: libglu1-mesa-dev
Version: 9.0.0-2
Followup-For: Bug #689089
Dear Maintainer,
I have rechecked this multiarch issue and it is still present. I have also
rebuilt the package with multiarch support and see absolutely no issue with it.
It's really as simple as adding a single 'Multi-Arch: same' line.
Personally I would however reorder a couple more lines as I think it makes
sense to have the Architecture and Multi-Arch lines together, and have the
Pre-Depends line right before the Depends one. So here is a proposed patch:
diff -ur glu-9.0.0.orig/debian/control glu-9.0.0/debian/control
--- glu-9.0.0.orig/debian/control 2015-02-10 17:49:48.093474576 +0100
+++ glu-9.0.0/debian/control2015-02-10 17:44:22.555025019 +0100
@@ -15,14 +15,14 @@
Package: libglu1-mesa
Section: libs
Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
Depends:
${shlibs:Depends},
${misc:Depends},
Provides: libglu1
Conflicts: mesag3 (<< 5.0.0-1), xlibmesa3, libglu1
Replaces: libglu1
-Pre-Depends: ${misc:Pre-Depends}
-Multi-Arch: same
Description: Mesa OpenGL utility library (GLU)
GLU offers simple interfaces for building mipmaps; checking for the
presence of extensions in the OpenGL (or other libraries which follow
@@ -40,6 +40,7 @@
Package: libglu1-mesa-dev
Section: libdevel
Architecture: any
+Multi-Arch: same
Depends:
libglu1-mesa (= ${binary:Version}),
libgl1-mesa-dev | libgl-dev,
Is there anything preventing this from being fixed?
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libglu1-mesa-dev depends on:
ii libgl1-mesa-dev [libgl-dev] 10.3.2-1
ii libglu1-mesa 9.0.0-2
libglu1-mesa-dev recommends no packages.
libglu1-mesa-dev 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
Archive: https://lists.debian.org/20150210165723.24229.4185.reportbug@amboise
Bug#689068: libxi-dev is not Multi-Arch compatible
Package: libxi-dev Version: 2:1.7.4-1+b2 Followup-For: Bug #689068 Dear Maintainer, The reason why the packages were different between builds is that some of the documentation's anchor ids where automatically generated and thus different for each build. So the solution is simply to explicitly specify these ids which I have done in this (ad-hoc) patch: debian/patches/0001-Documentation-Ids.patch With that I don't see anything that would prevent marking this package as Multi-Arch: same so I have done so. See the attached debian packaging files. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libxi-dev depends on: ii libx11-dev 2:1.6.2-3 ii libxext-dev 2:1.3.3-1 ii libxfixes-dev 1:5.0.1-2+b2 ii libxi6 2:1.7.4-1+b2 ii x11proto-input-dev 2.3.1-1 ii xorg-sgml-doctools 1:1.11-1 libxi-dev recommends no packages. libxi-dev suggests no packages. -- no debconf information libxi_1.7.4-1.diff.gz Description: application/gzip
Bug#689082: libxcomposite-dev is not Multi-Arch compatible
Package: libxcomposite-dev
Version: 1:0.4.4-1
Followup-For: Bug #689082
Dear Maintainer,
I have teste the proposed patch above. It works.
Personally I would however reorder a couple more lines as I think it makes
sense to have the Architecture and Multi-Arch lines together, and have the
Pre-Depends line right before the Depends one.
diff -ur debian.old/control debian/control
--- debian.old/control 2015-02-07 14:50:11.741708901 +0100
+++ debian/control 2015-02-07 14:49:13.678006557 +0100
@@ -23,9 +23,9 @@
Package: libxcomposite1
Section: libs
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Pre-Depends: ${misc:Pre-Depends}
Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
Description: X11 Composite extension library
libXcomposite provides an X Window System client interface to the Composite
extension to the X protocol.
@@ -41,10 +41,10 @@
Package: libxcomposite1-dbg
Architecture: any
+Multi-Arch: same
Section: debug
Priority: extra
Depends: ${shlibs:Depends}, ${misc:Depends}, libxcomposite1 (=
${binary:Version})
-Multi-Arch: same
Description: X11 Composite extension library (debug package)
libXcomposite provides an X Window System client interface to the Composite
extension to the X protocol.
@@ -63,6 +63,7 @@
Package: libxcomposite-dev
Architecture: any
+Multi-Arch: same
Section: libdevel
Depends: ${shlibs:Depends}, ${misc:Depends}, libxcomposite1 (=
${binary:Version}), libx11-dev, libxfixes-dev, x11proto-composite-dev (>=
1:0.4), x11proto-core-dev, libxext-dev
Description: X11 Composite extension library (development headers)
But either way this really works. Could the patch be applied and the package
updated?
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libxcomposite-dev depends on:
ii libx11-dev 2:1.6.2-3
ii libxcomposite1 1:0.4.4-1
ii libxext-dev 2:1.3.3-1
ii libxfixes-dev 1:5.0.1-2+b2
ii x11proto-composite-dev 1:0.4.2-2
ii x11proto-core-dev 7.0.26-1
libxcomposite-dev recommends no packages.
libxcomposite-dev 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
Archive: https://lists.debian.org/20150207135334.5429.81483.reportbug@amboise
Bug#689082: libxcomposite-dev is not Multi-Arch compatible
Package: libxcomposite-dev Version: 1:0.4.3-2 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libXcomposite.so symbolic link is missing so that developping 32bit applications using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libxcomposite-dev depends on: ii libx11-dev 2:1.5.0-1 ii libxcomposite1 1:0.4.3-2 ii libxext-dev 2:1.3.1-2 ii libxfixes-dev 1:5.0-4 ii x11proto-composite-dev 1:0.4.2-2 ii x11proto-core-dev 7.0.23-1 libxcomposite-dev recommends no packages. libxcomposite-dev 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 Archive: http://lists.debian.org/20120929000127.1044.8060.reportbug@amboise.dolphin
Bug#689068: libxi-dev is not Multi-Arch compatible
Package: libxi-dev Version: 2:1.6.1-1 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libXi.so symbolic link is missing so that developping 32bit applications using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no hardware-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libxi-dev depends on: ii libx11-dev 2:1.5.0-1 ii libxext-dev 2:1.3.1-2 ii libxi6 2:1.6.1-1 ii x11proto-input-dev 2.2-1 ii xorg-sgml-doctools 1:1.10-1 libxi-dev recommends no packages. libxi-dev 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 Archive: http://lists.debian.org/20120928212753.17718.48901.reportbug@amboise.dolphin
Bug#559464: xserver-xorg-video-intel: X crashes when running Wine tests
As far as I can tell this is fixed with the following set of packages: libdrm-intel1 2.4.15-1 xserver-xorg-video-intel 2:2.9.1-2 linux-image-2.6-6862.6.32+23 linux-image-2.6.30-2-686 2.6.30-8 linux-image-2.6.32-trunk-686 2.6.32-5 So this bug can be closed. -- Francois Gouget http://fgouget.free.fr/ Linux: the choice of a GNU generation -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#481361: xserver-xorg-video-ati: No display on DVI output
On Mon, 15 Dec 2008, Francois Gouget wrote: [...] > >From there I could do a git-bisect which pointed me to this patch as the > culprit: > > 547543bbefe605a453bfa5ae6d063ae02c5f040e is first bad commit > commit 547543bbefe605a453bfa5ae6d063ae02c5f040e > Author: Alex Deucher > Date: Sat Sep 23 08:21:59 2006 +1000 > > radeon: re-organise FP and CRTC register setting routines > > :04 04 0ac88422caf387f6cfda4214713d62f342ffb2ff > 089cf7f3e18f90d4d5595a78f61c41564ec2f60b M src I have created a bug report in Xorg's Bugzilla: Bug 19100 - radeon 7500: No display on DVI output http://bugs.freedesktop.org/show_bug.cgi?id=19100 -- Francois Gouget http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95 -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#481361: xserver-xorg-video-ati: No display on DVI output
First, as I said in a previous email (which I can't find now), this problem is still present in xserver-xorg-video-ati 1:6.9.0-1+lenny4. Fortunately, after some searching, I found the Git repository for my driver. It would be nice if this information was available in the xserver-xorg-video-ati package (after all we're open-source so why not make it easy for the user to find the authoritative source of the code). >From there I could do a git-bisect which pointed me to this patch as the culprit: 547543bbefe605a453bfa5ae6d063ae02c5f040e is first bad commit commit 547543bbefe605a453bfa5ae6d063ae02c5f040e Author: Alex Deucher Date: Sat Sep 23 08:21:59 2006 +1000 radeon: re-organise FP and CRTC register setting routines :04 04 0ac88422caf387f6cfda4214713d62f342ffb2ff 089cf7f3e18f90d4d5595a78f61c41564ec2f60b M src Unfortunately it is somewhat long and cannot cleanly be reverted in the current tip. But hopefully it will point the way to the fix. -- Francois Gouget http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous ! -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#481361: xserver-xorg-video-ati: No display on DVI output
[...] > if none of that helps can you try the attached patches and let me know > which, if any, help? This bug is still present in xserver-xorg-video-ati 1:6.9.0-1+lenny4. Has any progress been made on this? Is there anything I can do to help? -- Francois Gouget http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares? -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#481361: xserver-xorg-video-ati: No display on DVI output
On Fri, 16 May 2008, Alex Deucher wrote: [...] > The following options may also > help: Option "DefaultTMDSPLL" "TRUE" Option "DisplayPriority" "HIGH" I had already had "DefaultTMDSPLL" set to "yes". I set it to "TRUE" just to make sure but it did not make a difference. I tried setting "DisplayPriority" to "HIGH" in addition to the above but again no difference. > If that doesn't help, try a modeline with a reduced refresh rate (50 > hz rather than 60): > Modeline "1920x1200_50.00_rb" 127.75 1920 1968 2000 2080 1200 1203 > 1209 1229 +HSync -Vsync I tried this one by modifying my Monitor section as follows: Section "Monitor" Identifier "IIyama" Option "PreferredMode" "1920x1200_50.00_rb" ModeLine"1920x1200_50.00_rb" 127.75 1920 1968 2000 2080 1200 1203 1209 1229 +HSync -Vsync EndSection Unfortunately there was no change. I did see that 1920x1200_50.00_rb was the preferred mode in the Xorg.0.log file, however I found no other indication of the actual selected refresh rate in that file. However I also tried "PreferredMode" "1024x768" and then it's clear that it's taken into account, and even if I'm still not sure of the refresh rate it's very unlikely to be so high that either the card or the monitor cannot handle this low resolution. > if none of that helps can you try the attached patches and let me know > which, if any, help? The patches test different combinations of RADEON_PLL_DCE3 and RADEON_PLL_USE_REF_DIV. RADEON_PLL_DCE3 is not known in the 6.8.0 codebase. So I tried the patches in the 6.8.1~git20080512.94bf8f01 codebase. * pllboth.diff corresponds to the existing code of the 6.8.1 codebase. Unfortunately that version of the driver does not work either. * Then I reverted pllboth.diff and applied plldce3.diff and installed the resulting driver. Unfortunately there was no change either. * Finally I reverted plldce3.diff and applied pllrefdiv.diff but again there was no change. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481361: xserver-xorg-video-ati: No display on DVI output
On Fri, 16 May 2008, Alex Deucher wrote: [...] > 1920x1200 is probably a bit much for your card bandwidth-wise. Sure, this graphics card is pretty old and not very powerful. However: * I used it to drive the VGA output in 1920x1440x75Hz for 7 years with my 21" CRT. * About 6 months ago I switched to an LCD screen and used it to drive the DVI output at 1920x1200x60Hz without trouble. * It's only last wednesday when I upgraded that the DVI output stopped working at all. * I have since downgraded the driver to and I'm using the DVI output in 1920x1200x60Hz (as confirmed by both xrandr 1.1 and my LCD screen). So it's not a hardware problem. > Do lower resolutions work ok? (1680x1050 or 1024x768) You might try > reducing your color depth to 16 bits. I thought about an issue with the single-link DVI bandwidth limit too. So I tried 1600x1200x60Hz and 1024x768x60Hz and neither worked. I did not try 16 bits mode. > The following options may also > help: Option "DefaultTMDSPLL" "TRUE" Option "DisplayPriority" "HIGH" > > If that doesn't help, try a modeline with a reduced refresh rate (50 > hz rather than 60): > Modeline "1920x1200_50.00_rb" 127.75 1920 1968 2000 2080 1200 1203 > 1209 1229 +HSync -Vsync I will try this tonight. Do these correspond to driver settings that changed between 6.6.3 and 6.8.0? -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481361: xserver-xorg-video-ati: No display on DVI output
Package: xserver-xorg-video-ati Version: 1:6.8.0-1 Severity: important Since the upgrade to 1:6.8.0-1 I cannot get the X server to work through may ATI 7500 DVI output. More details: * My ATI 7500 has three outputs: - DVI - S-Video - VGA * My LCD monitor (an iiyama B2403WS) has two inputs: - HDMI + a DVI to HDMI cable - VGA * If I hook up the VGA output to the monitor, then the display goes through the VGA output. However this results in a very ugly display on my LCD monitor (dur to the digital->analog->digital roundtrip and the high resolution) and is thus absolutely unusable. * If I only hook up the DVI output, then the monitor displays an all-blue screen for a bit and then enters power-save mode. This is exactly the same thing that is happening if the monitor's DVI input is not connected to anything. So this means the graphics card is not putting out a signal (or nothing that's recognisable). * Even when connected using the VGA cable, the monitor would sometimes go black and repeatedly display a 'No signal' message. Moving the mouse or using the keyboard did not get it out of that state. That last issue might have been fixed by setting DPMS to off in xorg.conf. It might be related to the DVI issue, but then maybe not. * This issue seems a bit similar to bug 481084 except in my case it happens after a cold boot and with a single display. (so it's not a docking / suspend / multi-display issue) I tried upgrading xserver-xorg-video-ati to 1:6.8.1~git20080512.94bf8f01-1 but this did not help. The only fix I found so far is to revert back to 1:6.6.3-2 (from the stable branch). More specifically now I use the following packages: --- ii xserver-xorg1:7.1.0-19 the X.Org X server ii xserver-xorg-core 2:1.1.1-21etch4 X.Org X server -- core server ii xserver-xorg-input-all 1:7.3+10 the X.Org X server -- input driver metapacka ii xserver-xorg-input-evdev1:1.1.2-6 X.Org X server -- evdev input driver ii xserver-xorg-input-kbd 1:1.1.0-4 X.Org X server -- keyboard input driver ii xserver-xorg-input-mouse1:1.1.1-3 X.Org X server -- mouse input driver ii xserver-xorg-input-synaptics0.14.6-1 Synaptics TouchPad driver for X.Org/XFree86 ii xserver-xorg-input-wacom0.7.4.1-5 X.Org X server -- wacom input driver ii xserver-xorg-video-ati 1:6.6.3-2 X.Org X server -- ATI display driver --- -- 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 2007-07-16 14:04 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1674940 2008-04-29 20:37 /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: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] /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 3772 2008-05-15 01:47 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # 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" FontPath"unix/:7100"# local font server # if the local font server has problems, we can fall back on these FontPath"/usr/share/fonts/X11/100dpi/:unscaled" FontPath"/usr/share/fonts/X11/75dpi/:unscaled" FontPath"/usr/local/share/fonts/ttfonts" FontPath"/usr/local/share/fonts/misc" FontPath"/usr/local/share/fonts/xpfonts" FontPath"/usr/share/fonts/truetype/freefont" FontPath"/usr/share/fonts/truetype/thryomanes" FontPath"/usr/share/fonts/X11/Type1" FontPath"/usr/share/fonts/X11/misc" FontPath"/usr/share/fonts/X11/100dpi" FontPath"/usr/share/fonts/X11/75dpi" EndSection Section "Module" Load"bitmap" L
Bug#203942: closed by Brice Goglin <[EMAIL PROTECTED]> (ping timeout, closing)
Brice Goglin wrote: > Closing this bug since I didn't get any reply from the submitter after > my ping a month ago. If anybody ever reproduces this problem, feel > free to reopen. What the heck is this then? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203942;msg=24 -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407036: xserver-xorg: Server crashes after hibernate
On Tue, 20 Feb 2007, Brice Goglin wrote: [...] > > Backtrace: > > 0: /usr/bin/X(xf86SigHandler+0x84) [0x80c4354] > > 1: [0xb7ef6420] > > 2: /usr/bin/X(Dispatch+0x81) [0x8086b91] > > 3: /usr/bin/X(main+0x489) [0x806e699] > > 4: /lib/tls/libc.so.6(__libc_start_main+0xc8) [0xb7d00ea8] > > 5: /usr/bin/X(FontFileCompleteXLFD+0xa9) [0x806d9d1] > > This backtrace looks similar to #410696 and #410386. But, these bugs > have nothing to do with suspending. Did you guys ever get such a crash > without suspending? No. More precisely: * If I suspend to disk, then I have a high probability of getting a crash on restore. I'd say at least 3 out of 4 (initially it seemed pretty much systematic). * If I suspend to memory, then there is no crash. * I never got any problem in normal use. * I don't know if it is alternating suspend to memory and suspend to disk that causes the problem. I could check that. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407036: xserver-xorg: Server crashes after hibernate
Package: xserver-xorg-core Version: 2:1.1.1-17 Followup-For: Bug #407036 I'm getting this bug too: after I restore from hibernation I get sent back to the KDM login prompt. Note that my configuration is different from the original reporter: I have a Noemagic graphics card rather than an ATI one. Also, I use the hibernate script with swsusp rather than suspend2. Of interest too, in Xorg.0.log.old I got a backtrace of the crash: Could not init font path element unix/:7100, removing from list! (II) Open ACPI successful (/var/run/acpid.socket) (II) NEOMAGIC(0): Stretching disabled (II) Configured Mouse: ps2EnableDataReporting: succeeded (II) Open ACPI successful (/var/run/acpid.socket) (II) NEOMAGIC(0): Stretching disabled (II) Configured Mouse: ps2EnableDataReporting: succeeded (II) Open ACPI successful (/var/run/acpid.socket) (II) NEOMAGIC(0): Stretching disabled (II) Configured Mouse: ps2EnableDataReporting: succeeded Backtrace: 0: /usr/bin/X(xf86SigHandler+0x84) [0x80c4354] 1: [0xb7ef6420] 2: /usr/bin/X(Dispatch+0x81) [0x8086b91] 3: /usr/bin/X(main+0x489) [0x806e699] 4: /lib/tls/libc.so.6(__libc_start_main+0xc8) [0xb7d00ea8] 5: /usr/bin/X(FontFileCompleteXLFD+0xa9) [0x806d9d1] Fatal server error: Caught signal 11. Server aborting -- Package-specific info: Contents of /var/lib/x11/X.roster: xserver-xorg /etc/X11/X target does not match checksum in /var/lib/x11/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 13 Jul 7 2006 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1597964 Feb 7 20:54 /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: Neomagic Corporation NM2380 [MagicMedia 256XL+] (rev 10) /etc/X11/xorg.conf unchanged from checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r- 1 root root 4054 Aug 18 2006 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: Xorg X server log files on system: -rw-r--r-- 1 root root 36321 Feb 17 12:26 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: UNKNOWN Current Operating System: Linux oleron 2.6.19acpi #2 PREEMPT Fri Dec 1 18:41:08 CET 2006 i686 Build Date: 07 February 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present 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: Sat Feb 17 12:25:50 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Sony F560" (**) | |-->Device "NeoMagic NM2380" (**) |-->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" (WW) The directory "/usr/local/share/win98fonts" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/share/truetype" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/X11/ttf-bitstream-vera" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/X11/ttf-dejavu" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/X11/freefont" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/X11/unfonts" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/X11/uralic" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/X11/util". Entry deleted from font path. (Run 'mkfontdir' on "/usr/share/fonts/X11/util"). (**) FontPath set to: unix/:7100, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi (==) RgbPath set to "/etc/X11/rgb" (==) ModulePath set to "/usr/lib/xorg/modules" (II) Open ACPI successful (/var/run/acpid.socket) (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.0 X.Org XInput driver : 0.6 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/lib/xorg/modules/fonts/libbitmap.so (II) Module bitmap: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0
Bug#203942: xfree86-common: [Xsession] want more flexible ssh-agent invocation
On Sat, 27 Jan 2007, Brice Goglin wrote: > Hi, > > About 4 years ago, you reported a bug to the Debian BTS regarding > ssh-agent not being invocated flexibly enough by Xsession. > Did you reproduce this problem recently? If not, I will close this bug > in the next weeks. As far as I know nothing has changed since then. The 90x11-common_ssh-agent tweaks $STARTUP so that ssh-agent is not started until it is exec-ed in 99x11-common_start. So no script between 90 and 99 benefits from the ssh-agent context. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#218169: "CGA snow" effect on Radeon 7500 at 24bpp
I have the problem described in this bug report and unfortunately the problem is still present now that I have upgraded to xserver-xfree86 4.3.0-7. >From my comment to the bug report on XFree86's site: (http://bugs.xfree86.org/show_bug.cgi?id=175) In 4.3.0 the problem has actually worsened. The SWcursor trick I described in my previous patch does not work anymore. Also, there's even more artifacts. I have actually taken a screenshot (in the literal sense since a screen capture would not show anything), and you can check it out there: http://fgouget.free.fr/tmp/img_2660.jpg For the screenshot I started a recursive ls to cause constant screen updates while I was taking the picture. Things are even worse than in the picture because the bands like the one that obscures the Slashdot entry below 'NY Holds Spam Scam Contest' keep moving around so that at any one time you see three or four of them. All in all this makes 4.3.0 unusable as is. I have performed some extra tests: * my screen is in 1920x1440 in 24bpp. The problem persists even if I lower the resolution all the way down to 1280x1024. * however as soon as I switch to 16bpp the problem goes away. * I tried the XaaNoScreenToScreenCopy and this time I still had the snow effect (in addition to the display becoming unusably slow) -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"
Bug#203963: acknowledged by developer (Re: Bug#203963: Add support for ~/.Xclients)
On Mon, 4 Aug 2003, Debian Bug Tracking System wrote: [...] > On Mon, Aug 04, 2003 at 09:49:25AM +1000, Daniel Stone wrote: > > No, this is incorrect. $REALSTARTUP, which may be ~/.[Xx]session, if it > > exists, is only executed at the *end* of the Xsession.d chain, after > > all the system Xsession scripts have been run. I apologize for the delay in my reply, I don't like restarting my X server. ~/.xsession is started at the end of the Xsession.d, that's correct. However, in that case it's up to the ~/.xsession script to select a window manager to run, i.e. the user has to duplicate the functionality of 50xfree86-common_determine-startup. Note that: * ~/.xsession does not inherit variables such as REALSTARTUP * ~/.xsession cannot just call 50xfree86-common_determine-startup because all it would get is REALSTARTUP="... ~/.xsession"... again. > I am closing this bug due to the above analysis. So I don't think the bug should be closed: * forcing each user to duplicate 50xfree86-common_determine-startup functionality just so he can customize his mouse acceleration or have an xterm on startup does not seem like a good solution. * there's an interoperability issue with RedHat systems (e.g. HOME shared via NFS). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#203963: acknowledged by developer (Re: Bug#203963: Add support for ~/.Xclients)
On Mon, 4 Aug 2003, Debian Bug Tracking System wrote: [...] > On Mon, Aug 04, 2003 at 09:49:25AM +1000, Daniel Stone wrote: > > No, this is incorrect. $REALSTARTUP, which may be ~/.[Xx]session, if it > > exists, is only executed at the *end* of the Xsession.d chain, after > > all the system Xsession scripts have been run. I apologize for the delay in my reply, I don't like restarting my X server. ~/.xsession is started at the end of the Xsession.d, that's correct. However, in that case it's up to the ~/.xsession script to select a window manager to run, i.e. the user has to duplicate the functionality of 50xfree86-common_determine-startup. Note that: * ~/.xsession does not inherit variables such as REALSTARTUP * ~/.xsession cannot just call 50xfree86-common_determine-startup because all it would get is REALSTARTUP="... ~/.xsession"... again. > I am closing this bug due to the above analysis. So I don't think the bug should be closed: * forcing each user to duplicate 50xfree86-common_determine-startup functionality just so he can customize his mouse acceleration or have an xterm on startup does not seem like a good solution. * there's an interoperability issue with RedHat systems (e.g. HOME shared via NFS). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
Bug#203963: Add support for ~/.Xclients
Package: xfree86-common Version: 4.2.1-6 On RedHat a non-root user can create a ~/.Xclients script file and its contents is executed when the user logs in via xdm. This is quite practical for starting a couple of applications when logging into X. For instance I use it to start an xterm, xmms and gkrellm. I also use this functionality to run xset and modify some of the X server settings. However Debian does not suppor any equivalent scheme. I believe the standard response is that the user should write his own .xsession file which means each user would have to duplicate the functionality of all the scripts in '/etc/X11/Xsession.d' which would be pretty ugly. So I propose to add the following script to '/etc/X11/Xsession.d'. Ideally one would also apply the change I proposed in bug 203942 and call the new script 98xfree86-common_xclients. This way the xterm I start in my .Xclients file would inherit the ssh-agent environment variables. So here is the script. I wrote it so that support for ~/.Xclients can be enabled/disabled using /etc/X11/Xsession.options like for the other features. --- cut here --- if grep -qs ^allow-user-xclients "$OPTIONFILE"; then if [ -e "$HOME/.Xclients" ]; then if [ -x "$HOME/.Xclients" ]; then "$HOME/.Xclients" else sh "$HOME/.Xclients" fi fi fi --- cut here --- -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
Bug#203963: Add support for ~/.Xclients
Package: xfree86-common Version: 4.2.1-6 On RedHat a non-root user can create a ~/.Xclients script file and its contents is executed when the user logs in via xdm. This is quite practical for starting a couple of applications when logging into X. For instance I use it to start an xterm, xmms and gkrellm. I also use this functionality to run xset and modify some of the X server settings. However Debian does not suppor any equivalent scheme. I believe the standard response is that the user should write his own .xsession file which means each user would have to duplicate the functionality of all the scripts in '/etc/X11/Xsession.d' which would be pretty ugly. So I propose to add the following script to '/etc/X11/Xsession.d'. Ideally one would also apply the change I proposed in bug 203942 and call the new script 98xfree86-common_xclients. This way the xterm I start in my .Xclients file would inherit the ssh-agent environment variables. So here is the script. I wrote it so that support for ~/.Xclients can be enabled/disabled using /etc/X11/Xsession.options like for the other features. --- cut here --- if grep -qs ^allow-user-xclients "$OPTIONFILE"; then if [ -e "$HOME/.Xclients" ]; then if [ -x "$HOME/.Xclients" ]; then "$HOME/.Xclients" else sh "$HOME/.Xclients" fi fi fi --- cut here --- -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#203942: More flexible ssh-agent invocation
Package: xfree86-common Version: 4.2.1-6 The way ssh-agent is started in 90xfree86-common_ssh-agent is not very flexible. In particular it makes it impossible to start extra processes like an xterm or two that would inherit the SSH_XXX environment variables. So what I propose is the following: * Replace 90xfree86-common_ssh-agent with the following --- cut here --- SSHAGENT=/usr/bin/ssh-agent SSHAGENTARGS= if grep -qs ^use-ssh-agent "$OPTIONFILE"; then if [ -x "$SSHAGENT" -a -z "$SSH_AUTH_SOCK" -a -z "$SSH2_AUTH_SOCK" ]; then if [ -f /usr/bin/ssh-add1 ] && cmp -s "$SSHAGENT" /usr/bin/ssh-agent2; then # use ssh-agent2's ssh-agent1 compatibility mode SSHAGENTARGS=-1 fi fi fi eval `"$SSHAGENT" -s $SSHAGENTARGS` >/dev/null --- cut here --- 'ssh-agent -s' outputs a mini-script that sets the SSH_XXX variables. Our eval runs this code which sets the environment variables in the current shell. * Add a 99xfree86-common_start script to actually invoke REALSTARTUP --- cut here --- exec $REALSTARTUP --- cut here --- * Then, between 90 and 99 administrators are free to add whatever scripts they want to run in the ssh-agent environment. Next I'll send an example taking advantage of this. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
Bug#203942: More flexible ssh-agent invocation
Package: xfree86-common Version: 4.2.1-6 The way ssh-agent is started in 90xfree86-common_ssh-agent is not very flexible. In particular it makes it impossible to start extra processes like an xterm or two that would inherit the SSH_XXX environment variables. So what I propose is the following: * Replace 90xfree86-common_ssh-agent with the following --- cut here --- SSHAGENT=/usr/bin/ssh-agent SSHAGENTARGS= if grep -qs ^use-ssh-agent "$OPTIONFILE"; then if [ -x "$SSHAGENT" -a -z "$SSH_AUTH_SOCK" -a -z "$SSH2_AUTH_SOCK" ]; then if [ -f /usr/bin/ssh-add1 ] && cmp -s "$SSHAGENT" /usr/bin/ssh-agent2; then # use ssh-agent2's ssh-agent1 compatibility mode SSHAGENTARGS=-1 fi fi fi eval `"$SSHAGENT" -s $SSHAGENTARGS` >/dev/null --- cut here --- 'ssh-agent -s' outputs a mini-script that sets the SSH_XXX variables. Our eval runs this code which sets the environment variables in the current shell. * Add a 99xfree86-common_start script to actually invoke REALSTARTUP --- cut here --- exec $REALSTARTUP --- cut here --- * Then, between 90 and 99 administrators are free to add whatever scripts they want to run in the ssh-agent environment. Next I'll send an example taking advantage of this. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
