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 -- Ubuntu-x mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
