Bug 2844

Summary: Radeon driver should wait for engine to become idle before uploading HW cursor data to framebuffer
Product: xorg Reporter: Michel Dänzer <michel>
Component: Driver/RadeonAssignee: Michel Dänzer <michel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high CC: aet
Version: git   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Patch
none
Patch, Take Two michel: 6.8-branch?

Description Michel Dänzer 2005-03-28 21:55:55 UTC 
The Radeon drivers generally wait for the engine to become idle before touching
the framebuffer. One exception is the HW cursor code. I'm going to attach and
commit to HEAD a patch which reportedly fixes lockups caused by this on some
machines when moving the mouse cursor.
Comment 1 Michel Dänzer 2005-03-28 21:57:40 UTC 
Created attachment 2229 [details] [review]
Patch
Comment 2 Michel Dänzer 2005-03-28 22:05:53 UTC 
Created attachment 2230 [details] [review]
Patch, Take Two

Better patch, moved the byte order independent code to a common macro.
Comment 3 Michel Dänzer 2005-03-28 22:16:38 UTC 
Committed to HEAD.
Comment 4 Michel Dänzer 2005-03-28 22:17:45 UTC 
Comment on attachment 2230 [details] [review]
Patch, Take Two

Should this be backported to the 6.8 branch?
Comment 5 Aapo Tahkola 2005-05-09 06:31:43 UTC 
Hard lock up when 3d app with reasonable fillrate is combined with cursor changes.
Option SWcursor seems to fix this.
Revisions 1.6 and 1.5 of radeon_cursor.c behave exact same.
Tested on Radeon 9600 pro.
Comment 6 Michel Dänzer 2005-05-09 14:13:39 UTC 
(In reply to comment #5)
> Hard lock up when 3d app with reasonable fillrate is combined with cursor changes.
> Option SWcursor seems to fix this.
> Revisions 1.6 and 1.5 of radeon_cursor.c behave exact same.

In other words, it's unrelated to this entry. Why did you reopen it?

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.