dri-devel September 2013

dri-devel@lists.freedesktop.org

153 participants
824 discussions

[Bug 69321] starting openCL crashes/boots system
by bugzilla-daemon＠freedesktop.org 17 Sep '13

17 Sep '13

https://bugs.freedesktop.org/show_bug.cgi?id=69321 --- Comment #4 from udo <udovdh(a)xs4all.nl> --- mesa]# git bisect bad f0435ebb07d01a77ca0d98967a002898811a5206 is the first bad commit commit f0435ebb07d01a77ca0d98967a002898811a5206 Author: Tom Stellard <thomas.stellard(a)amd.com> Date: Mon Aug 26 17:55:49 2013 -0700 r600g/compute: Don't flush the cs in pipe_context::launch_grid() This is the state tracker's responsibility. Reviewed-by: Marek Olšák <marek.olsak(a)amd.com> :040000 040000 800ca408fbce3ab20ed2ee525775ccf4af8450da bdad2d7895292c4d54838153e74f8eb1d1f4839b M src -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH v9 0/2] Introduce buffer synchronization framework
by Inki Dae 17 Sep '13

17 Sep '13

Hi all, This patch set introduces a buffer synchronization framework based on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism, and is rebased on linux-3.12-rc1 The purpose of this framework is to provide not only buffer access control to CPU and CPU, and CPU and DMA, and DMA and DMA but also easy-to-use interfaces for device drivers and user application. In addtion, this patch set suggests a way for enhancing performance. Changelog v9: - Delete only one sync object matched at DEL_OBJ_FROM_RSV macro. - Fix memory leak issue at dmabuf_sync_single_lock() Changelog v8: Consider the write-and-then-read ordering pointed out by David Herrmann, - The ordering issue means that a task don't take a lock to the dmabuf so this task would be stalled even though this task requested a lock to the dmabuf between other task unlocked and tries to lock the dmabuf again. For this, we have added a wait event mechanism using only generic APIs, wait_event_timeout and wake_up functions. The below is how to handle the ordering issue using this mechanism: 1. Check if there is a sync object added prior to current task's one. 2. If exists, it unlocks the dmabuf so that other task can take a lock to the dmabuf first. 3. Wait for the wake up event from other task: current task will be waked up when other task unlocks the dmabuf. 4. Take a lock to the dmabuf again. - Code cleanups. Changelog v7: Fix things pointed out by Konrad Rzeszutek Wilk, - Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL. - Make sure to unlock and unreference all dmabuf objects when dmabuf_sync_fini() is called. - Add more comments. - Code cleanups. Changelog v6: - Fix sync lock to multiple reads. - Add select system call support. . Wake up poll_wait when a dmabuf is unlocked. - Remove unnecessary the use of mutex lock. - Add private backend ops callbacks. . This ops has one callback for device drivers to clean up their sync object resource when the sync object is freed. For this, device drivers should implement the free callback properly. - Update document file. Changelog v5: - Rmove a dependence on reservation_object: the reservation_object is used to hook up to ttm and dma-buf for easy sharing of reservations across devices. However, the dmabuf sync can be used for all dma devices; v4l2 and drm based drivers, so doesn't need the reservation_object anymore. With regared to this, it adds 'void *sync' to dma_buf structure. - All patches are rebased on mainline, Linux v3.10. Changelog v4: - Add user side interface for buffer synchronization mechanism and update descriptions related to the user side interface. Changelog v3: - remove cache operation relevant codes and update document file. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. For generic user mode interface, we have used fcntl and select system call[3]. As you know, user application sees a buffer object as a dma-buf file descriptor. So fcntl() call with the file descriptor means to lock some buffer region being managed by the dma-buf object. And select() call means to wait for the completion of CPU or DMA access to the dma-buf without locking. For more detail, you can refer to the dma-buf-sync.txt in Documentation/ There are some cases user-space process needs this buffer synchronization framework. One of which is to primarily enhance GPU rendering performance in case that 3D app draws somthing in a buffer using CPU, and other process composes the buffer with its own backbuffer using GPU. In case of 3D app, the app calls glFlush to submit 3d commands to GPU driver instead of glFinish for more performance. The reason, we call glFlush, is that glFinish blocks caller's task until the execution of the 3d commands is completed. So that makes GPU and CPU more idle. As a result, 3d rendering performance with glFinish is quite lower than glFlush. However, the use of glFlush has one issue that the the buffer shared with GPU could be broken when CPU accesses the buffer just after glFlush because CPU cannot be aware of the completion of GPU access to the buffer. Of course, the app can be aware of that time using eglWaitGL but this function is valid only in case of the same context. The below summarizes how app's window is displayed on Tizen[4] platform: 1. X client requests a window buffer to Xorg. 2. X client draws something in the window buffer using CPU. 3. X client requests SWAP to Xorg. 4. Xorg notifies a damage event to Composite Manager. 5. Composite Manager gets the window buffer (front buffer) through DRI2GetBuffers. 6. Composite Manager composes the window buffer and its own back buffer using GPU. At this time, eglSwapBuffers is called: internally, 3d commands are flushed to gpu driver. 7. Composite Manager requests SWAP to Xorg. 8. Xorg performs drm page flip. At this time, the window buffer is displayed on screen. Web app based on HTML5 also has the same issue. Web browser and Web app are different process. The Web app can draw something in its own buffer using CPU, and then the Web Browser can compose the buffer with its own back buffer. Thus, in such cases, a shared buffer could be broken as one process draws something in a buffer using CPU, when other process composes the buffer with its own buffer using GPU without any locking mechanism. That is why we need user land locking interface, fcntl system call. And last one is a deferred page flip issue. This issue is that a window buffer rendered can be displayed on screen in about 32ms in worst case: assume that the gpu rendering is completed within 16ms. That can be incurred when compositing a pixmap buffer with a window buffer using GPU and when vsync is just started. At this time, Xorg waits for a vblank event to get a window buffer so 3d rendering will be delayed up to about 16ms. As a result, the window buffer would be displayed in about two vsyncs (about 32ms) and in turn, that would show slow responsiveness. For this, we could enhance the responsiveness with locking mechanism: skipping one vblank wait. I guess Android, Chrome OS, and other platforms are using their own locking mechanisms with similar reason; Android sync driver, KDS, and DMA fence. The below shows the deferred page flip issue in worst case: |------------ <- vsync signal |<------ DRI2GetBuffers | | | |------------ <- vsync signal |<------ Request gpu rendering time | | |<------ Request page flip (deferred) |------------ <- vsync signal |<------ Displayed on screen | | | |------------ <- vsync signal Thanks, Inki Dae References: [1] http://lwn.net/Articles/470339/ [2] https://patchwork.kernel.org/patch/2625361/ [3] http://linux.die.net/man/2/fcntl [4] https://www.tizen.org/ Inki Dae (2): dmabuf-sync: Add a buffer synchronization framework dma-buf: Add user interfaces for dmabuf sync support Documentation/dma-buf-sync.txt | 286 ++++++++++++ drivers/base/Kconfig | 7 + drivers/base/Makefile | 1 + drivers/base/dma-buf.c | 86 ++++ drivers/base/dmabuf-sync.c | 951 ++++++++++++++++++++++++++++++++++++++++ include/linux/dma-buf.h | 16 + include/linux/dmabuf-sync.h | 257 +++++++++++ 7 files changed, 1604 insertions(+) create mode 100644 Documentation/dma-buf-sync.txt create mode 100644 drivers/base/dmabuf-sync.c create mode 100644 include/linux/dmabuf-sync.h -- 1.7.9.5

1 2

[Bug 60827] X under radeon driver crashes after resuming from hibernation
by bugzilla-daemon＠bugzilla.kernel.org 17 Sep '13

17 Sep '13

https://bugzilla.kernel.org/show_bug.cgi?id=60827 --- Comment #7 from archiesix(a)gmail.com --- The problem persists in Kernel 3.11.1 -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

exynos4: power domain issue with hdmi out
by Alban Browaeys 17 Sep '13

17 Sep '13

Hi, with Odroid U2 (exynos4412 quad) + a custom kernel based on linux-next 20130912 and before I am unable to get a hdmi output other than vertical lines (a few whites on black background, sometimes yellow ) that are static (no changes whatever the content sent to the hdmi output. The issue disappeared as soon as I enabled fimd ... I narrowed it further, ie nowI can get hdmi output without fimd but with pd_lcd0 commented as to avoid it goind into power off at boot. Find that via fbcon enabled and content is displayed fined until the kernel turns off the unused power domains (just before freeing unused kernel memory). What could be the root issue ? Could pd_lcd0 wake up a parent item that should be too by pd_tv ? For one the non devicetree kernel from hardkernel setup s5p_fimd_device even if it does not use it. So the issue would be hidden. I also wonder if while developping s5p_device_hdmi such an issue appeared . Best regards Alban

1 0

Stereo 3D v3
by Damien Lespiau 17 Sep '13

17 Sep '13

Follow up of: http://lists.freedesktop.org/archives/dri-devel/2012-September/028278.html Let's try again! This time, intead of a magic connector property to select if we want to return more modeinfo flags to userspace, this series introduces a new SET_CAP ioctl. So the flow goes as following: 1/ the DRM client (limited to the DRM master) can notify it knows about those flags through SET_CAP 2/ we parse the HDMI CEA vendor blog for 3D_Present and patch the mandatory modes with the layouts they support (in ->flags) 3/ we can then handle a modeset with one (and only one) of those stereo 3D layout set on the mode. This includes writing a vendor infoframe with the information about the layout we're sending libdrm patches will follow with a new drmSetCap() function and the stereo 3D flags. Testing has been done with intel-gpu-tools' testdisplay that can now compose a left and right image for the "top and bottom", "side by side half" and "frame packing" stereo 3d layouts (patches posted on intel-gfx).

6 30

[PATCH] drm/ttm: fix the tt_populated check in ttm_tt_destroy()
by Ben Skeggs 17 Sep '13

17 Sep '13

From: Ben Skeggs <bskeggs(a)redhat.com> After a vmalloc failure in ttm_dma_tt_alloc_page_directory(), ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and end up inside the driver's unpopulate() hook when populate() has never yet been called. On nouveau, the first issue to be hit because of this is that dma_address[] may be a NULL pointer. After working around this, ttm_pool_unpopulate() may potentially hit the same issue with the pages[] array. It seems to make more sense to avoid calling unpopulate on already unpopulated TTMs than to add checks to all the implementations. Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com> Cc: Jerome Glisse <jglisse(a)redhat.com> Cc: Thomas Hellstrom <thellstrom(a)vmware.com> --- drivers/gpu/drm/ttm/ttm_tt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 5e93a52..210d503 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -170,7 +170,7 @@ void ttm_tt_destroy(struct ttm_tt *ttm) ttm_tt_unbind(ttm); } - if (likely(ttm->pages != NULL)) { + if (ttm->state == tt_unbound) { ttm->bdev->driver->ttm_tt_unpopulate(ttm); } -- 1.8.3.2

2 1

about flashing firefox os on micromax a60 (amr6)
by Prasad Mhatre 17 Sep '13

17 Sep '13

hello, I have micromax a60 and specs are as follows:- <http://www.gsmarena.com/micromax_a60-3678.php> original os was :android 2.1 now currently os :android 2.2 frozen yogurt(flashed it) i want to flash firefox OS on it can you guide me to do so regards, prasad mhatre

1 0

[PATCH] gpu: host1x: use %pa to print dma_addr_t
by Olof Johansson 17 Sep '13

17 Sep '13

This removes two warnings where dma_addr_t variables were printed using %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t: drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' Signed-off-by: Olof Johansson <olof(a)lixom.net> --- drivers/gpu/host1x/hw/cdma_hw.c | 4 ++-- drivers/gpu/host1x/hw/debug_hw.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/host1x/hw/cdma_hw.c b/drivers/gpu/host1x/hw/cdma_hw.c index 2ee4ad5..3db3011 100644 --- a/drivers/gpu/host1x/hw/cdma_hw.c +++ b/drivers/gpu/host1x/hw/cdma_hw.c @@ -54,8 +54,8 @@ static void cdma_timeout_cpu_incr(struct host1x_cdma *cdma, u32 getptr, u32 *p = (u32 *)((u32)pb->mapped + getptr); *(p++) = HOST1X_OPCODE_NOP; *(p++) = HOST1X_OPCODE_NOP; - dev_dbg(host1x->dev, "%s: NOP at 0x%x\n", __func__, - pb->phys + getptr); + dev_dbg(host1x->dev, "%s: NOP at %pa+0x%x\n", __func__, + &pb->phys, getptr); getptr = (getptr + 8) & (pb->size_bytes - 1); } wmb(); diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c index 334c038..346a54b 100644 --- a/drivers/gpu/host1x/hw/debug_hw.c +++ b/drivers/gpu/host1x/hw/debug_hw.c @@ -171,8 +171,8 @@ static void show_channel_gathers(struct output *o, struct host1x_cdma *cdma) continue; } - host1x_debug_output(o, " GATHER at %08x+%04x, %d words\n", - g->base, g->offset, g->words); + host1x_debug_output(o, " GATHER at %pa+%04x, %d words\n", + &g->base, g->offset, g->words); show_gather(o, g->base + g->offset, g->words, cdma, g->base, mapped); -- 1.7.10.4

4 5

[PATCH] drm/radeon: additional gcc fixes for radeon_atombios.c
by Alex Deucher 16 Sep '13

16 Sep '13

Newer versions of gcc seem to wander off into the weeds when dealing with variable sizes arrays in structs. Rather than indexing the arrays, use pointer arithmetic. Fix up spread spectrum tables. See bugs: https://bugs.freedesktop.org/show_bug.cgi?id=66932 https://bugs.freedesktop.org/show_bug.cgi?id=66972 https://bugs.freedesktop.org/show_bug.cgi?id=66945 Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/gpu/drm/radeon/radeon_atombios.c | 66 +++++++++++++++++++++----------- 1 file changed, 43 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index 404e25d..f79ee18 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -1367,6 +1367,7 @@ bool radeon_atombios_get_ppll_ss_info(struct radeon_device *rdev, int index = GetIndexIntoMasterTable(DATA, PPLL_SS_Info); uint16_t data_offset, size; struct _ATOM_SPREAD_SPECTRUM_INFO *ss_info; + struct _ATOM_SPREAD_SPECTRUM_ASSIGNMENT *ss_assign; uint8_t frev, crev; int i, num_indices; @@ -1378,18 +1379,21 @@ bool radeon_atombios_get_ppll_ss_info(struct radeon_device *rdev, num_indices = (size - sizeof(ATOM_COMMON_TABLE_HEADER)) / sizeof(ATOM_SPREAD_SPECTRUM_ASSIGNMENT); - + ss_assign = (struct _ATOM_SPREAD_SPECTRUM_ASSIGNMENT*) + ((u8 *)&ss_info->asSS_Info[0]); for (i = 0; i < num_indices; i++) { - if (ss_info->asSS_Info[i].ucSS_Id == id) { + if (ss_assign->ucSS_Id == id) { ss->percentage = - le16_to_cpu(ss_info->asSS_Info[i].usSpreadSpectrumPercentage); - ss->type = ss_info->asSS_Info[i].ucSpreadSpectrumType; - ss->step = ss_info->asSS_Info[i].ucSS_Step; - ss->delay = ss_info->asSS_Info[i].ucSS_Delay; - ss->range = ss_info->asSS_Info[i].ucSS_Range; - ss->refdiv = ss_info->asSS_Info[i].ucRecommendedRef_Div; + le16_to_cpu(ss_assign->usSpreadSpectrumPercentage); + ss->type = ss_assign->ucSpreadSpectrumType; + ss->step = ss_assign->ucSS_Step; + ss->delay = ss_assign->ucSS_Delay; + ss->range = ss_assign->ucSS_Range; + ss->refdiv = ss_assign->ucRecommendedRef_Div; return true; } + ss_assign = (struct _ATOM_SPREAD_SPECTRUM_ASSIGNMENT*) + ((u8 *)ss_assign + sizeof(struct _ATOM_SPREAD_SPECTRUM_ASSIGNMENT)); } } return false; @@ -1477,6 +1481,12 @@ union asic_ss_info { struct _ATOM_ASIC_INTERNAL_SS_INFO_V3 info_3; }; +union asic_ss_assignment { + struct _ATOM_ASIC_SS_ASSIGNMENT v1; + struct _ATOM_ASIC_SS_ASSIGNMENT_V2 v2; + struct _ATOM_ASIC_SS_ASSIGNMENT_V3 v3; +}; + bool radeon_atombios_get_asic_ss_info(struct radeon_device *rdev, struct radeon_atom_ss *ss, int id, u32 clock) @@ -1485,6 +1495,7 @@ bool radeon_atombios_get_asic_ss_info(struct radeon_device *rdev, int index = GetIndexIntoMasterTable(DATA, ASIC_InternalSS_Info); uint16_t data_offset, size; union asic_ss_info *ss_info; + union asic_ss_assignment *ss_assign; uint8_t frev, crev; int i, num_indices; @@ -1509,45 +1520,52 @@ bool radeon_atombios_get_asic_ss_info(struct radeon_device *rdev, num_indices = (size - sizeof(ATOM_COMMON_TABLE_HEADER)) / sizeof(ATOM_ASIC_SS_ASSIGNMENT); + ss_assign = (union asic_ss_assignment *)((u8 *)&ss_info->info.asSpreadSpectrum[0]); for (i = 0; i < num_indices; i++) { - if ((ss_info->info.asSpreadSpectrum[i].ucClockIndication == id) && - (clock <= le32_to_cpu(ss_info->info.asSpreadSpectrum[i].ulTargetClockRange))) { + if ((ss_assign->v1.ucClockIndication == id) && + (clock <= le32_to_cpu(ss_assign->v1.ulTargetClockRange))) { ss->percentage = - le16_to_cpu(ss_info->info.asSpreadSpectrum[i].usSpreadSpectrumPercentage); - ss->type = ss_info->info.asSpreadSpectrum[i].ucSpreadSpectrumMode; - ss->rate = le16_to_cpu(ss_info->info.asSpreadSpectrum[i].usSpreadRateInKhz); + le16_to_cpu(ss_assign->v1.usSpreadSpectrumPercentage); + ss->type = ss_assign->v1.ucSpreadSpectrumMode; + ss->rate = le16_to_cpu(ss_assign->v1.usSpreadRateInKhz); return true; } + ss_assign = (union asic_ss_assignment *) + ((u8 *)ss_assign + sizeof(ATOM_ASIC_SS_ASSIGNMENT)); } break; case 2: num_indices = (size - sizeof(ATOM_COMMON_TABLE_HEADER)) / sizeof(ATOM_ASIC_SS_ASSIGNMENT_V2); + ss_assign = (union asic_ss_assignment *)((u8 *)&ss_info->info_2.asSpreadSpectrum[0]); for (i = 0; i < num_indices; i++) { - if ((ss_info->info_2.asSpreadSpectrum[i].ucClockIndication == id) && - (clock <= le32_to_cpu(ss_info->info_2.asSpreadSpectrum[i].ulTargetClockRange))) { + if ((ss_assign->v2.ucClockIndication == id) && + (clock <= le32_to_cpu(ss_assign->v2.ulTargetClockRange))) { ss->percentage = - le16_to_cpu(ss_info->info_2.asSpreadSpectrum[i].usSpreadSpectrumPercentage); - ss->type = ss_info->info_2.asSpreadSpectrum[i].ucSpreadSpectrumMode; - ss->rate = le16_to_cpu(ss_info->info_2.asSpreadSpectrum[i].usSpreadRateIn10Hz); + le16_to_cpu(ss_assign->v2.usSpreadSpectrumPercentage); + ss->type = ss_assign->v2.ucSpreadSpectrumMode; + ss->rate = le16_to_cpu(ss_assign->v2.usSpreadRateIn10Hz); if ((crev == 2) && ((id == ASIC_INTERNAL_ENGINE_SS) || (id == ASIC_INTERNAL_MEMORY_SS))) ss->rate /= 100; return true; } + ss_assign = (union asic_ss_assignment *) + ((u8 *)ss_assign + sizeof(ATOM_ASIC_SS_ASSIGNMENT_V2)); } break; case 3: num_indices = (size - sizeof(ATOM_COMMON_TABLE_HEADER)) / sizeof(ATOM_ASIC_SS_ASSIGNMENT_V3); + ss_assign = (union asic_ss_assignment *)((u8 *)&ss_info->info_3.asSpreadSpectrum[0]); for (i = 0; i < num_indices; i++) { - if ((ss_info->info_3.asSpreadSpectrum[i].ucClockIndication == id) && - (clock <= le32_to_cpu(ss_info->info_3.asSpreadSpectrum[i].ulTargetClockRange))) { + if ((ss_assign->v3.ucClockIndication == id) && + (clock <= le32_to_cpu(ss_assign->v3.ulTargetClockRange))) { ss->percentage = - le16_to_cpu(ss_info->info_3.asSpreadSpectrum[i].usSpreadSpectrumPercentage); - ss->type = ss_info->info_3.asSpreadSpectrum[i].ucSpreadSpectrumMode; - ss->rate = le16_to_cpu(ss_info->info_3.asSpreadSpectrum[i].usSpreadRateIn10Hz); + le16_to_cpu(ss_assign->v3.usSpreadSpectrumPercentage); + ss->type = ss_assign->v3.ucSpreadSpectrumMode; + ss->rate = le16_to_cpu(ss_assign->v3.usSpreadRateIn10Hz); if ((id == ASIC_INTERNAL_ENGINE_SS) || (id == ASIC_INTERNAL_MEMORY_SS)) ss->rate /= 100; @@ -1555,6 +1573,8 @@ bool radeon_atombios_get_asic_ss_info(struct radeon_device *rdev, radeon_atombios_get_igp_ss_overrides(rdev, ss, id); return true; } + ss_assign = (union asic_ss_assignment *) + ((u8 *)ss_assign + sizeof(ATOM_ASIC_SS_ASSIGNMENT_V3)); } break; default: -- 1.8.3.1

1 0

[Bug 64850] New: Second screen black on Pitcairn PRO
by bugzilla-daemon＠freedesktop.org 16 Sep '13

16 Sep '13

https://bugs.freedesktop.org/show_bug.cgi?id=64850 Priority: medium Bug ID: 64850 Assignee: dri-devel(a)lists.freedesktop.org Summary: Second screen black on Pitcairn PRO Severity: normal Classification: Unclassified OS: Linux (All) Reporter: flocke(a)shadowice.org Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 79637 --> https://bugs.freedesktop.org/attachment.cgi?id=79637&action=edit dmesg | grep drm right after boot (no X11) I just installed my new Pitcairn PRO card (Radeon 7850) in my PC. Every time I boot into linux (Arch Linux x86_64) my second monitor turns black right at boot. There are no errors and I can even start X11 with my dual-monitor configuration and move the mouse from my first screen to the right. It is as if the screen is there, only my monitor doesn't show it. This happens not in X11, in fact the secend screen goes black as soon as the kernel/kms is loaded. I attached the output of 'dmesg | grep drm' with the drm.debug=15 kernel option right after booting and befor starting X11 and I will attach the same commands output after running X11. -- You are receiving this mail because: You are the assignee for the bug.

1 31

← Newer
1
...
69
70
71
72
73
74
75
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2013