Bug 11870

Created attachment 11013 [details] [review]
locking workaround and cleanup

Locking workaround was provided Kostik Belousov kostikbel@gmail.com.  It modifies drm_close to only remove locking on the last close.  He recommends that device cloning as the final fix.

Patch tested on FreeBSD 7.0 current.

This looks pretty close, but now the file-priv-last-close code isn't being called until the whole-device last-close.  Looks solvable, though.

I've pushed a test exposing the issue for now.

Created attachment 11176 [details] [review]
revised drm_drv.c patch

Moved the file_priv->refs == 0 check earlier.  Patch includes the shared-code comment, but not the style required white-space changes.

Created attachment 11334 [details] [review]
Revised patch with style(9) fixes.

Created attachment 11358 [details] [review]
FreeBSD-current-compatible version of patch 11334

Modified Jung-uk Kim's patch to compile on FreeBSD-current

I have the following video hardware (on an AMD64 Athlon64 Mobile laptop):

drm0: <ATI Radeon RV350 Mobility 9600 M10 NP> on vgapci0
info: [drm] AGP at 0xe0000000 256MB
info: [drm] Initialized radeon 1.25.0 20060524
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R300 Microcode
info: [drm] writeback test succeeded in 1 usecs

Oops, forgot to mention that after I applied the attached patch, I have compiz working properly as my window manager, with all of the eye candy goodies it provides. It works much better than the in-tree behavior (kernel panic and I have to hard-power-off the box!), and it seems almost 99% perfectly useable.

BTW I am using the open-source r300 driver, as it's the only functional one for FreeBSD/amd64.

I get pretty darn good performance from all of them, including the plugins where an app is updating a window that is viewable during some sort of transformation effect (for example, manual Cube rotation while watching a YouTube video works very well).

Anybody know how to enable FSAA with the Open-Source r300 driver?

Three minor "bad" effects that I've noticed:
If I am using the "decoration" plugin, and have "/apps/compiz/plugins/decoration/allscreens/options/shadow_match" set to "any", then I get these ugly thick white borders around every on screen element that is not a normal window (menus, tooltips, etc...), while the shadows seem to appear fine for the normal window. I set this value to "none" and the artifacts went away (and I still seem to have drop-shadows from my windows).

A slow-down in the default (mode 0) resize method in compiz. It is too slow for me to use, as it sends update requests back to the window during the resize, causing the window to redraw itself (and re-lay-out its contents). This has been a relatively slow feature in most WM's for me though, and I think it is more likely linked to how GTK+ handles this event.

I have also noticed that the Totem video player seems to black-out the video when any screen event happens. If I re-size or move the Totem window, however, the video is redisplayed just fine. I added the "video" plugin to compiz and I get this behavior.

*** Bug 6463 has been marked as a duplicate of this bug. ***

*** Bug 12443 has been marked as a duplicate of this bug. ***

Created attachment 11602 [details]
screen corruption w/ patch 11358

screen corruption occurs at the top of the screen on T43p

Created attachment 11603 [details]
xlog for 11602

the driver still needs to have reasonableness checks like those described in http://bugs.freedesktop.org/show_bug.cgi?id=12443#c5

jkim's version committed.

(In reply to comment #13)
> jkim's version committed.
> 

Where was it committed? I still don't see it in FreeBSD -CURRENT...

This was committed to git master, I've asked anholt to commit to freebsd src as well.

Screen corruption still occurs on T43p (and it seems the screen is not repainted) unless         

Option      "CPPIOMode" "yes"

is specified.

I don't see how this is related to the original bug and I have not seen this on any radeon chipset that I have access to.

Applying the above patch (11334) leads to screen corruption and no refresh when running apps. Also see http://www.freebsd.org/cgi/query-pr.cgi?pr=119324

I still don't see any evidence that this is related to locking or AIGLX, which is the origin of this bug.  The user in the FreeBSD PR isn't even using AIGLX.  This issue appears to be chipset specific and may not be drm related at all.  Please file this as a new bug, including versions of xserver, mesa, ddx driver, and drm modules.  Also, please verify that the problem does not exist if dri is disabled and what steps are required to demonstrate the screen corruption.

Re-resolve bug from invalid reopening.