Re: Intel GPU driver import

On Mon, May 14, 2012 at 02:31:38PM +0300, Andriy Gapon wrote:
> on 13/05/2012 00:39 Konstantin Belousov said the following:
> > With r235375, all required VM support for new Intel GPU driver was
> > committed into HEAD. There are still some things to improve and
> > change, but now the all.14.9.patch does not touch anything outside agp
> > or drm.  This allows to start the process of importing the new Intel
> > GPU driver into HEAD.
> > 
> > I am writing this as initial head-up and to discuss some questions,
> > for which I do have answers but would prefer to have additional
> > feedback from people doing Xorg work.
> > 
> > The patch as-is just replaces the Intel DRI1 bits with DRI2
> > driver. Patch added most of the KMS infrastructure into DRM
> > core. Also, patch completely changed the locking model used by Intel
> > driver. I made absolutely minimal efforts needed to keep other DRI1
> > drivers compilable. Despite that, I got several surpising reports that
> > Radeon DRI1 still works.
> > 
> > That said, for import I can (first choice) just apply the patch,
> > replacing the Intel driver with new one. Or (second choice) I may
> > create another directory, say sys/dev/drm2, and import _only_ Intel
> > driver together with updated DRM core, there.
> > 
> > The positive points to the second approach is that we still have older
> > kernel drivers around. Also, I have more freedom in changing the DRM
> > core, without fearing breakage in the DRI1 land. Since I do not really
> > want to deal with Gen2-3 hardware, and VGA console does not work with
> > new driver (yet), there are definite advantages.
> > 
> > On the other hand, driver automatic loading will not work with
> > dev/drm2 approach. New driver have to use different module name to
> > co-exist with dri1 driver, so ddx driver cannot load new driver by old
> > name. As result, users need to manually kldload new driver before
> > starting Xorg.
> > 
> > My own preference is to implement second choice and put the driver
> > into dev/drm2.
> 
> 
> I think that I would prefer this path too for the reasons you already mentioned above:
> - potential problems for other drivers
> - need to easily fallback for those who use the intel driver and may run into
> problems with the new code
> - some missing bits related to kms like syscons support, which makes
> troubleshooting harder
> 
> BTW, I think that we should patch xf86-video-intel port to try loading
> "i915kms"/"i915gem"/... if i915 is not available.  I think that that should be
> fine for a FreeBSD-specific patch.
> Alternatively, we could keep the same names for drivers/modules and then have a
> global knob (WITH_DRM2/WITH_KMS/etc) to select which source is code is used to
> build the drivers.
No, I want both drivers to be presented in /boot/kernel in default 
install. Also, I want to avoid forcing user to recompile her kernel for
driver switching.

Regarding the patching xf86-video-intel, I am completely fine with this,
but the work should be done by xorg porters. Assuming they will to do
this and then maintain the (should be quite trivial) patch.

And I like the 'i915kms' name for the module. This and drm2.ko for core
drm infrastructure sound good, thank you.