Re: Bug#697029: [ilk] using GNOME 3 makes computer sluggish after a few minutes

[Ben Hutchings]

On Sat, 2013-02-23 at 12:05 -0800, Jonathan Nieder wrote:
> found 697029 linux/3.7.3-1~experimental.1
> tags 697029 - wontfix
> affects 697029 + release-notes
> quit
> 
> Hi,
> 
> Chris Wilson wrote:
> 
> > The performance issue on 3.7 is not due to the missed irq, but a
> > combination of using UXA and VT-d. In order to workaround an erratum
> > on Ironlake, every time we touch the GPU's page tables, we have to
> > idle the GPU before doing so. This causes extremely noticeable display
> > lag.

For reference, the workaround seems to be implemented by:

commit 6fbcfb3e467adb414e235eeefaeaf51ad12f2461
Author: David Woodhouse 
Date:   Sun Sep 25 19:11:14 2011 -0700

intel-iommu: Workaround IOTLB hang on Ironlake GPU

commit 5c0422878fcdc279ae9a8e8b66972a15b5efb67f
Author: Ben Widawsky 
Date:   Mon Oct 17 15:51:55 2011 -0700

drm/i915: ILK + VT-d workaround

However the latter is applied only to Ironlake M (mobile).  So either
there are two different bugs or there is some confusion about which
chips have the bug.

> Pierre AUSSAGUEL wrote:
> 
> > Appending intel_iommu=off seems to fix the problem (I tested a few
> > days befor posting).
> 
> Daniel Vetter wrote:
> 
> > Since we can't fix the hw, closing this as wontfix. Thanks for
> > reporting this issue anyway.
> 
> That makes this a distro issue, I suppose.
> 
> Ben and X team, any ideas?  Would it makes sense to disable
> intel_iommu by default on this hardware and require intel_iommu=on to
> reenable it?

Use of an IOMMU is in part a performance vs security trade-off.  I tend
to think that security settings should have consistent defaults, as
otherwise users may assume that a security feature is enabled when it is
not.

Aside from that, the Intel IOMMU can be enabled separately per device
(except behind PCI bridges).  Since IGPs aren't real PCI(e) devices and
Intel has not always validated their interaction with the IOMMU, they
often don't work with it.  There is already a kernel parameter to
disable it for the IGP ('intel_iommu=igfx_off') and a quirk to do so
automatically for the G4x and GM45.  Maybe the thing to do is to log a
message about this parameter when enabling the workaround for Ironlake.

> Should GNOME somehow detect that it should use classic
> mode by default when the iommu is enabled?

I think this would be a very poor heuristic.

> If we can't come up with a workaround, this should be mentioned in the
> release notes to prevent a regression on upgrade.  Please feel free to
> remind me in that case so I can come up with some wording (though I
> also wouldn't mind if someone else does).

"Graphics rendering may be very slow on Intel 'Ironlake M' GPUs (PCI ID
8086:0046) when an IOMMU (VT-d) is enabled.  The IOMMU functionality can
be disabled for the GPU by adding the kernel parameter
'intel_iommu=igfx_off'."

(The identification of which devices are affected may need to be
revised.)

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


signature.asc
Description: This is a digitally signed message part

Re: Bug#702668: RV350 AQ: not possible to select screen left of other screen, only clone mode is possible

[Ben Hutchings]

On Sat, 2013-03-09 at 13:11 -0800, Jonathan Nieder wrote:
> # regression
> severity 702668 important
> quit
> 
> Hi,
> 
> Jaap van Wingerde wrote:
> 
> > Version: 3.2.35-2
> [...]
> > It is not possible to select a screen right or left of other screen, only 
> > clone
> > mode is possible (gnome-control-center display). With 
> > linux-image-3.2.0-3-amd64
> > this works perfect.
> [...]
> > [   31.122989] pci :01:00.0: putting AGP V3 device into 8x mode
> > [   31.425620] [drm] Setting GART location based on new memory map
> > [   31.425750] [drm] Loading R300 Microcode
> > [   31.455633] platform radeon_cp.0: firmware: agent aborted loading 
> > radeon/R300_cp.bin (not found?)
> > [   31.456061] [drm:radeon_do_init_cp] *ERROR* Failed to load firmware!
> [...]
> > 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee 
> > ATI RV350 AQ [Radeon 9600] [1002:4151] (prog-if 00 [VGA controller])
> > Subsystem: ASUSTeK Computer Inc. A9600SE [1043:c004]
> 
> Thanks for reporting.  Is the firmware-linux-nonfree package installed?
> 
> Either way, please attach output from
> 
>   reportbug --template xserver-xorg-video-radeon

In version 3.2.35-1 I changed radeon to disable KMS when firmware is not
installed, because this generally doesn't work.  Previously the driver
would try to continue and this would often cause memory corruption or a
blank screen.

However, for the older chips such as the R300 family radeon should be
able to do KMS without any firmware (only 3D acceleration will be
disabled, as before).  I changed the driver again in 3.2.39-1 to revert
to the previous behaviour for these chips.

Jaap, please try the current version from unstable (3.2.39-2).

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


signature.asc
Description: This is a digitally signed message part

Re: 702668: not possible to select screen left of other screen, only clone mode is possible (solved)

[Ben Hutchings]

On Sat, 2013-04-06 at 11:14 +, Jaap van Wingerde wrote:
> Bug 702668 is solved with package .
> 
> The problem with loading radeon firmware still exists.
[...]

How is this a problem?  You have chosen not to install it.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
   - John Lehman, Secretary of the US Navy 1981-1987


signature.asc
Description: This is a digitally signed message part

Re: Bug#572754: Closing

[Ben Hutchings]

On Thu, 2013-06-06 at 09:26 +0800, Paul Wise wrote:
> Control: reopen -1
> Control: found -1 3.9.4-1
> 
> The bug is still reproducible with Linux from jessie.

Well I wonder whether it's really a kernel bug anyway.  It's surely up
to the X server and DDX to decide what to render when you switch back to
its VT, whether or not the kernel is doing modesetting for it.  X
maintainers, could you comment on this?

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.


signature.asc
Description: This is a digitally signed message part

Improving hardware support in Debian stable

[Ben Hutchings]

This mail is a follow-up to yesterday's meeting at DebConf:
https://penta.debconf.org/penta/schedule/dc13/event/1013.en.html
(recordings not yet available, but should be soon)

I don't think anyone took notes at the time, but I think there was
general consensus that:

1. compat-drivers should be packaged separately from linux, and should
build a separate binary package per subsystem (and per flavour).  This
should remove the risk of regressions for hardware that's already
supported.

2. The installer should install whichever of these binary packages are
needed (presumably with the aid of discover).

3. Mesa drivers for new chips should be packaged with different names
and only bound to the new PCI IDs.  Mesa can then automatically load
whichever driver is appropriate.

4. The new/updated drivers potentially get updated at every point
release.  We won't attempt to support multiple new versions of a driver
per suite.  There is a risk of regression for those using them, but this
is no worse than the current situation where users must update the
entire kernel or X server from another suite which is updated even more
frequently.

I don't think X video drivers and libdrm modules were explicitly
addressed, but presumably they can be handled similarly to Mesa drivers?

Hardware support in the installer itself wasn't addressed within the
meeting proper, but after later discussion it was obvious that
compat-drivers must build udebs to be included in installer images.

Now there is a potential problem with the installer, in that the updated
kernel modules would always be 'installed' in the initrd, whereas on the
installed system they would only be installed if necessary.  So if a
backported driver has a regression in support for older hardware, it
would not affect the installed sytem but *would* affect the installer.

I'm not sure how to get around that.  Possibly the new modules should be
renamed and have their PCI IDs restricted.  But this is not ideal as it
will force people to configure module options differently, and it will
require new logic in initramfs-tools to find the updated drivers.  I'll
keep thinking about how to solve this, but would appreciate suggestions
from others...

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.


signature.asc
Description: This is a digitally signed message part

Re: Removing old unmaintained X drivers

[Ben Hutchings]

On Sat, 2013-09-28 at 10:16 -0500, Bob Tracy wrote:
> On Sat, Sep 28, 2013 at 02:29:05PM +0100, Jurij Smakov wrote:
> > On Thu, Sep 26, 2013 at 10:26 PM, Julien Cristau wrote:
> > > (...)
> > > xserver-xorg-video-sis
> > > (...)
> 
> The SiS chipset was, unfortunately, really popular with manufacturers of
> relatively expensive micro PeeCees (EzGo, Jadetec, etc.), which were
> essentially notebook hardware crammed into a small desktop case.  Here's
> a link with good pics: http://www.tomshardware.com/reviews/smallest,530-2.html
> and see also http://www.snotmonkey.com/work/ezgo/ for detailed specs.
> It's based on the P4, and I've got one of them.  Case has the footprint
> of a "shuttle", but is about half the height.  If I *could* switch video
> cards, I'd do it in a heartbeat because SiS video cards have given me nothing
> but grief through the years.
> 
> In the "unsolved wontfix" ubuntu bug list for the driver, mention is
> made of the fact XAA support went bye-bye, and the attempted use of EXA
> causes looping segfaults on X server startup.  Only current workaround
> is to disable acceleration.  Truly a case of "bad breath is better than
> no breath".

This sounds like a good reason to remove it, unless both vesa and fbdev
also fail on this hardware.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.


signature.asc
Description: This is a digitally signed message part

Re: Bug#825916: installation-reports: Installing Debian with AMD/ATI Radeon graphics card does not go well

[Ben Hutchings]

On Tue, 2016-05-31 at 12:34 +0200, scootergrisen wrote:
> Package: installation-reports
> Severity: important
> 
> When i install Debian on computer with AMD/ATI Radeon graphics card it does no
> go well.
> 
> After installation there is problem booting into the graphical desktop (GNOME)
> because it needs firmware-linux-nonfree and other packages to it seems.
>
> This is a big problem for a new user that wants to try Debian for the first
> time and have no idea why the system cant start the graphical desktop and what
> commands to type.
> 
> I would at least expect to be able to start the desktop into some low
> resolution mode like in Windows where you can get into the desktop even though
> you dont have the correct driver.

Yes, something should load a generic framebuffer driver if necessary.
I don't know what that would be though.

- I don't think it can be the kernel, as the kernel doesn't take that
  sort of policy decision
- It can't be the X or Wayland server, because they don't run as root
- I don't think it should be the display manager, because we have
  multiple implementations of that (gdm3, kdm, lightdm, ...)

Maybe a systemd unit/init script provided by an X/WL base package?

The other question is what the generic framebuffer driver would be, on
x86.  I just tried vga16fb, and gdm3 doesn't work on that - it seems to
be repeatedly starting an X server that quickly crashes.  efifb is
presumably preferable on UEFI systems.  uvesafb is another option but
requires a userland helper.

Ben.

> Then maybe the user is able to find information on the web/IRC to fix the
> problem.



-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.


signature.asc
Description: This is a digitally signed message part

Re: Bug#831286: installation-reports: Reiser4 (SFRN 4.0.1) linux-image-4.6.0-1+reiser4.0.1-amd64(4.6.3-1) d-i on Jessie successful install on HP Pavilion

[Ben Hutchings]

Control: reassign -1 xserver-xorg-input-all 1:7.7+15
Control: retitle -1 Drop dependency on xserver-xorg-input-vmmouse
Control: severity -1 important

On Thu, 2016-07-14 at 12:18 +, j...@metztli-it.com wrote:
[...]
> Boot method: USB
> Image version: 
> https://metztli.it/readOnlyEphemeral/metztli-jessie_4.6.3-1.iso 
> https://metztli.it/readOnlyEphemeral/metztli-jessie_4.6.3-1.SHA256SUM
[...]
> Comments/Problems:
> 
> Reiser4 [Software Format Release Number (SFRN) 4.0.1]-enabled d-i on USB[*], 
> implemented expert install with Debian Desktop Environment GUI.
> Custom kernel embedded as UDEB in Debian-Installer (d-i), automatically 
> downloaded kernel & matching reiser4progs from metztli.it.
> d-i also fetched required linux-base 4.3 dependency from Jessie backports and 
> last d-i phase removed nfs-common and xserver-xorg-input-vmmouse[**]
>  - as it conflicted with custom kernel package.
>
> https://metztli.it/readOnlyEphemeral/jessie-reiser4-tlacatecolotl.png
> 
> Sample install sequence originally illustrated on Debian Sid:
> https://metztli.it/blog/index.php/ixiptli/reiser4-sfrn-4-0-1
> https://metztli.it/blog/index.php/ixiptli/installing-a-reiser4-patched-linux
> 
> [*]
> dd if=metztli-jessie_4.6.3-1.iso of=/dev/sdb bs=4M; sync
> (where, of course, /dev/sdb represents [your] USB device)
> 
> [**] Note removing xserver-xorg-input-vmmouse also removes 
> task-gnome-desktop, task-desktop, and input driver metapackage 
> xserver-xorg-input-all
[...]

This is definitely a bug in xserver-xorg-input-all.  The kernel driver
for the VMware mouse device is incompatible with Xorg's vmmouse driver
but works with the generic evdev and libinput drivers.  xserver-xorg-
input-all must not depend on the vmmouse driver.

However, the Xorg vmmouse driver will continue to be used in jessie.
The custom kernel used in this image should not include the vmmouse
driver and should not declare that it breaks xserver-xorg-input-
vmmouse.  This is what has been done in the jessie-backports kernel
package.

Ben.

-- 

Ben Hutchings
73.46% of all statistics are made up.


signature.asc
Description: This is a digitally signed message part

Bug#831420: RM: xserver-xorg-input-vmmouse -- RoQA; obsolete and conflicts with kernel

[Ben Hutchings]

Package: ftp.debian.org
Severity: normal

This is a driver for the VMware virtual mouse device.  We now enable
the Linux kernel driver for this device, so Xorg will support it
through its generic libinput or evdev driver.  Further, the kernel and
Xorg vmmouse drivers cannot be used at the same time so the current
linux-image packages break this package.

Although this package might conceivably be useful on non-Linux kernels,
it is currently only built for Linux so I don't think that's a reason
to keep it.

Bug#779515: Should enable the qxl kernel driver when installed

[Ben Hutchings]

Source: xserver-xorg-video-qxl
Version: 0.1.1-2
Severity: normal

I've enabled the kernel's qxl driver, but disabled by default so that
it doesn't conflict with wheezy's version of xserver-xorg-video-qxl.

Please install a modprobe configuration file with the line:

options qxl modeset=1

(When I tried this on a VM host with virt-manager and QEMU from sid,
the qxl driver complained of missing features, so KMS still didn't
work.  However, the fall-back to UMS still worked.)

Ben.

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150301184754.9121.41900.report...@deadeye.wl.decadent.org.uk

Re: Bug#595511: linux-image-2.6.32-5-686: Blacklisting KMS for i8xx makes xorg intel driver unusable on these chipsets

[Ben Hutchings]

On Sun, Sep 05, 2010 at 02:25:25PM +0200, Cesare Leonardi wrote:
> On 09/04/2010 08:00 PM, Soenke wrote:
>> the recent update of linux-image-2.6.32 to 2.6.32-21 disables KMS for
>> i8xx chipsets. This causes the xorg-video-intel driver to hang on X
>> startup on my system.
>
> Yes, the situation for your i855 and previous intel chipset is in a bad  
> shape.
> For example look this (but there are other similar reports):
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594623
>
> It's both a kernel and a xserver-xorg-video-intel problem, but more the  
> latter. The kernel team is probably waiting to know if KMS should be  
> enabled or not for these chipsets and is working in concert with the  
> Ubuntu one for a common solution.
[...]

The Debian kernel team works closely with the X Strike Force regarding
DRM/KMS drivers, and we generally follow their advice on what options and
patches to use.

We're not working with Ubuntu on this, though we did follow their lead in
blacklisting those chips.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20100907122723.ga11...@decadent.org.uk

Nouveau kernel driver

[Ben Hutchings]

I'd like to pull nouveau from 2.6.33 into Debian's 2.6.32.  I'm hoping
this would allow for replacement of nv and its dodgy source with nouveau
(I realise nouveau has its own issues with non-free bits, but they're
more easily separable).  Does this sound like a good idea?

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: Nouveau kernel driver

[Ben Hutchings]

On Tue, 2010-01-05 at 22:15 +, Chris Lamb wrote:
> Ben Hutchings wrote:
> 
> > I'd like to pull nouveau from 2.6.33 into Debian's 2.6.32.  I'm hoping
> > this would allow for replacement of nv and its dodgy source with nouveau
> 
> This sounds like a good idea, but I should probably point out that I don't
> think we will be able to replace nv in squeeze with nouveau.

Why not?  Does it not support all the same hardware as nv, or is it
still too unstable?

> Would this this affect whether you want to spend time on it now? As you
> imply, we get this "for free" by waiting for .33, and I will have to get
> some -snapshot packages into testing anyway..

squeeze will be released with 2.6.32.  The release of .33 will be too
close to the freeze date.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
   Among economists, the real world is often a special case.


signature.asc
Description: This is a digitally signed message part

Re: loading kernel mode setting drivers

[Ben Hutchings]

On Thu, 2009-12-31 at 18:24 +, Julien Cristau wrote:
[...]
> One possible way to fix this, I guess, would be to replace this
> blacklist entry with a list of blacklisted fb drivers, to allow i915
> (and later radeon and nouveau) being loaded automatically on boot.  Is
> this feasible?  Are there other/better solutions?

That sounds like it might be a problem to maintain.  Would it be
feasible for each X video driver to blacklist the conflicting fb
driver(s), in the same way that KMS-capable X video drivers set module
parameters to enable KMS?

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou


signature.asc
Description: This is a digitally signed message part

Bug#508126: x11-utils: xprop -spy does not handle destruction properly

[Ben Hutchings]

Package: x11-utils
Version: 7.3+2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I would expect xprop -spy to exit cleanly when the target window is
destroyed.  The actual behaviour is that it sometimes dies with a
BadWindow error and sometimes hangs around after the target has been
destroyed.  This causes problems for xdg-screensaver, which relies
on it to exit when the target is destroyed.

Ben.

- -- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (100, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages x11-utils depends on:
ii  cpp4:4.3.2-2 The GNU C preprocessor (cpp)
ii  libc6  2.7-16GNU C Library: Shared libraries
ii  libfontconfig1 2.6.0-3   generic font configuration library
ii  libfontenc11:1.0.4-3 X11 font encoding library
ii  libfreetype6   2.3.7-2   FreeType 2 font engine, shared lib
ii  libgl1-mesa-glx [libgl 7.0.3-6   A free implementation of the OpenG
ii  libice62:1.0.4-1 X11 Inter-Client Exchange library
ii  libsm6 2:1.0.3-2 X11 Session Management library
ii  libx11-6   2:1.1.5-2 X11 client-side library
ii  libxaw72:1.0.4-2 X11 Athena Widget library
ii  libxext6   2:1.0.4-1 X11 miscellaneous extension librar
ii  libxft22.1.12-3  FreeType-based font drawing librar
ii  libxi6 2:1.1.4-1 X11 Input extension library
ii  libxinerama1   2:1.0.3-2 X11 Xinerama extension library
ii  libxmu62:1.0.4-1 X11 miscellaneous utility library
ii  libxmuu1   2:1.0.4-1 X11 miscellaneous micro-utility li
ii  libxrender11:0.9.4-2 X Rendering Extension client libra
ii  libxt6 1:1.0.5-3 X11 toolkit intrinsics library
ii  libxtst6   2:1.0.3-1 X11 Testing -- Resource extension 
ii  libxv1 2:1.0.4-1 X11 Video extension library
ii  libxxf86dga1   2:1.0.2-1 X11 Direct Graphics Access extensi
ii  libxxf86vm11:1.0.2-1 X11 XFree86 video mode extension l
ii  x11-common 1:7.3+18  X Window System (X.Org) infrastruc
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

x11-utils recommends no packages.

Versions of packages x11-utils suggests:
ii  mesa-utils7.0.3-6Miscellaneous Mesa GL utilities

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJPKu079ZNCRIGYgcRArrAAJ9+Q/XMiifbNJ+faDU1ir0IEa0yFwCfeUI+
jdkCoYzWKur9YQ/M5Zw+F5Q=
=v+q5
-END PGP SIGNATURE-



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

Bug#508126: x11-utils: xprop -spy does not handle destruction properly

[Ben Hutchings]

This patch seems to do the job.  Firstly we listen for destroy events.
However, since window destruction is asynchronous with other clients, we
may receive a BadWindow (or BadMatch, due to id reuse) error while
reporting a property change.  So secondly we catch these errors.
Possibly we should print a new-line before exiting in this case, since
the error received when we have generated partial output for a property
change.

Ben.

diff -Nru x11-utils.orig/xprop/xprop.c x11-utils/xprop/xprop.c
--- x11-utils.orig/xprop/xprop.c
+++ x11-utils/xprop/xprop.c
@@ -1596,6 +1596,18 @@
 
 static int spy = 0;
 
+static int (*old_error_handler)(Display *dpy, XErrorEvent *ev);
+
+static int spy_error_handler(Display *dpy, XErrorEvent *ev)
+{
+if (ev->error_code == BadWindow || ev->error_code == BadMatch) {
+   /* Window was destroyed */
+   exit(0);
+}
+
+return old_error_handler(dpy, ev);
+}
+
 int
 main (int argc, char **argv)
 {
@@ -1738,9 +1750,14 @@
XEvent event;
const char *format, *dformat;

-   XSelectInput(dpy, target_win, PropertyChangeMask);
+   XSelectInput(dpy, target_win, PropertyChangeMask | StructureNotifyMask);
+   old_error_handler = XSetErrorHandler(spy_error_handler);
for (;;) {
XNextEvent(dpy, &event);
+   if (event.type == DestroyNotify)
+   break;
+   if (event.type != PropertyNotify)
+   continue;
format = dformat = NULL;
if (props) {
int i;
--- END ---

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.


signature.asc
Description: This is a digitally signed message part

Bug#508126: xine-ui: ctrl/shift key press emulation implementation broken

[Ben Hutchings]

I need some guidance on how to deal with the following related bugs:

#374644: xine-ui: ctrl/shift key press emulation implementation broken
#506001: xine-ui: xine causes left ctrl keyup events every 20 seconds
These are the same bug: xine-ui suppresses screensavers by injecting
fake keystrokes, which may be received by other windows.  It also
suppresses gnome-screensaver cleanly, so we could disable the key
injection code without affecting GNOME users.  However, this would be a
regression for users of the X server screensaver, xscreensaver or the
KDE screensaver.

My proposed fix involves using xdg-screensaver, which supports all the
different screensavers.  However, this suffers from the following bugs:
#508125: xdg-screensaver: Race in suspend/resume can lead to process leak
#508126: x11-utils: xprop -spy does not handle destruction properly
I do not think that these are, in themselves, RC.

I have now proposed fixes for all of these, and the result appears to be
robust.  Should I NMU with these fixes?  Should any of these bugs be
down/upgraded?

Ben.

-- 
Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing anyway.


signature.asc
Description: This is a digitally signed message part

Bug#508126: xine-ui: ctrl/shift key press emulation implementation broken

[Ben Hutchings]

On Sat, 2009-01-03 at 18:00 +0100, Julien Cristau wrote:
> On Fri, Jan  2, 2009 at 15:30:01 +0000, Ben Hutchings wrote:
> 
> > #508126: x11-utils: xprop -spy does not handle destruction properly
> > 
> the xprop patch looks reasonable afaict, so go ahead and NMU.  somebody
> should also forward that patch to bugs.freedesktop.org.

Thanks, done.  The NMU-diff follows.

Ben.

diff -Nru x11-utils-7.3+2/debian/changelog x11-utils-7.3+2+nmu1/debian/changelog
--- x11-utils-7.3+2/debian/changelog2008-05-30 15:21:43.0 +0100
+++ x11-utils-7.3+2+nmu1/debian/changelog   2009-01-03 22:22:41.0 
+
@@ -1,3 +1,11 @@
+x11-utils (7.3+2+nmu1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Make xprop -spy exit cleanly when target window is destroyed
+(closes: #508126)
+
+ -- Ben Hutchings   Sat, 03 Jan 2009 22:22:40 +
+
 x11-utils (7.3+2) unstable; urgency=low
 
   * Relax Replaces on xutils and xbase-clients to allow further updates.
diff -Nru x11-utils-7.3+2/debian/patches/05_xprop_spy_exit_on_destroy.diff 
x11-utils-7.3+2+nmu1/debian/patches/05_xprop_spy_exit_on_destroy.diff
--- x11-utils-7.3+2/debian/patches/05_xprop_spy_exit_on_destroy.diff
1970-01-01 01:00:00.0 +0100
+++ x11-utils-7.3+2+nmu1/debian/patches/05_xprop_spy_exit_on_destroy.diff   
2009-01-03 22:21:48.0 +
@@ -0,0 +1,50 @@
+This patch by Ben Hutchings .
+
+xprop -spy should exit cleanly when the target window is destroyed.
+The current behaviour is that it sometimes dies with a BadWindow error
+and sometimes hangs around after the target has been destroyed.
+
+We fix this by listening for destroy events but also catching
+BadWindow errors (and BadMatch, which may sometimes be received
+instead of BadWindow).  We print a new-line before exiting from the
+error handler, since we may have generated partial output for a
+property change.
+
+--- x11-utils.orig/xprop/xprop.c
 x11-utils/xprop/xprop.c
+@@ -1596,6 +1596,19 @@
+ 
+ static int spy = 0;
+ 
++static int (*old_error_handler)(Display *dpy, XErrorEvent *ev);
++
++static int spy_error_handler(Display *dpy, XErrorEvent *ev)
++{
++if (ev->error_code == BadWindow || ev->error_code == BadMatch) {
++  /* Window was destroyed */
++  puts("");
++  exit(0);
++}
++
++return old_error_handler(dpy, ev);
++}
++
+ int
+ main (int argc, char **argv)
+ {
+@@ -1738,9 +1750,14 @@
+   XEvent event;
+   const char *format, *dformat;
+   
+-  XSelectInput(dpy, target_win, PropertyChangeMask);
++  XSelectInput(dpy, target_win, PropertyChangeMask | StructureNotifyMask);
++  old_error_handler = XSetErrorHandler(spy_error_handler);
+   for (;;) {
+   XNextEvent(dpy, &event);
++  if (event.type == DestroyNotify)
++  break;
++  if (event.type != PropertyNotify)
++  continue;
+   format = dformat = NULL;
+   if (props) {
+   int i;
diff -Nru x11-utils-7.3+2/debian/patches/series 
x11-utils-7.3+2+nmu1/debian/patches/series
--- x11-utils-7.3+2/debian/patches/series   2008-02-01 00:21:49.0 
+
+++ x11-utils-7.3+2+nmu1/debian/patches/series  2009-01-03 22:22:05.0 
+
@@ -1,2 +1,3 @@
 02_xev_flush_standard_output.diff
 04_xlsfonts_do_not_spew_usage_on_connection_error.diff -p0
+05_xprop_spy_exit_on_destroy.diff
--- END ---

-- 
Ben Hutchings
The world is coming to an end.  Please log off.


signature.asc
Description: This is a digitally signed message part

Bug#421025: XCreateFontSet fails with fixed 13 as first font pattern in UTF-8 environment

[Ben Hutchings]

On Fri, 2007-08-10 at 11:48 +0200, Brice Goglin wrote:
> Ben Hutchings wrote:
> > If list->charset_list != NULL and list->charset_count == 0, the Xmalloc
> > call in copy_string_list might return NULL (I don't know whether it
> > supports a size of 0), causing copy_string_list and XCreateFontSet() to
> > return NULL.  This seems unlikely to be triggered only by the exact font
> > pattern lists I identified though.
> >   
> 
> By the way, did you try with libx11-6 2:1.1.3-1 currently in experimental?

I have tried this now, and the assertion still fails.

I traced through the call with gdb and symbols from the libx11-dbg
package.  Most of the interesting code is in omGeneric.c; XCreateFontSet
indirectly calls create_oc in this file.  This gets some configuration
from files in /usr/share/X11/locale.  The "locale.dir" file specifies
that most UTF-8 locales should get font set configuration from
"en_US.UTF-8/XLC_LOCALE".  That specifies that it should look for fonts
covering the following character sets:

0. ISO8859-1
1. ISO8859-1 (again)
2. JISX0208.1983-0
3. KSC5601.1987-0
4. GB2312.1980-0
5. JISX0201.1976-0
6. ISO10646-1

parse_fontname somehow comes up with the following font names for these,
respectively:

0. -misc-fixed-bold-r-normal--13-100-100-100-c-70-iso8859-1
1. -misc-fixed-bold-r-normal--13-100-100-100-c-70-iso8859-1
2. -jis-fixed-medium-r-normal--13-94-100-100-c-0-jisx0208.1983-0
3. (nothing)
4. (nothing)
5. -misc-fixed-medium-r-normal--13-94-100-100-c-0-jisx0201.1976-0
6. -misc-fixed-bold-r-normal--13-120-75-75-c-70-iso10646-1

Then load_font_info calls XListFontsWithInfo for each of these names.
This fails for
"-jis-fixed-medium-r-normal--13-94-100-100-c-0-jisx0208.1983-0", and the
error propagates up to the caller of XCreateFontSet.  It would also fail
for "-misc-fixed-medium-r-normal--13-94-100-100-c-0-jisx0201.1976-0".

parse_fontname is calling parse_omit_name, which combines the font
name(s) originally passed to XCreateFontSet with a given character set
and then calls get_font_name, which calls XListFonts.  And XListFonts
for "-*-fixed-*-*-*-*-13-*-*-*-*-*-JISX0208.1983-0" returns
"-jis-fixed-medium-r-normal--13-94-100-100-c-0-jisx0208.1983-0".

XListFonts does little other than making a request to the server.  So I
guess this is really a server bug.

Here's a new test program:

#include 
#include 

#include 

int main(int argc, char ** argv)
{
Display * display;
char **name_list, **name_list_2;
int count, count_2, i;
XFontStruct *info;

assert(argc >= 2);
display = XOpenDisplay(0);
assert(display);
name_list = XListFonts(display, argv[1], 10, &count);
assert(name_list);

for (i = 0; i != count; ++i)
{
name_list_2 = XListFontsWithInfo(display, name_list[i], 1, &count_2,
 &info);
if (name_list_2)
{
printf("%s exists\n", name_list[i]);
XFreeFontInfo(name_list_2, info, count_2);
}
else
{
printf("%s doesn't exist!\n", name_list[i]);
}
}

XFreeFontNames(name_list);

return 0;
}

Run this with the argument
"-*-fixed-*-*-*-*-*-*-*-*-*-*-JISX0208.1983-0" and you should see the
bug (or not).

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.


signature.asc
Description: This is a digitally signed message part

Bug#421025: XCreateFontSet fails with fixed 13 as first font pattern in UTF-8 environment

[Ben Hutchings]

On Sun, 2007-09-23 at 06:29 +0100, Ben Hutchings wrote:
 
> Run this with the argument
> "-*-fixed-*-*-*-*-*-*-*-*-*-*-JISX0208.1983-0" and you should see the
> bug (or not).

I suspect you won't see it.

With my normal X server I get:

$ ./listfonts -*-fixed-*-*-*-*-13-*-*-*-*-*-JISX0208.1983-0
-jis-fixed-medium-r-normal--13-94-100-100-c-0-jisx0208.1983-0 doesn't exist!
-misc-fixed-medium-r-normal--13-94-100-100-c-0-jisx0208.1983-0 doesn't exist!

With an Xvfb server in a clean etch chroot I get:

$ DISPLAY=:1 ,/listfonts -*-fixed-*-*-*-*-13-*-*-*-*-*-JISX0208.1983-0
-jis-fixed-medium-r-normal--13-94-100-100-c-0-jisx0208.1983-0 exists
-misc-fixed-medium-r-normal--13-94-100-100-c-0-jisx0208.1983-0 exists

However:

$ xlsfonts | grep jisx0208
-jis-fixed-medium-r-normal--0-0-75-75-c-0-jisx0208.1983-0
-jis-fixed-medium-r-normal--16-110-100-100-c-160-jisx0208.1983-0
-jis-fixed-medium-r-normal--16-150-75-75-c-160-jisx0208.1983-0
-jis-fixed-medium-r-normal--24-170-100-100-c-240-jisx0208.1983-0
-jis-fixed-medium-r-normal--24-230-75-75-c-240-jisx0208.1983-0
-misc-fixed-medium-r-normal--0-0-75-75-c-0-jisx0208.1983-0
-misc-fixed-medium-r-normal--14-130-75-75-c-140-jisx0208.1983-0
$ diff <(xlsfonts | grep jisx0208) <(DISPLAY=:1 xlsfonts | grep jisx0208) && 
echo same
same

And:

$ ./listfonts -jis-fixed-medium-r-normal--0-0-75-75-c-0-jisx0208.1983-0
-jis-fixed-medium-r-normal--0-0-75-75-c-0-jisx0208.1983-0 doesn't exist!
$ DISPLAY=:1 ./listfonts 
-jis-fixed-medium-r-normal--0-0-75-75-c-0-jisx0208.1983-0
-jis-fixed-medium-r-normal--0-0-75-75-c-0-jisx0208.1983-0 exists

It seems like the servers are offering (in XListFonts) to make 13-pixel
fixed for JISX0208 by scaling the 14-pixel or 16-pixel bitmap (ugh!),
but my normal X server then disavows that in XListFontsWithInfo.  Where
do we go from here?

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.


signature.asc
Description: This is a digitally signed message part

Bug#502675: libdrm: Binary firmware in driver source

[Ben Hutchings]

Package: libdrm
Version: 2.3.1-1
Severity: serious
Justification: Policy 2.2.1

The libdrm source package includes the DRM drivers mga, r128, radeon
which include sourceless firmware images.  These could all be removed
from the source package since the drivers are built as part of
linux-2.6.

Ben.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#502675: closed by Julien Cristau <[EMAIL PROTECTED]> (Bug#502675: fixed in libdrm 2.3.1-2)

[Ben Hutchings]

Julien Cristau <[EMAIL PROTECTED]> wrote:
> libdrm (2.3.1-2) unstable; urgency=high
> .
>   * Remove from the source package a bunch of files that are only used by the
> kernel drm component.  This gets rid of the mga, r128 and radeon
> microcode, and thus closes: #502675.  Thanks, Ben Hutchings!

Shouldn't this be removed from the orig tarball?  I don't see any point
in patching it out.

Ben.



signature.asc
Description: This is a digitally signed message part

Bug#487834: xserver-xorg-video-radeon: Image scaling busted with XAA on Mobility Radeon 9600

[Ben Hutchings]

Option "XaaNoOffscreenPixmaps" seems to fix this, so presumably it
should be enabled by default on this hardware.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.


signature.asc
Description: This is a digitally signed message part

Bug#487834: xserver-xorg-video-radeon: Image scaling busted with XAA on Mobility Radeon 9600

[Ben Hutchings]

Package: xserver-xorg-video-radeon
Version: 1:6.8.191-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In Iceweasel 3 I see black rectangles in place of images that are
scaled.  This doesn't happen if I enable EXA, but that is currently
too slow to be usable on this hardware.

- -- 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 2006-11-22 22:22 /etc/X11/X -> /usr/bin/Xorg
- -rwxr-xr-x 1 root root 1717748 2008-06-09 14:34 /usr/bin/Xorg

Contents of /var/lib/x11/xorg.conf.roster:
xserver-xorg

VGA-compatible devices on PCI bus:
01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 
9600 M10]

/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 842 2008-06-24 13:39 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
# xorg.conf (X.Org X Window System server configuration file)
#
# 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 "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc101"
Option  "XkbLayout" "gb"
Option  "XkbOptions""ctrl:nocaps"
EndSection

Section "Monitor"
Identifier  "LVDS"
# Reported physical display size is wrong, so override it
DisplaySize 284 213
Option  "DPMS"
EndSection


Xorg X server log files on system:
- -rw-r- 1 root root 42036 2007-04-25 22:42 /var/log/Xorg.1.log
- -rw-r- 1 root root 57288 2007-09-23 15:33 /var/log/Xorg.2.log
- -rw-r--r-- 1 root root 46473 2008-06-24 13:37 /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.90
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Debian (xorg-server 2:1.4.1~git20080517-2)
Current Operating System: Linux deadeye 2.6.25-2-686 #1 SMP Thu Jun 12 16:26:30 
UTC 2008 i686
Build Date: 09 June 2008  03:18:20PM
 
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 24 13:37:30 2008
(==) Using config file: "/etc/X11/xorg.conf"
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |-->Screen "Default Screen Section" (0)
(**) |   |-->Monitor ""
(==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
(==) |-->Input Device ""
(==) |-->Input Device "Generic Keyboard"
(==) The core pointer device wasn't specified explicitly in the layout.
Using the default mouse configuration.
(==) The core keyboard device wasn't specified explicitly in the layout.
Using the first keyboard device.
(==) Automatically adding devices
(==) Automatically enabling devices
(==) No FontPath specified.  Using compiled-in default.
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
Entry deleted from font path.
(==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
(==) RgbPath set to "/etc/X11/rgb"
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) Open ACPI successful (/var/run/acpid.socket)
(II) Loader magic: 0x81e2560
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.3
X.Org Video Driver: 2.0
X.Org XInput driver : 2.0
X.Org Server Extension : 0.3
X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModule: "pcidata"
(II) Loading /usr/lib/xorg/modules//libpcidata.so
(II) Module pcidata: vendor="X.Org Foundation"
compiled for 1.4.0.90, module version = 1.0.0
ABI class: X.Org Video Driver, version 2.0
(++) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,3340 card 1014,0529 rev 03 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 8086,3341 card , rev 03 class 06,04,00 hdr 01

Bug#486606: xdm:unable to login - XDM authorization key matches an existing client

[Ben Hutchings]

In the interim, I made an NMU with the following trivial change.

Ben.

diff -u xdm-1.1.8/debian/changelog xdm-1.1.8/debian/changelog
--- xdm-1.1.8/debian/changelog
+++ xdm-1.1.8/debian/changelog
@@ -1,3 +1,10 @@
+xdm (1:1.1.8-1.1) unstable; urgency=low
+
+  * Non-maintainer upload
+  * Disable XDM-AUTHORIZATION in favour of MIT-MAGIC-COOKIE (closes: #486606)
+
+ -- Ben Hutchings <[EMAIL PROTECTED]>  Sun, 29 Jun 2008 12:23:37 +
+
 xdm (1:1.1.8-1) unstable; urgency=low
 
   * Drop lintian overrides, they're unused anyway.
diff -u xdm-1.1.8/debian/rules xdm-1.1.8/debian/rules
--- xdm-1.1.8/debian/rules
+++ xdm-1.1.8/debian/rules
@@ -16,7 +16,7 @@
 confflags += --with-pam \
--with-xdmconfigdir=/etc/X11/xdm \
--with-xdmscriptdir=\$${xdmconfigdir} \
-   --with-xdmauthdir=/var/lib/xdm \
+   --disable-xdm-auth \
--with-default-vt=vt7 \
--with-pixmapdir=/usr/share/X11/xdm/pixmaps \
--with-color-pixmap=debian.xpm \
--- END ---

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily Tomlin


signature.asc
Description: Digital signature

Bug#486606: xdm:unable to login - XDM authorization key matches an existing client

[Ben Hutchings]

On Sun, Jun 29, 2008 at 04:11:04PM +0200, Brice Goglin wrote:
> Ben Hutchings wrote:
> > In the interim, I made an NMU with the following trivial change.
> >   
> 
> Did you read the bug log before doing so? Julien committed a fix for
> this bug and another one and marked them as pending 5 days ago.

Sorry, I somehow missed the last message until after I uploaded.  However
I don't see that my upload does any harm (nor do I see any reason why
you or Julien could not upload already).

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily Tomlin


signature.asc
Description: Digital signature

Bug#486606: xdm:unable to login - XDM authorization key matches an existing client

[Ben Hutchings]

On Sun, Jun 29, 2008 at 06:24:18PM +0200, Julien Cristau wrote:
> On Sun, Jun 29, 2008 at 15:41:08 +0100, Ben Hutchings wrote:
> 
> > On Sun, Jun 29, 2008 at 04:11:04PM +0200, Brice Goglin wrote:
> > > Ben Hutchings wrote:
> > > > In the interim, I made an NMU with the following trivial change.
> > > >   
> > > 
> > > Did you read the bug log before doing so? Julien committed a fix for
> > > this bug and another one and marked them as pending 5 days ago.
> > 
> > Sorry, I somehow missed the last message until after I uploaded.  However
> > I don't see that my upload does any harm (nor do I see any reason why
> > you or Julien could not upload already).
> > 
> It causes extra work, so if you could in the future avoid 0-day NMUs on
> maintained packages that would be appreciated.  At least for non-RC bugs
> with maintainer activity...

I found this bug as a blocker of #486475, which is RC.  I'm not sure why
it wasn't marked as such or prioritised accordingly.  I've noted the
blocking now.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily Tomlin


signature.asc
Description: Digital signature

Bug#491979: [Fwd: Re: Bug#490601: fails with many xio errors when started from xdm]

[Ben Hutchings]

 Forwarded Message 
From: Ben Hutchings <[EMAIL PROTECTED]>
To: Tuomo Valkonen <[EMAIL PROTECTED]>
Cc: Ion general <[EMAIL PROTECTED]>
Subject: Re: Bug#490601: fails with many xio errors when started from
xdm
Date: Mon, 21 Jul 2008 01:00:41 +0100

I got a report of a weird and unreproducible error in Ion3 startup:
http://bugs.debian.org/490601

BadMatch is not a documented error code for XGetWindowProperty which
sends X_GetProperty requests.  However, the implementation in Xorg
appears to return BadMatch if and only if it's passed a reference to a
drawable that isn't a window:
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blob;hb=8822110d7d6b684f373fc883aeb7cab9734e9ddb;f=dix/dixutils.c#l197

I don't understand how the server coordinates window changes with the
WM.  Is it possible that a window can be completely deleted before the
WM has handled it?  In that case there is presumably a race condition
where a window could disppear and another drawable be created with the
same id.

This seems like a bug in Xorg, but we presumably need to work around it.
The obvious patch is below.

Ben.

--- ion3.orig/ioncore/rootwin.c
+++ ion3/ioncore/rootwin.c
@@ -58,10 +58,11 @@
 static char msg[128], request[64], num[32];
 
 /* Just ignore bad window and similar errors; makes the rest of
- * the code simpler.
+ * the code simpler.  Due to a Xorg bug, window lookups may fail
+ * with BadMatch instead of BadWindow.
  */
 if((ev->error_code==BadWindow ||
-(ev->error_code==BadMatch && ev->request_code==X_SetInputFocus) ||
+ev->error_code==BadMatch ||
 (ev->error_code==BadDrawable && ev->request_code==X_GetGeometry)) &&
ignore_badwindow)
 return 0;
--- END ---

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


signature.asc
Description: This is a digitally signed message part

Bug#491979: X server can return BadMatch to WM instead of BadWindow

[Ben Hutchings]

I would suggest the following change.  This is untested because the
BadWindow or BadMatch error is dependent on a race condition if I
understand correctly.  But it's "obviously correct". :-)

Ben.

--- xorg-server-1.4.2.orig/dix/dixutils.c
+++ xorg-server-1.4.2/dix/dixutils.c
@@ -245,7 +245,7 @@
 {
 int rc;
 rc = dixLookupDrawable((DrawablePtr*)pWin, id, client, M_WINDOW, access);
-return (rc == BadDrawable) ? BadWindow : rc;
+return (rc == BadDrawable || rc == BadMatch) ? BadWindow : rc;
 }
 
 _X_EXPORT int


-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


signature.asc
Description: This is a digitally signed message part

cloning 490601, reassign -1 to xorg-server

[Ben Hutchings]

# Automatically generated email from bts, devscripts version 2.10.34
clone 490601 -1
reassign -1 xorg-server 2:1.4.2-2


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

Bug#421025: XCreateFontSet fails with fixed 13 as first font pattern in UTF-8 environment

[Ben Hutchings]

Package: libx11-6
Version: 2:1.0.3-7
Severity: normal

--- Please enter the report below this line. ---
Test program:

-- BEGIN --
#include 
#include 
#include 

#include 

int main(int argc, char ** argv)
{
Display * display;
XFontSet fs;
char ** missing = 0;
int nmissing;
char * def = 0;
int i;

assert(argc >= 2);
setlocale(LC_ALL, "");
display = XOpenDisplay(0);
assert(display);
fs = XCreateFontSet(display, argv[1], &missing, &nmissing, &def);
assert(fs);
for (i = 0; i != nmissing; ++i)
printf("missing: %s\n", missing[i]);
printf("default: %s\n", def);
return 0;
}
-- END --

Output for various valid locales and font patterns:

$ LC_CTYPE=C ./a.out -*-fixed-*-*-*-*-13-*-*-*-*-*-*-*
default:
$ LC_CTYPE=en_GB ./a.out -*-fixed-*-*-*-*-13-*-*-*-*-*-*-*
default:
$ LC_CTYPE=en_GB.UTF-8 ./a.out -*-fixed-*-*-*-*-13-*-*-*-*-*-*-*
a.out: fontset.c:21: main: Assertion `fs' failed.
Aborted
$ LC_CTYPE=fr_FR.UTF-8 ./a.out -*-fixed-*-*-*-*-13-*-*-*-*-*-*-*
a.out: fontset.c:21: main: Assertion `fs' failed.
Aborted
$ LC_CTYPE=fr_FR.UTF-8 ./a.out -*-fixed-*-*-*-*-13-*-*-*-*-*-*-*,*  # note 
fallback of "*" here
a.out: fontset.c:21: main: Assertion `fs' failed.
Aborted
$ LC_CTYPE=fr_FR.UTF-8 ./a.out -*-fixed-*-*-*-*-14-*-*-*-*-*-*-*
missing: KSC5601.1987-0
missing: GB2312.1980-0
default:
$ LC_CTYPE=fr_FR.UTF-8 ./a.out 
-*-fixed-*-*-*-*-14-*-*-*-*-*-*-*,-*-fixed-*-*-*-*-13-*-*-*-*-*-*-*
missing: KSC5601.1987-0
missing: GB2312.1980-0
default:

Ben.

--- System information. ---
Architecture: i386
Kernel:   Linux 2.6.18-4-686

Debian Release: 4.0
  500 testing shadbolt 
  500 testing mirror 
  100 unstablemirror 

--- Package information. ---
Depends(Version) | Installed
-+-=
libc6   (>= 2.3.6-6) | 2.3.6.ds1-13
libxau6  | 1:1.0.1-2
libxdmcp6| 1:1.0.1-2
libx11-data  | 2:1.0.3-7



signature.asc
Description: This is a digitally signed message part

Bug#421025: XCreateFontSet fails with fixed 13 as first font pattern in UTF-8 environment

[Ben Hutchings]

On Thu, 2007-04-26 at 21:21 +0200, Brice Goglin wrote:
> Seems to works fine here:
> $ LC_CTYPE=fr_FR ./prout '-*-fixed-*-*-*-*-13-*-*-*-*-*-*-*'
> default:
> $ LC_CTYPE=fr_FR.utf8 ./prout '-*-fixed-*-*-*-*-13-*-*-*-*-*-*-*'
> missing: KSC5601.1987-0
> missing: GB2312.1980-0
> default:
> (the other cases get either the first or the second output from above).

Was the fr_FR.utf8 locale actually installed on the test system?  I
found that the test passes for UTF-8 locales that aren't actually
installed.

> Could you try to debug a little bit and see while it fails?

I don't know where to look.  strace shows no system call failures, but
it can dump the X protocol conversation (-e read=3 -e write=3).  Would
that be useful?

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


signature.asc
Description: This is a digitally signed message part

Bug#421025: XCreateFontSet fails with fixed 13 as first font pattern in UTF-8 environment

[Ben Hutchings]

On Fri, 2007-04-27 at 00:46 +0200, Brice Goglin wrote:
> Brice Goglin wrote:
> > I was rather thinking of locating where this assertion is (I don't see
> > it in libx11, strace/gdb might help to locate the library or binary
> > where it comes from). And then try to understand where the error comes
> > from by either reading the corresponding code, or adding some debug
> > printf. Not very easy...
> >   
> 
> I might have been drinking too much lately since the assertion is in
> your program, not in fontset.c in a lib :)
> 
> Now we have to understand why the code at the URL below returns NULL:
> http://git.debian.org/?p=pkg-xorg/lib/libx11.git;a=blob;f=src/FSWrap.c;h=10634ceecae26eab5306507cadda2181019ae2be;hb=HEAD#l167
> 
> That would be either XOpenOM returning NULL,

Doesn't depend on the font name.

> or XCreateOC returning NULL,

It's got to be that one.

>  or list->charset_list && *missing_charset_list == NULL...

If list->charset_list != NULL and list->charset_count == 0, the Xmalloc
call in copy_string_list might return NULL (I don't know whether it
supports a size of 0), causing copy_string_list and XCreateFontSet() to
return NULL.  This seems unlikely to be triggered only by the exact font
pattern lists I identified though.

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.


signature.asc
Description: This is a digitally signed message part

Bug#383465: Replacement of xserver-xorg-video-nv

[Ben Hutchings]

Is nouveau likely to be in good enough shape to replace nv for squeeze?

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.


signature.asc
Description: This is a digitally signed message part

Re: loading kernel mode setting drivers

[Ben Hutchings]

On Mon, 2010-01-25 at 00:56 +0100, Julien Cristau wrote:
> On Tue, Jan 12, 2010 at 01:34:45 +0100, Marco d'Itri wrote:
> 
> > On Jan 12, Julien Cristau  wrote:
> > 
> > > Marco, what do you think of switching to this, or at least using its fb
> > > part?
> > I do not mind explicitly blacklisting each fb driver, but I would like
> > to have a way to semi-automatically generate the list. Is there any?
> > 
> I suppose something like
> find /lib/modules/$(uname -r)/kernel/drivers/video -type f|while read
> mod; do echo blacklist $(basename $mod .ko); done
> could work (possibly excluding some generic and backlight drivers, if
> those should be autoloaded?).

What about my suggestion of removing the MODULE_DEVICE_TABLE
declarations from fb modules, so they do not appear in modules.pcimap
etc?  Did you see any problem with that?

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.


signature.asc
Description: This is a digitally signed message part

Re: loading kernel mode setting drivers

[Ben Hutchings]

Julien Cristau wrote:
> On Mon, Jan 25, 2010 at 00:27:48 +0000, Ben Hutchings wrote:
> 
> > What about my suggestion of removing the MODULE_DEVICE_TABLE
> > declarations from fb modules, so they do not appear in modules.pcimap
> > etc?  Did you see any problem with that?
> > 
> Dropping those and udev's blacklist would be fine as far as I'm
> concerned.  Not sure what this means for people with custom kernel,
> since they'd lose the blacklist too, but I don't care much either way.

I suppose we don't really want this level of coupling between udev and
the kernel.  So I'm happy to recommend your recipe to Marco, but with a
restriction to PCI drivers:

find /lib/modules/$(uname -r)/kernel/drivers/video -type f | {
while read mod; do
/sbin/modinfo $mod | grep -q '^alias: *pci' \
        && echo blacklist $(basename $mod .ko)
done
}

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.


signature.asc
Description: This is a digitally signed message part

Bug#569103: Uses obsolete V4L1 API

[Ben Hutchings]

Package: xserver-xorg-video-v4l
Version: 3.95.dfsg.1-8.1
Severity: serious

The V4L1 API is obsolete and does not work with most new V4L drivers.
You can use libv4l as an emulation layer; see
.

Ben.

-- System Information:
Debian Release: squeeze/sid
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: i386 (x86_64)

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

Versions of packages xserver-xorg-video-v4l depends on:
ii  libc6 2.10.2-5   Embedded GNU C Library: Shared lib
ii  xserver-xorg-core 2:1.7.4-2  Xorg X server - core server

xserver-xorg-video-v4l recommends no packages.

xserver-xorg-video-v4l suggests no packages.



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

Re: [ubuntu-x] Status of kernel X drivers

[Ben Hutchings]

On Thu, 2010-02-18 at 14:40 -0800, Bryce Harrington wrote:
[...]
> From apw's Kernel Summary, about why we are going with 2.6.32:
> 
>   The primary decision for the kernel team at UDS is to choose the base
>   kernel version for the release.  For Lucid this will be 2.6.32.  This
>   version has just released providing the maximum stabalisation time, it
>   also is expected to be the kernel of choice for long term releases
>   from other distributions.[1]
> 
> If other distros are pulling the 2.6.33 drm on top of their 2.6.32 for
> their long term releases as sounds like is the case[2], then this would
> be a fairly significant divergence on our part for no real gain.
[...]
> 2: 
> http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-12/drm-upgrayedd.patch?view=log

Fedora has been backporting drm (and nouveau) for a long time but it's
not so clear what means for RHEL.

I think this is something we will also consider doing in Debian.  A year
from now I expect nv to be dead and radeon UMS to be removed upstream,
making it impractical to backport new hardware support.  Given that, the
maintenance burden for 2.6.33 drm should be lower.  But this is really
outside my area of expertise and certainly not my decision to make.

We should probably also consider what this means for drm on the
2.6.32-stable branch.  Should the drm developers still send patches
there as well, where applicable?  If all the distributions using 2.6.32
use the backported drm, should we ask Greg K-H to pull that?

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.


signature.asc
Description: This is a digitally signed message part

Re: [ubuntu-x] Status of kernel X drivers

[Ben Hutchings]

On Sun, 2010-02-21 at 23:20 +, Ben Hutchings wrote:
[...]
> I think this is something we will also consider doing in Debian.  A year
> from now I expect nv to be dead and radeon UMS to be removed upstream,
> making it impractical to backport new hardware support.  Given that, the
> maintenance burden for 2.6.33 drm should be lower.  But this is really
> outside my area of expertise and certainly not my decision to make.

I understand that the X maintainers would be happy with this.  Do I hear
any objections from the kernel team?

> We should probably also consider what this means for drm on the
> 2.6.32-stable branch.  Should the drm developers still send patches
> there as well, where applicable?  If all the distributions using 2.6.32
> use the backported drm, should we ask Greg K-H to pull that?

This is yet to be considered.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
   Among economists, the real world is often a special case.


signature.asc
Description: This is a digitally signed message part

Re: Bug#572067: linux-libc-dev: Can not install, file conflict with libdrm

[Ben Hutchings]

On Mon, 2010-03-01 at 13:50 +0100, Jens-Michael Hoffmann wrote:
> Package: linux-libc-dev
> Version: 2.6.33-1~experimental.2
> Severity: normal
> 
> When trying to install linux-libc-dev from experimental, dpkg shows the 
> following error message:
> 
> dpkg: error processing 
> /var/cache/apt/archives/linux-libc-dev_2.6.33-1~experimental.2_amd64.deb 
> (--unpack):
>  trying to overwrite '/usr/include/drm/nouveau_drm.h', which is also in 
> package libdrm-dev 0:2.4.18-2

It makes no sense to have the DRM headers split between libdrm-dev and
linux-libc-dev.  I'm happy to have libdrm-dev provide them all.  What do
you want to do?

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.


signature.asc
Description: This is a digitally signed message part

Bug#572067: Processed: reassign 572592 to linux-libc-dev, forcibly merging 572067 572592

[Ben Hutchings]

On Fri, 2010-03-05 at 19:37 +0100, Bastian Blank wrote:
> reassign 572067 libdrm-dev
> thanks
> 
> The linux kernel is source of the drm headers in the meantime.

It *is*, but it shouldn't be.  Let's fix this now.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg


signature.asc
Description: This is a digitally signed message part

Re: Bug#572067: linux-libc-dev: Can not install, file conflict with libdrm

[Ben Hutchings]

On Fri, 2010-03-05 at 10:59 +0100, Julien Cristau wrote:
> On Fri, Mar  5, 2010 at 04:03:15 +0000, Ben Hutchings wrote:
> 
> > On Mon, 2010-03-01 at 13:50 +0100, Jens-Michael Hoffmann wrote:
> > > Package: linux-libc-dev
> > > Version: 2.6.33-1~experimental.2
> > > Severity: normal
> > > 
> > > When trying to install linux-libc-dev from experimental, dpkg shows the 
> > > following error message:
> > > 
> > > dpkg: error processing 
> > > /var/cache/apt/archives/linux-libc-dev_2.6.33-1~experimental.2_amd64.deb 
> > > (--unpack):
> > >  trying to overwrite '/usr/include/drm/nouveau_drm.h', which is also in 
> > > package libdrm-dev 0:2.4.18-2
> > 
> > It makes no sense to have the DRM headers split between libdrm-dev and
> > linux-libc-dev.  I'm happy to have libdrm-dev provide them all.  What do
> > you want to do?
> > 
> I think we should go back to libdrm-dev installing the headers.  I sent
> a patch to dri-devel a few days ago that makes libdrm install its
> headers in $(includedir)/libdrm so they don't conflict with the ones
> installed by the kernel, waiting for some feedback on that…

I have committed changes to remove /usr/include/drm from linux-libc-dev.
Please give libdrm-dev a versioned dependency on linux-libc-dev
(>= 2.6.32-10).

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


signature.asc
Description: This is a digitally signed message part

Re: Packagaing nouveau firmware

[Ben Hutchings]

On Fri, 2010-03-26 at 18:43 +0100, Sven Joachim wrote:
> On 2010-03-26 16:26 +0100, Ben Hutchings wrote:
> 
> > On Fri, 2010-03-26 at 10:51 +0100, Sven Joachim wrote:
> >> Thanks for the explanation.  Speaking of the firmware, is anyone working
> >> on packaging it?  Ubuntu has a package¹ in multiverse which works fine
> >> for me and could be used as a base, although it should probably named
> >> firmware-nouveau for consistency.
> > [...]
> >
> > I'll have a look at that.  I heard there were some concerns about
> > licencing a while back, as they were apparently large blobs extracted
> > from the Nvidia drivers and might be copyrightable.
> 
> They are not that large compared to the whole Nvidia driver (biggest
> file is 33K), but they might be copyrightable.  The debian/copyright
> file of the Ubuntu package says:
> 
>  These files are firmware-like programs for initialising GPU 
> context-switching.
>  They were extracted from memory-mapped IO traces of the nvidia binary driver
>  initialising the hardware.  They were not generated by reverse-engineering 
> the
>  source code of the binary driver.
>  .
>  It is unclear to me whether these files are actually copyrightable.  It seems
>  that these programs are likely to be generated by the driver at runtime 
> rather
>  than being hand-written.  The nouveau driver takes this approach for nv4x
>  cards.  If they are copyrightable, they should fall under the nvidia binary
>  driver's licence, below.
> 
> Followed by the text of the actual license.  Since Nvidia does not
> distribute the files themselves and their license only allows
> redistribution of unmodified files, it seems that if the files are
> copyrightable they are also undistributable, but I'm no legal expert.

I think this is legally risky and ftpmaster will probably not allow it.

> > Do you know what happened about that?
> 
> The latest thing I could find is a thread on the ubuntu-x list in
> February, starting at
> https://lists.ubuntu.com/archives/ubuntu-x/2010-February/000773.html.
> I don't know if any progress has been made since then.
> 
> An alternative to the nouveau-firmware package would be to backport
> Marcin Kościelnicki's ctxprogs generator that is included in 2.6.34.
> It generates the GPU initialization data on the fly, so no firmware is
> needed.

Right, I think we may have to do that.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: Packagaing nouveau firmware

[Ben Hutchings]

On Mon, 2010-03-29 at 07:23 +0200, Sven Joachim wrote:
> On 2010-03-29 03:36 +0200, Ben Hutchings wrote:
> 
> > On Fri, 2010-03-26 at 18:43 +0100, Sven Joachim wrote:
> >> Followed by the text of the actual license.  Since Nvidia does not
> >> distribute the files themselves and their license only allows
> >> redistribution of unmodified files, it seems that if the files are
> >> copyrightable they are also undistributable, but I'm no legal expert.
> >
> > I think this is legally risky and ftpmaster will probably not allow it.
> 
> Yeah.  I'll mention this problem in xserver-xorg-video-nouveau's
> README.Debian and include a script to download and install the firmware.

I don't think you need to mention it.

> >> An alternative to the nouveau-firmware package would be to backport
> >> Marcin Kościelnicki's ctxprogs generator that is included in 2.6.34.
> >> It generates the GPU initialization data on the fly, so no firmware is
> >> needed.
> >
> > Right, I think we may have to do that.
> 
> Actually, that generator is only for NV50 cards (for NV40 cards there is
> already a generator in 2.6.33), which is what I have here.  I don't know
> if there are any other supported cards which still need external
> firmware.

After this change, external firmware/ctxprogs are optional for all cards
(it will only be used if you set module parameter nouveau_ctxfw=1).

> Commit d5f3c90d4f3ad6b054f9855b7b69137b97bda131 is what you would need
> to cherry-pick.  I applied this to the 2.6.33.1 kernel, and the result
> seems to work fine (I'm using it right now).  This also gets rid of any
> MODULE_FIRMWARE stuff, making it possible to include nouveau.ko in the
> intitramfs without hitting #575241. :-)

I have cherry-picked that and a couple of following bug fixes.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Bug#576393: qemu-kvm provokes segfault in X server

[Ben Hutchings]

Package: xserver-xorg
Version: 1:7.5+5
Severity: important

I've been exercising graphics in qemu-kvm a bit more and have seen the
host's X server crash a couple of times.  I expect I can reproduce it
again if you want me to gather more information.

The backtrace from Xorg.0.log.old is:

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x3b) [0x80ad72b]
1: /usr/bin/X (0x8048000+0x5a8a5) [0x80a28a5]
2: (vdso) (__kernel_rt_sigreturn+0x0) [0xf7770410]
3: /usr/bin/X (mieqProcessDeviceEvent+0xb9) [0x809fd29]
4: /usr/bin/X (mieqProcessInputEvents+0x6c) [0x809feac]
5: /usr/bin/X (ProcessInputEvents+0x17) [0x80b1437]
6: /usr/bin/X (0x8048000+0x2be40) [0x8073e40]
7: /usr/bin/X (0x8048000+0x1e93a) [0x806693a]
8: /lib/i686/cmov/libc.so.6 (__libc_start_main+0xe5) [0xf74a3b55]
9: /usr/bin/X (0x8048000+0x1e521) [0x8066521]
Segmentation fault at address 0x64

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting

Ben.

-- 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 Mar 18  2009 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1712764 Mar 23 22:13 /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 Mobile GM965/GL960 
Integrated Graphics Controller (rev 0c)

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

Xorg X server configuration file status:
-rw-r--r-- 1 root root 2802 Feb 13 16:40 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
InputDevice"nipple" "CorePointer"
InputDevice"touchpad" "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  "glx"
Load  "record"
Load  "dri"
Load  "extmod"
Load  "dbe"
Load  "dri2"
EndSection

Section "InputDevice"
Identifier  "Keyboard0"
Driver  "kbd"
EndSection

Section "InputDevice"
Identifier  "nipple"
Driver  "mouse"
Option  "Protocol" "auto"
Option  "Device" "/dev/input/mouse0"
Option  "ZAxisMapping" "4 5 6 7"
EndSection

Section "InputDevice"
Identifier  "touchpad"
Driver  "synaptics"
Option  "Protocol" "events"
Option  "Device" "/dev/input/mouse1"
Option  "SHMConfig" "on"
EndSection

Section "Monitor"
Identifier   "Monitor0"
VendorName   "Monitor Vendor"
ModelName"Monitor Model"
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" # []
#Option "ShowCache" # []
#Option "XvMCSurfaces"  # 
#Option "PageFlip"  # []
Identifier  "Card0"
Driver  "intel"
VendorName  "Intel Corporation"
BoardName   "Mobile GM965/GL960 Integrated Graphics Controller"
BusID   "PCI:0:2:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor0"
SubSection "Display"
Viewport   0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 24
EndSubSection
EndSection



Xorg X server log files on system:
-rw-r--r-- 1 root root 49555 Dec 28 15:56 /var/log/Xo

Bug#576393: qemu-kvm provokes segfault in X server

[Ben Hutchings]

x27;\000', name = 0}, {
min = 0, max = 0, resolution = 0, mode = 0 '\000', name = 0}, {
min = 0, max = 0, resolution = 0, mode = 0 '\000', name = 0}, {
min = 0, max = 0, resolution = 0, mode = 0 '\000', name = 0}, {
min = 0, max = 0, resolution = 0, mode = 0 '\000', name = 0}, {
min = 0, max = 136180172, resolution = 0, mode = 240 '\360', 
name = 4290973000}, {min = 0, max = 4290972976, 
resolution = 4149291337, mode = 204 '\314', name = 134919401}, {
min = 0, max = 4290972976, resolution = 0, mode = 0 '\000', name = 0}, 
  {min = 2, max = 0, resolution = 2, mode = 153 '\231', 
name = 136180172}, {min = 4290973624, max = 134876191, resolution = 1, 
mode = 160 '\240', name = 0}, {min = 0, max = 4290973588, 
resolution = 4149174493, mode = 134 '\206', name = 4147530204}, {
min = 136180172, max = 166689704, resolution = 4290973080, 
mode = 113 'q', name = 32}, {min = 1, max = 4290973460, 
resolution = 0, mode = 7 '\a', name = 0}, {min = 0, max = 0, 
resolution = 0, mode = 0 '\000', name = 0} , {
min = 0, max = 0, resolution = 0, mode = 221 '\335', name = 32}, {
min = 136180172, max = 32, resolution = 171135424, mode = 200 '\310', 
name = 135140110}, {min = 32, max = 4290973496, resolution = 1, 
mode = 71 'G', name = 4290973400}, {min = 136180172, max = 4290973416, 
resolution = 171140088, mode = 192 '\300', name = 4290973496}, {
min = 1, max = 134784785, resolution = 169790576, mode = 8 '\b', 
name = 4150038516}, {min = 4150043584, max = 1800, 
resolution = 4290973480, mode = 221 '\335', name = 1800}, {min = 1800, 
max = 171666976, resolution = 1792, mode = 0 '\000', 
name = 171140088}, {min = 1800, max = 4149178635, 
resolution = 136180172, mode = 0 '\000', name = 136242656}}, keys = {
  min_keycode = -3993784, max_keycode = 134919875}}, dga_event = {
header = 192 '\300', type = 0, length = 0, time = 0, subtype = -3995384, 
detail = -3995540, dx = -3995544, dy = -143487417, screen = 145827528, 
state = 10100}, raw_event = {header = 192 '\300', type = 0, length = 0, 
time = 0, deviceid = -3995384, sourceid = -3995540, detail = {
  button = 4290971752, key = 4290971752}, valuators = {
  mask = "G\216r\367", , data = {145827700, 
145827636, 134943200, 145827636, 1, 145827528, 172325888, 0, 
-146942328, 0, -143487487, 172325888, 892, 1024, 
0 }, data_frac = {0 , 145827636, 
167522360, 135587579, 32, 32, -144928780, -3993944, -143223808, 29, 
99, 0, 43, 43, -144928780, 32, -3993944, -3993980, 32, 1, -3993800, 
32, 0, 0, -143223760, 35}, data_raw = {2110102, -3993980, 43, 
-3994604, 0, 0, -147770984, 172098632, 172099432, -3995160, 
-147910644, 172098632, 172099432, 330, 18, 1, -3995120, 0, -143558622, 
171500120, 1, 171569982, 0, -3994100, -3995120, -147935973, 136180172, 
4, -3995120, -3994072, 0, 7845976, -2134048768, 330, 18, 1}, 
  data_raw_frac = {-3995120, -64641, -65248, -1, 136004405, 16, 0, 43, 0, 
0, 0, 0, 0, 0, -2147483648, 49167, 0, 1073709056, 0, -939524096, 
16387, 0, 0, 0, -1938948096, 49166, 0, -1072788370, 288, 18875263, 0, 
136004405, 0, 0, 0, 8064
(gdb) up
#2  0x0809feac in mieqProcessInputEvents () at ../../mi/mieq.c:471
471 in ../../mi/mieq.c
(gdb) info locals
e = 
evlen = 
screen = 0x8b15368
event = 0xa336400
dev = 0xa332418
(gdb) up
#3  0x080b1437 in ProcessInputEvents ()
at ../../../../hw/xfree86/common/xf86Events.c:165
165 ../../../../hw/xfree86/common/xf86Events.c: No such file or directory.
in ../../../../hw/xfree86/common/xf86Events.c
(gdb) info locals
x = 136180172
y = 134914603
(gdb) up
#4  0x08074040 in Dispatch () at ../../dix/dispatch.c:407
407 ../../dix/dispatch.c: No such file or directory.
in ../../dix/dispatch.c
(gdb) info locals
result = 
client = 0xa375870
nready = 0
start_tick = 1340
(gdb) up
#5  0x0806693a in main (argc=9, argv=0xffc31114, envp=0xffc3113c)
at ../../dix/main.c:285
285 ../../dix/main.c: No such file or directory.
in ../../dix/main.c
(gdb) info locals
i = 
alwaysCheckForInput = {0, 1}

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Bug#616301: xserver-xorg-video-radeon:screen goes black, system hangs after 2sec:[youtube(FF/Opera)-reset req.]

[Ben Hutchings]

On Fri, 2011-03-04 at 21:01 +0200, Faidon Liambotis wrote:
> severity 616301 critical
> thanks

No, not unless it will affect a large proportion of users.

> My system locks up whenever I click on a YouTube video link since
> yesterday. I can probably live without YouTube :), but in any case this
> shouldn't happen.
> 
> This isn't a singled out case nor in exotic, possibly faulty, hardware.
> It's on a standard 1½-year old Dell OptiPlex 780 desktop with a Radeon
> HD card (one of the standard configurations) and this is on a stock
> squeeze system.
> 
> The findings so far seem to suggest this is a Mesa issue; I'd probably
> file it under "Linux kernel bugs" (or even DoS bugs) but I'm not sure
> where to properly file such bugs in the post-KMS stack world.

If there is a kernel driver involved then it should be assigned to the
kernel.  Even without KMS, a Mesa driver should be considered untrusted
and should not be able to trigger a crash or hang.  With KMS, this
applies to the X driver too.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: Bug#616093: Possible Solution

[Ben Hutchings]

On Thu, 2011-03-03 at 16:13 +0100, Martin Künstner wrote:
> Hello,
> 
> after searching for "QFont::fromString: Invalid description 'Sans
> Serif,10,5,0,50,0'"
> 
> I found that i have to install ibus.
> 
> After installing ibus everything now works for me.

Going back to your original message (which I didn't see before, as this
bug was reassigned):

> on the file open dialog libre office get stuck and the whole system gets 
> frozen
> no user interaction is possible any more
> mous is moving but every otner action is no more possible
> you cant even change to console via STRG+F1

You need to use the Alt key as well.

> system is not more responding

This really sounds like LibreOffice (or more likely an extension to LO)
has grabbed and then not released the keyboard and mouse.  Applications
can override normal window focus temporarily ('grab') for purposes like
drag-and-drop, but unfortunately this is not automatically released when
you release the mouse buttons.  If an application fails to release its
grab it can effectively break the entire desktop session in the way you
described.  However, the console switching keystrokes should still work.
Could you temporarily remove ibus and test that Strg-Alt-F1 works when
the system is in this state?

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: Bug#616093: Possible Solution

[Ben Hutchings]

On Sun, 2011-03-06 at 17:13 +0100, Martin Künstner wrote:
> Am Sonntag, den 06.03.2011, 15:54 + schrieb Ben Hutchings:
> > On Thu, 2011-03-03 at 16:13 +0100, Martin Künstner wrote:
> > > Hello,
> > > 
> > > after searching for "QFont::fromString: Invalid description 'Sans
> > > Serif,10,5,0,50,0'"
> > > 
> > > I found that i have to install ibus.
> > > 
> > > After installing ibus everything now works for me.
> > 
> > Going back to your original message (which I didn't see before, as this
> > bug was reassigned):
> > 
> > > on the file open dialog libre office get stuck and the whole system gets 
> > > frozen
> > > no user interaction is possible any more
> > > mous is moving but every otner action is no more possible
> > > you cant even change to console via STRG+F1
> > 
> > You need to use the Alt key as well.
> > 
> > > system is not more responding
> > 
> > This really sounds like LibreOffice (or more likely an extension to LO)
> > has grabbed and then not released the keyboard and mouse.  Applications
> > can override normal window focus temporarily ('grab') for purposes like
> > drag-and-drop, but unfortunately this is not automatically released when
> > you release the mouse buttons.  If an application fails to release its
> > grab it can effectively break the entire desktop session in the way you
> > described.  However, the console switching keystrokes should still work.
> > Could you temporarily remove ibus and test that Strg-Alt-F1 works when
> > the system is in this state?
> 
> I meant Strg-Alt-F1
> and it did not respond. 
> 
> The system does not respond at all:
> even Strg-Alt-Backspace to Kill X

Well, that key combination is now disabled by default.

> or Strg-Alt-F1 to F6 did do anything.
> Everything is blocked.

OK, that does sound like something more serious than an unreleased grab.
But I cannot see what difference ibus could make.

> I think the BUG is in KDM.

I don't think so.  kdm gets out of the way once you have logged in.

Ben.

> In this log file i found the log message
> "QFont::fromString: Invalid description 'Sans Serif,10,5,0,50,0'


-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Bug#616301: xserver-xorg-video-radeon:screen goes black, system hangs after 2sec:[youtube(FF/Opera)-reset req.]

[Ben Hutchings]

On Sun, 2011-03-06 at 13:08 -0500, Alex Deucher wrote:
> On Fri, Mar 4, 2011 at 8:50 PM, Ben Hutchings  wrote:
> > On Fri, 2011-03-04 at 21:01 +0200, Faidon Liambotis wrote:
> >> severity 616301 critical
> >> thanks
> >
> > No, not unless it will affect a large proportion of users.
> >
> >> My system locks up whenever I click on a YouTube video link since
> >> yesterday. I can probably live without YouTube :), but in any case this
> >> shouldn't happen.
> >>
> >> This isn't a singled out case nor in exotic, possibly faulty, hardware.
> >> It's on a standard 1½-year old Dell OptiPlex 780 desktop with a Radeon
> >> HD card (one of the standard configurations) and this is on a stock
> >> squeeze system.
> >>
> >> The findings so far seem to suggest this is a Mesa issue; I'd probably
> >> file it under "Linux kernel bugs" (or even DoS bugs) but I'm not sure
> >> where to properly file such bugs in the post-KMS stack world.
> >
> > If there is a kernel driver involved then it should be assigned to the
> > kernel.  Even without KMS, a Mesa driver should be considered untrusted
> > and should not be able to trigger a crash or hang.  With KMS, this
> > applies to the X driver too.
> >
> 
> With or without KMS, the userspace acceleration drivers can certainly
> cause GPU hangs if the 3D engine is programmed with some combination
> of commands it doesn't like.

You can't solve the halting problem but you can implement a watchdog,
can't you?

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Bug#616301: xserver-xorg-video-radeon:screen goes black, system hangs after 2sec:[youtube(FF/Opera)-reset req.]

[Ben Hutchings]

On Sun, 2011-03-06 at 19:49 -0500, John D. Hendrickson and Sara Darnell
wrote:
> I haven't heard of many chips that won't hang given the wrong 
> instructsion whether it's GPU or keyboard controller.

Of course.  This is why the kernel driver filters the commands going to
the GPU - the commands come from unprivileged applications (the Mesa
driver is just a shared library) and should not be trusted.

> Sounds like more 
> than a driver issue but a choice of driver issue.  How are you going to 
> have it both ways without an ammount of care you have no time for?
> 
> having interrupting access / watchdog is nice if your driver can do that
> 
> Ben Hutchings wrote:
[...]

Don't top-post.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: iMac-G3 fails to boot with 2.6.37-1-powerpc (Bug#614221)

[Ben Hutchings]

On Sat, 2011-03-05 at 20:43 +, Ben Hutchings wrote:
[...]
> * Has anyone tested 2.6.37-{1,2} on a non-Mac system yet, and does
> vga16fb work there?

I'm still interested in the answer to this.

[...]
> * Could some Mac users test and report whether i915 or nouveau can
> successfully take over the display from offb in 2.6.37 or 2.6.38-rc6?

i915 on a powerpc, eh?  What was I thinking?

I've now talked briefly to the DRI and powerpc upstream maintainers, and
the answer is that radeon is mostly broken on at least 32-bit powerpc
while nouveau is in better shape but not quite stable yet.  So I'm going
to revert most of the FB configuration changes I made in 2.6.37-1 for
the next upload to unstable.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Bug#635137: Sometimes hangs after suspend & resume

[Ben Hutchings]

Package: compiz
Version: 0.8.4-4
Severity: important

After suspending and resuming my laptop (Thinkpad T61 with Intel GM965
GPU) compiz sometimes appears to hang, leaving the X display blank
except for the mouse pointer.

The kernel, GPU and X server are still working: the mouse pointer is
responsive and I can switch between virtual consoles.  I can recover
by stopping compiz (kill -9) and starting it again.

Next time this happens, I will try to attach to compiz with gdb.  It
might be helpful to build a debug symbol package so that I can provide
more details.

Ben.

-- System Information:
Debian Release: wheezy/sid
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (x86_64)

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

Versions of packages compiz depends on:
ii  compiz-core   0.8.4-4OpenGL window and compositing mana
ii  compiz-gnome  0.8.4-4OpenGL window and compositing mana
ii  compiz-gtk0.8.4-4OpenGL window and compositing mana
ii  compiz-plugins0.8.4-4OpenGL window and compositing mana

compiz recommends no packages.

Versions of packages compiz suggests:
ii  compizconfig-settings-manager 0.8.4-2Compizconfig Settings Manager

-- 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/2011071127.15192.32358.reportbug@localhost

Re: Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Ben Hutchings]

273d0b501ea64d7b719acafc93a5b7fa
> 
> As a side note, keeping the bundling in src:debian-installer for the
> next few weeks makes us autonomous: we can enable and disable those
> extra modules without requiring a new linux upload… so it's nasty but I
> actually thought about the few advantages we were getting out of this!
> 
> We should also be OK legal-wise, given we already have linux in
> Built-Using via its udebs, so copying things around from linux-image
> wouldn't change anything there, would it?
> 
> Of course in the long run, if having those modules is desired, it will
> be better to have them merged in linux and to drop the nasty code, e.g.
> in a point release.
[...]

Definitely.

I will spend some time investigating this, but I doubt I'll come up
with a better fix in time.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


signature.asc
Description: This is a digitally signed message part

Re: Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Ben Hutchings]

Control: tag -1 patch

On Sun, 2023-05-14 at 00:21 +0200, Ben Hutchings wrote:
[...]
> So I suppose there's a regression in either efifb or fbdev_drv.

I'm not spotting any functional changes in fbdev or the submodules it
depends on between bullseye and bookworm.  So this implicates either
efifb or, as you mentioned, GRUB.

> > Via QEMU, under BIOS and UEFI, results are:
> > 
> >   +-+-+-+-+
> >   |  Graphics   |  Bullseye 11.7  |  Bookworm RC 2  |  Daily builds   |
> >   +-+++++++
> >   | |  BIOS  |  UEFI  |  BIOS  |  UEFI  |  BIOS  |  UEFI  |
> >   +-+++++++
> >   | |   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
> >   | -vga std|   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
> >   | -vga cirrus |   OK   |   OK   |   OK   |  KO-S  |   OK   |  KO-S  |
> >   | -vga qxl|   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   | -vga virtio |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   | -vga vmware |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   +-+++++++
> 
> I started testing with QEMU and OVMF from unstable, and I'm instead
> seeing Xorg failing to start in the same cases you see glitches.  The
> relevant error message seems to be this one:
> http://codesearch.debian.net/show?file=xorg-server_2%3A21.1.7-3%2Fhw%2Fxfree86%2Ffbdevhw%2Ffbdevhw.c&line=504
[...]

I tested with QEMU from bullseye and OVMF from unstable, and again I
saw Xorg failing to start, rather than glitches.  Weird.

I also patched the kernel to report the internal screen_info structure
and the fb_var_screeninfo structure passed in and out of
FBIOPUT_VSCREENINFO.  The key difference is:

- With -vga qxl, screen_info says 32 bpp, X wants 32 bpp, the kernel
  agrees with that.
- With -vga std or -vga cirrus screen_info says 24 bpp, X wants 32
  bpp, and the kernel says 24 bpp.

I think the problem is this GRUB has native drivers for Bochs and
Cirrus that reprogram the framebuffer bit depth, and the kernel is then
confused about what the bit depth is supposed to be.  With QXL, GRUB
doesn't have a native driver so it doesn't reconfigure the framebuffer.

Unfortunately, with Secure Boot we have to use a monolithic GRUB build
so I can't easily exclude video_bochs and video_cirrus to see if that
improves matters.

But what does works for me is:

--- a/build/boot/x86/grub/grub-efi.cfg
+++ b/build/boot/x86/grub/grub-efi.cfg
@@ -5,7 +5,7 @@ else
 fi
 
 if loadfont $font ; then
-  set gfxmode=800x600
+  set gfxmode=800x600x32
   set gfxpayload=keep
   insmod efi_gop
   insmod efi_uga
--- END ---

A full patch is attached.

This works for me with all the QEMU graphics devices.  But I haven't
tested on real hardware.


Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
From 49a5e562850e3ae4f64ed2d61bd582d8adedc393 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Sun, 14 May 2023 19:17:45 +0200
Subject: [PATCH] Always use 32 bpp for GRUB EFI graphical menu (Closes:
 #1036019)

---
 build/boot/x86/grub/grub-efi.cfg | 2 +-
 debian/changelog | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/build/boot/x86/grub/grub-efi.cfg b/build/boot/x86/grub/grub-efi.cfg
index 0a9a67d48..14708c7bc 100644
--- a/build/boot/x86/grub/grub-efi.cfg
+++ b/build/boot/x86/grub/grub-efi.cfg
@@ -5,7 +5,7 @@ else
 fi
 
 if loadfont $font ; then
-  set gfxmode=800x600
+  set gfxmode=800x600x32
   set gfxpayload=keep
   insmod efi_gop
   insmod efi_uga
diff --git a/debian/changelog b/debian/changelog
index 4624187fe..6be6864b5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,12 @@
 debian-installer (20230428) UNRELEASED; urgency=medium
 
+  [ Cyril Brulebois ]
   * Bump Linux kernel ABI to 6.1.0-9.
   * Switch source format from 1.0 to 3.0 (native).
 
+  [ Ben Hutchings ]
+  * Always use 32 bpp for GRUB EFI graphical menu (Closes: #1036019)
+
  -- Cyril Brulebois   Thu, 27 Apr 2023 22:52:15 +0200
 
 debian-installer (20230427) unstable; urgency=medium


signature.asc
Description: This is a digitally signed message part

Re: Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Ben Hutchings]

On Sun, 2023-05-14 at 19:40 +0200, Ben Hutchings wrote:
[...]
> This works for me with all the QEMU graphics devices.  But I haven't
> tested on real hardware.

Now tested successfully on 2 custom desktops:

- Asus P8Z68-V LX motherboard, Intel Core i5 2500 CPU, integrated GPU
- ASRock B450 PRO4, AMD Ryzen 5 3600 CPU, Radeon RX580 GPU

and 2 laptops:

- Lenovo ThinkPad T420, Intel Core i5 2nd gen CPU, integrated GPU
- Lenovo ThinkPad T460, Intel Core i5 6th gen CPU, integrated GPU

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


signature.asc
Description: This is a digitally signed message part

Bug#333273: xvfb: Uses incorrect line padding when depth>8

[Ben Hutchings]

reopen 333273
close 333273 1:1.0.2-8.1

Brice Goglin wrote:
> I think this has been fixed in upstream XFree86 right after 4.3.0 got
> released. So it's probably fixed in Xorg nowadays.

Agreed.  I can see the bug fix in Xorg's git tree way back in 2003 (!)
and have verified this fix in the current version in Debian.  Therefore
I'm closing this with the first version number for xorg-server in
Debian.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


signature.asc
Description: This is a digitally signed message part

Bug#333273: xvfb: Uses incorrect line padding when depth>8

[Ben Hutchings]

Package: xvfb
Version: 4.3.0.dfsg.1-14sarge1
Severity: important

According to the Xvfb manual page, the -fbdir option can be used to
make it expose its framebuffer in X window dump format.  However, if
it is run with a depth of 32, the bytes_per_line member of the
XWDHeader structure is set to 4 * width but each line is actually
padded to 16 * width.  Similarly, if it is run with a depth of 16,
bytes_per_line is set to 2 * width but lines are padded to 4 * width.
This makes the feature quite useless.  It is, however, possible to
generate correct window dumps using xwd -root.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages xvfb depends on:
ii  libc6  2.3.2.ds1-22  GNU C Library: Shared libraries an
ii  libfreetype6   2.1.7-2.4 FreeType 2 font engine, shared lib
ii  xfree86-common 4.3.0.dfsg.1-14   X Window System (XFree86) infrastr
ii  zlib1g 1:1.2.2-4.sarge.2 compression library - runtime

-- no debconf information


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