[ubuntu-x] ANN: Kernel Mode-Setting for Intel Graphics

[Bryce Harrington]

On Tue, Jun 23, 2009 at 08:42:56PM -0400, Geir Ove Myhr wrote:
> Just a couple of questions about troubleshooting and triaging KMS bugs:
> 
> 1. Where is the right place to file KMS bugs upstream? I think I have
> seen some being filed under Product=xorg. Component=Driver/intel at
> bugs.freedesktop.org and that it has worked out all right since it is
> after all the same people that write the KMS kernel code and the 2D
> driver modesetting code, but I guess it is not really the right place.

No, you're right, it is still the right place.  The same upstream folks
we've been working with before on these bugs will be working on them in
the kernel code.

So for now, we keep filing KMS bugs to freedesktop.org against xorg, at
least until we're given different directions.

> 2. What packages do we apply patches to in order to test them? I have
> helped ubuntu bug reporters by providing binary packaged
> xserver-xorg-video-intel with upstream debug patches for testing on a
> couple of occations (e.g. LP #379157 and #384660).

Both of those bugs are examples of things that will need a kernel patch
instead of an -intel driver patch to solve.  So patches for these would
be going against something in the drivers/gpu/drm/ directory in the
kernel.

> Would I now need to build the ubuntu kernel? Is it much more involved
> than building the -intel driver?

At least it requires building the i915 kernel module.  Building the
kernel is not really that much more complex than building X bits;
it has a different configuration system, but it's not hard to use and
probably we won't need to mess with it at all.  A nice plus is that the
kernel doesn't really have messy dependencies that are always changing,
like we have with X, so that regard it is actually rather less involved
than building -intel.

The particular portion of the kernel we're looking at is the "Direct
Rendering Manager" (DRM).  Historically, this is the section of code
that did the 3D hardware accelerated rendering stuff.  Now this chunk of
code also handles memory management (GEM), and mode-setting.

Look at drivers/gpu/drm/drm_edid.c for the EDID stuff, including monitor
quirks.  The video card quirks seem to be missing, but presumably would
go into the drivers/gpu/drm/i915/ directory.

> 3. Where is the upstream git-master for KMS source code? I looked at
> http://git.kernel.org/ and it wasn't obvious which tree to use.

Yeah, it's a tad complicated there, but from our perspective I think we
can simplify it down.  For -intel there are two git-masters we care about.

The first is David Airlie's drm-2.6 repo, which has what ends up being
sent to Linus:

  http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next

In particular, 'drm-next' is the branch to look at, although it appears
'drm-fixes' is the more active one at the moment.


The second is Eric Anholt's drm-intel repo, which is what Intel develops
and periodically sends to David for merging:

  http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=summary

He has a drm-intel-next branch, which is probably what we'll be
interested in the most.


David Airlie's tree we care about because that's what Ubuntu's kernel team
will be pulling from.

Eric Anholt's tree we care about because that's where the upstream
development work for -intel goes on, and where we will be sending our
patches.


> 4. As far as I understand everything that involves communication with
> hardware is now handled by KMS. That is, failures in monitor
> detection, failure to get EDID information, incorrect parsing of EDID,
> etc. are now KMS bugs. Right? Anything more to look out for?

Yep, that's my understanding as well.

Other things to look out for include incorrect resolution setup for any
reason, misbehavior when switching resolutions, and anything that occurs
when vt switching or doing a suspend/resume.


Hope this helps,
Bryce