[ANNOUNCE] xf86-video-intel 2.99.905
chris2553 at gmail.com
Mon Nov 4 10:19:51 CET 2013
On 10/31/13 16:09, Chris Clayton wrote:
> On 10/31/13 13:58, Chris Wilson wrote:
>> On Thu, Oct 31, 2013 at 08:29:02AM +0000, Chris Clayton wrote:
>>> Hi again.
>>> On 10/30/13 17:12, Chris Clayton wrote:
>>>> Hi Chris,
>>>> I've been trying out this driver and have been getting some text rendering problems on my KDE-3.5.10 desktop. I've also
>>>> grabbed the tar ball of the latest git version of the driver (ed282456240cc0a7ae9a235ea8aea14a8b8a54ef) and get the same
>>>> problem. I do not see the problem with 2.99.904.
>>>> The problem is that if I open a new konqueror window, place the mouse cursor in it and then scroll the window contents
>>>> with the mouse wheel, I get text in the window decorations at the bottom of the window. I've attached a snapshot of an
>>>> affected konqueror window (hope it gets through your and X.org's mail filters). Sometimes the text also spills out on to
>>>> the desktop itself and remains there until that part of the screen is refreshed for some reason - e.g. drag a window
>>>> onto and then off the area. I have a snapshot of that too and can send it if it would help, although I guess that's
Another data point. Over the weekend I was compiling an update to ImageMagick. In fact I was compiling it on my desktop
and my laptop at the same time, with the konsole window from the desktop opened on the laptop (via DISPLAY=laptop:0).
The attached screenshot shows that the leakage I described in my original email can happen horizontally as well as
Would it be useful if I opened a bugzilla report for this problem?
>>>> Do you have any immediate ides which change might be the "culprit" and I could try reverting? If not, I can clone the
>>>> git tree and do a bisect.
>>> I've done a bisect and I ended up with:
>>> ec0866e86d365ae3fd9790b1b263d49fc4981220 is the first bad commit
>>> commit ec0866e86d365ae3fd9790b1b263d49fc4981220
>>> Author: Chris Wilson <chris at chris-wilson.co.uk>
>>> Date: Wed Oct 16 22:39:54 2013 +0100
>>> sna/glyphs: Fix computation of extents for long strings
>>> And make sure we consider such overflowing strings for correct clipping
>>> against Windows.
>>> To offset the cost of doing a full extents check (~10% on aa10text), we
>>> introduce an approximate extents query (~1% on aa10text). The disparity
>>> should be rare, and should be an overestimate to force redundant
>>> Reported-by: Clemens Eisserer <linuxhippy at gmail.com>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70541
>>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>>> :040000 040000 9f18aa33be6c0af2cd6e527943efa8dfe401c7cb 65a7be4deacaacc9c6f90a911317f40b37299bf4 M src
>>> Unfortunately, the commit doesn't revert cleanly and looks a bit too complex for me to start hacking out. However, I
>>> have confirmed that a driver built from a tarball up to and including the preceding does not have the problem, whereas
>>> one built from the tarball that includes up to and including this commit does.
>> That's odd as that regression was fixed shortly after
>> commit f81a7f7192a821654bc72a6b34625a6367cb8479
>> Author: Chris Wilson <chris at chris-wilson.co.uk>
>> Date: Fri Oct 18 09:19:14 2013 +0100
>> sna/glyphs: Remove glyph_approx_extents
>> It didn't consider the height of the glyph above the baseline, i.e. it
>> was fundamentally flawed. The only thing to do is to make sure that
>> glyph_extents() is sufficiently fast never to show up in profiles.
>> (Until then QA should spot the ~10% regression.) An alternative would be
>> to feed the drawable clip extents to the render engine and avoid manual
>> clipping if the clip region covers the whole drawable.
>> Reported-by: Clemens Eisserer <linuxhippy at gmail.com>
>> Reported-by: Jiri Slaby <jirislaby at gmail.com>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70552
>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>> But the description of your symptoms does match up with
>> Can you please verify that you have tested with the latest? An Xorg.0.log
>> would be the best proof.
> Attached are two Xorg.0.log files. As the names indicate, one is for the released 2.99.905 driver and the other is for a
> driver up to and including 82e6d41c2f4f343bd1854d3d8ee4b624b5d68971, which, 30 minutes or so ago, was the latest commit.
> Both drivers exhibit the problem I described yesterday.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 217928 bytes
Desc: not available
More information about the xorg