Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

On 2019-08-29 11:29+0200 Moritz Mühlenhoff wrote:


I'm seeing the same [instabilities] with RX 570 (which according to Wikipedia 
should
be the same architecture as your RX 550) and the stable Buster release,
both with the standard 4.19 kernel and the 5.2 kernel from buster-backports.


The short story is after a BIOS upgrade my box has been stable for 27 days and 
counting.

For the longer story read on

I am now of the opinion that this whole mess is due to
incompatibilities between real AMD Motherboard and graphics chip sets
*as sold with initial BIOS* to unsuspecting Linux users in the last
couple of years and the AMD documentation of those chip sets (which
Linux kernel developers must rely on).  So the net result of these
initially buggy BIOS's is general Linux-AMD instability.  (Do a google
search for the terms (without quotes) "amd linux instability" and you
will find many sorry tales.)

Up to a month ago, I had solved virtually all the night-time almost
completely idle lockups by using the kernel parameters idle=nomwait
rcu_nocbs=0-15 (where the 15 corresponds to one less than the 16
hardware threads I have on my Ryzen 7 1700 system).  But the rcu_nocbs
parameter requires a special kernel build with a different
configuration (CONFIG_RCU_NOCB_CPU=y) than what Debian supplies.  With
that custom kernel (4.18.10-custom) the idle lockups dropped to just
one for a large number of months, but the active (as opposed to idle)
instability issues still caused lockups with up times between them
that ranged from 0.5 days to 24 days with an average up time of a week
or so.

Soon after I reported this box instability to kernel developers I got
the advice from them to try a BIOS update.  But I put that off for
more than a year because such upgrades are considered to be a last
resort.  The reason for that is they can turn your motherboard into a
brick with low but still non zero probability due to a number of
different causes (such as AMD/Motherboard vendor screw ups with the
BIOS upgrade, internet download errors with the BIOS, power outages
during the BIOS upgrade, etc.)  Also, there was huge churn in the BIOS
upgrades with ASUS (my motherboard vendor) putting out 10 (!) of them
since the BIOS I received when I bought the box.  So I decided to wait
until that churn had settled down, i.e., ASUS had gotten
asymptotically closer to the definitive BIOS for my box.  And
meanwhile the above average up time of ~1 week was livable.

The upshot was that 27 days ago I finally arranged for some
professionals to do the BIOS upgrade.  That made the AMD CBS Power
Supply Idle Control option available for the first time, and I set
that control from "auto" to "Typical Current Idle" (which apparently is an
alternative to setting the custom kernel parameter rcu_nocbs=0-15 for
dealing with idle instability issues).  The net result of this update
is the current up time (still with the same 4.18.10-custom kernel and
kernel parameters) is 27 days and counting which is a new record.  So
I am beginning to hope that this BIOS upgrade has solved the active
lockup issues not covered by rcu_nocbs=0-15, and might even (with
Power Supply Idle Control set to "Typical Current Idle") solve the
idle lockup issues if I drop rcu_nocbs=0-15.

Therefore, if the current up time experiment with kernel 4.18.10 custom is
able to continue for another month or so, my plan is to try a similar
experiment with stock Debian kernel (i.e. without the custom kernel
parameter rcu_nocbs=0-15), and if I get, say ~60 days up time with that
kernel, I will likely conclude this problem has been completely solved,
and I will close this bug report.

Meanwhile, I hope if you decide as a last resort to try updating your
own BIOS (after careful consideration of the known risks), that will
completely solve this issue for you.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

I avoided trying early kernel-4.17.x versions, but yesterday I updated
from kernel-4.16.x to kernel 4.17.17-1, but frankly that change has
not helped this lockup problem at all.  For example, after trying
direct use (with a KDE desktop if that makes any difference) for the
first time with that kernel, the kernel only lasted a half an hour
before I got a lockup which could only be solved by hitting the reset
button!  And roughly 8 hours later after that reset I got another
lockup which also required a reset to regain control.

So it appears the substantial number of AMD graphics fixes in
kernel-4.17.x are not sufficient to stabilize use of this AMD RX 550
graphics card that should no longer be considered cutting-edge hardware
(i.e. it was first offered for sale at least 16 months ago).

Because of these on-going issues with direct use of this card, I am
going back to using the X-terminal method with this kernel which
experience with kernel-4.16.x shows is much more stable since it
avoids using this graphics card completely (except for the direct
display of the Linux console login prompt).

I will try again to use this card directly when kernel-4.18.x is
promoted to Buster.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

On 2018-06-02 10:07-0700 Alan W. Irwin wrote:


The propagation of kernel 4.16.12 from Sid to Buster has greatly
improved this situation, i.e., no lock ups so far (uptime approaching
3 days since I switched to 4.16.12 from 4.16.5) and may have
completely solved it. [...]


Well, further experience showed lockups occurred roughly as often for
4.16.12 as for 4.16.5.  So currently I am only able to use this
computer in a reliable way using an X-terminal (an alternate computer
with a different X server that runs "X -query "
to control and display remote desktop results that are running on this
computer).

Therefore I plan to wait for kernel 4.17.x (which apparently has many
graphics fixes for modern AMD cards such as the RX 550) to propagate
to Buster before I try this computer again with a local X server,
i.e., direct use rather than X-terminal use.

Alan
______
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

The propagation of kernel 4.16.12 from Sid to Buster has greatly
improved this situation, i.e., no lock ups so far (uptime approaching
3 days since I switched to 4.16.12 from 4.16.5) and may have
completely solved it.  For further details see
<https://bugs.freedesktop.org/show_bug.cgi?id=106671>.

I would like to see what sort of maximum uptime I can now achieve with
this card without lock ups and report that here for the benefit of
other Debian users of AMD RX 550 graphics cards so please leave this
bug open for at least several more months.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

So far my experiment to bypass the RX 550 by displaying on another
computer has been a success, i.e., no lock up issues have been
encountered under this mode of operation.  So it is a rather short
(roughly one day) test so far but still consistent with the hypothesis
that the lock ups are likely caused by an issue with
xserver-xorg-video-amdgpu itself or the kernel functions that are used
by that device driver.

Also, assuming I have now found a stable mode of operation for this
new computer that is not subject to lock ups, I would like to test the
RX 550 for latest kernel and X to see if the lock ups (for direct
display) go away.  Can you advise on the best way to build the latest
kernel and X so those choices are easy to use with Debian Buster
without compromising the Debian Buster versions of kernel and X?  (I
am experienced at software builds, but it has been many years since I
built the Linux kernel, and I have no experience building X, yet.)

I have also reported this bug upstream at
<https://bugs.freedesktop.org/show_bug.cgi?id=106671> in case the X
developers have helpful advice about working around the problem or
want me to perform some specific tests.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Bug#900087: xserver-xorg-video-amdgpu: AMD RX 550 often locks up

[Alan W. Irwin]

Package: xserver-xorg-video-amdgpu
Version: 18.0.1-1
Severity: important

Dear Maintainer,

The lock ups for the AMD RX 550 graphics card I have been experiencing
occur on time scales of a few hours after a boot to up to a maximum of
two days after a reboot.  The frequency of those backups is the reason
I rated the severity of this issue as "important", but, of course,
feel free to classify the severity any other way you like.

Those lock ups have now become so frequent (3 of them yesterday) that
I am now testing my new computer by using it normally but remotely
using the display of another computer.  In this mode the only use of
the RX 550 is to display the login prompt to a Linux console.  And
that non-X use is so light, I am hoping the system stays up a long
time without lock ups to confirm what I have found so far that the
actual lock ups only occur when X is running directly on this
computer.

These lock ups when X is running on this computer all freeze the
X display but come in several different varieties:

* I can login from another computer via ssh and execute "shutdown -r now".
However, the display remains black on the subsequent POST phase unless
I hit the reset button.

* I cannot login from another computer with ssh, but networking is up
with this computer (i.e., ping works), and I had to hit the reset button.

* Not even ping works, and I had to hit the reset button.

On one occasion (I have forgotten which of the 3 varieties of lock ups
this was) when I hit the reset button the card still gave a black
screen during the POST phase so I was concerned it had been turned
into a brick.  However, as a last-ditch effort to get this display
working again, I tried depressing the power button for 3 seconds so
the computer powered off.  Then several minutes later I powered on,
and the card properly displayed the POST phase again after that.

Between lock-up events, the card does display with extremely high
quality, e.g., The Weather Network videos of the recent Hawaii
eruption.  Also, the non-graphical component of this new box seems to
be reliable.  For example, I recently copied 0.5TB of files from my
old computer to this new computer using rsync, and then checked every
one of those 4 trillion bits that had been transferred by a subsequent
invocation of rsync --checksum.  I am pretty sure this rsync
--checksum test means the Ryzen 7 1700 CPU's, its 64GB of memory, the
(external) source drive, and the (internal) destination drive are all
reliable.

I also ran "dpkg --verify" and "dpkg --audit" on xserver-xorg-video-amdgpu
and firmware-amd-graphics (this firmware package is required for
the RX 550) to verify those packages had not somehow become corrupted.

I also noticed the following polaris-related (the RX 550 uses the POLARIS12
chipset) messages that are retrieved by dmesg

WATCHOUT! root@merlin> dmesg |grep -B3 -A3 -i polaris
[   31.637861] ata10: DUMMY
[   31.637863] ata11: SATA max UDMA/133 abar m4096@0xfe708000 port 0xfe708200 
irq 69
[   31.637865] ata12: SATA max UDMA/133 abar m4096@0xfe708000 port 0xfe708280 
irq 70
[   31.639015] [drm] initializing kernel modesetting (POLARIS12 0x1002:0x699F 
0x1043:0x0513 0xC7).
[   31.639026] [drm] register mmio base: 0xFE80
[   31.639026] [drm] register mmio size: 262144
[   31.639036] [drm] probing gen 2 caps for device 1022:1453 = 737903/e
--
[   31.639302] amdgpu :0a:00.0: Invalid PCI ROM header signature: expecting 
0xaa55, got 0x
[   31.639322] ATOM BIOS: 115-C994PI0-102
[   31.639616] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment 
size is 9-bit
[   31.639825] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_mc.bin
[   31.639834] amdgpu :0a:00.0: VRAM: 4096M 0x00F4 - 
0x00F4 (4096M used)
[   31.639836] amdgpu :0a:00.0: GTT: 256M 0x - 
0x0FFF
[   31.639840] [drm] Detected VRAM RAM=4096M, BAR=256M
--
[   31.640488] [drm]   DDC: 0x4878 0x4878 0x4879 0x4879 0x487a 0x487a 0x487b 
0x487b
[   31.640488] [drm]   Encoders:
[   31.640489] [drm] DFP3: INTERNAL_UNIPHY
[   31.640511] amdgpu :0a:00.0: firmware: failed to load 
amdgpu/polaris12_pfp_2.bin (-2)
[   31.640518] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   31.640523] amdgpu :0a:00.0: Direct firmware load for 
amdgpu/polaris12_pfp_2.bin failed with error -2
[   31.640660] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_pfp.bin
[   31.640674] amdgpu :0a:00.0: firmware: failed to load 
amdgpu/polaris12_me_2.bin (-2)
[   31.640679] amdgpu :0a:00.0: Direct firmware load for 
amdgpu/polaris12_me_2.bin failed with error -2
[   31.640793] amdgpu :0a:00.0: firmware: direct-loading firmware 
amdgpu/polaris12_me.bin
[   31.640808] amdgpu :0a:00.0: firmware: failed to load 
amdgpu/polaris12_ce_2.bin (-2)
[   31.640813] amdgpu :0a:00.0: Direct firmware load for 
amdgpu/polaris12_ce_2.bin failed w

Bug#899086: xserver-xorg-video-amdgpu: completely fails to detect AMD RX 550 (which uses the Polaris 12 chipset) unless firmware-amd-graphics package installed

[Alan W. Irwin]

Package: xserver-xorg-video-amdgpu
Version: 18.0.1-1
Severity: normal

Dear Maintainer,

I recently performed a successful text install of Debian Buster using
a snapshot from
.
That install was minimal, i.e., there were no extra packages installed
beyond those absolutely required by the text installer.  I then
followed up by using that minimal Debian system to install
xserver-xorg-video-amdgpu (generally recommended for new chipsets like
the Polaris 12) and other X-related packages.  But I specifically
excluded firmware-amd-graphics because that was only a suggestion
(i.e., not a dependency of xserver-xorg-video-amdgpu), and I try to
avoid using firmware blobs as far as possible for all the obvious
practical as well as free software reasons.  However, all subsequent
attempts to configure X for my AMD RX 550 (Polaris 12) card, failed at
or near the detection stage with messages similar to the following:

[180858.109] (II) AMDGPU: Driver for AMD Radeon:
All GPUs supported by the amdgpu kernel driver
[180858.109] (II) [KMS] drm report modesetting isn't supported.
[180858.109] (EE) Screen 0 deleted because of no matching config section.
[180858.109] (II) UnloadModule: "amdgpu"
[180858.109] (EE) Device(s) detected, but none match those in the config file.

That is a ambiguous error message because no details are given here or
elsewhere in the error log.  Also, no issues were reported by
/var/log/messages and /var/log/syslog.  However, dmesg did have an
drm-related error message concerning firmware (sorry, lost the
details) which eventually lead me to reluctantly install what turns
out to be the absolutely essential (at least for the RX 550)
firmware-amd-graphics package.  At first that installation made no
difference until I realized you also had to reboot for the firmware
to take effect.  After that (text) reboot, I issued the

startx

command, X recognized this graphics card, and X came up without an
issue.  I suspect to reproduce the bad behaviour above with this model
of graphics cards (and likely other modern AMD GPU's as well) all you
will have to do is to purge the firmware-amd-graphics package, perform
a text reboot, and then issue "startx".

In sum, the issues are

1. Ambiguous error messages (at least within this log file) for the
situation when firmware-amd-graphics is not installed for at least this RX 550
Polaris 12 chipset.

2. You cannot even get started with X configuration with this hardware
unless the firmware-amd-graphics is installed.  This is, of course,
consistent with the statement "Some [AMD] GPUs may require firmware to
operate the X Window System" at
, but at least a table of
which AMD chipsets (such as my Polaris 12) where this is an issue
would be extremely useful at that website since it would reduce a lot
of hair-pulling by Debian users like me who try to avoid firmware whenever
that is possible.

Thanks for your packaging efforts that have made it possible for me
to use this card (albeit with firmware) and best wishes,

Alan

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
0a:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Lexa PRO [Radeon RX 550] [1002:699f] (rev c7)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1910 May 17 10:30 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# Use defaults for most things, but configure the exceptions to
# defaults that I like.

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
# Use automatic evdev detection of mouse and keyboard
# so no InputDevice commands here.
EndSection

# As recommended by http://pkg-xorg.alioth.debian.org/howto/configure-input.html
# Note there is no keyboard equivalent because that is configured using
# /etc/default/keyboard and following the udevadmin command given in man 
keyboard
# (or reboot the system) to make those options visible to X.

Section "InputClass"
Identifier   "evdev-pointer"
MatchIsPointer "on"
Driver "evdev"
# Disable mouse wheel if it exists (found in evdev man page)
Option "ButtonMapping" "1 2 3 0 0"
EndSection

Section "Monitor"
Identifier   "Monitor0"
DisplaySize   410   260 # mm
VendorName   "ACI"
ModelName"ASUS VH198"
 ### Comment all HorizSync and VertRefresh values to use DDC:
 #HorizSync30.0 - 80.0
 HorizSync30.0 - 67.6
 VertRefresh  55.0 - 75.0
 Option  "DPMS"
EndSection


#Section "Module"
#   Load  "modesetting"
#EndSection

# This section inferred from the Jessie "Card0" identifier and gene

Bug#803885: xserver-xorg-video-intel: glxgears segfaults for g33 chipset

[Alan W. Irwin]

On 2015-11-03 13:32+0100 Julien Cristau wrote:


Please provide the full dmesg, X log and gdb backtrace.


See three (compressed) files attached.  The dmesg and X log results
were taken just after the gdb backtrace session where glxgears
segfaulted.

Let me know if there is anything else you need.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

dmesg.out.gz
Description: dmesg output


Xorg.0.log.gz
Description: X log


gdb_backtrace.out.gz
Description: gdb backtrace

Bug#803885: xserver-xorg-video-intel: glxgears segfaults for g33 chipset

[Alan W. Irwin]

Package: xserver-xorg-video-intel
Version: 2:2.21.15-2+b2
Severity: normal

Dear Maintainer,

For my Intel g33 video chipset glxgears ran without issues on Debian
Wheezy, but for Debian Jessie it segfaults on startup.  I also find
that glxgears works fine for that identical Debian Jessie box if the
results are displayed on a remote X server (an X-terminal also running
Debian Jessie, but that box has an nvidia chipset so I am using the
xserver-xorg-video-nouveau package in that case to display the results
of glxgears).

I also find similar results with the foobillardplus 3D game; segfault on
startup with direct display using g33 chipset, but no issues if the game
is displayed remotely using an X-terminal with nvidia chipset.

My working hypothesis at this point to explain these startup segfaults
with both glxgears and foobillardplus is that some regression (likely
upstream) in 3D support for the Intel g33 chipset has been introduced
between Debian Wheezy and Jessie.  If you don't have access to g33
hardware to test this hypothesis yourself, please let me know if you
would like me to run any further tests of the hypothesis.


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Sep 25 14:02 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2401376 Feb 10  2015 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express 
Integrated Graphics Controller [8086:29c2] (rev 02)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 4480 Sep 25 14:26 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# Use defaults for most things, but configure the exceptions to
# defaults that I like.

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
# Use automatic evdev detection of mouse and keyboard
# so no InputDevice commands here.
EndSection

# As recommended by http://pkg-xorg.alioth.debian.org/howto/configure-input.html
# Note there is no keyboard equivalent because that is configured using
# /etc/default/keyboard and following the udevadmin command given in man 
keyboard
# (or reboot the system) to make those options visible to X.

Section "InputClass"
Identifier   "evdev-pointer"
MatchIsPointer "on"
Driver "evdev"
# Disable mouse wheel if it exists (found in evdev man page)
Option "ButtonMapping" "1 2 3 0 0"
EndSection

Section "Monitor"
Identifier   "Monitor0"
DisplaySize   410   260 # mm
VendorName   "ACI"
ModelName"ASUS VH198"
 ### Comment all HorizSync and VertRefresh values to use DDC:
 #HorizSync30.0 - 80.0
 HorizSync30.0 - 67.6
 VertRefresh  55.0 - 75.0
 Option  "DPMS"
EndSection

# This section generated by Xorg -configure command.
Section "Device"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz",
### : "%"
### [arg]: arg optional
#Option "NoAccel"   # []
#Option "AccelMethod"   # 
#Option "Backlight" # 
#Option "DRI"   # 
#Option "ColorKey"  # 
#Option "VideoKey"  # 
#Option "Tiling"# []
#Option "LinearFramebuffer" # []
#Option "SwapbuffersWait"   # []
#Option "TripleBuffer"  # []
#Option "XvPreferOverlay"   # []
#Option "HotPlug"   # []
#Option "ReprobeOutputs"# []
#Option "XvMC"  # []
#Option "ZaphodHeads"   # 
#Option "TearFree"  # []
#Option "PerCrtcPixmaps"# []
#Option "FallbackDebug" # []
#Option "DebugFlushBatches" # []
#Option "DebugFlushCaches"  # []
#Option "DebugWait" # []
#Option "BufferCache"   # []
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

Section "Device"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz",
### : "%"
### [arg]: arg optional
#Option "NoAccel"   # []
#Option "AccelMethod"   # 
#Option "Backlight" # 
#Option "DRI"   # 
#Option "ColorKey"  # 
#Option "VideoKey"  # 
#Opti

Bug#689377: xserver-xorg-input-evdev: emits non-fatal but concerning (EE) errors in the X log for a serial mouse

[Alan W. Irwin]

Package: xserver-xorg-input-evdev
Version: 1:2.7.0-1+b1
Severity: normal

The principal issue is as described in the subject line.  This bug is
closely related to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688674, but for a
completely different system (64-bit for this report versus 32-bit for 
bug=688674) with entirely different mouse
(logitech serial mouse attached using inputattach for this report versus a 
Chesen PS2
converter for mouse + keyboard for bug=688674).

For now the (EE) messages are non-fatal, and the mouse and keyboard
appear to work fine with no issues.  However, in 16 years of X
configuration, these two bugs are the first (EE) errors in the X log
that I have encountered that was not fatal in some way.  Thus, the
(EE) messages I get for these two cases are a concern since it may
only be by chance that the issue is not fatal.

Since I get the same (EE) error messages for two entirely different
mice and systems and my friend who runs fedora does not get these
error messages I suspect the underlying cause of this is some evdev
software issue specific to Debian that has nothing to do with mouse
hardware.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Sep 28 14:21 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2044664 Aug 21 12:55 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express 
Integrated Graphics Controller [8086:29c2] (rev 02)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 2841 Sep 28 15:25 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# Use defaults for most things, but configure the exceptions to
# defaults that I like.

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
# Use automatic evdev detection of mouse and keyboard
# so no InputDevice commands here.
EndSection

# As recommended by http://pkg-xorg.alioth.debian.org/howto/configure-input.html
# Note there is no keyboard equivalent because that is configured using
# /etc/default/keyboard and following the udevadmin command given in man 
keyboard
# (or reboot the system) to make those options visible to X.

Section "InputClass"
Identifier   "evdev-pointer"
MatchIsPointer "on"
Driver "evdev"
# Disable mouse wheel if it exists (found in evdev man page)
Option "ButtonMapping" "1 2 3 0 0"
EndSection

Section "Monitor"
Identifier   "Monitor0"
DisplaySize   410   260 # mm
VendorName   "ACI"
ModelName"ASUS VH198"
 ### Comment all HorizSync and VertRefresh values to use DDC:
 #HorizSync30.0 - 80.0
 HorizSync30.0 - 67.6
 VertRefresh  55.0 - 75.0
 Option  "DPMS"
EndSection

# This section generated by Xorg -configure command.
Section "Device"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz",
### : "%"
### [arg]: arg optional
#Option "AccelMethod"   # 
#Option "DRI"   # []
#Option "ColorKey"  # 
#Option "VideoKey"  # 
#Option "Tiling"# []
#Option "LinearFramebuffer" # []
#Option "Shadow"# []
#Option "SwapbuffersWait"   # []
#Option "TripleBuffer"  # []
#Option "XvPreferOverlay"   # []
#Option "DebugFlushBatches" # []
#Option "DebugFlushCaches"  # []
#Option "DebugWait" # []
#Option "HotPlug"   # []
#Option "RelaxedFencing"# []
#Option "Throttle"  # []
#Option "UseVmap"   # []
#Option "ZaphodHeads"   # 
#Option "DelayedFlush"  # []
#Option "FallbackDebug" # []
#Option "BufferCache"   # []
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor0"

SubSection "Display"
Viewport   0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 24
EndSubSection
EndSection


/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 3.2.0-3-amd64 (De

Bug#688812: Substitute GMA950 everywhere I said GMA500 in the text

[Alan W. Irwin]

Subject line says it all


--
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/alpine.DEB.2.00.1209260933200.31522@ybpnyubfg.ybpnyqbznva

Bug#688818: I am going to close this bug report

[Alan W. Irwin]

Because I stated in the subject line and body that it was GMA 500 rather
than the correct GMA 950.  Important difference!

I have resubmited this bug report again with correct subject line and
body GMA id.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__


--
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/alpine.DEB.2.00.1209251521370.31522@ybpnyubfg.ybpnyqbznva

Bug#688822: xserver-xorg-video-intel: GMA 950 regression for LIBGL_ALWAYS_INDIRECT=1

[Alan W. Irwin]

Package: xserver-xorg-video-intel
Version: 2:2.19.0-5
Severity: normal

When Debian stable was installed on this ASUS Eee box (b202) with
945GM chipset (GMA 950 graphics core), I could ssh in to a remote box
and play the low-end 3D game foobillard without problems with this
incantation:

env LIBGL_ALWAYS_INDIRECT=1 foobillard

and the same remote box foobillard incantation worked when I was in
temporary thin-client/X-terminal mode for this box using 

"X -query remoteboxname" 

to access the remote box via xdm rather than ssh.

Now with Debian testing installed on this Eee box (but Debian stable
still installed on the remote box), a regression (relative to Debian
stable) has appeared for the X -query method.  The symptom is there is
a screwup in the order of how the various layers of the 3D image
from the game are painted on the screen.  The layer that contains the
billards table is painted on the screen after the layer that contains
the billard balls rather than the other way around like it should be
and the result is the billard balls can only be seen very briefly.
This obviously makes this low-end 3D game unplayable on a remote box
with the "X -query" method on Debian testing. Interestingly, the game
continues to work fine on Debian testing if the ssh method is used to
play the game on that same remote box.


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Sep 19 18:50 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2027892 Jul 18 02:35 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE 
Express Integrated Graphics Controller [8086:27ae] (rev 03)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 2841 Sep 19 18:31 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# Use defaults for most things, but configure the exceptions to
# defaults that I like.

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
# Use automatic evdev detection of mouse and keyboard
# so no InputDevice commands here.
EndSection

# As recommended by http://pkg-xorg.alioth.debian.org/howto/configure-input.html
# Note there is no keyboard equivalent because that is configured using
# /etc/default/keyboard and following the udevadmin command given in man 
keyboard
# (or reboot the system) to make those options visible to X.

Section "InputClass"
Identifier   "evdev-pointer"
MatchIsPointer "on"
Driver "evdev"
# Disable mouse wheel if it exists (found in evdev man page)
Option "ButtonMapping" "1 2 3 0 0"
EndSection

Section "Monitor"
Identifier   "Monitor0"
DisplaySize   410   260 # mm
VendorName   "ACI"
ModelName"ASUS VH198"
 ### Comment all HorizSync and VertRefresh values to use DDC:
 #HorizSync30.0 - 80.0
 HorizSync30.0 - 67.6
 VertRefresh  55.0 - 75.0
 Option  "DPMS"
EndSection

# This section generated by Xorg -configure command.
Section "Device"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz",
### : "%"
### [arg]: arg optional
#Option "AccelMethod"   # 
#Option "DRI"   # []
#Option "ColorKey"  # 
#Option "VideoKey"  # 
#Option "Tiling"# []
#Option "LinearFramebuffer" # []
#Option "Shadow"# []
#Option "SwapbuffersWait"   # []
#Option "TripleBuffer"  # []
#Option "XvPreferOverlay"   # []
#Option "DebugFlushBatches" # []
#Option "DebugFlushCaches"  # []
#Option "DebugWait" # []
#Option "HotPlug"   # []
#Option "RelaxedFencing"# []
#Option "Throttle"  # []
#Option "UseVmap"   # []
#Option "ZaphodHeads"   # 
#Option "DelayedFlush"  # []
#Option "FallbackDebug" # []
#Option "BufferCache"   # []
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor0"

SubSection "Display"
Viewport   0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 24
EndSubSection
EndSection


/etc/X11/xorg.conf.d does not exist.

KMS co

Bug#688818: xserver-xorg-video-intel: GMA 500 regression for LIBGL_ALWAYS_INDIRECT=1 playing of 3D games

[Alan W. Irwin]

Package: xserver-xorg-video-intel
Version: 2:2.19.0-5
Severity: normal

When Debian stable was installed on this ASUS Eee box (b202) with
945GM chipset (GMA 500 graphics core), I could ssh in to a remote box
and play the low-end 3D game foobillard without problems with this
incantation:

env LIBGL_ALWAYS_INDIRECT=1 foobillard

and the same remote box foobillard incantation worked when I was in
temporary thin-client/X-terminal mode for this box using 

"X -query remoteboxname" 

to access the remote box via xdm rather than ssh.

Now with Debian testing installed on this Eee box (but Debian stable
still installed on the remote box), a regression (relative to Debian
stable) has appeared for the X -query method.  The symptom is there is
a screwup in the order of how the various layers of the 3D image
from the game are painted on the screen.  The layer that contains the
billards table is painted on the screen after the layer that contains
the billard balls rather than the other way around like it should be
and the result is the billard balls can only be seen very briefly.
This obviously makes this low-end 3D game unplayable on a remote box
with the "X -query" method on Debian testing. Interestingly, the game
continues to work fine on Debian testing if the ssh method is used to
play the game on that same remote box.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Sep 19 18:50 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2027892 Jul 18 02:35 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE 
Express Integrated Graphics Controller [8086:27ae] (rev 03)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 2841 Sep 19 18:31 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# Use defaults for most things, but configure the exceptions to
# defaults that I like.

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
# Use automatic evdev detection of mouse and keyboard
# so no InputDevice commands here.
EndSection

# As recommended by http://pkg-xorg.alioth.debian.org/howto/configure-input.html
# Note there is no keyboard equivalent because that is configured using
# /etc/default/keyboard and following the udevadmin command given in man 
keyboard
# (or reboot the system) to make those options visible to X.

Section "InputClass"
Identifier   "evdev-pointer"
MatchIsPointer "on"
Driver "evdev"
# Disable mouse wheel if it exists (found in evdev man page)
Option "ButtonMapping" "1 2 3 0 0"
EndSection

Section "Monitor"
Identifier   "Monitor0"
DisplaySize   410   260 # mm
VendorName   "ACI"
ModelName"ASUS VH198"
 ### Comment all HorizSync and VertRefresh values to use DDC:
 #HorizSync30.0 - 80.0
 HorizSync30.0 - 67.6
 VertRefresh  55.0 - 75.0
 Option  "DPMS"
EndSection

# This section generated by Xorg -configure command.
Section "Device"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz",
### : "%"
### [arg]: arg optional
#Option "AccelMethod"   # 
#Option "DRI"   # []
#Option "ColorKey"  # 
#Option "VideoKey"  # 
#Option "Tiling"# []
#Option "LinearFramebuffer" # []
#Option "Shadow"# []
#Option "SwapbuffersWait"   # []
#Option "TripleBuffer"  # []
#Option "XvPreferOverlay"   # []
#Option "DebugFlushBatches" # []
#Option "DebugFlushCaches"  # []
#Option "DebugWait" # []
#Option "HotPlug"   # []
#Option "RelaxedFencing"# []
#Option "Throttle"  # []
#Option "UseVmap"   # []
#Option "ZaphodHeads"   # 
#Option "DelayedFlush"  # []
#Option "FallbackDebug" # []
#Option "BufferCache"   # []
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor0"

SubSection "Display"
Viewport   0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 24
EndSubSection
EndSection


/etc/X11/xorg.conf.d does not exist.

KMS con

Bug#688812: xserver-xorg-video-intel: Reapplying the same "Outline" desktop effect slows GMA 950 graphics core to a "permanent" crawl

[Alan W. Irwin]

Package: xserver-xorg-video-intel
Version: 2:2.19.0-5
Severity: normal

For this particular Intel GMA500 graphics core, the KDE desktop is
normally quite responsive.  However, during initial configuration of
KDE I was trying to get rid of a colored halo that appears for window
that happens to have the focus. Furthermore, I noticed in "Configure
desktop effects"->"All effects" the simple "Outline" effect (helper
effect to render an outline) was on by default.  Therefore, as an
experiment I turned that off and applied, but saw no difference in the
halo.  Therefore, just to leave it in the same state as before the
experiment I turned that "Outline" effect on again. Shortly after my
whole desktop slowed to a crawl (e.g., during the slowdown it took
about a minute for a window to gain focus and another minute to
respond to a click on an icon).  "top" showed the cpu was completely
idle so I assume the gpu was borked in some way by the above cycling
of this Desktop effect. The slowdown was "permanent" in the sense that
logout/login or a (warm) reboot would not get rid of it.  

The only way I discovered to get out of this trap was to move my whole
desktop configuration aside (i.e., 

mv .kde .kde_broken

) and start my configuration all over again.

I ascribe the whole thing to a nasty interaction between the Intel GMA
500 GPU, the Intel software graphics stack, and KDE.  But as a first
approximation I have assigned the bug to the xserver-xorg-video-intel
package since my understanding is that although this particular Intel 
graphics core is supported by Intel, it is still somewhat older than
the latest graphics cores that Intel actively tests with their
graphics software.  Furthermore, the KDE desktop effects do work with
other chips, and, in fact, the KDE default desktop effects which do
include the "Outline" effect appear to work well also with GMA500
graphics so long as you are careful not to change anything such as
turn off then turn on the same effect.

By the way, this is a production box, and I don't want to lose my KDE
configuration so I am extremely reluctant to try the above experiment
again to confirm that was the source of the slowdown.  But since I was
forced to start all over with KDE configuration to beat that original
slowdown, there has been no sign of that issue again, and KDE has
proved to be completely reliable.  Furthermore, I have gone through
every (simple) step in the KDE reconfiguration that I did originally
except for fiddling with the "Outline" effect so I think it is pretty
clear that fiddle as I described it above was the action that exposed
this severe slowdown bug for GMA 500.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Sep 19 18:50 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2027892 Jul 18 02:35 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE 
Express Integrated Graphics Controller [8086:27ae] (rev 03)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 2841 Sep 19 18:31 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# Use defaults for most things, but configure the exceptions to
# defaults that I like.

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
# Use automatic evdev detection of mouse and keyboard
# so no InputDevice commands here.
EndSection

# As recommended by http://pkg-xorg.alioth.debian.org/howto/configure-input.html
# Note there is no keyboard equivalent because that is configured using
# /etc/default/keyboard and following the udevadmin command given in man 
keyboard
# (or reboot the system) to make those options visible to X.

Section "InputClass"
Identifier   "evdev-pointer"
MatchIsPointer "on"
Driver "evdev"
# Disable mouse wheel if it exists (found in evdev man page)
Option "ButtonMapping" "1 2 3 0 0"
EndSection

Section "Monitor"
Identifier   "Monitor0"
DisplaySize   410   260 # mm
VendorName   "ACI"
ModelName"ASUS VH198"
 ### Comment all HorizSync and VertRefresh values to use DDC:
 #HorizSync30.0 - 80.0
 HorizSync30.0 - 67.6
 VertRefresh  55.0 - 75.0
 Option  "DPMS"
EndSection

# This section generated by Xorg -configure command.
Section "Device"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz",
### : "%"
### [arg]: arg optional
#Option "AccelMethod"   # 
#Option "DRI"   # []
#Option "ColorKey"  # 
#Option "VideoKey"  # 
#Option "Tiling"# []
#Opti

Simple cookbook for xmodmap to xkb conversion for personal use

[Alan W. Irwin]

The uniform advice for a long time for everyone using the xmodmap
approach to configure their personal keyboard has been to convert to
xkb.  But the latter is extremely complex, and on top of that it has
terrible overall documentation (i.e., few howto's and cookbooks).
Furthermore, xmodmap continued to sort of work so I (and I think many
others as well) have stuck with xmodmap longer than we should have.

I have recently upgraded one of my production boxes to wheezy so I
thought this would be a good opportunity to convert a fairly short
.Xmodmap file I have been required to use with the edt mode of the jed
editor over the years to the equivalent xkb files.

I did follow links from
http://pkg-xorg.alioth.debian.org/howto/configure-input.html to
http://wiki.debian.org/XStrikeForce/InputHotplugGuide to
http://madduck.net/docs/extending-xkb/.  However, madduck's document
was conversational in style with exploration of a lot of extranous
dead ends he had tried so it was difficult to figure out from that
document the minimum needed to get a simple conversion of a personal
xmodmap file to a personal set of xkb files that did the same job.
Eventually after several days of screwing around I finally achieved
success so the edt mode for the jed editor works for me again.

As a result of this misadventure, I believe straightforward cookbook
documentation of the conversion from the personal xmodmap approach to
the personal xkb approach is required.  I have attached such cookbook
documentation which I am happy to donate to Debian.

I believe this cookbook documentation belongs on
http://pkg-xorg.alioth.debian.org/howto/configure-input.html (along
with a direct link to http://madduck.net/docs/extending-xkb/ as well).
However, when I approached Cyril Brulebois about an update to that
website with this cookbook, it turned out he was too busy with other
Debian matters to deal with it at the moment, but he did suggest:
"Feel free to resend your mail to debian-x@, maybe somebody else will
be able to pick it up, and merge things."

So that is what I have done, and I do hope somebody does pick this up
for that website because those Debian users who currently use a
personal xmodmap approach really do need a quick coobkbook of what to
do to get converted to the equivalent personal xkb approach.

Alan
__________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

xmodmap_to_xkb.txt.gz
Description: cookbook documentation of a successful conversion of a modest .Xmodmap file to equivalent xkb files

Bug#688674: xserver-xorg-input-evdev: emits non-fatal but concerning (EE) errors in the X log for PS2 to USB adapter

[Alan W. Irwin]

Package: xserver-xorg-input-evdev
Version: 1:2.7.0-1+b1
Severity: normal

The principal issue is as described in the subject line.  I use an
ordinary PS2 to USB converter with two sockets for keyboard and
mouse and one USB socket that is plugged into my computer.  So I
presume the device looks like a combined USB mouse and keyboard 
to the computer, and this appears to be confusing evdev some way
(although a friend of mine with a similar converter does not
see the issue on Fedora).

For now the (EE) messages are non-fatal, and the mouse and keyboard
appear to work fine with no issues.  However, in 16 years of X
configuration, this is the first (EE) error in the X log that I have
encountered that was not fatal in some way.  Thus, the (EE) messages I
get in this case are a concern since it may only be by chance that the
issue is not fatal.

Additional information concerning this particular device obtained
using "lsusb --verbose" is as follows:

Bus 002 Device 002: ID 0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse 
Adapter
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 8
  idVendor   0x0a81 Chesen Electronics Corp.
  idProduct  0x0205 PS/2 Keyboard+Mouse Adapter
  bcdDevice0.10
  iManufacturer   1 
  iProduct2 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   59
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  2 
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  1 Keyboard
  iInterface  0 
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength  64
 Report Descriptors: 
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  2 Mouse
  iInterface  0 
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 148
 Report Descriptors: 
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Sep 19 18:50 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2027892 Jul 18 02:35 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE 
Express Integrated Graphics Controller [8086:27ae] (rev 03)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 2841 Sep 19 18:31 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# Use defaults for most things, but configure the exceptions to
# defaults that I like.

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
# Use automatic evdev detection of mouse and keyboard
# so no InputDevice commands here.
EndSection

# A

Bug#588566: xserver-xorg-input-all: For amd64 should depend on xserver-xorg-input-kbd and xserver-xorg-input-mouse

[Alan W. Irwin]

On 2011-03-06 03:24+0100 Cyril Brulebois wrote:


Hi Alan,

Alan W. Irwin  (26/02/2011):

I do plan to give inputattach a quick try once I move from Debian
Squeeze to Debian testing (probably in 6-12 months after testing has
had a chance to settle down for a while), but if the inputattach
method doesn't work, I will still need to fallback to the legacy
approach at that point.


ok.


Of course, this discussion is all just a side issue to my original
bug report on the missing dependency issue for the legacy approach.
Please fix that!  Also, please remove the moreinfo tag.


Please don't “!” me. I'm not convinced this is a bug to only pull
evdev on Linux. AFAICT if it doesn't work for your device, that's a
bug (could be in the kernel, in the server, or in the driver) which
ought to be fixed. So back to the initial bug report, closing. Feel
free to file one (probably against xserver-xorg-input-evdev, that
should be a good start) if you want us to look into it.


Hi Cyril:

evdev and inputattach are separate issues.

The issue I would like to see addressed is that xserver-xorg-input-all
does not depend on xserver-xorg-input-kbd and xserver-xorg-input-mouse
like it should.  Could I have a response to that issue, please?
If there is some reason why those package dependencies should not
be fixed, that is fine, but I would like to hear what that reason is.

Alan
__________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
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/alpine.DEB.2.00.1103051838510.2378@ybpnyubfg.ybpnyqbznva

Bug#615491: Please close this bug report

[Alan W. Irwin]

I have changed the status of the upstream bug report at
https://bugs.freedesktop.org/show_bug.cgi?id=34877 to
RESOLVED/NOTOURBUG because the issue turned out to be due to the
PLplot standard example that was generating multiple duplicated
boundaries with a last large boundary segment.  Under those conditions
you get correct fills (consistent with the specified fill rule) which
look "obviously" incorrect.  So the seriously obfuscated example was
at fault here and not X's fill rule implementation for the two
different fill rules. Once that PLplot standard example was fixed so
the boundaries were not duplicated and the last boundary segment was
small both the even-odd and non-zero winding rule fill rules produced
correct results for the self-intersecting boundary case that also
looked obviously correct.

Therefore, please close this bug report.

Alan
______
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
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/alpine.DEB.2.00.1103041412410.4288@ybpnyubfg.ybpnyqbznva

Bug#615491: xserver-xorg-core: does not fill correctly for complex boundaries

[Alan W. Irwin]

On 2011-03-01 13:04+0100 Michel Dänzer wrote:


On Mon, 2011-02-28 at 12:03 -0800, Alan W. Irwin wrote:

Following your suggestion, I tried the EvenOddRule fill rule case for
both fbdev and vesa, and the results were consistent (i.e., many fill
rendering errors) with what happens for the intel driver. This has
been the first time I have ever tried fbdev or vesa so in each case I
confirmed those were the drivers I was running by checking
/var/log/Xorg.0.log.  So the answer to your question is "yes".


So, please file a bug upstream at
http://bugs.freedesktop.org/enter_bug.cgi?product=xorg , component
Server/general. However, beware that the problem is likely to be in some
very old code that hardly anyone really wants to mess with, so your best
bet may be to start digging yourself. The miFillPolygon() function in
mi/mipoly.c may be a good place to start.


I doubt I will be looking into that fill code myself since it is
probably going to take a fill algorithm expert to figure out these
EvenOddRule and WindingRule bugs. Such experts are presumably few and
far between. Nevertheless, I followed your suggestion about reporting
the bug upstream at bugs.freedesktop.org (see
https://bugs.freedesktop.org/show_bug.cgi?id=34877), and hopefully
that bug report will generate some action.

Alan
______
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
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/alpine.DEB.2.00.1103011019170.2378@ybpnyubfg.ybpnyqbznva

Bug#615491: xserver-xorg-core: does not fill correctly for complex boundaries

[Alan W. Irwin]

On 2011-02-28 14:15+0100 Michel Dänzer wrote:


On Sam, 2011-02-26 at 13:52 -0800, Alan W. Irwin wrote:

Package: xserver-xorg-core
Version: 2:1.7.7-11
Severity: normal


The PLplot development team have just implemented a demanding 2D fill
rendering test for the X stack where we modify our standard example 27
(see http://plplot.sourceforge.net/examples.php?demo=27) to change
from drawing the boundary line of "spirographic" (e.g., hypotrochoid
and epitrochoid) curves to filling those curves.  The boundaries
of the 9 test curves are illustrated in the first attachment.


[...]


Driver  "intel"


Does the problem also occur with other drivers, e.g. fbdev or vesa (will
only work if booting with i915.modeset=0 to disable KMS)?


Thanks, Michel, for your reply.

Following your suggestion, I tried the EvenOddRule fill rule case for
both fbdev and vesa, and the results were consistent (i.e., many fill
rendering errors) with what happens for the intel driver. This has
been the first time I have ever tried fbdev or vesa so in each case I
confirmed those were the drivers I was running by checking
/var/log/Xorg.0.log.  So the answer to your question is "yes".

BTW, it should only take a few minutes for you to run this test for
yourself for your favorite X stack and video hardware.  Here is the
cookbook.

* Get latest svn trunk version of PLplot source code following
the directions (including appending '/trunk' to the HTTPS URL)
at http://sourceforge.net/scm/?type=svn&group_id=2915.  This
download should only take a few minutes.

* Optionally modify drivers/xwin.c to change XSetFillRule call from
WindingRule to EvenOddRule (if you want to see the horrendous results
from that filling rule as opposed to the mildly bad results from
WindingRule).

* Optionally modify examples/c/x27c.c (say to change the number of
points in the boundary from 2 to 200 or 200).

* Build this particular PLplot x27c test and the xwin driver in an
initially empty build tree. This should only take a minute or so.

mkdir build_dir
cd build_dir
cmake -DBUILD_TEST=ON /PATH/TO/TOP/OF/SOURCE/TREE
make xwin x27c

* Run example to show fill problems for self-intersecting boundaries.
examples/c/x27c -dev xwin

You advance from one page of that test example to the next by hitting
the return/enter key.  The first set of pages should display just the
self-intersecting boundaries, and the last set of pages should display
the filled results for those boundaries.  For the EvenOddRule fill
rule, the first three "fill" pages are blank and the remaining pages
badly filled.  For the WindingRule fill rule, the first three "fill"
pages are fine, but the remaining ones have small fill errors (showing
as fill asymmetries on the right of the figure).

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
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/alpine.DEB.2.00.1102281012130.3192@ybpnyubfg.ybpnyqbznva

Bug#615491: xserver-xorg-core: does not fill correctly for complex boundaries

[Alan W. Irwin]

Package: xserver-xorg-core
Version: 2:1.7.7-11
Severity: normal


The PLplot development team have just implemented a demanding 2D fill
rendering test for the X stack where we modify our standard example 27
(see http://plplot.sourceforge.net/examples.php?demo=27) to change
from drawing the boundary line of "spirographic" (e.g., hypotrochoid
and epitrochoid) curves to filling those curves.  The boundaries
of the 9 test curves are illustrated in the first attachment.

The fills of those test curves (implemented using XFillPolygon with a
Complex shape and 2 points in the polygon describing the boundary)
have rendering errors.  

If the fill is done with the EvenOddRule filling rule (set using
XSetFillRule) the rendering errors are severe. The first through 3rd
test cases show blank results (not illustrated) and the 4th test case
(second attachment) and remaining more complex fill cases (not
illustrated) show severe rendering errors with many fills missing and
some areas filled that should not be.  

If the fill is done with the WindingRule filling rule, the fill
rendering errors are much less severe than in the case of the
EvenOddRule filling rule. The first (attached), second (not
illustrated) , and 3rd (not illustrated) test cases look fine, but the
fourth (attached) and remaining (not illustrated) test cases have
minor rendering errors (areas filled which should not be on the
right-hand side of the figure so the total result is asymmetric rather
than symmetric as it should be for the symmetric hypotrochoid and
epitrochoid boundary curves of the fill.

Because most applications and libraries (including the PLplot one)
have great success with X filling with a small (3 or 4) number of
points in the boundary for the normal default EvenOddRule filling
rule, I tried the experiment of reducing the number of points from
2 to 200, but that made no qualitative difference to the severely
bad fill rendering for the EvenOddRule filling rule.

PLplot has a great many device drivers other than the xwin one used to
produce these results.  For many of them (for example, Qt-based and
pango/cairo-based devices), I tried both the winding number fill rule
and the odd-even fill rule, and I got results consistent with those
described above where I was using a device that depended on X
directly.  That result makes sense since these libraries ultimately
end up calling X to display these filled results for complex
boundaries using either of the two filling rules.  So ultimately, all
of these different bad fill results for complex boundaries must be
caused by fill issues in the X stack.

I am not sure which package in the X stack is responsible for filling
so please move this bug report to the appropriate package if
xserver-xorg-core is not responsible for filling. Also, I am virtually
positive this is an upstream issue.  I am therefore completely willing
to propagate this bug report elsewhere (if the Debian X strike force
doesn't want to do that themselves), but I need guidance on which
component of the X stack is responsible for filling before I do such
propagation.

Finally, I am not sure exactly how to attach screenshots to Debian
bugs using reportbug so I may have to do that later if it does
not work with this initial report.

Alan W. Irwin

-- 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 Jul  5  2010 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1889440 Jan 11 19:12 /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 82G33/G31 Express 
Integrated Graphics Controller (rev 02)

/var/lib/x11/xorg.conf.md5sum does not exist.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 2941 Jul  7  2010 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
InputDevice"Mouse0" "CorePointer"
InputDevice"Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
ModulePath   "/usr/lib/xorg/modules"
FontPath "/usr/share/fonts/X11/misc"
FontPath "/usr/share/fonts/X11/cyrillic"
FontPath "/usr/share/fonts/X11/100dpi/:unscaled"
FontPath "/usr/share/fonts/X11/75dpi/:unscaled"
FontPath "/usr/share/fonts/X11/Type1"
FontPath "/usr/share/fonts/X11/100dpi"
FontPath "/usr/share/fonts/X11/75dpi"
FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
FontPath "built-ins"
EndSection

Section "Module"
Load  "dri2"
Load  "glx"
Load  &quo

Bug#588566: xserver-xorg-input-all: For amd64 should depend on xserver-xorg-input-kbd and xserver-xorg-input-mouse

[Alan W. Irwin]

On 2011-02-25 22:00+0100 Cyril Brulebois wrote:


tag 588566 moreinfo
thanks

Hi Alan,

Julien Cristau  (09/07/2010):

I haven't actually used it, but the package comes with a README,
which says:

inputattach for Debian
--

This package does not include an initscript to initialize your
devices automatically; it isn't possible to adequately control
inputattach as would be required for an initscript.

To automatically attach a serial device to the input layer, the
recommended approach is simply to add the appropriate lines to
/etc/rc.local, or to a local udev rules file. For example, to
configure a Mouse Systems mouse on the first serial port:
 * in /etc/rc.local
inputattach --daemon -msc /dev/ttyS0
 * or in /etc/udev/010_local.rules
ACTION="add", KERNEL=="ttyS0", RUN+="inputattach --daemon -msc %p"


I'd be interested to know how that works out (I guess you'd use -mman
instead of -msc to reproduce the behaviour from your xorg.conf).


any news about that?


Hi Cyril:

Ultimately, I decided to stick with the legacy approach since that was
working (aside from the dependency issue described by this bug
report), and I didn't want to disrupt a hard-working production system
with a bunch of mouse configuration experiments for special new
software (inputattach) that is specialized for serial devices and
unlikely to be as well tested as the legacy approach.

I do plan to give inputattach a quick try once I move from Debian
Squeeze to Debian testing (probably in 6-12 months after testing has
had a chance to settle down for a while), but if the inputattach
method doesn't work, I will still need to fallback to the legacy
approach at that point.

Of course, this discussion is all just a side issue to my original
bug report on the missing dependency issue for the legacy approach.
Please fix that!  Also, please remove the moreinfo tag.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
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/alpine.DEB.2.00.1102261001550.3192@ybpnyubfg.ybpnyqbznva

Bug#606340: This bug not completely fixed in 2:2.13.0-5

[Alan W. Irwin]

To follow up on my previous report, I have now had success with
xserver-xorg-video-intel/2:2.13.0-5 on the 32-bit 945GME system.

To recount the sequence of events, I originally encountered the error
with the 2:2.13.0-5 version when trying to use "apt-get install
xserver-xorg-video-intel" on a working Debian testing install without
a subsequent reboot.  I then followed advice in this bug thread to
downgrade to 2:2.13.0-2.  I couldn't get that to work, however, so as
a last resort I tried a reboot, and it worked.  That required reboot
for 2:2.13.0-2 has been niggling at me ever since so today I tried
2:2.13.0-5 again, and it worked.  I then tried a reboot, and
2:2.13.0-5 continued to work.

So my working hypothesis to explain what I encountered is rebooting is
sometimes necessary to get recent versions of xserver-xorg-video-intel
to work.  Anyhow, if any Debian user encounters the "(EE) No devices
detected" error for xserver-xorg-video-intel, I would highly recommend
trying a reboot to see if that solves the issue.

To replicate the issue I encountered, I suggest following exactly the
same sequence of events that I did which is (1) to do an expert
minimal install of Debian without X (i.e., drop all tasks from
tasksel), and (2) for that working minimal install, try installing
xserver-xorg-video-intel without subsequent rebooting.  If the "(EE)
No devices detected" error is encountered (like happened for me) and
further rebooting solves it, then that would confirm the hypothesis.

Assuming the hypothesis is correct, one solution to the issue which I
think would justify closing this bug report would be to warn users
about the reboot requirement with an install warning message for
xserver-xorg-video-intel.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
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/alpine.DEB.2.00.1102011039360.3241@ybpnyubfg.ybpnyqbznva

Bug#606340: This bug not completely fixed in 2:2.13.0-5

[Alan W. Irwin]

I confirm the issue still exists for
xserver-xorg-video-intel/2:2.13.0-5 for at least one Intel-based
system (32-bit 945GME) but also does not exist for another Intel-based
system (64-bit g33).  Both systems had the same monitor (ASUS VH198T).
The 945GME was connected with DVI while the g33 was connected with
VGA.  In both cases the other alternative connection (VGA for the
945GME or DVI for the g33) is not available.

For the 945GME the tail of the server log was
(II) Primary Device is: PCI 00@00:02:0
(EE) No devices detected.

Fatal server error:
no screens found

If I downgrade the 945GME system to 2:2.13.0-2, that error message
disappears, and X on that system works normally.

More hardware details for the 945GME that fails with 2:2.13.0-5
but which succeeds with 2:2.13.0-2:

Linux meadowlark 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686
GNU/Linux

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME
Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME,
943/940GML Express Integrated Graphics Controller (rev 03)

(This is the 32-bit ASUS Eee box [b202 version] with dvi connection to a
ASUS VH198T LCD monitor.  The chipset for this box is identified
everywhere but the Linux space as the 945GSE chipset).

More hardware details for the g33 that succeeds with the 2:2.13.0-5
version of the driver:

Linux raven 2.6.32-5-amd64 #1 SMP Fri Dec 10 15:35:08 UTC 2010 x86_64
GNU/Linux

00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express
Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation 82G33/G31 Express
Integrated Graphics Controller (rev 02)

(This is a 64-bit generic "white box" desktop PC built about 3 years ago with
ASUS P5K-V motherboard with VGA connection to a ASUS VH198T LCD
monitor.)

Both systems are running Debian testing.

When I first got the failure on the 945GME (during the initial Debian
testing install for the system), I compared the log in detail with the
g33 log.  The logs were essentially identical until the above error
message occurred for the 945GME.  There were no obvious error messages
with similar time stamp in any other file in /var/log.  So it seemed
pretty hopeless until I discovered the workaround suggested in this
thread to downgrade (from 2:2.13.0-5 in my case) to 2:2.13.0-2.

For what it is worth, the guy who sold me this used 945GME never had
issues with it on Ubuntu, but I don't know what version of Ubuntu was
the last he tried, or whether this issue (whatever it is) was in his
future if he had hung on to the box and done further Ubuntu upgrades
as time progressed.

I would be happy to send any further data from any of the 945GME
(using 2:2.13.0-2 or 2:2.13.0-5) or g33 (using 2:2.13.0-5) systems to
help track down what the problem is.  I am very happy that the
workaround of downgrading to 2:2.13.0-2 makes it possible to use the
945GME system, but obviously that workaround is not a permanent
solution.

Alan
______
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
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/alpine.DEB.2.00.1101181937410.7110@ybpnyubfg.ybpnyqbznva

Bug#588566: xserver-xorg-input-all: For amd64 should depend on xserver-xorg-input-kbd and xserver-xorg-input-mouse

[Alan W. Irwin]

On 2010-07-09 19:32+0100 Julien Cristau wrote:


On Fri, Jul  9, 2010 at 11:04:19 -0700, Alan W. Irwin wrote:


Package: xserver-xorg-input-all
Version: 1:7.5+6
Severity: normal

The default hot plugging X input system implemented using evdev
did not detect my serial mouse so I turned hot plugging off using

Option  "AutoAddDevices""False"
Option  "AutoEnableDevices" "False"

in the ServerFlags section of xorg.conf with corresponding InputDevice
sections that load the kbd and mouse drivers.

However, the result was a complete freeze because
xserver-xorg-input-kbd and xserver-xorg-input-mouse were not installed
by default by xserver-xorg-input-all.  The issue was resolved by
installing those drivers, but wouldn't it be better to have them
installed by default for the benefit of those like me with hardware
where the evdev approach does not work?

Of course, if xserver-xorg-input-mouse and/or xserver-xorg-input-kbd
interfere with evdev, that is a different story, but I don't think
they affect it at all unless the user specifically is requesting kbd
and mouse drivers as I outlined above.


Can't you use inputattach to turn your serial mouse into an input
device, which can then be picked up by evdev?


Possibly, but I don't know how to do that.  There appears to be a lot
of churn in how X handles input now (Ubuntu has dropped HAL for
example) so there are lots of differences between distros and all
general X input advice has to taken with a grain of salt since it may
only apply to certain distros.  Given the churn, I think you will see
the appeal of the tried-and-true mouse driver approach for me.

For what it is worth, here is the configuration that works for me with
that serial mouse:

Section "InputDevice"
Identifier  "Mouse0"
Driver  "mouse"
Option  "Protocol" "Mouseman"
Option  "Device" "/dev/ttyS0"
Option  "Buttons"   "3"
Option  "Emulate3Buttons"   "off"
# Desperate workaround to turn off wheel part of mouse which makes
# middle clicking extremely unreliable.
Option  "ZAxisMapping"  "8 9"
EndSection

I have included that ZAxisMapping option because that is what I have,
but it is not really necessary for that particular mouse (bought in
1996 from logitech and still going strong!).

Of course, I assume the legacy mouse driver will not be supported
indefinitely so I am willing to learn about inputattach if that
actually works for the above mouse (and can be configured statically so
I don't have to worry about it each time I run startx).

So if you can recommend a good web reference for inputattach whose
advice is applicable to Debian, I would be willing to give it a try.
But even if that turns out to be a success for me, it may not work for
others with legacy mouse hardware.  Thus, I think the dependency issue
for xserver-xorg-input-all continues to be a valid concern so long as
you are still offering the xserver-xorg-input-kbd and
xserver-xorg-input-mouse packages that historically have worked so
well for a huge variety of hardware for the case where the user is not
concerned about hot plugging.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
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/alpine.deb.2.00.1007091219170.27...@ybpnyubfg.ybpnyqbznva

Bug#588560: xserver-xorg-video-intel: generates confusing "FATAL: Module fbcon not found." message

[Alan W. Irwin]

On 2010-07-09 18:40+0100 Julien Cristau wrote:


On Fri, Jul  9, 2010 at 10:12:20 -0700, Alan W. Irwin wrote:


Package: xserver-xorg-video-intel
Version: 2:2.9.1-4
Severity: minor

There is plenty of advice on the internet to ignore this message which
is why I have classified this as a minor bug.  Nevertheless, when you
are fighting some X configuration issue and see this message it
introduces a lot of fear, uncertainty, and doubt about how you have
configured X.  Fortunately, I fought through to success (the issues I
encountered will be reported in a different bug), but the "FATAL"
message is still there with that successful X configuration which
means it really is a meaningless message just like the web says.  So
therefore, please just remove this useless and confusing message!

Also, if this is the wrong package to report this bug (say if this is
caused by the X server rather than intel driver), please forward this
bug to the appropriate X package.


The message comes from modprobe.  The message is harmless if it means
your kernel has fbcon compiled in, but it isn't if it means fbcon is
missing.  There's no way for X to know...


Does the kernel advertise somewhere (say in /proc) that it has fbcon
capability?

If not, shouldn't that kernel issue be addressed so that X can
discover whether or not the kernel has fbcon capability? The current
uncertainty about what this message means puts X users who are
struggling with X configuration in a bad position so I strongly hope a
solution can be found.

Alan
__________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
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/alpine.deb.2.00.1007091205200.27...@ybpnyubfg.ybpnyqbznva

Bug#588566: xserver-xorg-input-all: For amd64 should depend on xserver-xorg-input-kbd and xserver-xorg-input-mouse

[Alan W. Irwin]

Package: xserver-xorg-input-all
Version: 1:7.5+6
Severity: normal

The default hot plugging X input system implemented using evdev
did not detect my serial mouse so I turned hot plugging off using

Option  "AutoAddDevices""False"
Option  "AutoEnableDevices" "False"

in the ServerFlags section of xorg.conf with corresponding InputDevice
sections that load the kbd and mouse drivers.

However, the result was a complete freeze because
xserver-xorg-input-kbd and xserver-xorg-input-mouse were not installed
by default by xserver-xorg-input-all.  The issue was resolved by
installing those drivers, but wouldn't it be better to have them
installed by default for the benefit of those like me with hardware
where the evdev approach does not work?

Of course, if xserver-xorg-input-mouse and/or xserver-xorg-input-kbd
interfere with evdev, that is a different story, but I don't think
they affect it at all unless the user specifically is requesting kbd
and mouse drivers as I outlined above.

Alan W. Irwin

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xserver-xorg-input-all depends on:
ii  xserver-xorg-input-evd 1:2.3.2-6 X.Org X server -- evdev input driv
ii  xserver-xorg-input-syn 1.2.2-2   Synaptics TouchPad driver for X.Or
ii  xserver-xorg-input-wac 0.10.5+20100416-1 X.Org X server -- Wacom input driv

xserver-xorg-input-all recommends no packages.

xserver-xorg-input-all 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/20100709180419.30381.11504.report...@localhost.localdomain

Bug#579910: vmware video driver breaks X configure

[Alan W. Irwin]

I confirm the issue on my newly configured Debian squeeze box.

Since there is a workaround (uninstall xserver-xorg-video-vmware)
it probably is okay to leave this at normal severity level, but
the unimpeded use of X --configure is quite important these days to
obtain the core of a useful X configuration for a vastly changed X 
configuration landscape.  Therefore, if the workaround were not

available I would have requested classifying this bug at a much
higher severity level.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
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/alpine.deb.2.00.1007091019080.30...@ybpnyubfg.ybpnyqbznva

Bug#588560: xserver-xorg-video-intel: generates confusing "FATAL: Module fbcon not found." message

[Alan W. Irwin]

Package: xserver-xorg-video-intel
Version: 2:2.9.1-4
Severity: minor

There is plenty of advice on the internet to ignore this message which
is why I have classified this as a minor bug.  Nevertheless, when you
are fighting some X configuration issue and see this message it
introduces a lot of fear, uncertainty, and doubt about how you have
configured X.  Fortunately, I fought through to success (the issues I
encountered will be reported in a different bug), but the "FATAL"
message is still there with that successful X configuration which
means it really is a meaningless message just like the web says.  So
therefore, please just remove this useless and confusing message!

Also, if this is the wrong package to report this bug (say if this is
caused by the X server rather than intel driver), please forward this
bug to the appropriate X package.

Alan W. Irwin

-- 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 Jul  5 21:09 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1878240 Jun  3 08:09 /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 82G33/G31 Express 
Integrated Graphics Controller (rev 02)

/var/lib/x11/xorg.conf.md5sum does not exist.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 2941 Jul  7 13:12 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
InputDevice"Mouse0" "CorePointer"
InputDevice"Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
ModulePath   "/usr/lib/xorg/modules"
FontPath "/usr/share/fonts/X11/misc"
FontPath "/usr/share/fonts/X11/cyrillic"
FontPath "/usr/share/fonts/X11/100dpi/:unscaled"
FontPath "/usr/share/fonts/X11/75dpi/:unscaled"
FontPath "/usr/share/fonts/X11/Type1"
FontPath "/usr/share/fonts/X11/100dpi"
FontPath "/usr/share/fonts/X11/75dpi"
FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
FontPath "built-ins"
EndSection

Section "Module"
Load  "dri2"
Load  "glx"
Load  "extmod"
Load  "dri"
Load  "record"
Load  "dbe"
EndSection

Section "ServerFlags"
Option  "AutoAddDevices""False"
Option  "AutoEnableDevices" "False"
#   Option  "DontZap"   "False"
EndSection

Section "InputDevice"
Identifier  "Keyboard0"
Driver  "kbd"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc105"
Option  "XkbLayout" "us"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

Section "InputDevice"
Identifier  "Mouse0"
Driver  "mouse"
Option  "Protocol" "Mouseman"
Option  "Device" "/dev/ttyS0"
Option  "Buttons"   "3"
Option  "Emulate3Buttons"   "off"
# Desperate workaround to turn off wheel part of mouse which makes
# middle clicking extremely unreliable.
Option  "ZAxisMapping"  "8 9"
EndSection

Section "Monitor"
Identifier   "Monitor0"
DisplaySize   410   260 # mm
VendorName   "ACI"
ModelName"ASUS VH198"
 ### Comment all HorizSync and VertRefresh values to use DDC:
#HorizSync30.0 - 80.0
HorizSync30.0 - 67.6
VertRefresh  55.0 - 75.0
Option  "DPMS"
EndSection

Section "Device"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz"
### [arg]: arg optional
#Option "NoAccel"   # []
#Option "SWcursor"  # []
#Option "ColorKey"  # 
#Option "CacheLines"# 
#Option "Dac6Bit"   # []
#Option "DRI"   # []
#Option "NoDDC"

Bug#563850: test

[Alan W. Irwin]

Just checking for whether I am subscribed to this bug or not.



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#563850: xserver-xorg-video-sis: X server crashes when logging out from KDE via xdm

[Alan W. Irwin]

Package: xserver-xorg-video-sis
Version: 1:0.10.1-2
Severity: normal

I have a minimal Debian testing system (core packages + X server
packages) where I gain access to a fast remote computer running KDE(3.5)
X clients and xdm using

X -query remotehostname

My minimal system (which has an integrated SIS video chipset) has a
serial mouse so I have followed the general advice in the discussion
of bug 547143 to ignore HAL by setting AutoAddDevices and
AutoEnableDevices to False. The result is the KDE (remote) desktop
runs fine without any issues _before_ logout except some errors
reported from HAL below in the log vile (which presumably are expected
when it is ignored).  However, when I do the KDE desktop logout,
additional errors are generated in the logfile below starting with

(EE) SIS(0): Unable to map IO aperture. Invalid argument (22)

Those appear to have no practical implications (since I am logging out
anyway), but I thought I should report them "for the record".

Alan W. Irwin

-- 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 Jan  5 00:56 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1689944 Oct 13 04:31 /usr/bin/Xorg

/var/lib/x11/xorg.conf.roster does not exist.

VGA-compatible devices on PCI bus:
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 
65x/M650/740 PCI/AGP VGA Display Adapter

/var/lib/x11/xorg.conf.md5sum does not exist.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 9040 Jan  5 11:11 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
InputDevice"Mouse0" "CorePointer"
InputDevice"Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
ModulePath   "/usr/lib/xorg/modules"
FontPath "/usr/share/fonts/X11/misc"
FontPath "/usr/share/fonts/X11/cyrillic"
FontPath "/usr/share/fonts/X11/100dpi/:unscaled"
FontPath "/usr/share/fonts/X11/75dpi/:unscaled"
FontPath "/usr/share/fonts/X11/Type1"
FontPath "/usr/share/fonts/X11/100dpi"
FontPath "/usr/share/fonts/X11/75dpi"
FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
FontPath "built-ins"
EndSection

Section "Module"
Load  "dri2"
Load  "record"
Load  "dbe"
Load  "glx"
Load  "dri"
Load  "extmod"
EndSection

Section "ServerFlags"
Option  "AutoAddDevices""False"
Option  "AutoEnableDevices" "False"
EndSection

Section "InputDevice"
Identifier  "Keyboard0"
Driver  "kbd"
Option  "CoreKeyboard"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc105"
Option  "XkbLayout" "us"

EndSection

Section "InputDevice"
Identifier  "Mouse0"
Driver  "mouse"
Option  "CorePointer"
Option  "Protocol" "Mouseman"
Option  "Device" "/dev/ttyS0"
Option  "ZAxisMapping" "4 5"
EndSection

Section "Monitor"
Identifier  "Sony CPD-15SF2"
VendorName   "Sony"
ModelName"CPD-15SF2"
Option  "DPMS"
# Next 3 data lines from the monitor manual
HorizSync   31-65
VertRefresh 50-120
# Following values needed to calculate correct X/Y DPI.
DisplaySize 285 213
# Results from "gtf 912 687 85"
# 912x687 @ 85.00 Hz (GTF) hsync: 61.37 kHz; pclk: 74.63 MHz
Modeline "912x687_85.00"  74.63  912 968 1064 1216  687 688 691 722  
-HSync +Vsync
Option "PreferredMode" "912x687_85.00"  
EndSection

Section "Device"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz"
### [arg]: arg optional
#Option "Accel" # []
#Option "AccelMethod"   # 
#Option "TurboQueue"# []
#Option "FastVram"  # []
#Option &qu

Bug#451917: xserver-xorg-video-intel: upgrade from 2:2.1.1-4 to 2:2.2.0-1 breaks X for g33 chipset

[Alan W. Irwin]

Brice,

FYI, I just tried the new 2:1.4.1~git20071119-1 version of xserver-xorg-core
combined with version 2:2.2.0-1 of xserver-xorg-video-intel just in case
that new combination might fix the problem.  No change. There is still a
complete lockup from X -probeonly.  When I downgrade to version 2:2.1.1-4 of
xserver-xorg-video-intel X works fine in combination with the new
xserver-xorg-core.

What's the next step?  Is there a debianized latest git version of
xserver-xorg-video-intel that I could try for you?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#451917: xserver-xorg-video-intel: continued report for XAA possibility

[Alan W. Irwin]

Package: xserver-xorg-video-intel
Version: 2:2.2.0-1
Followup-For: Bug #451917

XAA was a nice idea, which I thought might work, but it didn't help.  X
-probeonly still gives complete lockup for version 2:2.2.0-1 of
xserver-xorg-video-intel while there are no X problems for version 2.1.1-4
of that package.

>From the log below xaa is only loaded after the error message

(EE) intel(0): First SDVO output reported failure to sync

which I still think is an important diagnostic.

Let me know if there are any other tests I can run to help you narrow this
problem down.

Alan
-- 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 2007-11-20 12:52 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1827360 2007-09-29 14:13 /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 82G33/G31 Express 
Integrated Graphics Controller (rev 02)

/var/lib/x11/xorg.conf.md5sum does not exist.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 2594 2007-11-21 09:05 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
# xorg.conf (xorg 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 "Files"
EndSection

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "CoreKeyboard"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc101"
Option  "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
Option  "CorePointer"
Option  "Device""/dev/input/mice"
Option  "Protocol"  "ExplorerPS/2"
Option  "Buttons"   "3"
Option  "Emulate3Buttons"   "off"
# Desperate workaround to turn off wheel part of mouse which makes
# middle clicking extremely unreliable.
Option  "ZAxisMapping"  "8 9"
EndSection

Section "Device"
Identifier  "g33/X3000"
Driver  "intel"
BusID   "PCI:0:2:0"
Option  "ModeDebug"  "on"
Option  "Monitor-VGA-1" "Sony Multiscan G200"
Option  "AccelMethod" "XAA"
#   Option  "DDC""off"
EndSection

Section "Monitor"
Identifier  "Sony Multiscan G200"
Option  "DPMS"
HorizSync   30-96
VertRefresh 48-120
#gtf 1024 768 85
# 1024x768 @ 85.00 Hz (GTF) hsync: 68.60 kHz; pclk: 94.39 MHz
Modeline "1024x768_85.00"  94.39  1024 1088 1200 1376  768 769 772 807  -HSync 
+Vsync
#gtf 1024 768 60
# 1024x768 @ 60.00 Hz (GTF) hsync: 47.70 kHz; pclk: 64.11 MHz
#Modeline "1024x768_60.00"  64.11  1024 1080 1184 1344  768 769 772 795  -HSync 
+Vsync
#gtf 800 600 60
# 800x600 @ 60.00 Hz (GTF) hsync: 37.32 kHz; pclk: 38.22 MHz
#Modeline "800x600_60.00"  38.22  800 832 912 1024  600 601 604 622  -HSync 
+Vsync

Option "PreferredMode" "1024x768_85.00"
#Option "PreferredMode" "1024x768_60.00"
#Option "PreferredMode" "800x600_60.00"
EndSection

Section "Screen"
Identifier  "Default Screen"
Device  "g33/X3000"
Monitor "Sony Multiscan G200"
DefaultDepth16
SubSection "Display"
Depth   16
EndSubSection
SubSection "Display"
Depth   24
EndSubSection
EndSection

Section "ServerLayout"
Identifier  "Default Layout"
Screen  "Default Screen"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
EndSection


Xorg X server log files on system:
-rw-r--r-- 1 root root 44338 2007-11-21 09:09 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:

X.Org X Server 1.4.0
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Debian (xorg-server 2:1.4-3)
Current Operating System: Linux raven 2.6.22-2-amd64 #1 SMP Thu Aug 30 23:43:59 
UTC 2007 x86_64
Build Date: 29 September 2007  08:59:46PM
 
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed

Bug#451917: xserver-xorg-video-intel: upgrade from 2:2.1.1-4 to 2:2.2.0-1 breaks X for g33 chipset

[Alan W. Irwin]

On 2007-11-19 11:11+0100 Brice Goglin wrote:


Alan W. Irwin wrote:

Package: xserver-xorg-video-intel
Version: 2:2.2.0-1
Severity: normal


X -probeonly

completely locks up the keyboard with the monitor immediately put into its
low-power state (as close to turned off as possible without quite being
turned off) so the only recourse is to log in remotely and shutdown or to
reset to regain control of the keyboard.  Everything worked fine
for previous version (2:2.1.1-4) although there was initially a lot
of trouble with modelines and VGA-1 until I found the right combination
in xorg.conf to get 2:2.1.1-4 to work.

Note, I have tried some other variations such as VGA rather than VGA-1, but
that didn't help the complete lockup with X -probeonly.  In the log below
you will see

First SDVO output reported failure to sync

I previously (with 2:2.1.1-4) never saw that error message.

Any advice you could give me to work around the present hard lock
and restore X to normalcy would be much appreciated.  For example,
is there any way for me to get back to 2:2.1.1-4?


The 2:2.1.1-4 package is available from:
http://snapshot.debian.net/archive/2007/09/17/debian/pool/main/x/xserver-xorg-video-intel/

Could you also try 2:2.1.99-1 to see if it was broken too?
http://snapshot.debian.net/archive/2007/11/14/debian/pool/main/x/xserver-xorg-video-intel/



Here are the results of my tests now.  The Debian testing version of xorg
works fine on the graphical chip in my g33 chipset (ASUS P5K-V MB).
xorg.conf uses a gtf-generated [EMAIL PROTECTED] modeline.  The Debian unstable
version of xorg using xserver-xorg-video-intel version 2:2.1.1-4 works fine
as well with exactly the same xorg.conf file.  If the Debian unstable
version of xorg is kept exactly the same except and "upgrade" of the
xserver-xorg-video-intel package to either 2:2.1.99-1 or 2:2.2.0-1,

X -probeonly

completely locks up (no access to keyboard).  So the problem was introduced
between 2:2.1.1-4 and 2:2.1.99-1.

When passing this information to upstream, I suggest you emphasize the
error message "First SDVO output reported failure to sync" since googling for
that phrase indicates it is a fairly rare error message.

It there are any other tests you would like me to do (especially if you
have any newer xserver-xorg-video-intel versions you would like me to try),
I would be glad to help because a clean sid version means Debian testing
will be that much better.

Finally, I suggest you find some temporary means to keep the present
unstable version of xorg from being deployed to Debian testing until this
bug is fixed.  I believe g33 chipset owners using Debian testing (which
works right now for me and presumably them) will be severely disappointed if
that precaution is not taken.

Alan
__________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#451917: xserver-xorg-video-intel: upgrade from 2:2.1.1-4 to 2:2.2.0-1 breaks X for g33 chipset

[Alan W. Irwin]

Package: xserver-xorg-video-intel
Version: 2:2.2.0-1
Followup-For: Bug #451917


Brice said:

> Anyway, could you try changing your modeline into something else?
For instance [EMAIL PROTECTED] or [EMAIL PROTECTED] instead?
(use gtf to get the corresponding modeline).

Hi Brice:

I was also concerned that perhaps my mixed debian testing/unstable system
was causing a problem with just updating xserver-xorg-core and
xserver-xorg-video-intel (although that simple procedure worked for
xserver-xorg-video-intel version 2:2.1.1-4) so I removed those packages (and
everything dependent on them such as xorg), then reinstalled the unstable
xorg using

apt-get -t unstable xorg

For that newly installed unstable xorg, "X -probeonly" completely locks up
both for [EMAIL PROTECTED] and [EMAIL PROTECTED]  The results for the latter 
are given
below.

This is a production system so my top priority is to get X working again,
Thus, the next thing I am going to try is removing xorg from unstable and
reinstalling the testing version.  I only moved to the unstable xorg version
in desperation when I could not get modelines to work at all before (see
Bug#448983, where the VGA-1 peculiarity for my g33 system was first
mentioned.) However, I think I am on top of that modeline problem, and so I
may get a working X out of xorg testing.  If that doesn't work, then
I will attempt to go back to xserver-xorg-video-intel version 2:2.1.1-4).

Alan

-- 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-10-31 18:15 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1827360 2007-09-29 14:13 /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 82G33/G31 Express 
Integrated Graphics Controller (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 2557 2007-11-19 11:09 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
# xorg.conf (xorg 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 "Files"
EndSection

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "CoreKeyboard"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc101"
Option  "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
Option  "CorePointer"
Option  "Device""/dev/input/mice"
Option  "Protocol"  "ExplorerPS/2"
Option  "Buttons"   "3"
Option  "Emulate3Buttons"   "off"
# Desperate workaround to turn off wheel part of mouse which makes
# middle clicking extremely unreliable.
Option  "ZAxisMapping"  "8 9"
EndSection

Section "Device"
Identifier  "g33/X3000"
Driver  "intel"
BusID   "PCI:0:2:0"
Option  "ModeDebug"  "on"
Option  "Monitor-VGA-1" "Sony Multiscan G200"
#   Option  "DDC""off"
EndSection

Section "Monitor"
Identifier  "Sony Multiscan G200"
Option  "DPMS"
HorizSync   30-96
VertRefresh 48-120
#gtf 1024 768 85
# 1024x768 @ 85.00 Hz (GTF) hsync: 68.60 kHz; pclk: 94.39 MHz
#Modeline "1024x768_85.00"  94.39  1024 1088 1200 1376  768 769 772 807  -HSync 
+Vsync
#gtf 1024 768 60
# 1024x768 @ 60.00 Hz (GTF) hsync: 47.70 kHz; pclk: 64.11 MHz
#Modeline "1024x768_60.00"  64.11  1024 1080 1184 1344  768 769 772 795  -HSync 
+Vsync
#gtf 800 600 60
# 800x600 @ 60.00 Hz (GTF) hsync: 37.32 kHz; pclk: 38.22 MHz
Modeline "800x600_60.00"  38.22  800 832 912 1024  600 601 604 622  -HSync 
+Vsync

#Option "PreferredMode" "1024x768_85.00"
#Option "PreferredMode" "1024x768_60.00"
Option "PreferredMode" "800x600_60.00"
EndSection

Section "Screen"
Identifier  "Default Screen"
Device  "g33/X3000"
Monitor "Sony Multiscan G200"
DefaultDepth16
SubSection "Display"
Depth   16
EndSubSection
SubSection "Display"
Depth   24
EndSu

Bug#451917: xserver-xorg-video-intel: upgrade from 2:2.1.1-4 to 2:2.2.0-1 breaks X for g33 chipset

[Alan W. Irwin]

Package: xserver-xorg-video-intel
Version: 2:2.2.0-1
Severity: normal


X -probeonly

completely locks up the keyboard with the monitor immediately put into its
low-power state (as close to turned off as possible without quite being
turned off) so the only recourse is to log in remotely and shutdown or to
reset to regain control of the keyboard.  Everything worked fine
for previous version (2:2.1.1-4) although there was initially a lot
of trouble with modelines and VGA-1 until I found the right combination
in xorg.conf to get 2:2.1.1-4 to work.

Note, I have tried some other variations such as VGA rather than VGA-1, but
that didn't help the complete lockup with X -probeonly.  In the log below
you will see

First SDVO output reported failure to sync

I previously (with 2:2.1.1-4) never saw that error message.

Any advice you could give me to work around the present hard lock
and restore X to normalcy would be much appreciated.  For example,
is there any way for me to get back to 2:2.1.1-4?

Alan W. Irwin

-- 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 2007-10-31 18:15 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1827360 2007-09-29 14:13 /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 82G33/G31 Express 
Integrated Graphics Controller (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 2128 2007-11-18 23:47 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
# xorg.conf (xorg 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 "Files"
EndSection

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "CoreKeyboard"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc101"
Option  "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
Option  "CorePointer"
Option  "Device""/dev/input/mice"
Option  "Protocol"  "ExplorerPS/2"
Option  "Buttons"   "3"
Option  "Emulate3Buttons"   "off"
# Desperate workaround to turn off wheel part of mouse which makes
# middle clicking extremely unreliable.
Option  "ZAxisMapping"  "8 9"
EndSection

Section "Device"
Identifier  "g33/X3000"
Driver  "intel"
BusID   "PCI:0:2:0"
Option  "ModeDebug"  "on"
Option  "Monitor-VGA-1" "Sony Multiscan G200"
#   Option  "DDC""off"
EndSection

Section "Monitor"
Identifier  "Sony Multiscan G200"
Option  "DPMS"
HorizSync   30-96
VertRefresh 48-120
# 1024x768 @ 85.00 Hz (GTF) hsync: 68.60 kHz; pclk: 94.39 MHz
Modeline "1024x768_85.00"  94.39  1024 1088 1200 1376  768 769 772 807  -HSync 
+Vsync
Option "PreferredMode" "1024x768_85.00"
EndSection

Section "Screen"
Identifier  "Default Screen"
Device  "g33/X3000"
Monitor "Sony Multiscan G200"
DefaultDepth16
SubSection "Display"
Depth   16
EndSubSection
SubSection "Display"
Depth   24
EndSubSection
EndSection

Section "ServerLayout"
Identifier  "Default Layout"
Screen  "Default Screen"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
EndSection


Xorg X server log files on system:
-rw-

Bug#448983: xserver-xorg-video-intel: ignores Modes and minimum VertRefresh to always choose [EMAIL PROTECTED] for Intel g33 chipset

[Alan W. Irwin]

On 2007-11-04 00:20+0100 Brice Goglin wrote:


0:2:1 is not another graphic board, it is a kind of fake ID that old windows
used to manage the second screen or so. X does not need it (and can't
use it).


Thanks for the update-pciids tip.  For the record, the first few lines from
lspci now read

00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM
Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express
Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation 82G33/G31 Express Integrated
Graphics Controller (rev 02)


From what you said above the 00:02.1 is fake so that leaves only the

00:02.0.  There is nothing else in the list that refers to video or
graphics.



What matters is only the kinds of outputs that may be plugged (VGA, DVI,
...).
If you only have a signle VGA output, then either the driver is buggy,
or there's a hidden second VGA output somewhere.
You might want to check in the BIOS in case something rings a bell.


Nothing in the BIOS that I could find.  I think it must be a buggy driver
since I only have one VGA output and no DVI (or any other extra port related
to video when you look at the internal and external connector list from the
ASUS P5K-V MB manual).

Let me know if there is any other information you need to track this 
"VGA-1" problem down.


Alan
__________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#448983: xserver-xorg-video-intel: ignores Modes and minimum VertRefresh to always choose [EMAIL PROTECTED] for Intel g33 chipset

[Alan W. Irwin]

On 2007-11-03 09:24+0100 Brice Goglin wrote:


Alan W. Irwin wrote:

Worse yet, only the VGA one is documented in the intel man page.  However,
when I tried

Option  "Monitor-VGA-1" "Sony CPD-15SF2"

encouraged by your remark above but contrary to the man page that (finally)
solved the issue of having a good refresh rate right from startx.  That is,
my special modeline was finally recognized, and the "PreferredMode" option
worked for the first time.  So I am a happy camper after a couple of days
struggle with this.  Thanks very much for your help and especially the
informed guess above!


Ok, now I'd like to find out why the driver uses VGA-1 on your board
instead of VGA. It's usually when there are 2 VGA outputs.
What kind of machine is this and what kind of monitor can you plug on
it?


Its an ASUS P5K-V MB with g33 chipset.  See 
http://www.asus.com/products.aspx?l1=3&l2=11&l3=542&l4=0&model=1652&modelmenu=1

for a description.  There is some confusion about which GMA there is with
the g33.  When I bought the card (a few days ago) the above site said it
used the gma X3000 and that agrees with what it says on the MB box, but now
the above site says its the gma 3100, and that is in agreement with
http://en.wikipedia.org/wiki/Intel_GMA and several other sites.  I have also
found references that say the g33 chipset includes the GMA X3100!

lspci is not too helpful in getting this GMA confusion straightened out.

00:00.0 Host bridge: Intel Corporation Unknown device 29c0 (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Unknown device 29c2
(rev 02)
00:02.1 Display controller: Intel Corporation Unknown device 29c3 (rev 02)
00:1a.0 USB Controller: Intel Corporation Unknown device 2937 (rev 02)
00:1a.1 USB Controller: Intel Corporation Unknown device 2938 (rev 02)
00:1a.2 USB Controller: Intel Corporation Unknown device 2939 (rev 02)
00:1a.7 USB Controller: Intel Corporation Unknown device 293c (rev 02)
00:1b.0 Audio device: Intel Corporation Unknown device 293e (rev 02)
00:1c.0 PCI bridge: Intel Corporation Unknown device 2940 (rev 02)
00:1c.4 PCI bridge: Intel Corporation Unknown device 2948 (rev 02)
00:1c.5 PCI bridge: Intel Corporation Unknown device 294a (rev 02)
00:1d.0 USB Controller: Intel Corporation Unknown device 2934 (rev 02)
00:1d.1 USB Controller: Intel Corporation Unknown device 2935 (rev 02)
00:1d.2 USB Controller: Intel Corporation Unknown device 2936 (rev 02)
00:1d.7 USB Controller: Intel Corporation Unknown device 293a (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation Unknown device 2918 (rev 02)
00:1f.2 IDE interface: Intel Corporation Unknown device 2921 (rev 02)
00:1f.3 SMBus: Intel Corporation Unknown device 2930 (rev 02)
00:1f.5 IDE interface: Intel Corporation Unknown device 2926 (rev 02)
01:00.0 Ethernet controller: Unknown device 1969:1048 (rev b0)
02:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI
Controller (rev 03)
02:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI
Controller (rev 03)
04:02.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine] (rev 06)
04:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev c0)

I assume all the "Unknown device" strings mean that this kind of hardware is
so new that it hasn't yet gotten into the authoritative PCI identification
data base (assuming such a database exists) or that it is there or Debian
testing does not yet have the relevant update. Is there something I could do
(I would need a cookbook because I have never fiddled with PCI
identification before) to get better identifications or do I just have to
wait?

The second and third entries from the lspci output above appear to be the
relevant ones.  However, with this MB, there is only one video-relevant port
available at the back of the case which is an ordinary classical VGA port.
Currently I have

BusID   "PCI:0:2:0"

in the Device section of xorg.conf and the log file says the following:

(II) Primary Device is: PCI 00:02:0
(WW) intel: No matching Device section for instance (BusID PCI:0:2:1) found
(--) Chipset G33 found

If I change the above BusID to PCI:0:2:1, X errors out (presumably because
PCI:0:2:1 is not connected with my monitor and cannot be because it is
somewhere on the MB rather than accessible at the back of the case).

My original report has (I believe) all the relevant log stuff, but if not, here
is the relevant EDID section for the monitor:

  170 root  10  -5 000 S0  0.0   0:00.00 khubd
172 root  10  -5 000 S0  0.0   0:00.00 kseriod
YS)
(II) intel(0): SDVO: R: 02 00   (Success)
(II) intel(0): I2C device "SDVOB DDC Bus:ddc2" registered at address 0xA0.
(II) intel(0): SDVO: W: 7A 02
(SDVO_CMD_SET_CONTROL_BUS_SWI
TCH)
(II) intel

Bug#448983: xserver-xorg-video-intel: ignores Modes and minimum VertRefresh to always choose [EMAIL PROTECTED] for Intel g33 chipset

[Alan W. Irwin]

On 2007-11-02 20:49+0100 Brice Goglin wrote:


In particular is there some confusion between VGA and VGA-1 that could be
causing the problem with adding modelines?


Possibly, yes.


Option  "Monitor-VGA" "Sony CPD-15SF2"


Monitor-VGA-1 might be better since the output of xrandr seems to say
that output VGA-1 is used here.


line in the device section of xorg.conf as recommended by the man page for
xorg.conf.  I haven't tried VGA-1, in that line (since the intel man page
says to use VGA), but I wonder if the confusion between VGA and VGA-1 is
causing a problem here?


VGA-1 is the name of the second VGA output when using the Intel driver.
VGA is the first one. These names are not well standardized across
drivers yet, I hope it will be better in the future.


Worse yet, only the VGA one is documented in the intel man page.  However,
when I tried

Option  "Monitor-VGA-1" "Sony CPD-15SF2"

encouraged by your remark above but contrary to the man page that (finally)
solved the issue of having a good refresh rate right from startx.  That is,
my special modeline was finally recognized, and the "PreferredMode" option
worked for the first time.  So I am a happy camper after a couple of days
struggle with this.  Thanks very much for your help and especially the
informed guess above!

In sum, here are the two man page changes I recommend to avoid other users
(no matter how experienced) running into these sorts of RandR problems again
and again.

1. Put a reference to the HowTo in the xorg.conf man page at the first
mention of RandR.  There is a lot of other RandR stuff in that man page now,
and the HowTo reference would make sense of it.

2. Change the intel man page so that it is clear VGA and VGA-1 are accepted
in the above Option command.  Right now it says only VGA which screwed me
up completely with regard to adding a special modeline and using the
"PreferredMode" option.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]