Bug#724944: [Intel-gfx] Patch for crashing intel server

2013-11-03 Thread Bas Wijnen 
Hi Chris,

I got a black screen while using your patch.
/sys/kernel/debug/dri/0/i915_gem_objects contents are shown below.  The first
time is while the video is running; the second after stopping it.  AFAICS,
there is no difference between them.

However, after starting a new video, there is a difference in active objects;
not sure if it is related (I don't really know what any of it means).  That is
the third one.

Thanks,
Bas

root@star:/sys/kernel/debug/dri/0# cat i915_gem_objects 
220 objects, 36782080 bytes
131 [131] objects, 34430976 [34430976] bytes in gtt
  0 [0] active objects, 0 [0] bytes
  131 [131] inactive objects, 34430976 [34430976] bytes
49 unbound objects, 638976 bytes
1 purgeable objects, 4096 bytes
6 pinned mappable objects, 15884288 bytes
118 fault mappable objects, 27901952 bytes
536870912 [268435456] gtt total

Xorg: 217 objects, 36642816 bytes (0 active, 30703616 inactive, 5922816 unbound)
root@star:/sys/kernel/debug/dri/0# cat i915_gem_objects 
220 objects, 36782080 bytes
131 [131] objects, 34430976 [34430976] bytes in gtt
  0 [0] active objects, 0 [0] bytes
  131 [131] inactive objects, 34430976 [34430976] bytes
49 unbound objects, 638976 bytes
1 purgeable objects, 4096 bytes
6 pinned mappable objects, 15884288 bytes
118 fault mappable objects, 27901952 bytes
536870912 [268435456] gtt total

Xorg: 217 objects, 36642816 bytes (0 active, 30703616 inactive, 5922816 unbound)
root@star:/sys/kernel/debug/dri/0# cat i915_gem_objects 
220 objects, 36782080 bytes
131 [131] objects, 34430976 [34430976] bytes in gtt
  2 [2] active objects, 32768 [32768] bytes
  129 [129] inactive objects, 34398208 [34398208] bytes
49 unbound objects, 638976 bytes
1 purgeable objects, 4096 bytes
6 pinned mappable objects, 15884288 bytes
118 fault mappable objects, 27901952 bytes
536870912 [268435456] gtt total

Xorg: 217 objects, 36642816 bytes (32768 active, 30670848 inactive, 5922816 
unbound)


-- 
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/20131103151517.ga24...@fmf.nl

Bug#724944: [Intel-gfx] Patch for crashing intel server

2013-10-24 Thread Bas Wijnen 
On Wed, Oct 23, 2013 at 09:28:28AM +0100, Chris Wilson wrote:
> No worries, if you can run
> 
> addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79 0xf8215
> 
> that should give me the information needed to pinpoint the crash.

$ addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79
0xf8215
/build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/intel.h:138
/build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/i915_video.c:156
/build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/intel_video.c:1584

Note that I'm running the unpatched Debian version again (so not with
your or my patch), which is why it was crashing.

In case you have different sources, here's some context for those lines:

intel.h:138 is
 static inline Bool intel_pixmap_tiled(PixmapPtr pixmap)
 {
>return intel_get_pixmap_private(pixmap)->tiling != I915_TILING_NONE;
 }

i915_video.c:156 is
/* front buffer, pitch, offset */
>   if (intel_pixmap_tiled(target)) {
tiling = BUF_3D_TILED_SURFACE;

and intel_video.c:1584 is
} else {
>   I915DisplayVideoTextured(scrn, adaptor_priv, id, clipBoxes,
width, height, dstPitch, dstPitch2,
src_w, src_h, drw_w, drw_h,
pixmap);
}

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#724944: [Intel-gfx] Patch for crashing intel server

2013-10-16 Thread Bas Wijnen 
On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote:
> > This does indeed stop the server from crashing, but actually makes the
> > problem worse: it used to play video for a few minutes and then crash
> > when trying.  With my patch it would play video for a few minutes and
> > then present black screens when trying.  With your patch, it presents
> > black screens from the start.
> 
> Start of video, or beginning of X?

Beginning of X.  After starting and logging in, I can play them for a
few minutes; afterwards it will crash.

> > I must say I'm not entirely sure if the backtrace I sent you is a
> > "typical" case; I managed to crash it sooner than usual, so perhaps it
> > wasn't the bug that I triggered before.  It did stop the crashing
> > however.
> > 
> > > However, that still leaveas the question as to how you ended up being
> > > unable to allocate bo...

I didn't check the backtrace myself, but when I wrote my shotgun-patch,
the problem was that pixmap_private was NULL; bo is in there, right?  So
at least in that case, it could never have allocated it, or at least it
couldn't store the pointer.

> > While looking for it I did find and try intel-gpu-time, and noticed that
> > it always reports the gpu 100% busy, even when running intel-gpu-time
> > sleep 5 from a linux virtual terminal (so not even X is displayed).  Is
> > that normal?
> 
> Hmm, looks like it should report correctly on i915.

Due to unrelated problems (unbearable slowness) I switched from gnome to
xfce.  It does report 0% now.  It seems gnome keeps the gpu busy even if
it's not displaying anything...

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#724944: [Intel-gfx] Patch for crashing intel server

2013-10-14 Thread Bas Wijnen 
On Sun, Oct 13, 2013 at 10:43:49AM +0100, Chris Wilson wrote:
> > > > My X server was crashing when playing video, and I wrote a patch to fix
> > > > it.  Please find the background and the patch at
> > > > http://bugs.debian.org/724944 .
> 
> Ok, I can see the allocation failure that leads to the crash:
> 
> commit f9a18c9f38d09c145eb513ca989966dc135c1e9b
> Author: Chris Wilson 
> Date:   Sun Oct 13 10:36:35 2013 +0100

This does indeed stop the server from crashing, but actually makes the
problem worse: it used to play video for a few minutes and then crash
when trying.  With my patch it would play video for a few minutes and
then present black screens when trying.  With your patch, it presents
black screens from the start.

I must say I'm not entirely sure if the backtrace I sent you is a
"typical" case; I managed to crash it sooner than usual, so perhaps it
wasn't the bug that I triggered before.  It did stop the crashing
however.

> However, that still leaveas the question as to how you ended up being
> unable to allocate bo...
> 
> You can watch /sys/kernel/debug/dri/0/i915_gem_objects (or just use
> intel-gpu-overlay) and see if there is an object leak.

I don't have enough knowledge about the internals to know how that
works.  I can see the file if I mount the debugfs, but what am I looking
for?

I don't seem to have intel-gpu-overlay on my system; does it make sense
to install it?  If so, where do I get it?

While looking for it I did find and try intel-gpu-time, and noticed that
it always reports the gpu 100% busy, even when running intel-gpu-time
sleep 5 from a linux virtual terminal (so not even X is displayed).  Is
that normal?

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#724944: [Intel-gfx] Patch for crashing intel server

2013-10-12 Thread Bas Wijnen 
On Sat, Oct 12, 2013 at 09:46:14PM +0100, Chris Wilson wrote:
> On Fri, Oct 11, 2013 at 09:24:54PM +0200, Bas Wijnen wrote:
> > Hello,
> > 
> > My X server was crashing when playing video, and I wrote a patch to fix
> > it.  Please find the background and the patch at
> > http://bugs.debian.org/724944 .
> 
> The patch is a shotgun solution, putting NULL pointer checks where the
> pointer is explicitly not allowed to be NULL. I need an actual
> stacktrace to find the root cause.
> -Chris

Sure thing; you can find it attached.  Of course it shows when the
segfault is triggered, not when the data became NULL.  And that should
be fixed, because even though the server doesn't crash with the patch,
it also doesn't play video.

If you need any more information (like debug statements in the
set_pixmap_private?), please let me know how I can generate it.

Thanks,
Bas
#0  0xb758f424 in __kernel_vsyscall ()
#1  0xb719380f in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xb7196cc3 in __GI_abort () at abort.c:90
#3  0xb77574a9 in OsAbort () at ../../os/utils.c:1299
#4  0xb7630d07 in ddxGiveUp (error=error@entry=EXIT_ERR_ABORT)
at ../../../../hw/xfree86/common/xf86Init.c:1063
#5  0xb7630da3 in AbortDDX (error=error@entry=EXIT_ERR_ABORT)
at ../../../../hw/xfree86/common/xf86Init.c:1107
#6  0xb775cc41 in AbortServer () at ../../os/log.c:767
#7  0xb775d6be in FatalError (
f=f@entry=0xb7785084 "Caught signal %d (%s). Server aborting\n")
at ../../os/log.c:908
#8  0xb7754d84 in OsSigHandler (signo=11, sip=0xbfbe0f0c, unused=0xbfbe0f8c)
at ../../os/osinit.c:147
#9  
#10 0xb6f26d79 in intel_pixmap_tiled (pixmap=0xb8945808)
at ../../../src/uxa/intel.h:138
#11 I915DisplayVideoTextured (scrn=0xb83f2f08, adaptor_priv=0xb83eed70, 
id=808596553, dstRegion=0xbfbe14a8, width=352, height=288, 
video_pitch=176, video_pitch2=352, src_w=352, src_h=288, drw_w=384, 
drw_h=288, pixmap=0xb8425d98) at ../../../src/uxa/i915_video.c:156
#12 0xb6f22215 in I830PutImageTextured (scrn=0xb83f2f08, src_x=0, src_y=0, 
drw_x=1308, drw_y=192, src_w=352, src_h=288, drw_w=384, drw_h=288, 
id=808596553, buf=0xb314 , 
width=352, height=288, sync=0, clipBoxes=0xbfbe14a8, data=0xb83eed70, 
drawable=0xb88fad78) at ../../../src/uxa/intel_video.c:1584
#13 0xb764877c in xf86XVPutImage (client=0xb8906010, pDraw=0xb88fad78, 
pPort=0xb840ce58, pGC=0xb89206d8, src_x=0, src_y=0, src_w=352, src_h=288, 
drw_x=0, drw_y=0, drw_w=384, drw_h=288, format=0xb840ccd0, 
data=0xb314 , sync=0, width=352, 
height=288) at ../../../../hw/xfree86/common/xf86xv.c:1827
#14 0xb769304c in XvdiPutImage (client=client@entry=0xb8906010, 
pDraw=0xb88fad78, pPort=0xb840ce58, pGC=0xb89206d8, src_x=0, src_y=0, 
src_w=352, src_h=288, drw_x=0, drw_y=0, drw_w=384, drw_h=288, 
image=image@entry=0xb840ccd0, 
data=0xb314 , sync=0, 
width=width@entry=352, height=288) at ../../Xext/xvmain.c:673
#15 0xb7694648 in ProcXvShmPutImage (client=0xb8906010)
at ../../Xext/xvdisp.c:1025
#16 0xb7696dae in ProcXvDispatch (client=0xb8906010)
at ../../Xext/xvdisp.c:1212
#17 0xb75ed35d in Dispatch () at ../../dix/dispatch.c:432
#18 0xb75db38a in main (argc=13, argv=0xbfbe1774, envp=0xbfbe17ac)
at ../../dix/main.c:298
#0  0xb758f424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb719380f in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 
resultvar = 
pid = -1221525504
selftid = 29720
#2  0xb7196cc3 in __GI_abort () at abort.c:90
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0xbfbe0db0, 
sa_sigaction = 0xbfbe0db0}, sa_mask = {__val = {3078486656, 
  3073441792, 171515904, 3076194304, 3076196648, 5, 3078438944, 
  3076120729, 3076197088, 3071376880, 1, 5, 0, 0, 0, 0, 0, 0, 0, 
  3076259256, 0, 0, 0, 3071717608, 0, 0, 0, 3078438912, 1, 
  3078475476, 3078475380, 3076146208}}, sa_flags = -1216480640, 
  sa_restorer = 0xb7196b80 <__GI_abort>}
sigs = {__val = {32, 0 }}
#3  0xb77574a9 in OsAbort () at ../../os/utils.c:1299
No locals.
#4  0xb7630d07 in ddxGiveUp (error=error@entry=EXIT_ERR_ABORT)
at ../../../../hw/xfree86/common/xf86Init.c:1063
i = 
#5  0xb7630da3 in AbortDDX (error=error@entry=EXIT_ERR_ABORT)
at ../../../../hw/xfree86/common/xf86Init.c:1107
i = 
#6  0xb775cc41 in AbortServer () at ../../os/log.c:767
No locals.
#7  0xb775d6be in FatalError (
f=f@entry=0xb7785084 "Caught signal %d (%s). Server aborting\n")
at ../../os/log.c:908
args = 0xbfbe0ee4 "\v"
args2 = 0xbfbe0ee4 "\v"
beenhere = 1
#8  0xb7754d84 in OsSigHandler (signo=11, sip=0xbfbe0f0c, unused=0xbfbe0f8c)
at ../../os/osinit.c:147
unused = 0xbfb

Bug#724944: Patch

2013-10-11 Thread Bas Wijnen 
On Fri, Oct 11, 2013 at 08:53:03PM +0200, Julien Cristau wrote:
> Thanks.  Can you please send this upstream to
> intel-...@lists.freedesktop.org?

Done.  (I didn't subscribe to the list; not sure if that was required.
My mail wasn't bounced, so I suppose it worked.)

By the way, I just noticed that while the patch does prevent the server
from crashing, it doesn't actually solve the problem: videos are now all
black.  Not crashing the server is certainly an improvement, but this is
still unusable. :-(

I'm guessing the problem is whatever sets the intel_pixmap_private field
to NULL, but I have no idea where to look for that, or how to debug it.

It only happens after the server has been running for some time (a few
minutes), which sounds like it will not be easy to track down,
unfortunately.  If anyone wants to try, or can tell me what I can try,
please let me know.

Thanks,
Bas


-- 
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/20131012031509.gp2...@a82-93-13-222.adsl.xs4all.nl

Bug#724944: Patch

2013-10-11 Thread Bas Wijnen 
Control: tags -1 + patch

First of all, I can see how you're busy, but if you think my problem is
trivial, please just tell me so.  If I'm sending a message saying "I
don't know how to continue", even explicitly saying that I know this may
not be what you need, a reply only saying "this is not what we need" is
totally unhelpful.  It shouldn't be too much effort to type the extra
sentence "what you describe you did should have worked, did you try
restarting the server?" (which I thought I did, but I suppose I didn't).
A line like that helps more than you might think; it confirms that I was
on the right track.  Since I don't know much about the code or how it's
supposed to work, that is good to know.

Anyway, a server which is unable to play any video 5 minutes after
starting gives quite a strong motivation to fix things.  So after I got
a backtrace, I debugged the thing.  The problem was that the result of
intel_get_pixmap_private() could be NULL, but that wasn't checked.  So I
grepped for it and added checks to all calls of that function.  The
patch is attached.  You will want to check if I'm handling it the right
way everywhere, because I just guessed the proper course of action.
Then again, most code would segfault without handling it, so perhaps
most of these can't ever be triggered anyay (but I'm not too sure about
that; it certainly can set it to NULL when calloc fails).

Thanks,
Bas
Index: xserver-xorg-video-intel-2.21.15/src/uxa/intel.h
===
--- xserver-xorg-video-intel-2.21.15.orig/src/uxa/intel.h   2013-10-11 
00:30:38.343948391 -0400
+++ xserver-xorg-video-intel-2.21.15/src/uxa/intel.h2013-10-11 
00:30:38.335948384 -0400
@@ -130,12 +130,17 @@
 
 static inline Bool intel_pixmap_is_dirty(PixmapPtr pixmap)
 {
-   return pixmap && intel_get_pixmap_private(pixmap)->dirty;
+   struct intel_pixmap *priv;
+   if (!pixmap)
+   return FALSE;
+   priv = intel_get_pixmap_private(pixmap);
+   return priv && priv->dirty;
 }
 
 static inline Bool intel_pixmap_tiled(PixmapPtr pixmap)
 {
-   return intel_get_pixmap_private(pixmap)->tiling != I915_TILING_NONE;
+   struct intel_pixmap *priv = intel_get_pixmap_private(pixmap);
+   return priv && priv->tiling != I915_TILING_NONE;
 }
 
 dri_bo *intel_get_pixmap_bo(PixmapPtr pixmap);
Index: xserver-xorg-video-intel-2.21.15/src/uxa/i830_render.c
===
--- xserver-xorg-video-intel-2.21.15.orig/src/uxa/i830_render.c 2013-10-11 
00:30:38.343948391 -0400
+++ xserver-xorg-video-intel-2.21.15/src/uxa/i830_render.c  2013-10-11 
00:30:38.335948384 -0400
@@ -293,9 +293,9 @@
filter |= (MIPFILTER_NONE << TM0S3_MIP_FILTER_SHIFT);
 
if (intel_pixmap_tiled(pixmap)) {
+   struct intel_pixmap *priv = intel_get_pixmap_private(pixmap);
tiling_bits = TM0S1_TILED_SURFACE;
-   if (intel_get_pixmap_private(pixmap)->tiling
-   == I915_TILING_Y)
+   if (priv && priv->tiling == I915_TILING_Y)
tiling_bits |= TM0S1_TILE_WALK;
} else
tiling_bits = 0;
@@ -585,9 +585,9 @@
assert(intel->in_batch_atomic);
 
if (intel_pixmap_tiled(intel->render_dest)) {
+   struct intel_pixmap *priv = 
intel_get_pixmap_private(intel->render_dest);
tiling_bits = BUF_3D_TILED_SURFACE;
-   if (intel_get_pixmap_private(intel->render_dest)->tiling
-   == I915_TILING_Y)
+   if (priv && priv->tiling == I915_TILING_Y)
tiling_bits |= BUF_3D_TILE_WALK_Y;
} else
tiling_bits = 0;
Index: xserver-xorg-video-intel-2.21.15/src/uxa/i915_render.c
===
--- xserver-xorg-video-intel-2.21.15.orig/src/uxa/i915_render.c 2013-10-11 
00:30:38.343948391 -0400
+++ xserver-xorg-video-intel-2.21.15/src/uxa/i915_render.c  2013-10-11 
00:30:38.339948386 -0400
@@ -351,9 +351,9 @@
 
/* offset filled in at emit time */
if (intel_pixmap_tiled(pixmap)) {
+   struct intel_pixmap *priv = intel_get_pixmap_private(pixmap);
tiling_bits = MS3_TILED_SURFACE;
-   if (intel_get_pixmap_private(pixmap)->tiling
-   == I915_TILING_Y)
+   if (priv && priv->tiling == I915_TILING_Y)
tiling_bits |= MS3_TILE_WALK;
} else
tiling_bits = 0;
@@ -883,9 +883,9 @@
uint32_t tiling_bits;
 
if (intel_pixmap_tiled(dest)) {
+   struct intel_pixmap *priv = 
intel_get_pixmap_private(dest);
tiling_bits = BUF_3D_TILED_SURFACE;
-   if (intel_get_pixmap_private(dest)->tiling
-   == I915_TILING_Y)
+

Bug#724944: Patch

2013-10-11 Thread Bas Wijnen 
Control: tags -1 + patch

First of all, I can see how you're busy, but if you think my problem is
trivial, please just tell me so.  If I'm sending a message saying "I don't know
how to continue", even explicitly saying that I know this may not be what you
need, a reply only saying "this is not what we need" is totally unhelpful.  It
shouldn't be too much effort to type the extra sentence "what you describe you
did should have worked, did you try restarting the server?" (which I thought I
did, but I suppose I didn't).  A line like that helps more than you might
think; it confirms that I was on the right track.  Since I don't know much
about the code or how it's supposed to work, that is good to know.

Anyway, a server which is unable to play any video 5 minutes after starting
gives quite a strong motivation to fix things.  So after I got a backtrace, I
debugged the thing.  The problem was that the result of
intel_get_pixmap_private() could be NULL, but that wasn't checked.  So I
grepped for it and added checks to all calls of that function.  The patch is
attached.  You will want to check if I'm handling it the right way everywhere,
because I just guessed the proper course of action.  Then again, most code
would segfault without handling it, so perhaps most of these can't ever be
triggered anyay (but I'm not too sure about that; it certainly can set it to
NULL when calloc fails).

Thanks,
Bas
Index: xserver-xorg-video-intel-2.21.15/src/uxa/intel.h
===
--- xserver-xorg-video-intel-2.21.15.orig/src/uxa/intel.h   2013-10-11 
00:30:38.343948391 -0400
+++ xserver-xorg-video-intel-2.21.15/src/uxa/intel.h2013-10-11 
00:30:38.335948384 -0400
@@ -130,12 +130,17 @@
 
 static inline Bool intel_pixmap_is_dirty(PixmapPtr pixmap)
 {
-   return pixmap && intel_get_pixmap_private(pixmap)->dirty;
+   struct intel_pixmap *priv;
+   if (!pixmap)
+   return FALSE;
+   priv = intel_get_pixmap_private(pixmap);
+   return priv && priv->dirty;
 }
 
 static inline Bool intel_pixmap_tiled(PixmapPtr pixmap)
 {
-   return intel_get_pixmap_private(pixmap)->tiling != I915_TILING_NONE;
+   struct intel_pixmap *priv = intel_get_pixmap_private(pixmap);
+   return priv && priv->tiling != I915_TILING_NONE;
 }
 
 dri_bo *intel_get_pixmap_bo(PixmapPtr pixmap);
Index: xserver-xorg-video-intel-2.21.15/src/uxa/i830_render.c
===
--- xserver-xorg-video-intel-2.21.15.orig/src/uxa/i830_render.c 2013-10-11 
00:30:38.343948391 -0400
+++ xserver-xorg-video-intel-2.21.15/src/uxa/i830_render.c  2013-10-11 
00:30:38.335948384 -0400
@@ -293,9 +293,9 @@
filter |= (MIPFILTER_NONE << TM0S3_MIP_FILTER_SHIFT);
 
if (intel_pixmap_tiled(pixmap)) {
+   struct intel_pixmap *priv = intel_get_pixmap_private(pixmap);
tiling_bits = TM0S1_TILED_SURFACE;
-   if (intel_get_pixmap_private(pixmap)->tiling
-   == I915_TILING_Y)
+   if (priv && priv->tiling == I915_TILING_Y)
tiling_bits |= TM0S1_TILE_WALK;
} else
tiling_bits = 0;
@@ -585,9 +585,9 @@
assert(intel->in_batch_atomic);
 
if (intel_pixmap_tiled(intel->render_dest)) {
+   struct intel_pixmap *priv = 
intel_get_pixmap_private(intel->render_dest);
tiling_bits = BUF_3D_TILED_SURFACE;
-   if (intel_get_pixmap_private(intel->render_dest)->tiling
-   == I915_TILING_Y)
+   if (priv && priv->tiling == I915_TILING_Y)
tiling_bits |= BUF_3D_TILE_WALK_Y;
} else
tiling_bits = 0;
Index: xserver-xorg-video-intel-2.21.15/src/uxa/i915_render.c
===
--- xserver-xorg-video-intel-2.21.15.orig/src/uxa/i915_render.c 2013-10-11 
00:30:38.343948391 -0400
+++ xserver-xorg-video-intel-2.21.15/src/uxa/i915_render.c  2013-10-11 
00:30:38.339948386 -0400
@@ -351,9 +351,9 @@
 
/* offset filled in at emit time */
if (intel_pixmap_tiled(pixmap)) {
+   struct intel_pixmap *priv = intel_get_pixmap_private(pixmap);
tiling_bits = MS3_TILED_SURFACE;
-   if (intel_get_pixmap_private(pixmap)->tiling
-   == I915_TILING_Y)
+   if (priv && priv->tiling == I915_TILING_Y)
tiling_bits |= MS3_TILE_WALK;
} else
tiling_bits = 0;
@@ -883,9 +883,9 @@
uint32_t tiling_bits;
 
if (intel_pixmap_tiled(dest)) {
+   struct intel_pixmap *priv = 
intel_get_pixmap_private(dest);
tiling_bits = BUF_3D_TILED_SURFACE;
-   if (intel_get_pixmap_private(dest)->tiling
-   == I915_TILING_Y)
+

Bug#724944: xserver-xorg-video-intel: segfaults when trying to play movies

2013-10-01 Thread Bas Wijnen 
On Tue, Oct 01, 2013 at 04:51:01PM +0200, Julien Cristau wrote:
> Still no info about what's going on in the driver.

On Tue, Oct 01, 2013 at 02:25:28AM +0200, Bas Wijnen wrote:
> Please tell me what to do or install if you need more 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/20131001150101.gt9...@fmf.nl

Bug#724944: xserver-xorg-video-intel: segfaults when trying to play movies

2013-09-30 Thread Bas Wijnen 
On Mon, Sep 30, 2013 at 10:39:47PM +0200, Julien Cristau wrote:
> On Mon, Sep 30, 2013 at 05:14:21 +0200, Bas Wijnen wrote:
> 
> > On Sun, Sep 29, 2013 at 10:18:00PM +0200, Cyril Brulebois wrote:
> > > Please provide us with a backtrace. Some hints are available at:
> > >   http://x.debian.net/howto/use-gdb.html
> > 
> > I've now made it crash while it was running with -core.  It took me some 
> > time
> > to find the core file (it would be good to mention on that page that for 
> > (new)
> > gdm, it is in /var/lib/gdm3).
> > 
> > Anyway, I attached the gdb logs of the bt and bt full commands.  I don't 
> > know
> > why it says it has no symbol table; I did install the -dbg package.  Should 
> > I
> > do something to load the symbols from that package?
> > 
> That trace doesn't seem to have debug symbols for the driver.

I didn't realize there was a per-driver debug package; it would be useful if
this FIXME in the gdb document at least mentions that.

Hopefully the attached file is better, even though it still complains about
some missing symbols.  Please tell me what to do or install if you need more
information.

Thanks,
Bas
#0  0xb757d424 in __kernel_vsyscall ()
#1  0xb718380f in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xb7186cc3 in __GI_abort () at abort.c:90
#3  0xb7745499 in OsAbort () at ../../os/utils.c:1299
#4  0xb761ecf7 in ddxGiveUp (error=error@entry=EXIT_ERR_ABORT) at 
../../../../hw/xfree86/common/xf86Init.c:1063
#5  0xb761ed93 in AbortDDX (error=error@entry=EXIT_ERR_ABORT) at 
../../../../hw/xfree86/common/xf86Init.c:1107
#6  0xb774ac31 in AbortServer () at ../../os/log.c:767
#7  0xb774b6ae in FatalError (f=f@entry=0xb77730a4 "Caught signal %d (%s). 
Server aborting\n") at ../../os/log.c:908
#8  0xb7742d74 in OsSigHandler (signo=11, sip=0xbfa6d08c, unused=0xbfa6d10c) at 
../../os/osinit.c:147
#9  
#10 0xb6f16d79 in ?? () from /usr/lib/xorg/modules/drivers/intel_drv.so
#11 0xb6f12215 in ?? () from /usr/lib/xorg/modules/drivers/intel_drv.so
#12 0xb763676c in xf86XVPutImage (client=0xb8e6ff18, pDraw=0xb8e72230, 
pPort=0xb89aee78, pGC=0xb8e69f58, src_x=0, src_y=0, 
src_w=1280, src_h=720, drw_x=0, drw_y=0, drw_w=1278, drw_h=720, 
format=0xb89aebf0, 
data=0xb4ad6000 
"5t5\227\066t6\227\066t7\227\067t7\227\065t5\227\064t2\227\060t1\227\064t7\227\065v3\226\062u2\227\064t6\231\066s6\232\065t6\231\065w5\227\066z6\224\060|)\222.|(\211\037|\031\210\027}\030\207\030~\027\206\035~\036\207\036}\037\211
 |!\214$|&\216&z'\217(z)\221-{0\220-{(\215\033|\030\212\033|\034\212\033| 
\216%|!\222(|(\220'z'\220(y*\220,x-\217,y/\214.{\023\210\006~\017\204\017\200\022\201\024~\025\205\027~\031\207\034~\036\211\037}\037\213#|%\215&{&\216&{&\216&z'\216&{'\215'{(\216"...,
 sync=0, width=1280, height=720) at ../../../../hw/xfree86/common/xf86xv.c:1827
#13 0xb768103c in XvdiPutImage (client=client@entry=0xb8e6ff18, 
pDraw=0xb8e72230, pPort=0xb89aee78, pGC=0xb8e69f58, src_x=0, 
src_y=0, src_w=1280, src_h=720, drw_x=0, drw_y=0, drw_w=1278, drw_h=720, 
image=image@entry=0xb89aebf0, 
data=0xb4ad6000 
"5t5\227\066t6\227\066t7\227\067t7\227\065t5\227\064t2\227\060t1\227\064t7\227\065v3\226\062u2\227\064t6\231\066s6\232\065t6\231\065w5\227\066z6\224\060|)\222.|(\211\037|\031\210\027}\030\207\030~\027\206\035~\036\207\036}\037\211
 |!\214$|&\216&z'\217(z)\221-{0\220-{(\215\033|\030\212\033|\034\212\033| 
\216%|!\222(|(\220'z'\220(y*\220,x-\217,y/\214.{\023\210\006~\017\204\017\200\022\201\024~\025\205\027~\031\207\034~\036\211\037}\037\213#|%\215&{&\216&{&\216&z'\216&{'\215'{(\216"...,
 sync=0, width=width@entry=1280, height=720) at ../../Xext/xvmain.c:673
#14 0xb7682638 in ProcXvShmPutImage (client=0xb8e6ff18) at 
../../Xext/xvdisp.c:1025
#15 0xb7684d9e in ProcXvDispatch (client=0xb8e6ff18) at ../../Xext/xvdisp.c:1212
#16 0xb75db35d in Dispatch () at ../../dix/dispatch.c:432
#17 0xb75c938a in main (argc=13, argv=0xbfa6d904, envp=0xbfa6d93c) at 
../../dix/main.c:298
#0  0xb757d424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb718380f in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 
resultvar = 
pid = -1221591040
selftid = 26623
#2  0xb7186cc3 in __GI_abort () at abort.c:90
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0xbfa6cf30, sa_sigaction = 
0xbfa6cf30}, sa_mask = {__val = {3078412928, 
  3073376256, 171515904, 3076120576, 3076122920, 1, 3078365216, 
3076047001, 3076123360, 3071311344, 1, 1, 0, 0, 
  0, 0, 0, 0, 0, 3076185528, 0, 0, 0, 3071652072, 0, 0, 0, 
3078365184, 1, 3078401748, 3078401652, 3076072480}}, 
  sa_flags = -1216554368, sa_re

Bug#724944: xserver-xorg-video-intel: segfaults when trying to play movies

2013-09-29 Thread Bas Wijnen 
On Sun, Sep 29, 2013 at 10:18:00PM +0200, Cyril Brulebois wrote:
> Please provide us with a backtrace. Some hints are available at:
>   http://x.debian.net/howto/use-gdb.html

I've now made it crash while it was running with -core.  It took me some time
to find the core file (it would be good to mention on that page that for (new)
gdm, it is in /var/lib/gdm3).

Anyway, I attached the gdb logs of the bt and bt full commands.  I don't know
why it says it has no symbol table; I did install the -dbg package.  Should I
do something to load the symbols from that package?

Thanks,
Bas
#0  0xb757d424 in __kernel_vsyscall ()
#1  0xb718380f in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xb7186cc3 in __GI_abort () at abort.c:90
#3  0xb7745499 in OsAbort () at ../../os/utils.c:1299
#4  0xb761ecf7 in ddxGiveUp (error=error@entry=EXIT_ERR_ABORT) at 
../../../../hw/xfree86/common/xf86Init.c:1063
#5  0xb761ed93 in AbortDDX (error=error@entry=EXIT_ERR_ABORT) at 
../../../../hw/xfree86/common/xf86Init.c:1107
#6  0xb774ac31 in AbortServer () at ../../os/log.c:767
#7  0xb774b6ae in FatalError (f=f@entry=0xb77730a4 "Caught signal %d (%s). 
Server aborting\n") at ../../os/log.c:908
#8  0xb7742d74 in OsSigHandler (signo=11, sip=0xbfa6d08c, unused=0xbfa6d10c) at 
../../os/osinit.c:147
#9  
#10 0xb6f16d79 in ?? () from /usr/lib/xorg/modules/drivers/intel_drv.so
#11 0xb6f12215 in ?? () from /usr/lib/xorg/modules/drivers/intel_drv.so
#12 0xb763676c in xf86XVPutImage (client=0xb8e6ff18, pDraw=0xb8e72230, 
pPort=0xb89aee78, pGC=0xb8e69f58, src_x=0, src_y=0, 
src_w=1280, src_h=720, drw_x=0, drw_y=0, drw_w=1278, drw_h=720, 
format=0xb89aebf0, 
data=0xb4ad6000 
"5t5\227\066t6\227\066t7\227\067t7\227\065t5\227\064t2\227\060t1\227\064t7\227\065v3\226\062u2\227\064t6\231\066s6\232\065t6\231\065w5\227\066z6\224\060|)\222.|(\211\037|\031\210\027}\030\207\030~\027\206\035~\036\207\036}\037\211
 |!\214$|&\216&z'\217(z)\221-{0\220-{(\215\033|\030\212\033|\034\212\033| 
\216%|!\222(|(\220'z'\220(y*\220,x-\217,y/\214.{\023\210\006~\017\204\017\200\022\201\024~\025\205\027~\031\207\034~\036\211\037}\037\213#|%\215&{&\216&{&\216&z'\216&{'\215'{(\216"...,
 sync=0, width=1280, height=720) at ../../../../hw/xfree86/common/xf86xv.c:1827
#13 0xb768103c in XvdiPutImage (client=client@entry=0xb8e6ff18, 
pDraw=0xb8e72230, pPort=0xb89aee78, pGC=0xb8e69f58, src_x=0, 
src_y=0, src_w=1280, src_h=720, drw_x=0, drw_y=0, drw_w=1278, drw_h=720, 
image=image@entry=0xb89aebf0, 
data=0xb4ad6000 
"5t5\227\066t6\227\066t7\227\067t7\227\065t5\227\064t2\227\060t1\227\064t7\227\065v3\226\062u2\227\064t6\231\066s6\232\065t6\231\065w5\227\066z6\224\060|)\222.|(\211\037|\031\210\027}\030\207\030~\027\206\035~\036\207\036}\037\211
 |!\214$|&\216&z'\217(z)\221-{0\220-{(\215\033|\030\212\033|\034\212\033| 
\216%|!\222(|(\220'z'\220(y*\220,x-\217,y/\214.{\023\210\006~\017\204\017\200\022\201\024~\025\205\027~\031\207\034~\036\211\037}\037\213#|%\215&{&\216&{&\216&z'\216&{'\215'{(\216"...,
 sync=0, width=width@entry=1280, height=720) at ../../Xext/xvmain.c:673
#14 0xb7682638 in ProcXvShmPutImage (client=0xb8e6ff18) at 
../../Xext/xvdisp.c:1025
#15 0xb7684d9e in ProcXvDispatch (client=0xb8e6ff18) at ../../Xext/xvdisp.c:1212
#16 0xb75db35d in Dispatch () at ../../dix/dispatch.c:432
#17 0xb75c938a in main (argc=13, argv=0xbfa6d904, envp=0xbfa6d93c) at 
../../dix/main.c:298
#0  0xb757d424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb718380f in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 
resultvar = 
pid = -1221591040
selftid = 26623
#2  0xb7186cc3 in __GI_abort () at abort.c:90
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0xbfa6cf30, sa_sigaction = 
0xbfa6cf30}, sa_mask = {__val = {3078412928, 
  3073376256, 171515904, 3076120576, 3076122920, 1, 3078365216, 
3076047001, 3076123360, 3071311344, 1, 1, 0, 0, 
  0, 0, 0, 0, 0, 3076185528, 0, 0, 0, 3071652072, 0, 0, 0, 
3078365184, 1, 3078401748, 3078401652, 3076072480}}, 
  sa_flags = -1216554368, sa_restorer = 0xb7186b80 <__GI_abort>}
sigs = {__val = {32, 0 }}
#3  0xb7745499 in OsAbort () at ../../os/utils.c:1299
No locals.
#4  0xb761ecf7 in ddxGiveUp (error=error@entry=EXIT_ERR_ABORT) at 
../../../../hw/xfree86/common/xf86Init.c:1063
i = 
#5  0xb761ed93 in AbortDDX (error=error@entry=EXIT_ERR_ABORT) at 
../../../../hw/xfree86/common/xf86Init.c:1107
i = 
#6  0xb774ac31 in AbortServer () at ../../os/log.c:767
No locals.
#7  0xb774b6ae in FatalError (f=f@entry=0xb77730a4 "Caught signal %d (%s). 
Server aborting\n") at ../../os/log.c:908
args = 0xbfa6d064 "\v"
args2 = 0xbfa6d064 "\v"
beenhere = 1
#8  0xb7742d74 in OsSigHandler (signo=11, sip=0xbfa6d08c, unused=0xbfa6d10c) at 
../../os/osinit.c:147
unused = 0xbfa6d10c
sip = 0xbfa6d08c
signo = 11
#9  
No symbol table

Bug#724944: xserver-xorg-video-intel: segfaults when trying to play movies

2013-09-29 Thread Bas Wijnen 
Control: notfound -1 2:2.21.15-1+b2

On Sun, Sep 29, 2013 at 10:18:00PM +0200, Cyril Brulebois wrote:
> No, that isn't data loss.

I sure lost data on it, but I'm not arguing that the lower severity is
reasonable.

> Please provide us with a backtrace. Some hints are available at:
>   http://x.debian.net/howto/use-gdb.html

The backtrace was included in the log file, hence I didn't think it would be
useful to generate another one.  I can see how it would be helpful to have a
trace with symbols, but I needed help with getting those; that was on the page
however, so I installed xserver-xorg-core-dbg.  For that, I needed to upgrade
to the +b2 version, which doesn't crash anymore...

> Also, where's the bug script output?

I don't have a proper mail system set up on this host, so reportbug doesn't
work well (I think).  But you're right, I should have generated that list.
Sorry about that.

Thanks for your quick reply and sorry for the noise,
Bas


-- 
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/20130930012111.gm9...@fmf.nl

Bug#724944: xserver-xorg-video-intel: segfaults when trying to play movies

2013-09-29 Thread Bas Wijnen 
Package: xserver-xorg-video-intel
Version: 2:2.21.15-1+b1
Severity: grave
Justification: kills entire session; including applications running on it, 
which likely results in data loss.

I can reliably crash the X server by starting almost any video with almost any
player.  At least mplayer, xine, totem, and xawtv (showing images from my
webcam) have managed to crash it.  Log file attached.  If you need debugging
symbols or anything like that, let me know how to generate it and I'm happy to
send it.

The only way I have currently found to play video without crashing X, is using
mplayer -vo x11.  I think that disables a lot of hardware acceleration, but I'm
by no means an expert on this topic.

Thanks,
Bas


Xorg.0.log.old
Description: application/trash

Bug#573849: xserver-xorg-video-radeon: Be verbose about discarding modes

2010-03-14 Thread Bas Wijnen 
On Sun, Mar 14, 2010 at 02:46:15PM -0500, Alex Deucher wrote:
> > I didn't test, but looking at the source I find it hard to believe that
> > there will be more information than "mode clock too high".  After all,
> > the rejecting code (which I quoted above) doesn't provide any more
> > information than that.
> 
> yeah, that's what it will tell you, but I that's all you should need.

It now says "The maximum I can handle is 170 MHz, this mode is 162 MHz,
I can't handle this one because the clock is too high".  It doesn't make
sense. ;-)

> >> You can also manually specify modelines in your xorg.conf or at run
> >> time using xrandr to override what the driver/xserver's selections.
> 
> It will work.  The point of manual modelines is that you can use them
> to override what the driver/xserver decides or to add modes that may
> not be in your monitor's edid.  If you specify one, then presumably
> you know what you are doing.

Ok, that sounds good.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#573849: xserver-xorg-video-radeon: Be verbose about discarding modes

2010-03-14 Thread Bas Wijnen 
On Sun, Mar 14, 2010 at 10:21:02AM -0500, Alex Deucher wrote:
> >    /* clocks over 135 MHz have heat issues with DVI on RV100 */
> >    if ((radeon_output->MonType == MT_DFP) &&
> >        (info->ChipFamily == CHIP_FAMILY_RV100) &&
> >        (pMode->Clock > 135000))
> >            return MODE_CLOCK_HIGH;
> >
> > This explains why it refuses the mode.
> >
> > Looking at the source should not be required for understanding the log
> > file.  Please make it more readable by adding a line about the heat
> > issues.  It may also be a good idea to allow overriding the check.  I
> > never had any trouble using 1600x1200 with this card and monitor.
> 
> You can start the xserver with higher verbosity levels and it will
> tell you why modes were rejected.

I didn't test, but looking at the source I find it hard to believe that
there will be more information than "mode clock too high".  After all,
the rejecting code (which I quoted above) doesn't provide any more
information than that.

> You can also manually specify modelines in your xorg.conf or at run
> time using xrandr to override what the driver/xserver's selections.

That might work, but I'm not sure.  This is the code when a modeline is
already present (in this case it's a default modeline), and is checked
for validity.  I expect that check to be performed when specifying it
manually as well.

But I didn't test, because I recompiled the package with the check
removed, and so I have a workaround already.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#573849: xserver-xorg-video-radeon: Be verbose about discarding modes

2010-03-14 Thread Bas Wijnen 
Package: xserver-xorg-video-radeon
Version: 6.12.5-1
Severity: wishlist

Since fairly recently (a few months, I think), by Radeon refuses to set
my monitor to 1600x1200.  Looking at the server log, I found (in random
order):

(II) RADEON(0): #6: hsize: 1600  vsize 1200  refresh: 60  vid: 16553
(II) RADEON(0): Modeline "1600x1200"x0.0  162.00  1600 1664 1856 2160 1200 1201 
1204 1250 +hsync +vsync (75.0 kHz)
(II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 31 H max: 81 kHz, 
PixClock max 170 MHz
(II) RADEON(0): Not using mode "1600x1200" (mode clock too high)

This makes no sense.  It should be able to go up to 170 MHz, but it
refuses 162 MHz.  In the source I found:

/* clocks over 135 MHz have heat issues with DVI on RV100 */
if ((radeon_output->MonType == MT_DFP) &&
(info->ChipFamily == CHIP_FAMILY_RV100) &&
(pMode->Clock > 135000))
return MODE_CLOCK_HIGH;

This explains why it refuses the mode.

Looking at the source should not be required for understanding the log
file.  Please make it more readable by adding a line about the heat
issues.  It may also be a good idea to allow overriding the check.  I
never had any trouble using 1600x1200 with this card and monitor.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#388568: Acknowledgement (xserver-xorg: postinst can hang)

2006-09-21 Thread Bas Wijnen 
tags 388568 +patch
thanks

I have found the problem.  On line 966 of the postinst it says:

db_input "$PRIORITY" "$TEMPLATE" || debug_echo "v_s_d_i/db_input $PRIORITY
$TEMPLATE"

This is followed by

if [ $? -eq 30 ]; then

The return value of 30 is specified for db_input.  However, if db_input
returns 30, debug_echo is called, which always returns 0.  So the check never
matches, and the validation loop is entered even though no question is asked.

The easiest solution is to remove the debug_echo.  If it is needed for some
reason, a construct like this should be made (note that this happens in a set
+e block):

db_input "$PRIORITY" "$TEMPLATE"
retval=$?
if [ $retval -ne 0 ] ; then debug_echo "v_s_d_i/db_input $PRIORITY $TEMPLATE"
; fi
if [ $? -eq 30 ]; then

Thanks,
Bas Wijnen

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html


signature.asc
Description: Digital signature

Bug#388568: xserver-xorg: postinst can hang

2006-09-21 Thread Bas Wijnen 
Package: xserver-xorg
Version: 7.1.0-1
Severity: Grave
Justification: Renders package unusable

When trying to make a live CD using live-package, the install hangs on the
postinst of xserver-xorg.  Breaking out of it and doing dpkg --configure
--pending by hand (so the debconf frontend is not noninteractive) in the
chroot results in a looping null_string_error (from templates).  No question
is asked, just the error and when I press Ok the error reappears.  Looking at
the postinst, this can only come from line 1249, getting a monitor identifier.

I have no idea why this happens now though, since yesterday I managed to make
some CD images.  Perhaps a new debconf version was released in between...

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html


signature.asc
Description: Digital signature

Bug#260598: acknowledged by developer (Re: Bug#260598: Pointer background not updated for i740 X server)

2004-09-28 Thread Bas Wijnen 

Hello,

Sorry for being unresponsive.  Since I have a new laptop, I don't really 
use the other computer at all anymore, so I couldn't do much testing. 
Anyway, it has been behaving weird, so I'm thinking it might be a 
hardware problem.  Especially if nobody else experiences it.


Thanks,
Bas

Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
#260598: xserver-xfree86: [i740] X cursor not updated correctly,
which was filed against the xserver-xfree86 package.

It has been closed by one of the developers, namely
Branden Robinson <[EMAIL PROTECTED]>.

Their explanation is attached below.  If this explanation is
unsatisfactory and you have not received a better one in a separate
message then please contact the developer, by replying to this email.

Debian bug tracking system administrator
(administrator, Debian Bugs database)



Requested further information from submitter on 12 August.

No reply recieved.

Closing bug from unresponsive submitter.

--=20
G. Branden Robinson| Never attribute to malice that
Debian GNU/Linux   | which can be adequately explained
[EMAIL PROTECTED] | by stupidity.
http://people.debian.org/~branden/ | -- Hanlon's Razor

--tfmLD+Hxjexp/STe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iEYEARECAAYFAkFY1M4ACgkQ6kxmHytGonw+PwCgkWvXTI9XUR9Un34GucLS4GNv
KrQAoJCAuWbgI2Xe7NXxZzaWUf3tlfsS
=Q+a7
-END PGP SIGNATURE-

--tfmLD+Hxjexp/STe--


signature.asc
Description: OpenPGP digital signature

Bug#260598: Pointer background not updated for i740 X server

2004-07-29 Thread Bas Wijnen 
The config file was generated by dpkg-reconfigure xserver-xfree86.  All the
comments were already there, including that one.  I tried uncommenting it and
using "on" and "off", but that didn't help.

Thanks,
Bas Wijnen

On Tue, Jul 27, 2004 at 02:06:47AM -0500, Branden Robinson wrote:
> retitle 260598 xserver-xfree86: [i740] X cursor not updated correctly
> tag 260598 + upstream moreinfo
> thanks
> 
> On Wed, Jul 21, 2004 at 12:15:23PM +0200, Bas Wijnen wrote:
> > Package: xserver-xfree86
> > Version: 4.3.0.dfsg.1-6
> > 
> > The background of the pointer on my X, using the i740 server, is not
> > updated when the pointer moves in steps.  Nor is the pointer updated,
> > until it moves again.  This means that when there is a step move, or an
> > other sudden change (the scroll wheel makes step moves in gnome-terminal,
> > for example.  An other change is the mapping of a window under the
> > pointer due to interactive placement), the pointer is not redrawn until
> > it moves.  When it does, there is a square below it which is filled with
> > its old background.  An especially big mess can be made when dragging a
> > window: in that case parts of the square under the pointer are copied
> > over themselves.  As an example I made a screen shot of an xterm, which
> > shows the background from a "change virtual desktop with hotkey, then
> > move the mouse" situation, where I used the scrollwheel to go up and down
> > several times, and which I dragged a little over the desktop.
> [...]
> > All problems mentioned can be "solved" by forcing a redraw, for example you
> > switching to and from a different virtual desktop.  Having to do that all 
> > the
> > time is quite annoying though.
> 
> Have you tried turning off the hardware cursor?  The XF86Config-4 you
> supplied has a commented-out line to do exactly this.  (Though I do note
> with some disappointment that upstream did not deign to provide a manpage
> for the i740 driver.)
> 
> -- 
> G. Branden Robinson| One man's "magic" is another man's
> Debian GNU/Linux   | engineering.  "Supernatural" is a
> [EMAIL PROTECTED] | null word.
> http://people.debian.org/~branden/ | -- Robert Heinlein



-- 
I encourage sending me encrypted e-mail.
Please send the central message of e-mails as plain text in the message body,
   not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
for more information, see http://129.125.47.90/e-mail.html


pgphgyaenhLrd.pgp
Description: PGP signature

Bug#260598: XF86Config-4

2004-07-21 Thread Bas Wijnen 
I forgot the attachment in the bug report.  Here it is.

-- 
I encourage sending me encrypted e-mail.
Please send the central message of e-mails as plain text in the message body,
   not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
for more information, see http://129.125.47.90/e-mail.html
# $XFree86: xc/programs/Xserver/hw/xfree86/XF86Conf.cpp,v 3.44 2001/12/17 
20:52:29 dawes Exp $
#
# Copyright (c) 1994-1998 by The XFree86 Project, Inc.
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
# 
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
# 
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
# THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
# OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
# 
# Except as contained in this notice, the name of the XFree86 Project shall
# not be used in advertising or otherwise to promote the sale, use or other
# dealings in this Software without prior written authorization from the
# XFree86 Project.
#
# $XConsortium: XF86Conf.cpp /main/22 1996/10/23 11:43:51 kaleb $

# The ordering of sections is not important in version 4.0 and later.

# **
# Files section.  This allows default font and rgb paths to be set
# **

Section "Files"

# The location of the RGB database.  Note, this is the name of the
# file minus the extension (like ".txt" or ".db").  There is normally
# no need to change the default.

RgbPath "/usr/X11R6/lib/X11/rgb"

# Multiple FontPath entries are allowed (which are concatenated together),
# as well as specifying multiple comma-separated entries in one FontPath
# command (or a combination of both methods)

FontPath"/usr/X11R6/lib/X11/fonts/local/"
FontPath"/usr/X11R6/lib/X11/fonts/misc/"
FontPath"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
FontPath"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
FontPath"/usr/X11R6/lib/X11/fonts/Type1/"
FontPath"/usr/X11R6/lib/X11/fonts/CID/"
FontPath"/usr/X11R6/lib/X11/fonts/Speedo/"
FontPath"/usr/X11R6/lib/X11/fonts/75dpi/"
FontPath"/usr/X11R6/lib/X11/fonts/100dpi/"

# ModulePath can be used to set a search path for the X server modules.
# The default path is shown here.

#ModulePath "/usr/X11R6/lib/modules"

EndSection

# **
# Module section -- this is an optional section which is used to specify
# which run-time loadable modules to load when the X server starts up.
# **

Section "Module"
# This loads the DBE extension module.

Load"dbe"

# This loads the miscellaneous extensions module, and disables
# initialisation of the XFree86-DGA extension within that module.

SubSection  "extmod"
Option  "omit xfree86-dga"
EndSubSection

# This loads the Type1 and FreeType font modules

Load"type1"
Load"freetype"

EndSection


# **
# Server flags section.  This contains various server-wide Options.
# **

Section "ServerFlags"

# Uncomment this to cause a core dump at the spot where a signal is 
# received.  This may leave the console in an unusable state, but may
# provide a better stack trace in the core dump to aid in debugging

#Option "NoTrapSignals"

# Uncomment this to disable the  server abort sequence
# This allows clients to receive this key event.

#Option "DontZap"

# Uncomment this to disable the / mode switching
# sequences.  This allows clients to receive these key events.

#Option "DontZoom"

# Uncomment this to disable tuning with the xvidtune client. With
# it the client can still run and fetch card and monitor attributes,
# but it will not be allowed to change them. If it tries it will
# receive a protocol error.

#Option "DisableVidModeExtension"

# Uncomment this to enable the use of a non-local xvidtune client.

#Option

Bug#260598: Pointer background not updated for i740 X server

2004-07-21 Thread Bas Wijnen 
Package: xserver-xfree86
Version: 4.3.0.dfsg.1-6

The background of the pointer on my X, using the i740 server, is not updated
when the pointer moves in steps.  Nor is the pointer updated, until it moves
again.  This means that when there is a step move, or an other sudden change
(the scroll wheel makes step moves in gnome-terminal, for example.  An other
change is the mapping of a window under the pointer due to interactive
placement), the pointer is not redrawn until it moves.  When it does, there is
a square below it which is filled with its old background.  An especially big
mess can be made when dragging a window: in that case parts of the square
under the pointer are copied over themselves.  As an example I made a screen
shot of an xterm, which shows the background from a "change virtual desktop
with hotkey, then move the mouse" situation, where I used the scrollwheel to
go up and down several times, and which I dragged a little over the desktop.

You can find it at:
http://129.125.47.90/~shevek/desktop-bug.png

Note that the computer was running GNU/Linux when this screenshot was taken,
not GNU/Hurd.  It is named hurd because I develop (and run) GNU/Hurd on it,
but I wasn't at that moment.

My XF86Config-4 is attached.

This problem occurs since I upgraded to gnome 2.6, at which time I guess I
also upgraded to the dfsg version of X (I got the new pointers after that
upgrade anyway.)  I checked, and the bug also occurs without gnome (actually,
with only X and an xterm, without even a window manager.)

$ uname -a
Linux hurd 2.6.2 #7 Fri Feb 13 15:35:02 CET 2004 i686 GNU/Linux
$ COLUMNS=200 dpkg -l | grep xserver
ii  xserver-common   4.3.0.dfsg.1-6
files and utilities common to all X servers
ii  xserver-xfree86  4.3.0.dfsg.1-6
the XFree86 X server

All problems mentioned can be "solved" by forcing a redraw, for example you
switching to and from a different virtual desktop.  Having to do that all the
time is quite annoying though.

Thanks,
Bas Wijnen

-- 
I encourage sending me encrypted e-mail.
Please send the central message of e-mails as plain text in the message body,
   not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
for more information, see http://129.125.47.90/e-mail.html


pgpCOas0ZTdRO.pgp
Description: PGP signature