Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[James Robertson]

> Can you try a newer kernel?  3.6 or 3.7?  That may help with the
> modesettings.  As for the acceleration, corruption, you might try a
> newer version of mesa.

I cheated a little and tried the latest aptosid kernel
linux-image-aptosid-amd64_3.6-12_amd64  - same screen corruption
issues.

I followed some documentation and started to compile and install the
latest mesa on Sid...  I gave up after a few hours and as a test
installed Arch as it has a new Kernel 3.6.3-1 and the latest Mesa
9.0-1 - Still had screen corruption issues.

Bad for a Debian bug report, sorry about that but I was getting a bit
frustrated.

I can't help but think it's something to do with the monitors.  I
mean, why would a different model monitor (Benq) that has native
1920x1080 work fine when used paired with one of my AOC's?  But using
the 2 identical model AOC's causes the problem?

I am going to try fglrx on Arch for a test.


-- 
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/CAMALoy9fZt8CEVt0x3rSu=1c7u9m-5ul1sahhhqqph3feg5...@mail.gmail.com

Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[James Robertson]

> The only other option I was going to try was using a Display port to
> DVI adapter from the side of my laptop to replace the VGA from the
> docking station.  If I purchase one to  try that I'll let you know.

I bought a an Active display port adapter for my laptop.  That won't
even work with resolutions above 1280x1024 under Debian (works fine up
to native 1980x1080 res on Windows 7).

I wanted to use one of my monitors in portrait mode but the the
rotation would not work if I had Option "NoAccel" "true".  Of course
disabling it meant I get the hideous screen corruption.

All of this works fine on Windows 7 with DVI/VGA or Display Port so at
least I can confirm it's not a hardware limitation.

I am quite bummed to have this problem.  Can anyone suggest ways in
which I can troubleshoot/resolve it?

Thanks


-- 
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/camaloy_qnu3_kwn9gc9jrw+koqjvzpreocnvdjt4zsgxe+t...@mail.gmail.com

Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[James Robertson]

Update...  Setting option

Option "NoAccel" "true"

Has fixed the problem.  I haven't noticed any problems having this
enabled in the way I use my computer, videos, glxgears etc. all work
ok.

So I suppose this bug report can be closed if desired.

The only other option I was going to try was using a Display port to
DVI adapter from the side of my laptop to replace the VGA from the
docking station.  If I purchase one to  try that I'll let you know.

Regards,

James


-- 
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/camaloy8cowo8foupomgxl0px1oj2hfwq6hla61ml_qpsztm...@mail.gmail.com

Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[James Robertson]

On 2 August 2012 20:31, Michel Dänzer  wrote:
> Thanks. That's not what we generally call 'tearing' but looks like some
> kind of intermittent display corruption.
>
> Unfortunately, I don't have any ideas offhand what could cause that.

I did some more testing and it seems as though the monitor,
combination of identical monitor models or VGA port on the monitors
might be the issue.

The monitors I am using are identical AOC's.  Product Name:
e2250Swda, Model No:  215LM00019.  I had a older spare Benq monitor
E2200HD with native resolution of 1920x1080 and swapped it with the
VGA connected AOC.  Everything worked fine on both displays with
1920x1080 without disabling EXAPixmaps!
I then swapped it around so AOC on VGA and Benq on DVI and the
corruption came back.  I also swapped out the AOC's in case the issue
was with one of them but same problem on both.

Previously even if I disabled the VGA port with the AOC attached to
it, the AOC on the DVI port would still get display corruption.  With
the Benq connected to VGA but disabled no corruption occurs on (either
of) the DVI connected AOC.

I have attached an xrandr --verbose for both combinations in case it
shows something useful.  I couldn't see anything that might explain
why sorry.

Thanks again.

James
Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 8192 x 8192
DVI-0 connected 1920x1080+0+0 (0x55) normal (normal left inverted right x axis 
y axis) 477mm x 268mm
Identifier: 0x51
Timestamp:  324965
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   0
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID:
000009d10c794554
27120103802f1a782e3585a656489a24
125054a56bba710081408100950f8180
9500b3000101023a801871382d40582c
4500dd0c111e00ff004e3938
30343134373032360a2000fd0032
4c1e5e15000a20202020202000fc
0042656e5120453232303048440a0042
load detection: 1 (0x0001)  range:  (0,1)
underscan vborder: 0 (0x)   range:  (0,128)
underscan hborder: 0 (0x)   range:  (0,128)
underscan:  off
supported: off  on   auto
coherent: 1 (0x0001)range:  (0,1)
  1920x1080 (0x55)  148.5MHz +HSync +VSync *current +preferred
h: width  1920 start 2008 end 2052 total 2200 skew0 clock   67.5KHz
v: height 1080 start 1084 end 1089 total 1125   clock   60.0Hz
  1680x1050 (0x56)  146.2MHz -HSync +VSync
h: width  1680 start 1784 end 1960 total 2240 skew0 clock   65.3KHz
v: height 1050 start 1053 end 1059 total 1089   clock   60.0Hz
  1280x1024 (0x57)  135.0MHz +HSync +VSync
h: width  1280 start 1296 end 1440 total 1688 skew0 clock   80.0KHz
v: height 1024 start 1025 end 1028 total 1066   clock   75.0Hz
  1280x1024 (0x58)  108.0MHz +HSync +VSync
h: width  1280 start 1328 end 1440 total 1688 skew0 clock   64.0KHz
v: height 1024 start 1025 end 1028 total 1066   clock   60.0Hz
  1440x900 (0x59)  136.8MHz -HSync +VSync
h: width  1440 start 1536 end 1688 total 1936 skew0 clock   70.6KHz
v: height  900 start  903 end  909 total  942   clock   75.0Hz
  1440x900 (0x5a)  106.5MHz -HSync +VSync
h: width  1440 start 1520 end 1672 total 1904 skew0 clock   55.9KHz
v: height  900 start  903 end  909 total  934   clock   59.9Hz
  1280x960 (0x5b)  108.0MHz +HSync +VSync
h: width  1280 start 1376 end 1488 total 1800 skew0 clock   60.0KHz
v: height  960 start  961 end  964 total 1000   clock   60.0Hz
  1280x800 (0x5c)   83.5MHz +HSync -VSync
h: width  1280 start 1352 end 1480 total 1680 skew0 clock   49.7KHz
v: height  800 start  803 end  809 total  831   clock   59.8Hz
  1152x864 (0x5d)  108.0MHz +HSync +VSync
h: width  1152 start 1216 end 1344 total 1600 skew0 clock   67.5KHz
v: height  864 start  865 end  868 total  900   clock   75.0Hz
  1152x720 (0x5e)   67.3MHz -HSync +VSync
h: width  1152 start 1208 end 1328 total 1504 skew0 clock   44.7KHz
v: height  720 start  721 end  724 total  746   clock   60.0Hz
  1024x768 (0x5f)   78.8MHz +HSync +VSync
h: width  1024 start 1040 end 1136 total 1312 skew0 clock   60.1KHz
v: height  768 start  769 end  772 total  800   clock   75.1Hz
  1024x768 (0x60)   65.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1344 skew0 clock   48.4KHz
v: height  768 start  771 end  777 total  806   clock   60.0Hz
  

Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[James Robertson]

On 22 July 2012 13:20, James Robertson  wrote:
> On 21 July 2012 03:45, Michel Dänzer  wrote:
>>
>> Can you elaborate on what exactly 'tearing and corruption' means?
>
> I have created a brief video to show the tearing.  It occurs when
> basically any input occurs such as typing, moving the mouse and as per
> the video moving windows.
>
> https://docs.google.com/open?id=0B2vLcjUrgXL-aUdWekU0dE9qbHM
>
>> Does booting with radeon.disp_priority=2 on the kernel command line
>> help?
>
> No
>
>> Please provide the output of xrandr --verbose for each case
>
> Please see attached txt file.
>
> On 21 July 2012 04:33, Alex Deucher  wrote:
>> Also note that rendering can only be synchronized to one head at a
>> time to avoid tearing.  If you have windows that span multiple heads,
>> you may get tearing on the non-synced heads.
>
> I don't fully understand the technical side of what you have described
> but wouldn't this mean tearing should only occur when using multiple
> monitors?  I get tearing on DVI-0 or VGA-0 standalone.
>
> I would also note that the tearing is worse when using both DVI-0 and
> VGA-0 together.  I also physically removed DVI-0 and visa versa for
> VGA-0 and still had the problem.
>
> Thanks

Whilst watching a flash video in Chromium this evening, I scrolled
down the web page and noticed the tearing even when I had "EXAPixmaps"
"off".  The tearing was not as severe, but nonetheless occurred.

As a quick test I tried setting the VGA-0 Display to 1680x1050 (DVI-0
still at 1920x1080) and it was fine.  Using just DVI-0 standalone
@1920x1080 also had tearing.

Thanks


--
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/CAMALoy_2OT00eyb+mjqMGCNQ=KnTZzb8M=napxitducp8tn...@mail.gmail.com

Bug#641197: patch submitted

[James Robertson]

It appears as though a patch has been submitted for this.

http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=6f1d7bcdd461b1f6cc64370793f52d7c170187d0



-- 
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/CAMALoy_2HyEoV=6iK=1f9eJ8EZ6oBTEzH=3uks6zrdwxgdq...@mail.gmail.com

Bug#641197: libxft2: Include Ubuntu LCD filter patch

[James Robertson]

Package: libxft2
Version: 2.2.0-3
Severity: wishlist

Dear Maintainer,

xft does not utilise the lcdfilter option.  An example is when using
Openbox and GTK2 based apps with the following configuration in
~/fonts.conf.

 
   
   lcddefault
   
 

The result is that the fonts rendered by Openbox look slightly different to 
those rendered by GTK2.

I researched and found that Ubuntu had added a patch in the following version 
that utilises lcdfilter:

http://archive.ubuntu.com/ubuntu/pool/main/x/xft/xft_2.1.14-2ubuntu1.diff.gz

I tested the patch on 2.2.0-3 and it has worked well and my Window Manager 
fonts now look the same as GTK2.
Attached is the patch (100-libXft-2.1.10-lcd-filter-3.patch)

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

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

Versions of packages libxft2 depends on:
ii  libc6  2.13-20  
ii  libfontconfig1 2.8.0-3  
ii  libfreetype6   2.4.6-2  
ii  libx11-6   2:1.4.4-1
ii  libxrender11:0.9.6-2
ii  multiarch-support  2.13-20  

libxft2 recommends no packages.

libxft2 suggests no packages.

-- no debconf information
--- a/src/xftdpy.c
+++ b/src/xftdpy.c
@@ -369,6 +369,10 @@
 	goto bail1;
 if (!_XftDefaultInitInteger (dpy, pat, FC_RGBA))
 	goto bail1;
+#ifdef FC_LCD_FILTER
+if (!_XftDefaultInitInteger (dpy, pat, FC_LCD_FILTER))
+	goto bail1;
+#endif
 if (!_XftDefaultInitBool (dpy, pat, FC_ANTIALIAS))
 	goto bail1;
 #ifdef FC_EMBOLDEN
@@ -521,6 +525,14 @@
 			  XftDefaultGetInteger (dpy, FC_RGBA, screen, 
 		subpixel));
 }
+#ifdef FC_LCD_FILTER
+if (FcPatternGet (pattern, FC_LCD_FILTER, 0, &v) == FcResultNoMatch)
+{
+	FcPatternAddInteger (pattern, FC_LCD_FILTER,
+			 XftDefaultGetInteger (dpy, FC_LCD_FILTER, screen,
+		   FC_LCD_DEFAULT));
+}
+#endif
 if (FcPatternGet (pattern, FC_MINSPACE, 0, &v) == FcResultNoMatch)
 {
 	FcPatternAddBool (pattern, FC_MINSPACE,
--- a/src/xftfreetype.c
+++ b/src/xftfreetype.c
@@ -469,6 +469,21 @@
 	goto bail1;
 }
 
+#ifdef FC_LCD_FILTER 
+/*
+ * Get lcd_filter value
+ */
+switch (FcPatternGetInteger (pattern, FC_LCD_FILTER, 0, &fi->lcd_filter)) {
+case FcResultNoMatch:
+	fi->lcd_filter = FC_LCD_DEFAULT;
+	break;
+case FcResultMatch:
+	break;
+default:
+	goto bail1;
+}
+#endif
+
 /*
  * Get matrix and transform values
  */
--- a/src/xftglyphs.c
+++ b/src/xftglyphs.c
@@ -21,27 +21,18 @@
  */
 
 #include "xftint.h"
-#include 
 
 #if HAVE_FT_GLYPHSLOT_EMBOLDEN
 #include 
 #endif
 
-static const intfilters[3][3] = {
-/* red */
-#if 0
-{65538*4/7,65538*2/7,65538*1/7 },
-/* green */
-{65536*1/4, 65536*2/4, 65537*1/4 },
-/* blue */
-{65538*1/7,65538*2/7,65538*4/7 },
+#if FREETYPE_MAJOR*1 + FREETYPE_MINOR*100 + FREETYPE_PATCH < 20202
+#  error  "FreeType 2.2.2 or later required to compile this version of libXft"
 #endif
-{65538*9/13,65538*3/13,65538*1/13 },
-/* green */
-{65538*1/6, 65538*4/6, 65538*1/6 },
-/* blue */
-{65538*1/13,65538*3/13,65538*9/13 },
-};
+
+#include FT_OUTLINE_H
+#include FT_LCD_FILTER_H
+#include FT_SYNTHESIS_H
 
 /*
  * Validate the memory info for a font
@@ -69,6 +60,295 @@
 		font->glyph_memory, glyph_memory);
 }
 
+
+/* we sometimes need to convert the glyph bitmap in a FT_GlyphSlot
+ * into a different format. For example, we want to convert a
+ * FT_PIXEL_MODE_LCD or FT_PIXEL_MODE_LCD_V bitmap into a 32-bit
+ * ARGB or ABGR bitmap.
+ *
+ * this function prepares a target descriptor for this operation.
+ *
+ * input :: target bitmap descriptor. The function will set its
+ *  'width', 'rows' and 'pitch' fields, and only these
+ *
+ * slot  :: the glyph slot containing the source bitmap. this
+ *  function assumes that slot->format == FT_GLYPH_FORMAT_BITMAP
+ *
+ * mode  :: the requested final rendering mode. supported values are
+ *  MONO, NORMAL (i.e. gray), LCD and LCD_V
+ *
+ * the function returns the size in bytes of the corresponding buffer,
+ * it's up to the caller to allocate the corresponding memory block
+ * before calling _fill_xrender_bitmap
+ *
+ * it also returns -1 in case of error (e.g. incompatible arguments,
+ * like trying to convert a gray bitmap into a monochrome one)
+ */
+static int
+_compute_xrender_bitmap_size( FT_Bitmap*  target,
+  FT_GlyphSlotslot,
+  FT_Render_Mode  mode )
+{
+FT_Bitmap*  ftbit;
+int width, height, pitch;
+
+if ( slot->format != FT_GLYPH_FORMAT_BITMAP )
+return -1;
+
+// compute the size of the final bitmap
+ftbit  = &slot->bitmap;
+
+width  = ftbit->width;
+height = ftbit->rows;
+pitch  = (width+3) & ~3;
+
+switch ( ftbit->pixel_mode )
+