Bug 17341 - No pixmaps or text after 1ab7239b73a5e298cadaf44e5605cf05855f08e9
Summary: No pixmaps or text after 1ab7239b73a5e298cadaf44e5605cf05855f08e9
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: Other All
: high blocker
Assignee: Jesse Barnes
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: intel-2.5
  Show dependency treegraph
 
Reported: 2008-08-28 12:10 UTC by Philip Langdale
Modified: 2008-09-12 14:23 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
don't use drm_bo_map if !use_drm_mode (766 bytes, patch)
2008-08-29 09:04 UTC, Jesse Barnes
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Philip Langdale 2008-08-28 12:10:24 UTC
I've been tracking the bleeding edge Intel experience (drm/mesa/xserver) with the exception of kernel modesetting and after this particular change to the driver, text and pixmaps stopped rendering with EXA (and UXA just renders garbage as if the row stride is wrong)

It can't be reverted cleanly against the current tip.

My hardware is an Acer TravelMate 5720 with an X3100.
Comment 1 Jesse Barnes 2008-08-28 12:48:56 UTC
You could try something like this, but I'm seeing some bugginess too. with GEM enabled kernels.  Trying to track it down.

diff --git a/src/i965_render.c b/src/i965_render.c                              
index a4334c6..180bcfd 100644                                                   
--- a/src/i965_render.c                                                         
+++ b/src/i965_render.c                                                         
@@ -1450,7 +1450,7 @@ gen4_render_state_init(ScrnInfoPtr pScrn)                 
                                                                                
     render_state->card_state_offset = pI830->gen4_render_state_mem->offset;    
                                                                                
-    if (pI830->gen4_render_state_mem->bo) {                                    
+    if (pI830->use_drm_mode) {                                                 
        ret = dri_bo_map(pI830->gen4_render_state_mem->bo, 1);                  
        if (ret) {                                                              
            xf86DrvMsg(pScrn->scrnIndex, X_WARNING,                             
Comment 2 Philip Langdale 2008-08-28 14:27:02 UTC
That seems to have got things back to where they were. Thanks.
Comment 3 Gordon Jin 2008-08-29 06:06:19 UTC
Philip, are you using GEM kernel? Is the sympton the same as bug#17304?
Comment 4 Philip Langdale 2008-08-29 07:57:27 UTC
Yes, it seems like the same bug. His EXA and UXA + tiling symptoms seem exactly like mine. I have not tried UXA without tiling yet, but I'll check today.
Comment 5 Jesse Barnes 2008-08-29 09:04:35 UTC
Created attachment 18570 [details] [review]
don't use drm_bo_map if !use_drm_mode

Here's a more complete patch that fixes the teardown path as well.
Comment 6 Philip Langdale 2008-08-29 10:11:45 UTC
That fixes EXA but UXA without tiling looks the same - no pixmaps and text. And UXA with tiling shows the incorrect stride corruption. As a bonus, attempting to VT switch from X with UXA turned on causes it to immediately switch back to X. But who knows what's going on there.
Comment 7 Jesse Barnes 2008-08-29 10:34:35 UTC
Yeah, tiling & UXA don't get along right now, so you have to disable it manually.

The VT switch problem probably deserves a separate bug though.
Comment 8 Philip Langdale 2008-08-29 10:42:27 UTC
Just to clarify - UXA without tiling is *not* fixed by your patch. The patch only fixes EXA.
Comment 9 Gordon Jin 2008-09-09 19:04:12 UTC
Jesse, how about commit your patch?
I hope it could also help bug#17304 and #17425.
Comment 10 Jesse Barnes 2008-09-12 14:23:59 UTC
Ok, just pushed this workaround.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.