Alex Deucher wrote:
Before I go grepping through the tree, where would I find this code (in
the DRM, DRI, or 2D)? Also is it for r100 or r200 or both? is there a
r200_cp_dispatch_clear()?
It's in the drm module. The r200 shares the radeon kernel code.
Keith
--
Before I go grepping through the tree, where would I find this code (in
the DRM, DRI, or 2D)? Also is it for r100 or r200 or both? is there a
r200_cp_dispatch_clear()?
thanks,
Alex
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Tue, 2003-10-14 at 06:44, Alex Deucher wrote:
> > I've uploade
Sounds good. I may play around with it when I get a chance. Any other
thoughts on what it might be if not clears?
Alex
--- Michel D�nzer <[EMAIL PROTECTED]> wrote:
> On Tue, 2003-10-14 at 06:44, Alex Deucher wrote:
> > I've uploaded some screenshots as an example:
> > http://www.botchco.com/
On Tue, 2003-10-14 at 06:44, Alex Deucher wrote:
> I've uploaded some screenshots as an example:
> http://www.botchco.com/alex/2048-error/
>
> the new version of xscreensaver displays a separate instance on each
> head of a xinerama desktop. so in this case only the context running up
> again the
I've uploaded some screenshots as an example:
http://www.botchco.com/alex/2048-error/
the new version of xscreensaver displays a separate instance on each
head of a xinerama desktop. so in this case only the context running up
again the 2048 limit (the right side) shows the error. When I turn off
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2003-10-13 at 16:26, Alex Deucher wrote:
> >
> > perhaps the limit is actually 2047?
>
> No, the RE_WIDTH_HEIGHT register takes 11 bits for the coordinates of
> the rightmost column and bottommost line. There may be off-by-one
> errors
> i
On Mon, 2003-10-13 at 16:26, Alex Deucher wrote:
>
> perhaps the limit is actually 2047?
No, the RE_WIDTH_HEIGHT register takes 11 bits for the coordinates of
the rightmost column and bottommost line. There may be off-by-one errors
in the code though...
> perhaps it is bandwidth.
I agree with
Also, I don't think it's a bandwith issue. I can run mergedfb in
"above" mode with a virtual desktop of 1280x1792 (1024x768 above
1280x1024) and all is well. this is signifigantly more bandwidth than
2048x768. Unless the pitch has more to do with it than the height...
Alex
--- Michel Dänzer <[
You are right. Last night I created a virtual desktop of 2100x768 and
display mode of 1024x768, then ran several fullscreen GL xscreensaver
hacks. All of them displayed fine. I haven't looked at the source to
the hacks, but I assume they look at the current display mode and the
create a 3D windo
On Mon, 2003-10-13 at 06:13, Alex Deucher wrote:
> You can have as big a virtual desktop as you want so long as the total
> 3D contexts are not greater than 2048 in either direction.
Wrong. The 2048 limit is for the virtual location of the right and
bottom edges of 3D windows. The 3D engine couldn
You can have as big a virtual desktop as you want so long as the total
3D contexts are not greater than 2048 in either direction.
Alex
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2003-10-13 at 01:26, Alex Deucher wrote:
> > -- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > On Sun, 2003
On Mon, 2003-10-13 at 01:26, Alex Deucher wrote:
> -- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > On Sun, 2003-10-12 at 17:27, Alex Deucher wrote:
> > > Well, I solved the problem...sort of... it happens when I'm using a
> > > merged mode that's 2048 wide. Does anyone know why there would be
> >
Well, I just tried the mergedfb mode for the first time this evening and I
can confirm what Alex is seeing... Many of the GL xscreensaver modes (and
xlock modes) are pretty psychedlic.
On Sun, 12 Oct 2003, Alex Deucher wrote:
>
> --- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > On Sun, 2003-10-
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sun, 2003-10-12 at 17:27, Alex Deucher wrote:
> > Well, I solved the problem...sort of... it happens when I'm using a
> > merged mode that's 2048 wide. Does anyone know why there would be
> > corruption at 2048x768 (2 heads of 1024x768)? Has anyo
Further info on this. Not all GL apps are affected. I've only tried
xscreensavers. of the GL screensavers most show that corruption I
spoke of, but some seem unaffected (many from the rss package:
http://rss-glx.sourceforge.net/).
Those that work:
BusySpheres
Cage
Colorfire
Hufos smoke
hufos tu
On Sun, 2003-10-12 at 17:27, Alex Deucher wrote:
> Well, I solved the problem...sort of... it happens when I'm using a
> merged mode that's 2048 wide. Does anyone know why there would be
> corruption at 2048x768 (2 heads of 1024x768)? Has anyone tried a
> single head at 2048x1536?
You could tr
Well, I solved the problem...sort of... it happens when I'm using a
merged mode that's 2048 wide. Does anyone know why there would be
corruption at 2048x768 (2 heads of 1024x768)? Has anyone tried a
single head at 2048x1536? Mergedfb works at 2048x768, it just shows
that corruption I described b
I just got my 9200 up and running but I'm seeing some weird behavior.
3d works fine if I run in single head mode. however, if I run with
mergedfb I get weird corruption in fullscreen apps like screen savers.
for example, if I run the atlantis screen saver, there appears to be
"junk" from previou
18 matches
Mail list logo
