[PATCH] Improve wait_vline range
Hi alex, the attached patch is an improvement to the wait_vline_range function. It adds a checking that the desired crtc is active and limits the given vline range to the visible are of the crtc, fxing the issue that the xserver gets a runaway process. Could you push this to the r6xx-r7xx-support branch? Thanks, Christian.
On Sun, Feb 22, 2009 at 1:08 PM, Christian König
Hi alex,
the attached patch is an improvement to the wait_vline_range function. It adds a checking that the desired crtc is active and limits the given vline range to the visible are of the crtc, fxing the issue that the xserver gets a runaway process.
Could you push this to the r6xx-r7xx-support branch?
Pushed! thanks Christian, Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
This patch introduces a segfault for me due to rhdCrtc->CurrentMode being NULL. Had to work around it with the following: diff --git a/src/r6xx_accel.c b/src/r6xx_accel.c index 19a339f..c5b0f50 100644 --- a/src/r6xx_accel.c +++ b/src/r6xx_accel.c @@ -209,7 +209,7 @@ wait_vline_range(ScrnInfoPtr pScrn, drmBufPtr ib, int crtc, int start, int stop) return; start = max(start, 0); - stop = min(stop, rhdCrtc->CurrentMode->VDisplay-1); + stop = min(stop, (rhdCrtc->CurrentMode ? rhdCrtc->CurrentMode->VDisplay : rhdCrtc->Height) - 1); #if 0 ErrorF("wait_vline_range: start %d stop %d\n", start, stop); Haven't had a chance to figure out why DxModeSet, which sets CurrentMode, isn't called. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
This patch introduces a segfault for me due to rhdCrtc->CurrentMode being NULL. Had to work around it with the following: Using height is not a god idea, since it is the height of the
Am Dienstag, den 24.02.2009, 00:01 -0800 schrieb Yang Zhao: framebuffer, not what the crtc is actually scanning out of the framebuffer (AFAIK). Waiting for a line that's not scanned out can easyly deadlock the hardware.
Haven't had a chance to figure out why DxModeSet, which sets CurrentMode, isn't called. I know why, Active gets set when the Crtc is assigned to ANY connector, and not if the crtc is active and displaying a picture. You probably have more than one connector and the monitor isn't connected to the first one. We are hardcoded waiting on the first one atm, since i haven't had time yet to figure out on which crtc we are actually rendering.
@Alex: Could you push this bugfix (again). I promise not to write patches at three o'clock in the morning again. Bye, Christian.
On Tue, Feb 24, 2009 at 4:45 PM, Christian König
This patch introduces a segfault for me due to rhdCrtc->CurrentMode being NULL. Had to work around it with the following: Using height is not a god idea, since it is the height of the
Am Dienstag, den 24.02.2009, 00:01 -0800 schrieb Yang Zhao: framebuffer, not what the crtc is actually scanning out of the framebuffer (AFAIK). Waiting for a line that's not scanned out can easyly deadlock the hardware.
Haven't had a chance to figure out why DxModeSet, which sets CurrentMode, isn't called. I know why, Active gets set when the Crtc is assigned to ANY connector, and not if the crtc is active and displaying a picture. You probably have more than one connector and the monitor isn't connected to the first one. We are hardcoded waiting on the first one atm, since i haven't had time yet to figure out on which crtc we are actually rendering.
@Alex: Could you push this bugfix (again). I promise not to write patches at three o'clock in the morning again.
no worries :) Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Feb 24, 09 22:45:20 +0100, Christian König wrote:
Could you push this bugfix (again). I promise not to write patches at three o'clock in the morning again.
We've all done that in the past, and we will probably continue to do so
:-P
Thanks for you work, Christian!
Matthias
--
Matthias Hopf
participants (4)
-
Alex Deucher -
Christian König -
Matthias Hopf -
Yang Zhao