Re: Radeon mouse pointer bug
On Mon, 2003-02-17 at 16:18, Sean E. Russell wrote: > > On Monday 17 February 2003 05:52 am, Michel Dänzer wrote: > > The patch is only an attempt to fix the crashes with software cursor. > > Heh. Sorry. I didn't try to crash the server. > > Y'know, this gets me to thinking... getting accellerated GL working on X can > sometimes be a chore. If this patch silently disables GL when SWCursor is > present, [...] Please look at the patch before commenting on it. It doesn't disable the DRI with software cursor (I merely said that would be the worst case solution) but guards the function calls which I suspect cause the crash. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon mouse pointer bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 17 February 2003 05:52 am, Michel Dänzer wrote: > The patch is only an attempt to fix the crashes with software cursor. Heh. Sorry. I didn't try to crash the server. Y'know, this gets me to thinking... getting accellerated GL working on X can sometimes be a chore. If this patch silently disables GL when SWCursor is present, wouldn't this make it much more difficult for newbies to track down why "they've done everything they can think of, following all of the examples and tutorials they can find, but DRM just doesn't work?" IM(limited)E, there are plenty of messages saying /what/ has been done, but few saying /why/. Just voicing a stream of conciousness. In any case, I think you guys are doing a great job. > > Are you suggesting that I might be able to fix this if I pull the head of > > CVS and build from those sources, > > Yes. Ok, thanks. - -- ### SER Deutsch|Esperanto|Francaise|Linux|Java|Ruby|Aikido|Dirigibles ### ### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737 ### ### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg ### -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+UP0yP0KxygnleI8RAr96AJwOfIkkEno2RtNmC/5ocQjMW/XtCwCgtVPb ah+IGO2OLrkbFUWX/V642QM= =f6Pj -END PGP SIGNATURE- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon mouse pointer bug
On Mon, 2003-02-17 at 08:11, Sean E. Russell wrote: > > On Sunday 16 February 2003 04:47 pm, Michel Dänzer wrote: > ... > > 'Of course'? A crash is a bug. Does this patch help? > ... > > Unfortunately, it doesn't. I made sure that I unloaded the radeon and agpgart > kernel modules (although I didn't reboot) before starting X. I also verified > that, in the XFree logfile: > > (II) RADEON(0): Using hardware cursor (scanline 1052) > > but the lag is still present. The patch is only an attempt to fix the crashes with software cursor. > Are you suggesting that I might be able to fix this if I pull the head of CVS > and build from those sources, Yes. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Radeon mouse pointer bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Quotes reordered] On Sunday 16 February 2003 04:47 pm, Michel Dänzer wrote: ... > 'Of course'? A crash is a bug. Does this patch help? ... Unfortunately, it doesn't. I made sure that I unloaded the radeon and agpgart kernel modules (although I didn't reboot) before starting X. I also verified that, in the XFree logfile: (II) RADEON(0): Using hardware cursor (scanline 1052) but the lag is still present. ... > handling vertical blank interrupts. This has been fixed in XFree86 CVS > after RC1. DRI CVS doesn't even have the affected code yet. I'm building from a Gentoo ebuild (modified to include the patch) -- the ebuild is xfree-drm, so I assume it contains whatever is necessary for DRI. At least, it worked on my machine when all else failed :-) Are you suggesting that I might be able to fix this if I pull the head of CVS and build from those sources, or does the fact that the patch doesn't solve my problem indicate that I'm further from a solution than that? Thanks, by the way, for your time and attention. - -- ### SER Deutsch|Esperanto|Francaise|Linux|Java|Ruby|Aikido|Dirigibles ### ### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737 ### ### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg ### -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+UIsrP0KxygnleI8RApHFAJ49fqCTYBnxz8AkBx8XybHL7iAv8ACgvryX 2lhBvbUlov3YmNCzT1Fwi88= =j/Cf -END PGP SIGNATURE- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon mouse pointer bug
On Mon, 2003-02-17 at 01:18, Sean E. Russell wrote: > > On Sunday 16 February 2003 04:47 pm, Michel Dänzer wrote: > > > First, I'm using KDE 3.1, which provides a shaded, transluescent mouse > > > pointer for the I-bar and the arrow; the other pointers (the hourglass, > > > the hand, the resize shapes) are the regular X shapes. > > > > Actually, I think they aren't, that's why they're not ARGB as well. This > > isn't a feature of KDE but the new Xlib. > > ARGB? The new cursors have 8 bits per alpha, red, green and blue component. > > > 4) The option SWCursor fixes the problem, but then of course causes X to > > > crash when trying to access any of the OpenGL functions. > > > > 'Of course'? A crash is a bug. Does this patch help? > > I say "of course," because I believe it was documented that DRI doesn't work > with SWCursor. True, software cursors don't mix well with the DRI and Xv, but it should never crash. In the worst case, the DRI should be disabled when software cursors are forced. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Radeon mouse pointer bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 16 February 2003 04:47 pm, Michel Dänzer wrote: > > First, I'm using KDE 3.1, which provides a shaded, transluescent mouse > > pointer for the I-bar and the arrow; the other pointers (the hourglass, > > the hand, the resize shapes) are the regular X shapes. > > Actually, I think they aren't, that's why they're not ARGB as well. This > isn't a feature of KDE but the new Xlib. ARGB? And, I had attributed the feature to KDE, because I had read somewhere that, well, it was a new feature of KDE 3.1 :-) It was probably a case of the blind leading the blind. > > 4) The option SWCursor fixes the problem, but then of course causes X to > > crash when trying to access any of the OpenGL functions. > > 'Of course'? A crash is a bug. Does this patch help? I say "of course," because I believe it was documented that DRI doesn't work with SWCursor. I'll try the patch, and let you know. Thanks! - -- ### SER Deutsch|Esperanto|Francaise|Linux|Java|Ruby|Aikido|Dirigibles ### ### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737 ### ### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg ### -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+UCpIP0KxygnleI8RAkTuAJ0YlrC01ojwngz5EBjX+gfoGKiKPwCfVzYf Nfg/0PSsti2RqJ3nl2e/gFU= =ByMW -END PGP SIGNATURE- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Radeon mouse pointer bug
On Son, 2003-02-16 at 21:59, Sean E. Russell wrote:
>
> I've been talking with Felix Kühling about a problem I've been observing WRT
> DRI, my Radeon, and KDE 3.1, and he suggested that it might be time to submit
> a bug report to the devel list, so here I am.
>
> The summary of the problem is that, with accellerated GL enabled, I get a lag
> of 2 seconds each time the mouse pointer changed "modes."
>
> First, I'm using KDE 3.1, which provides a shaded, transluescent mouse pointer
> for the I-bar and the arrow; the other pointers (the hourglass, the hand, the
> resize shapes) are the regular X shapes.
Actually, I think they aren't, that's why they're not ARGB as well. This
isn't a feature of KDE but the new Xlib.
The problem has been discussed on the XFree86 lists; the radeon 2D
driver function to wait for a vertical blank interfered with the DRM
handling vertical blank interrupts. This has been fixed in XFree86 CVS
after RC1. DRI CVS doesn't even have the affected code yet.
> 4) The option SWCursor fixes the problem, but then of course causes X to crash
> when trying to access any of the OpenGL functions.
'Of course'? A crash is a bug. Does this patch help?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v
retrieving revision 1.30
diff -p -u -r1.30 radeon_dri.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 2003/02/08 23:27:36 1.30
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 2003/02/16 22:46:20
@@ -1829,7 +1829,9 @@ static void RADEONDRITransitionTo3d(Scre
RADEONEnablePageFlip(pScreen);
info->have3DWindows = 1;
-xf86ForceHWCursor (pScreen, TRUE);
+
+if (info->cursor_start)
+ xf86ForceHWCursor (pScreen, TRUE);
}
static void RADEONDRITransitionTo2d(ScreenPtr pScreen)
@@ -1852,5 +1854,7 @@ static void RADEONDRITransitionTo2d(Scre
xf86FreeOffscreenArea(info->depthTexArea);
info->have3DWindows = 0;
-xf86ForceHWCursor (pScreen, FALSE);
+
+if (info->cursor_start)
+ xf86ForceHWCursor (pScreen, FALSE);
}
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c,v
retrieving revision 1.23
diff -p -u -r1.23 radeon_video.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c 2003/01/29 18:06:07 1.23
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c 2003/02/16 22:46:20
@@ -680,7 +680,8 @@ RADEONStopVideo(ScrnInfoPtr pScrn, point
if(pPriv->videoStatus & CLIENT_VIDEO_ON) {
RADEONWaitForFifo(pScrn, 2);
OUTREG(RADEON_OV0_SCALE_CNTL, 0);
- xf86ForceHWCursor (pScrn->pScreen, FALSE);
+ if (info->cursor_start)
+ xf86ForceHWCursor (pScrn->pScreen, FALSE);
}
if(info->videoLinear) {
xf86FreeOffscreenLinear(info->videoLinear);
@@ -1282,7 +1283,7 @@ RADEONPutImage(
REGION_RECTS(clipBoxes));
}
-if (!(pPriv->videoStatus & CLIENT_VIDEO_ON))
+if (info->cursor_start && !(pPriv->videoStatus & CLIENT_VIDEO_ON))
xf86ForceHWCursor (pScrn->pScreen, TRUE);
RADEONDisplayVideo(pScrn, id, offset, offset, width, height, dstPitch,
@@ -1349,7 +1350,7 @@ RADEONVideoTimerCallback(ScrnInfoPtr pSc
if(pPriv->offTime < now) {
unsigned char *RADEONMMIO = info->MMIO;
OUTREG(RADEON_OV0_SCALE_CNTL, 0);
- if (pPriv->videoStatus & CLIENT_VIDEO_ON)
+ if (info->cursor_start && pPriv->videoStatus & CLIENT_VIDEO_ON)
xf86ForceHWCursor (pScrn->pScreen, FALSE);
pPriv->videoStatus = FREE_TIMER;
pPriv->freeTime = now + FREE_DELAY;
@@ -1360,7 +1361,7 @@ RADEONVideoTimerCallback(ScrnInfoPtr pSc
xf86FreeOffscreenLinear(info->videoLinear);
info->videoLinear = NULL;
}
- if (pPriv->videoStatus & CLIENT_VIDEO_ON)
+ if (info->cursor_start && pPriv->videoStatus & CLIENT_VIDEO_ON)
xf86ForceHWCursor (pScrn->pScreen, FALSE);
pPriv->videoStatus = 0;
info->VideoTimerCallback = NULL;
@@ -1543,7 +1544,8 @@ RADEONDisplaySurface(
if (portPriv->videoStatus & CLIENT_VIDEO_ON) {
REGION_EMPTY(pScrn->pScreen, &portPriv->clip);
UpdateCurrentTime();
- xf86ForceHWCursor (pScrn->pScreen, FALSE);
+ if (info->cursor_start)
+ xf86ForceHWCursor (pScrn->pScreen, FALSE);
portPriv->videoStatus = FREE_TIMER;
portPriv->freeTime = currentTime.milliseconds + FREE_DELAY;
info->VideoTimerCallback = RADEONVideoTimerCallback;
