[Call for Testing] X.org 7.5 for FreeBSD

[Garrett Cooper]

On Sun, Mar 21, 2010 at 2:42 AM, jhell <jhell at dataix.net> wrote:
>
> On Sun, 14 Mar 2010 23:57, Robert Noland wrote:
> In Message-Id: <1268625423.2608.348.camel at balrog.2hip.net>
>
>> On Sun, 2010-03-14 at 15:02 -0600, Warren Block wrote:
>>>
>>> On Sat, 13 Mar 2010, Robert Noland wrote:
>>>
>>>> Ok, now that agp seems to be working... I have created a port for the
>>>> 2.9.1 version of the Intel driver.  You will need to uninstall the
>>>> existing intel driver and install this one.  You still won't have drm,
>>>> but should be a good bit better than vesa...
>>>>
>>>> http://people.freebsd.org/~rnoland/xf86-video-intel29.tar.gz
>>>
>>> Problem: after switching away from X with ctrl-alt-f4, on switching back
>>> the screen is corrupted.  Stuff that's drawn on top of it after that
>>> point is usually correct.  The clear areas on this image were caused by
>>> GIMP redrawing them; before opening it, they were the same as the strip
>>> on the right edge.
>>
>> Ok, I'm not surprised... I spent a little time playing with the 2.9.1
>> driver on my g45 today.  Basically... It is horrid...
>>
>
> Damn! I rely on this driver for my main machine that has a i845G in it. This
> thing tends to keep getting more shitty with every release. Or I suppose I
> could cough it up to ancient hardware to... ;)
>
> The last Intel driver I remember working seamlessly with my i845G with no
> known side effects and without HAL was 2.3*. After that it somehow became
> very dependent on HAL and if compiled without HAL would pretty much disable
> you(being me) from switching from X to the console and back again resulting
> in a reboot after a borked screen.
>
> Now that I see the following I sort of understand whats happening with this.
> And eventually this hardware will have to be replaced :(
>
>> When Intel chose to remove all non-GEM support for the 2.8 series
>> driver, what is actually going on is that it is calling into
>> libdrm_intel's fake buffer manager and doing ton's of memcpy's.  It
>> seems to be sort of ok as long as it is just basic 2d, but enable
>> composite in metacity and it falls on it's face...  Granted all of my
>> machines run with WITNESS and INVARIANTS, but you can almost count the
>> pixels as they are drawn...
>>
>> I was thinking that Intel had actually killed the fake buffer manager as
>> well, but it looks like it does still exist in libdrm git.  Perhaps it
>> was that they removed it from mesa.  At any rate, they don't deny that
>> it is broken, nor do they test it or have any intention of fixing it...
>>
>> The only reason for using the 2.9.1 driver that I can think of is if you
>> have an Ironlake chipset, which isn't supported in 2.7.1.  I now have to
>> decide whether to spend time back porting Ironlake support to 2.7.1 or
>> spend time on GEM.

    Intel's killing off non-GEM support slowly and surely, so we have
to port GEM or die a slow and painful death on Intel accelerated
hardware: http://www.phoronix.com/scan.php?page=news_item&px=Njc2NA ,
http://software.intel.com/sites/oss/project_spotlight.htm . Kind of
sad now that anholt is no longer really a contributing member to
FreeBSD.
Thanks,
-Garrett