dri-devel Digest, Vol 12, Issue 16

[Mario Kleiner]

> Message: 2
> Date: Thu, 3 Mar 2011 16:51:28 -0800
> From: Jesse Barnes <jbarnes at virtuousgeek.org>
> Subject: Re: vblank problem (and proposed fix) on crtc > 1
> To: Ilija Hadzic <ihadzic at research.bell-labs.com>
> Cc: dri-devel at lists.freedesktop.org
> Message-ID: <20110303165128.495158c9 at jbarnes-vaio.home>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 3 Mar 2011 17:34:53 -0600 (CST)
> Ilija Hadzic <ihadzic at research.bell-labs.com> wrote:
>
>> The fix/improvement I propose is to extend the request.type field
>> in drmVBlank structure with additional 5 bits that I call high_crtc
>> (there are lots of unused bits in that field). 5 bits covers for 32
>> CRTCs, which seems to be the hard limit imposed by various parts  
>> of the
>> Xorg and DDX (e.g. possible_crtcs mask in the display descriptor,
>> and the like). If high_crtc is zero, then DRM (kernel module)
>> looks at the primary/secondary flag and maps them to crtc 0 and 1
>> (backwards compatibility with older DDX or DDX for other device
>> that does not use the new high_crtc field). If it's not zero then it
>> means that the higher CRTC number is specified by DDX (i.e. userland
>> is a new DDX) and vblank is waited on the specified CRTC (this is  
>> used
>> only for crtc > 1, crtc 0 and 1, still use the old style).
>
> Yeah, I think that should work, though another option would be to just
> add a new ioctl.  That would make compat checking easy for new  
> code; it
> could just call the new ioctl and if that returned -ENOTTY it could
> fall back to the old one and throw away the CRTC info or complain if
> the count was too high.
>
> But you're right that when we re-wrote the code we fixed it to  
> handle >
> 2 CRTCs, so it should be mostly ready for that (modulo testing, which
> it sounds like you're doing already).
>
> Jesse
>

I'm all for it! On evergreen and other recent radeon's, swapbuffers  
can become really ugly without this extension.

As far as i can see, the vblank wait ioctl() is the only place (at  
least for GLX/X/ddx don't know about the other api's like EGL or  
libkms), that needs fixing for > 2 crtc's and these patches should do  
it fine. Code also looks correct to me.

Maybe a new ddx could check the (bumped) drm abi version number to  
decide if it should use the new or old method to protect against the  
"new ddx on old kernel" case?

Add a ...

Reviewed-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de>

...and a big ...

Acked-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de>

if you wish. Maybe it would be even possible to slip the small kernel  
patch into 2.6.38-rc? It is rather a bugfix than a new feature.
-mario

>
> ------------------------------
>
> Message: 3
> Date: Thu,  3 Mar 2011 17:38:04 -0800 (PST)
> From: bugzilla-daemon at freedesktop.org
> Subject: [Bug 34588] Screen corruption when running gtkperf on
> 	awesomewm
> To: dri-devel at lists.freedesktop.org
> Message-ID: <20110304013804.C9B4F130009 at annarchy.freedesktop.org>
> Content-Type: text/plain; charset="UTF-8"
>
> https://bugs.freedesktop.org/show_bug.cgi?id=34588
>
> --- Comment #2 from Jeff Cook <jeff at deserettechnology.com>  
> 2011-03-03 17:38:04 PST ---
> Yes, disabling tiling fixes it.
>
> I just tried this today and it is still occurring in new git  
> builds. I guess it
> is probably a dupe of the linked bug. I haven't tested a git build  
> of X yet,
> which apparently is the source of the bug.
>
> -- 
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi? 
> tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
>
>
> ------------------------------
>
> Message: 4
> Date: Thu,  3 Mar 2011 21:04:03 -0500
> From: Matt Turner <mattst88 at gmail.com>
> Subject: [PATCH] modeprint.c: use PRIu64 for printing uint64_t
> To: dri-devel at lists.freedesktop.org
> Message-ID: <1299204243-12379-1-git-send-email-mattst88 at gmail.com>
>
> Signed-off-by: Matt Turner <mattst88 at gmail.com>
> ---
>  tests/modeprint/modeprint.c |    7 ++++---
>  1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
> index 09b8df0..545ff40 100644
> --- a/tests/modeprint/modeprint.c
> +++ b/tests/modeprint/modeprint.c
> @@ -36,6 +36,7 @@
>  #include <stdint.h>
>  #include <unistd.h>
>  #include <string.h>
> +#include <inttypes.h>
>
>  #include "xf86drm.h"
>  #include "xf86drmMode.h"
> @@ -101,7 +102,7 @@ int printProperty(int fd, drmModeResPtr res,  
> drmModePropertyPtr props, uint64_t
>  	if (props->count_values) {
>  		printf("\tvalues       :");
>  		for (j = 0; j < props->count_values; j++)
> -			printf(" %llu", props->values[j]);
> +			printf(" %" PRIu64, props->values[j]);
>  		printf("\n");
>  	}
>
> @@ -116,7 +117,7 @@ int printProperty(int fd, drmModeResPtr res,  
> drmModePropertyPtr props, uint64_t
>  			printf("blob is %d length, %08X\n", blob->length, *(uint32_t *) 
> blob->data);
>  			drmModeFreePropertyBlob(blob);
>  		} else {
> -			printf("error getting blob %llu\n", value);
> +			printf("error getting blob %" PRIu64 "\n", value);
>  		}
>
>  	} else {
> @@ -132,7 +133,7 @@ int printProperty(int fd, drmModeResPtr res,  
> drmModePropertyPtr props, uint64_t
>  		if (props->count_enums && name) {
>  			printf("\tcon_value    : %s\n", name);
>  		} else {
> -			printf("\tcon_value    : %lld\n", value);
> +			printf("\tcon_value    : %" PRIu64 "\n", value);
>  		}
>  	}
>
> -- 
> 1.7.3.4
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu,  3 Mar 2011 21:20:52 -0500
> From: Matt Turner <mattst88 at gmail.com>
> Subject: [PATCH] don't try to build modetest without libkms
> To: dri-devel at lists.freedesktop.org
> Message-ID: <1299205252-24952-1-git-send-email-mattst88 at gmail.com>
>
> Signed-off-by: Matt Turner <mattst88 at gmail.com>
> ---
>  tests/Makefile.am |    9 +++++----
>  1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index ebf4853..01ca8b4 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -16,9 +16,6 @@ if HAVE_LIBKMS
>  SUBDIRS += kmstest
>  endif
>
> -if HAVE_INTEL
> -endif
> -
>  if HAVE_LIBUDEV
>
>  check_LTLIBRARIES = libdrmtest.la
> @@ -50,9 +47,13 @@ TESTS =						\
>  SUBDIRS += vbltest $(NULL)
>
>  if HAVE_INTEL
> +if HAVE_LIBKMS
> +SUBDIRS += \
> +	modetest
> +endif
> +
>  SUBDIRS += \
>  	modeprint				\
> -	modetest				\
>  	$(NULL)
>
>  TESTS +=					\
> -- 
> 1.7.3.4
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 4 Mar 2011 07:53:15 +0100 (CET)
> From: "Indan Zupancic" <indan at nul.nu>
> Subject: Re: [PATCH] fix backlight brightness on intel LVDS panel
> 	after 	reopening lid
> To: "Linus Torvalds" <torvalds at linux-foundation.org>
> Cc: Linux Kernel Mailing List <linux-kernel at vger.kernel.org>,	DRI
> 	mailing list <dri-devel at lists.freedesktop.org>,	Alex Riesen
> 	<raa.lkml at gmail.com>,	Tino Keitel <tino.keitel at tikei.de>,
> 	stable at kernel.org
> Message-ID:
> 	<3e6f092bd0aa54fd6b9eb524f6c87ecf.squirrel at webmail.greenhost.nl>
> Content-Type: text/plain;charset=UTF-8
>
> Hello,
>
> On Wed, February 23, 2011 02:09, Linus Torvalds wrote:
>> On Tue, Feb 22, 2011 at 2:31 PM, Tino Keitel  
>> <tino.keitel at tikei.de> wrote:
>>>
>>> I just tried 2.6.38-rc6 on my ThinkPad X61s without any other DRM
>>> related patches, and my backlight issue is gone.
>>
>> I applied Indan's fix in -rc6 (commit 951f3512dba5), since it had
>> several testers and seemed to simplify the code nicely too.
>
> Sadly, as so often in life, it's not correct. At this point I'm not  
> sure
> if it's better to revert that patch and add a correct one, or to just
> fix it up. The end result is the same I suppose. I've also found more
> documentation, namely: ACPI_IGD_OpRegion_Spec.pdf, which has the ASLE
> stuff in intel_opregion.c, and VOL_1_graphics_core.pdf, which mentions
> LBPC (I was looking at 3 before). Apparently the undocumented stuff
> the old code did was correct. What I don't understand is how BIOS
> makers could know about those bits.
>
> The good side is that that big warning in my patch description is
> invalid, something else was going on: The BIOS used LBPC to set and
> restore brightness, while the driver only used BLC_PWM_CTL after my
> patch.
>
> All credits to Intel for making something simple as backlight control
> as stupid and complex as possible:
>
> - It has two registers to control brightness, sometimes one is used,
> sometimes the other, sometimes both, and it's unknown what the BIOS
> uses, and it's undefined what registers are restored by the BIOS after
> reboot/resume.
>
> - When using ACPI and ASLE, the kernel requests a brightness change
> via a standard ACPI method, which in turns lets the BIOS generate an
> ASLE interrupt, which is handled by the driver. The brightness to set
> is between 0 and 255, and the driver is supposed to store the current
> brightness in another register. That register stores the brightness in
> percentages, which is used by the BIOS to restore brightness. How it
> does that is undefined, so it can use either register. So the BIOS
> obviously knows how to change the brightness, and it's still seemed
> like a good idea to bother the driver with it. The ASLE interface is
> a mess.
>
> All in all, after my patch, systems using ASLE and a BIOS storing
> the brightness in LBPC stopped working. The reason it works without
> ASLE is because the brightness is never changed by the driver, the
> backlight is only enabled or disabled.
>
> I'd love to clean up the whole backlight mess, but it's too late in
> the RC cycle to do that.
>
> So please revert my patch and apply Takashi Iwai's, which fixes the
> most immediate bug without changing anything else. This should go
> in stable too.
>
>> From f6b8a45b9544072e6ddbb944a4c03a9ec8cbca3a Mon Sep 17 00:00:00  
>> 2001 From: Takashi
> Iwai <tiwai at suse.de>
> Date: Mon, 21 Feb 2011 14:19:27 +0100
> Subject: [PATCH] drm/i915: Fix calculation of backlight value in  
> combined mode
>
> The commit a95735569312f2ab0c80425e2cd1e5cb0b4e1870
>     drm/i915: Refactor panel backlight controls
> causes a regression for GM45 that is using the combined mode for
> controlling the backlight brightness.  The commit introduced a  
> wrong bit shift for
> computing the current backlight level.
>
> Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=672946
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524
>
> Signed-off-by: Takashi Iwai <tiwai at suse.de>
> Cc: <stable at kernel.org>
> ---
>  drivers/gpu/drm/i915/intel_panel.c |    1 -
>  1 file changed, 1 deletion(-)
>
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -176,7 +176,6 @@
>  			val &= ~1;
>  			pci_read_config_byte(dev->pdev, PCI_LBPC, &lbpc);
>  			val *= lbpc;
> -			val >>= 1;
>  		}
>  	}
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 3 Mar 2011 21:01:52 +0100
> From: Paolo Ornati <ornati at gmail.com>
> Subject: Re: [2.6.38-rc6] G965: i915 Hangcheck timer elapsed... GPU
> 	hung	(not reproducible)
> To: Nick Bowler <nbowler at elliptictech.com>
> Cc: Andrew Morton <akpm at linux-foundation.org>,	Linux Kernel Mailing
> 	List <linux-kernel at vger.kernel.org>,	dri-devel at lists.freedesktop.org
> Message-ID: <20110303210152.5750c239 at gmail.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Wed, 2 Mar 2011 19:43:26 -0500
> Nick Bowler <nbowler at elliptictech.com> wrote:
>
>> So you might want to try again with the latest git xf86-video- 
>> intel and
>> see if it still happens.
>
> xf86-video-intel bug or not the kernel should be able to reset the GPU
> I think... (I'm using KMS).
>
> Anyway I'm using 2.6.38-rcX on this PC for a month, and it happened
> only once. This is the complete list of 2.6.38 based kernel I've  
> used an
> when (login time):
>
> Sun Jan 30 09:00:04 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c
> Sun Jan 30 15:52:14 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c
> Mon Jan 31 20:01:29 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c
> Tue Feb  1 19:31:05 CET 2011 -- Linux tux 2.6.38-rc2-00274-g1f0324c
> Wed Feb  2 19:39:28 CET 2011 -- Linux tux 2.6.38-rc3
> Thu Feb  3 19:22:14 CET 2011 -- Linux tux 2.6.38-rc3
> Fri Feb  4 20:14:07 CET 2011 -- Linux tux 2.6.38-rc3
> Sat Feb  5 08:09:57 CET 2011 -- Linux tux 2.6.38-rc3
> Sun Feb  6 09:28:15 CET 2011 -- Linux tux 2.6.38-rc3
> Sun Feb  6 13:09:55 CET 2011 -- Linux tux 2.6.38-rc3
> Mon Feb  7 19:31:43 CET 2011 -- Linux tux 2.6.38-rc3
> Tue Feb  8 19:56:27 CET 2011 -- Linux tux 2.6.38-rc3
> Wed Feb  9 20:09:37 CET 2011 -- Linux tux 2.6.38-rc4
> Fri Feb 11 20:01:20 CET 2011 -- Linux tux 2.6.38-rc4
> Sat Feb 12 09:16:32 CET 2011 -- Linux tux 2.6.38-rc4
> Sat Feb 12 12:28:23 CET 2011 -- Linux tux 2.6.38-rc4
> Sat Feb 12 14:39:15 CET 2011 -- Linux tux 2.6.38-rc4
> Sat Feb 12 15:05:29 CET 2011 -- Linux tux 2.6.38-rc4
> Sat Feb 12 15:20:37 CET 2011 -- Linux tux 2.6.38-rc4
> Sat Feb 12 15:23:49 CET 2011 -- Linux tux 2.6.38-rc4
> Sat Feb 12 20:44:18 CET 2011 -- Linux tux 2.6.38-rc4
> Sun Feb 13 08:40:09 CET 2011 -- Linux tux 2.6.38-rc4
> Sun Feb 13 13:11:28 CET 2011 -- Linux tux 2.6.38-rc4
> Mon Feb 14 20:20:12 CET 2011 -- Linux tux 2.6.38-rc4
> Tue Feb 15 20:28:22 CET 2011 -- Linux tux 2.6.38-rc4
> Sat Feb 19 08:55:51 CET 2011 -- Linux tux 2.6.38-rc4
> Sat Feb 19 09:56:02 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52
> Sat Feb 19 13:50:37 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52
> Sat Feb 19 18:05:28 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52
> Sat Feb 19 20:12:05 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52
> Sun Feb 20 08:57:19 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52
> Sun Feb 20 18:05:43 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52
> Mon Feb 21 20:22:51 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52
> Tue Feb 22 20:02:13 CET 2011 -- Linux tux 2.6.38-rc5-00100-g0cc9d52
> Wed Feb 23 20:06:45 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3
> Thu Feb 24 20:15:23 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3
> Fri Feb 25 20:04:37 CET 2011 -- Linux tux 2.6.38-rc6-00020-gd8204a3
> Sat Feb 26 09:18:44 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4
> Sat Feb 26 19:45:28 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4
> Sun Feb 27 09:12:54 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4  
> <--- GPU hung ;)
> Sun Feb 27 09:32:17 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4
> Sun Feb 27 15:32:46 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4
> Sun Feb 27 17:38:17 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4
> Mon Feb 28 21:00:49 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4
> Tue Mar  1 20:25:01 CET 2011 -- Linux tux 2.6.38-rc6-00113-g4662db4
> Thu Mar  3 20:27:57 CET 2011 -- Linux tux 2.6.38-rc6-00212-g3e1f235
>
> I'll see if it happens again...
>
> -- 
> 	Paolo Ornati
> 	Linux 2.6.38-rc6-00212-g3e1f235 on x86_64
>
>
> ------------------------------
>
> Message: 8
> Date: Fri,  4 Mar 2011 02:34:25 -0800 (PST)
> From: bugzilla-daemon at freedesktop.org
> Subject: [Bug 34929] [r300g] slowdown with r300g threading
> To: dri-devel at lists.freedesktop.org
> Message-ID: <20110304103425.80AC2130009 at annarchy.freedesktop.org>
> Content-Type: text/plain; charset="UTF-8"
>
> https://bugs.freedesktop.org/show_bug.cgi?id=34929
>
> --- Comment #6 from Fabio Pedretti <fabio.ped at libero.it> 2011-03-04  
> 02:34:24 PST ---
> (In reply to comment #5)
>> Come on, you cannot decently compare performance when running  
>> under GDB...
>> GDB has its own thread overhead
>
> The point is that on my system, for whatever reason, r300g  
> threading make every
> application I tried slower (or at least not faster), with or  
> without gdb.
> Running it under gdb amplifies the problem and may be a useful test  
> case to
> further debug the problem to who, instead, got the speedups,  
> possibly because
> on his system the thread management overhead is less than the  
> benefit from
> using two CPU cores. Maybe it's possible to leave the thread always  
> open
> without opening/exiting it many times.
>
> -- 
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi? 
> tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
>
>
> ------------------------------
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> End of dri-devel Digest, Vol 12, Issue 16
> *****************************************

*********************************************************************
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany

e-mail: mario.kleiner at tuebingen.mpg.de
office: +49 (0)7071/601-1623
fax:    +49 (0)7071/601-616
www:    http://www.kyb.tuebingen.mpg.de/~kleinerm
*********************************************************************
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)