From patchwork Wed Apr 20 19:38:48 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jesse Barnes X-Patchwork-Id: 722791 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by demeter1.kernel.org (8.14.4/8.14.3) with ESMTP id p3KJdF7u028222 for ; Wed, 20 Apr 2011 19:39:36 GMT Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 268E89EF72 for ; Wed, 20 Apr 2011 12:39:15 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by gabe.freedesktop.org (Postfix) with SMTP id 8E93A9E70A for ; Wed, 20 Apr 2011 12:38:56 -0700 (PDT) Received: (qmail 5320 invoked by uid 0); 20 Apr 2011 19:38:52 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 20 Apr 2011 19:38:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=virtuousgeek.org; h=Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:X-Identified-User; b=BLDnu9aNwes5EroY5dCabMg8hT5Y0LFVgxdwMnOLr+EDyRDpeqj0o2N5tnTYAyeMNpQwnhs+H1JDntWtwEYQTsgceW1aLmtIgTXeWLtWBHKIEnzYTyqd09XeRxD4FdX+; Received: from c-67-161-37-189.hsd1.ca.comcast.net ([67.161.37.189] helo=jbarnes-desktop) by box514.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QCdEi-0008Vi-7M; Wed, 20 Apr 2011 13:38:52 -0600 Date: Wed, 20 Apr 2011 12:38:48 -0700 From: Jesse Barnes To: Andrew Lutomirski Message-ID: <20110420123848.6a78ff68@jbarnes-desktop> In-Reply-To: References: <87pqyeklc3.fsf@pollan.anholt.net> <1280243037.2353.62.camel@atropine> <20110420120511.65632bd6@jbarnes-desktop> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-Identified-User: {10642:box514.bluehost.com:virtuous:virtuousgeek.org} {sentby:smtp auth 67.161.37.189 authed with jbarnes@virtuousgeek.org} Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] rfc: breaking old userspace gamma for 10-bit support X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Wed, 20 Apr 2011 19:39:40 +0000 (UTC) > > Andrew, do you have anything hacked together for this yet? > > Nope. I gave up because I couldn't even get the mode to set. :) Ok well you should be able to now. :) Using the patchset I posted earlier along with the two attached patches, the testdisplay program in intel-gpu-tools will set a 30bpp mode and draw some nice gradients (though without a 10bpc gamma ramp loaded). > One issue was that the RandR apis aren't really designed for cards > that can accept more than one gamma ramp size. Someone (I forget who) > suggested adding a display property to control it. It might be > possible to kill two birds with one stone by adding a property with > two settings: > > - Low depth: the logic you implemented: the bit depth is set to match > the framebuffer when possible and the gamma ramp size is set according > to the framebuffer depth. > - High depth: the bit depth is set to the maximum that the encoder, > connector, and monitor support at the requested resolution and the > gamma ramp size is set to whatever gives the highest precision in each > entry. Well, I haven't implemented anything, gamma-wise. If you select say 30bpp when you start X *and* you have a kernel with my patches applied, you'll get 10bpc all the way out to the display if it supports it. If the display does *not* support 10bpc, the pipe will dither it to 8bpc before sending it to the encoder. Current DDX on an old kernel will fail to create an FB with 10bpc because the kernel will reject it. So I guess I don't understand your low vs high distinction; the bit depth is ultimately tied to the framebuffer and its allocation. Correction happens after the fact in hw when the plane feeds bits to the pipe. Of course that's all separate from the color correction that happens before the bits get to the pipe. For that we have to wait until the DDX starts up and decides what to do. In a 30bpp mode, I'd hope it would default to using the 10 bit gamma ramp (1024 entries of 30 bits each), which I think is what you had in mind? For that, we'd just need to check whether we can hand the kernel a 1024 entry table, then do it if possible, otherwise fall back to the existing 256 entry code. diff --git a/tests/testdisplay.c b/tests/testdisplay.c index 5bf5183..eeff97e 100644 --- a/tests/testdisplay.c +++ b/tests/testdisplay.c @@ -369,6 +369,8 @@ allocate_surface(int fd, int width, int height, uint32_t depth, uint32_t bpp, format = CAIRO_FORMAT_RGB24; break; case 30: + format = CAIRO_FORMAT_RGB30; + break; case 32: format = CAIRO_FORMAT_ARGB32; break;