dri-devel June 2011

dri-devel@lists.freedesktop.org

101 participants
499 discussions

[Bug 37261] New: Norsetto shadow mapping doesn't render correctly
by bugzilla-daemon＠freedesktop.org 15 Jun '11

15 Jun '11

https://bugs.freedesktop.org/show_bug.cgi?id=37261 Summary: Norsetto shadow mapping doesn't render correctly Product: Mesa Version: git Platform: Other URL: http://norsetto.site11.com/?db_select=shadow&page_id=9 7 OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: sa(a)whiz.se Created an attachment (id=46775) --> (https://bugs.freedesktop.org/attachment.cgi?id=46775) Screenshot of bug The shadow mapping demo from norsetto doesn't render correctly with r600g, none of the objects are textured and the shadows are missing. Rendering on llvmpipe seems to be correct. The demo requires a simple change for the shaders to compile: --- data/shaders/bumpTBN_SH_FP.glsl.orig 2011-05-16 17:41:49.098224141 +0200 +++ data/shaders/bumpTBN_SH_FP.glsl 2011-05-16 17:41:57.978477020 +0200 @@ -46,7 +46,7 @@ void main() offset.y += offset.x; if ( offset.y > 1.1) - offset.y = 0; + offset.y = 0.0; vec4 shadow = ( offset_lookup( shadowMap, gl_TexCoord[1], offset+vec2(-1.5, 0.5) ) + offset_lookup( shadowMap, gl_TexCoord[1], offset+vec2( 0.5, 0.5) ) + System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.1 -- xserver: 1.10.1 -- mesa: git-c9aa3bb -- drm: 2.4.25 -- kernel: 2.6.39-rc7 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 36523] New: water reflections misrendered in sauerbraten with "shaders=high" setting
by bugzilla-daemon＠freedesktop.org 15 Jun '11

15 Jun '11

https://bugs.freedesktop.org/show_bug.cgi?id=36523 Summary: water reflections misrendered in sauerbraten with "shaders=high" setting Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: stefano.teso(a)gmail.com Water in sauerbraten misrenders (it's painted black) when enabling both (a) water reflections, and (b) 'high quality' shaders. Lowering the shader setting or disabling shaders altogether solves the problem. I'm running debian amd64 unstable, with custom kernel 2.6.39-rc4+ (git 91e8549), on a: 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Robson CE [AMD Radeon HD 6300 Series] [1002:68e4] Mesa is from git as well, here's what glxinfo has to say about it: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CEDAR OpenGL version string: 2.1 Mesa 7.11-devel (git-a22aba4) OpenGL shading language version string: 1.20 Screenshots to follow. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 6

[PATCH] DRM: clean up and document parsing of video= parameter
by Rolf Eike Beer 15 Jun '11

15 Jun '11

>From a8163a0acef17c66521de37464732a2a4f9e50ca Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer <eike-kernel(a)sf-tec.de> Date: Wed, 15 Jun 2011 11:27:02 +0200 Subject: [PATCH] DRM: clean up and document parsing of video= parameter The video= parameter of the DRM drivers supports some additional flags that the normal fb drivers do not have. They also allow to limit these flags to specific outputs. Both things were previously undocumented. Also the parsing of the line had some oddities: -A lot of misplaced options were silently ignored or partly rejected instead of stopping the parsing immediately -The 'R' option is documented to follow the 'M' option if specified. It is not documented that 'M' is needed to specify 'R' (also this is the case for normal fb drivers). In fact the code is correct for normal fb drivers but wrong for DRM ones. The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only if 'M' is given at all which is not needed for the DRM drivers. -the margins option ('m') was parsed but later ignored even if the later functions support it. -specifying multiple enable options at the same time did not lead to an error. -specifying something bogus for horizontal resolution (i.e. other things as digits) did not lead to an error but an invalid resolution was used. If any errors are encountered the position of the faulting string is now printed to the user and the complete mode is ignored. This gives much more consistent error behaviour. I also removed some useless assignments and changed the local flag variables to be bool. Signed-off-by: Rolf Eike Beer <eike-kernel(a)sf-tec.de> --- Documentation/fb/modedb.txt | 21 +++++++++- drivers/gpu/drm/drm_modes.c | 87 +++++++++++++++++++++++++++++------------- 2 files changed, 78 insertions(+), 30 deletions(-) diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt index ec4dee7..16aa084 100644 --- a/Documentation/fb/modedb.txt +++ b/Documentation/fb/modedb.txt @@ -20,7 +20,7 @@ in a video= option, fbmem considers that to be a global video mode option. Valid mode specifiers (mode_option argument): - <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m] + <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd] <name>[-<bpp>][@<refresh>] with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string. @@ -36,6 +36,21 @@ pixels and 1.8% of yres). Sample usage: 1024x768M@60m - CVT timing with margins +DRM drivers also add options to enable or disable outputs: + +'e' will force the display to be enabled, i.e. it will override the detection +if a display is connected. 'D' will force the display to be enabled and use +digital output. This is useful for outputs that have both analog and digital +signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd' +is specified the output is disabled. + +You can additionally specify which output the options matches to. +To force the VGA output to be enabled and drive a specific mode say: + video=VGA-1:1280x1024@60me + +Specifying the option multiple times for different ports is possible, e.g.: + video=LVDS-1:d video=HDMI-1:D + ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** What is the VESA(TM) Coordinated Video Timings (CVT)? @@ -132,5 +147,5 @@ There may be more modes. tridentfb - Trident (Cyber)blade chipset frame buffer vt8623fb - VIA 8623 frame buffer -BTW, only a few drivers use this at the moment. Others are to follow -(feel free to send patches). +BTW, only a few fb drivers use this at the moment. Others are to follow +(feel free to send patches). The DRM drivers also support this. diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index c2d32f2..ad74fb4 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -994,9 +994,10 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, { const char *name; unsigned int namelen; - int res_specified = 0, bpp_specified = 0, refresh_specified = 0; + bool res_specified = false, bpp_specified = false, refresh_specified = false; unsigned int xres = 0, yres = 0, bpp = 32, refresh = 0; - int yres_specified = 0, cvt = 0, rb = 0, interlace = 0, margins = 0; + bool yres_specified = false, cvt = false, rb = false; + bool interlace = false, margins = false, was_digit = false; int i; enum drm_connector_force force = DRM_FORCE_UNSPECIFIED; @@ -1015,54 +1016,65 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, for (i = namelen-1; i >= 0; i--) { switch (name[i]) { case '@': - namelen = i; if (!refresh_specified && !bpp_specified && - !yres_specified) { + !yres_specified && !cvt && !rb && was_digit) { refresh = simple_strtol(&name[i+1], NULL, 10); - refresh_specified = 1; - if (cvt || rb) - cvt = 0; + refresh_specified = true; + was_digit = false; } else goto done; break; case '-': - namelen = i; - if (!bpp_specified && !yres_specified) { + if (!bpp_specified && !yres_specified && !cvt && + !rb && was_digit) { bpp = simple_strtol(&name[i+1], NULL, 10); - bpp_specified = 1; - if (cvt || rb) - cvt = 0; + bpp_specified = true; + was_digit = false; } else goto done; break; case 'x': - if (!yres_specified) { + if (!yres_specified && was_digit) { yres = simple_strtol(&name[i+1], NULL, 10); - yres_specified = 1; + yres_specified = true; + was_digit = false; } else goto done; case '0' ... '9': + was_digit = true; break; case 'M': - if (!yres_specified) - cvt = 1; + if (yres_specified || cvt || was_digit) + goto done; + cvt = true; break; case 'R': - if (cvt) - rb = 1; + if (yres_specified || cvt || rb || was_digit) + goto done; + rb = true; break; case 'm': - if (!cvt) - margins = 1; + if (cvt || yres_specified || was_digit) + goto done; + margins = true; break; case 'i': - if (!cvt) - interlace = 1; + if (cvt || yres_specified || was_digit) + goto done; + interlace = true; break; case 'e': + if (yres_specified || bpp_specified || refresh_specified || + was_digit || (force != DRM_FORCE_UNSPECIFIED)) + goto done; + force = DRM_FORCE_ON; break; case 'D': + if (yres_specified || bpp_specified || refresh_specified || + was_digit || (force != DRM_FORCE_UNSPECIFIED)) + goto done; + if ((connector->connector_type != DRM_MODE_CONNECTOR_DVII) && (connector->connector_type != DRM_MODE_CONNECTOR_HDMIB)) force = DRM_FORCE_ON; @@ -1070,17 +1082,37 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, force = DRM_FORCE_ON_DIGITAL; break; case 'd': + if (yres_specified || bpp_specified || refresh_specified || + was_digit || (force != DRM_FORCE_UNSPECIFIED)) + goto done; + force = DRM_FORCE_OFF; break; default: goto done; } } + if (i < 0 && yres_specified) { - xres = simple_strtol(name, NULL, 10); - res_specified = 1; + char *ch; + xres = simple_strtol(name, &ch, 10); + if ((ch != NULL) && (*ch == 'x')) + res_specified = true; + else + i = ch - name; + } else if (!yres_specified && was_digit) { + /* catch mode that begins with digits but has no 'x' */ + i = 0; } done: + if (i >= 0) { + printk(KERN_WARNING + "parse error at position %i in video mode '%s'\n", + i, name); + mode->specified = false; + return false; + } + if (res_specified) { mode->specified = true; mode->xres = xres; @@ -1096,9 +1128,10 @@ done: mode->bpp_specified = true; mode->bpp = bpp; } - mode->rb = rb ? true : false; - mode->cvt = cvt ? true : false; - mode->interlace = interlace ? true : false; + mode->rb = rb; + mode->cvt = cvt; + mode->interlace = interlace; + mode->margins = margins; mode->force = force; return true; -- 1.7.3.4

1 0

[PATCH] drm: populate irq_by_busid-member for pci
by Wolfram Sang 15 Jun '11

15 Jun '11

Commit 8410ea (drm: rework PCI/platform driver interface) implemented drm_pci_irq_by_busid() but forgot to make it available in the drm_pci_bus-struct. This caused a freeze on my Radeon9600-equipped laptop when executing glxgears. Thanks to Michel for noticing the flaw. Reported-by: Michel Dänzer <daenzer(a)vmware.com> Signed-off-by: Wolfram Sang <w.sang(a)pengutronix.de> Cc: Dave Airlie <airlied(a)redhat.com> --- stable-candidate, 2.6.39 is affected, too. drivers/gpu/drm/drm_pci.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c index e1aee4f..e4e7fde 100644 --- a/drivers/gpu/drm/drm_pci.c +++ b/drivers/gpu/drm/drm_pci.c @@ -292,6 +292,7 @@ static struct drm_bus drm_pci_bus = { .get_name = drm_pci_get_name, .set_busid = drm_pci_set_busid, .set_unique = drm_pci_set_unique, + .irq_by_busid = drm_pci_irq_by_busid, .agp_init = drm_pci_agp_init, }; -- 1.7.2.5

1 0

[Bug 37476] New: [wine] Devil May Cry 4: TXD tgsi opcode unsupported / translation from TGSI failed / missing vertex shader
by bugzilla-daemon＠freedesktop.org 15 Jun '11

15 Jun '11

https://bugs.freedesktop.org/show_bug.cgi?id=37476 Summary: [wine] Devil May Cry 4: TXD tgsi opcode unsupported / translation from TGSI failed / missing vertex shader Product: Mesa Version: git Platform: Other URL: http://www.gamershell.com/download_27216.shtml OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: sa(a)whiz.se The demo of the game Devil May Cry 4 (running in Wine) isn't rendering correctly, quite a few objects are missing. The following errors are printed on the terminal: EE r600_shader.c:829 tgsi_unsupported - TXD tgsi opcode unsupported EE r600_shader.c:118 r600_pipe_shader_create - translation from TGSI failed ! EE r600_state_common.c:564 r600_draw_vbo - missing vertex shader EE r600_shader.c:829 tgsi_unsupported - TXD tgsi opcode unsupported EE r600_shader.c:118 r600_pipe_shader_create - translation from TGSI failed ! EE r600_state_common.c:564 r600_draw_vbo - missing vertex shader I used apitrace to capture the game, even though the trace ends in a segfault it's enough to reproduce the above errors. http://dl.dropbox.com/u/28577999/dmc4.trace.7z (93M) (To run the game in Wine native versions of WMASF.DLL and WMVCORE.DLL needs to be used) System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.1 -- xserver: 1.10.1 -- mesa: git-fd6f2d6 -- drm: 2.4.25 -- kernel: 2.6.39 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

4 4

[PATCH 3/3] alpha, drm: Add Alpha support to Radeon DRM code
by Jay Estabrook 15 Jun '11

15 Jun '11

Alpha needs to have the system bus address for the device's local memory available, so that it can be returned to user-level, where it may be used in an mmap(). So, we make bus.addr hold the ioremap() return for kernel use, and then we can modify bus.base appropriately. Signed-off-by: Jay Estabrook <jay.estabrook(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_ttm.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff -Naurp a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c --- a/drivers/gpu/drm/radeon/radeon_ttm.c 2011-04-26 23:48:50.000000000 -0400 +++ b/drivers/gpu/drm/radeon/radeon_ttm.c 2011-05-03 18:24:27.000000000 -0400 @@ -450,6 +450,29 @@ static int radeon_ttm_io_mem_reserve(str return -EINVAL; mem->bus.base = rdev->mc.aper_base; mem->bus.is_iomem = true; +#ifdef __alpha__ + /* + * Alpha: use bus.addr to hold the ioremap() return, + * so we can modify bus.base below. + */ + if (mem->placement & TTM_PL_FLAG_WC) + mem->bus.addr = + ioremap_wc(mem->bus.base + mem->bus.offset, + mem->bus.size); + else + mem->bus.addr = + ioremap_nocache(mem->bus.base + mem->bus.offset, + mem->bus.size); + + /* + * Alpha: Take just the bus offset and + * add the hose/domain memory base. + * Then, bus.base can be returned + * for use in an mmap() call. + */ + mem->bus.base = (mem->bus.base & 0x0ffffffffUL) + + rdev->ddev->hose->dense_mem_base; +#endif break; default: return -EINVAL; ---

2 2

[Bug 32511] New: glDrawPixels broken on savage
by bugzilla-daemon＠freedesktop.org 14 Jun '11

14 Jun '11

https://bugs.freedesktop.org/show_bug.cgi?id=32511 Summary: glDrawPixels broken on savage Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/Savage AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: bugzi09.fdo.tormod(a)xoxy.net Created an attachment (id=41267) --> (https://bugs.freedesktop.org/attachment.cgi?id=41267) full backtrace in savageWriteRGBASpan_565() The drawpix demo draws pixels spread around the screen instead of inside the window. Each line drawn (194 pixels) get displayed in a cluster, but not as a line. Only every 6th "line" get displayed, starting from the lower right of the screen, going left, then up (see drawpix-many.png). The cluster is divided in 4 squares of 8 times 8 pixels, where the first and fourth square is not complete. Each square is drawn from left to right, then from top to bottom. Square are drawn from left to right within a cluster. (See drawpix-line.png). I have tracked the drawing in mesa down to where it writes each pixel into the renderbuffer in savageWriteRGBASpan_565(), see the full backtrace in write_rgba-backtrace.gdb. This is with latest git. I think I have seen similar corruption using the antspotlight screensaver since a long time ago, and I never tried drawpix before so this can be an old bug. The bug reporter of the downstream Ubuntu bug says drawpix worked fine in Ubuntu 8.04 which had mesa 7.0.3. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 19

[PATCH] drm/radeon/kms: signed fix for evergreen thermal
by Alex Deucher 14 Jun '11

14 Jun '11

temperature is signed. Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/evergreen.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index e1b3d99..b06f2db 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -88,7 +88,8 @@ u32 evergreen_page_flip(struct radeon_device *rdev, int crtc_id, u64 crtc_base) /* get temperature in millidegrees */ int evergreen_get_temp(struct radeon_device *rdev) { - u32 temp, toffset, actual_temp = 0; + u32 temp, toffset; + int actual_temp = 0; if (rdev->family == CHIP_JUNIPER) { toffset = (RREG32(CG_THERMAL_CTRL) & TOFFSET_MASK) >> -- 1.7.1.1

1 0

[regression] blank screen with radeondrmfb on iMac G5 (ALS)
by Joachim Henke 14 Jun '11

14 Jun '11

Hello, I found a regression in Linux 2.6.37.2 - I know this report comes quite late, but I had no time to investigate until now. And I found that this still persists up to 2.6.39 :( When I upgraded from 2.6.37 to 2.6.37.3, after reboot my machine came up with a blank/black screen (backlight on). It's an iMac G5 (Ambient Light Sensor) with a Radeon 9600 (RV350). After Xorg had started, the screen remained blank. There were only a few Radeon specific changes between these two versions, so that I could quickly identify the cause. It's commit ce9eb2c297f918be46e36dd86b7e88cabdc3e22df (9fad321ac6bedd96f449754a1a25289ea1789a49 upstream). After reverting this with a simple patch, it works properly again: --- linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c.orig +++ linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c @@ -1515,11 +1515,6 @@ (rdev->pdev->subsystem_device == 0x4a48)) { /* Mac X800 */ rdev->mode_info.connector_table = CT_MAC_X800; - } else if ((rdev->pdev->device == 0x4150) && - (rdev->pdev->subsystem_vendor == 0x1002) && - (rdev->pdev->subsystem_device == 0x4150)) { - /* Mac G5 9600 */ - rdev->mode_info.connector_table = CT_MAC_G5_9600; } else #endif /* CONFIG_PPC_PMAC */ #ifdef CONFIG_PPC64 This is a diff from the dmesg [without my patch] -> [with my patch]: [drm] ring test succeeded in 0 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs -[drm] Connector Table: 12 (mac g5 9600) -[drm] No valid Ext TMDS info found in BIOS -[drm] No TV DAC info found in BIOS +[drm] Connector Table: 1 (generic) [drm] No TMDS info found in BIOS +[drm] No TV DAC info found in BIOS [drm] Radeon Display Connectors [drm] Connector 0: [drm] DVI-I [drm] HPD1 [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 [drm] Encoders: -[drm] DFP2: INTERNAL_DVO1 +[drm] DFP1: INTERNAL_TMDS1 [drm] CRT2: INTERNAL_DAC2 [drm] Connector 1: -[drm] DVI-I -[drm] HPD2 +[drm] VGA [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 [drm] Encoders: -[drm] DFP1: INTERNAL_TMDS1 [drm] CRT1: INTERNAL_DAC1 [drm] Connector 2: [drm] S-video On which kind of machines was the original commit tested/supposed to work? Do you see a possibility to fix this in a proper way upstream? Thanks and regards, Joachim Henke

3 10

Re: drm-radeon failures on R600: patches still don't work
by Markus Trippelsdorf 14 Jun '11

14 Jun '11

On 2011.06.12 at 13:48 +0300, Jaroslaw Fedewicz wrote: > > There was a recent thread as found on > https://lkml.org/lkml/2011/6/8/17, started by Markus Trippelsdorf: > > > The merge of the 'drm-radeon' branch by Linus yesterday breaks my setup > > (RS780). The mouse cursor is just a black block suddenly and I see an > > endless stream of: > > radeon 0000:01:05.0: r600_check_texture_resource:1338 texture invalid format 26 > > [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! > > This is also true of my laptop (Thinkpad Edge 13, AMD model) which has > built-in Radeon HD3200 (RS780) inside, and the most recent kernel from > git. > > Unfortunately, none of the patches proposed so far worked. The patch > by Markus (https://lkml.org/lkml/2011/6/8/19) did work in the sense > that X actually started up, but all graphics were very sluggish > including mouse movements, to the point of unability to do anything > remotely useful on that machine, and a patch proposed by Dave Airlie > (https://lkml.org/lkml/2011/6/8/117) didn't apply - it comes out the > line it added was already in the code. Hmm, maybe you're seeing a different problem. The issue that I saw was fixed by commit 428c6e3630 in the git tree (this is identical to the patch by Dave you're referring to above). Does a "git-revert fe6f0bd03d697835e76dd18d232ba476c65b8282" solve your problem? > I'm not a kernel hacker by any means, so sorry if I understood > anything wrong; if I need to supply any additional information, I'll > be glad to. It would be great if you could git-bisect the issue. Basically you just need to run: git bisect start git bisect bad git bisect good ecff4fcc7bbaf060646d2160123f8dc02605a047 build new kernel (reboot) and then run either "git bisect good" or "git bisect bad", depending on whether you see the problem or not, and then repeat the last 3 items in the list. (please see also "man git-bisect") > Also, sorry for not continuing that thread; I have just subscribed so > I can't "reply" to it. (That's no problem. But it is always a good idea to CC the people that you're talking about and also the dri-devel list in this case) -- Markus

2 1

← Newer
1
...
38
39
40
41
42
43
44
...
50
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2011