Date: Thu, 28 Jul 2011 17:10:52 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Koop Mast <kwm@FreeBSD.org>, x11@FreeBSD.org Subject: Re: Kernel Intel GPU driver and ports Message-ID: <4E316DEC.704@FreeBSD.org> In-Reply-To: <1311435693.2009.5.camel__41844.2894974307$1311435779$gmane$org@crashalot.rainbow-runner.nl> References: <20110723131613.GF17489@deviant.kiev.zoral.com.ua> <1311429114.1960.39.camel@crashalot.rainbow-runner.nl> <20110723140413.GG17489@deviant.kiev.zoral.com.ua> <1311435693.2009.5.camel__41844.2894974307$1311435779$gmane$org@crashalot.rainbow-runner.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
on 23/07/2011 18:41 Koop Mast said the following: > On Sat, 2011-07-23 at 17:04 +0300, Kostik Belousov wrote: >> From what I see using web browser, your plan is to update the stack in >> the ports. I suspect this might cause problems for non-Intel cards or >> for those who use in-tree i915.ko. In particular, new Mesa might not >> work. > > That is a good possibility. I only have a sandybridge intel card to > test. The only issue currently know are the nouveau driver (which needs > mesa 7.4.4 and doesn't work with 7.6.x), and the old intel driver. > > If it turns out other drivers don't work with the new setup, obviously > we need to make it so that they will work. Although I'm currently got > half a mind to just drop the nouveau driver. I just would like to report that with ports from the experimental x11 repository everything still works fine for me[*] with radeon hardware and driver, including OpenGL stuff (glxgears, KDE4 whistles and bells). [*] It's better to say that there are no regressions as the following long-standing bugs still affect me: 1. https://bugs.freedesktop.org/show_bug.cgi?id=28181 I will submit my local patch against xorg-server-1.10.3 sources a little bit later. 2. https://bugs.freedesktop.org/show_bug.cgi?id=27627 https://bugs.freedesktop.org/show_bug.cgi?id=28607 The problem can be considered minor but I still prefer to build xf86-video-ati from older sources. That doesn't introduce any regressions for me comparing to the latest version of the driver and does make the problem go away. I wish for some tool that could compare code paths before and after the problematic commit to find the regression. Apparently the problem affects only non-KMS case [**]. [**] Where KMS may actually stand for DRI2, GEM-over-TTM. It seems that radeon CS (command stream?) ioctls are only used in KMS environment. People have been known to call that collection of features as a single "KMS" super-feature. Maybe because they've come together in Linux and it is not expected that one of them is present but not other. But I have diverged from the main topic of this report. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E316DEC.704>