From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: Deep color support and bug fixes Date: Fri, 24 Jun 2011 10:32:16 +0100 Message-ID: References: <1305136090-5858-1-git-send-email-jbarnes@virtuousgeek.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 43EA79E70A for ; Fri, 24 Jun 2011 02:32:20 -0700 (PDT) In-Reply-To: <1305136090-5858-1-git-send-email-jbarnes@virtuousgeek.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Jesse Barnes , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, 11 May 2011 10:48:01 -0700, Jesse Barnes wrote: > A couple of bug fixes, and some patches to support deep color on Intel > chipsets. My main concern with extended fb->depth support is in validation that the crtc+encoder supports the requested fb, and that we have sufficient logging of the bpc (inc fb->depth/fb->bpp) changes during modeswitch. There are some restrictions that you add in mode_set() that need to be raised to intel_framebuffer_init() so that the error is detected early. But we should also be checking the requested fb->depth is valid during preparation, and error early. >>From the DDX, we declare the fb depth before we know what's attached, and once established that depth is permanent (if only due to the complexity of invalidating all client cached state for the old depth). So we're stuck with the user getting it right. In a composite-only, pixmap-per-crtc model changing depths on the fly is possible and clients can choose to take advantage of the deep-color support, or not. So here goes -depth 30... -Chris -- Chris Wilson, Intel Open Source Technology Centre