[Call for Testing] X.org 7.5 for FreeBSD
rnoland at FreeBSD.org
Sun Mar 21 13:47:14 UTC 2010
On Sun, 2010-03-21 at 03:06 -0700, Garrett Cooper wrote:
> 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
Yes, the 2.8+ driver requires GEM for drm and the 2.10+ driver requires
KMS. They keep removing code and making it that much more difficult to
keep things going. The situation that I generally find myself in, is
that in order to give radeon users newer/better code, I have to break
Intel. Intel tends to take up an unreasonable amount of time for me to
keep it functional.
Robert Noland <rnoland at FreeBSD.org>
More information about the freebsd-ports