Hi,
Some of r300 driver lockups are card dependant (and for now I have
only these card dependand lockups). Cards which will lock (soon or
later) are 9500 Pro (maybe 9500 too), 9700, 9800. What card do you have ?
Try to load fglrx 2d driver first, then uload it and then use r300 driver.
Peter Zu
On 6/30/05, Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
> >
> >>Please note that I havent tested this with current xorg cvs because of
> >>various inconveniences.
> >>What about the 2560 limit?
> >>I noticed that with the new RADEONDoAdjustFrame I can have
> >>1280x1024-1280x1
On Sun, 26 Jun 2005 23:48:11 -0400
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote:
> > On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote:
> >
> > > Disagree also about axing the comment - its useful to know why something
> > > is being done.
> >
>
On Thu, Jun 30, 2005 at 12:04:13AM +0100, Dave Airlie wrote:
> The issues remaining are:
> a) should we provide backwards compat stuff for users of old kernels in
> DRM CVS, without cluttering up the nice code..
It'd be nice to do something. Using RedHat EL4 the DRM CVS fails to
build because the
Hi,
every now and then I try to run Xglx with the DRI r300 driver. It
doesn't really work at all, but you never know, maybe soon r300 will be
complete enough to get it working properly, so I try.
However, every time I run metacity under Xglx, X locks up immediately. I
was wondering if this m
http://bugzilla.kernel.org/show_bug.cgi?id=3192
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|DEFERRED|CLOSED
--- Additional Comments Fro
On Thu, Jun 30, 2005 at 11:32:52AM -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Alan Hourihane wrote:
> > On Thu, Jun 30, 2005 at 04:19:45 +0200, Egbert Eich wrote:
> >>Alan Hourihane writes:
> >> > On Thu, Jun 30, 2005 at 03:23:52 +0200, Egbert Eich wrote:
> >>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan Hourihane wrote:
> On Thu, Jun 30, 2005 at 04:19:45 +0200, Egbert Eich wrote:
>>Alan Hourihane writes:
>> > On Thu, Jun 30, 2005 at 03:23:52 +0200, Egbert Eich wrote:
>> > > Alan Hourihane writes:
>> > > > On Thu, Jun 30, 2005 at 09:46:41AM +0100
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Egbert Eich wrote:
> @@ -612,8 +612,7 @@
> _tnl_allow_pixel_fog( ctx, GL_FALSE );
> _tnl_allow_vertex_fog( ctx, GL_TRUE );
>
> - mmesa->primary_offset = mmesa->mgaScreen->primary.handle;
> -
> + mmesa->primary_offset = drmAgpBase(sPriv->
Paul Mackerras wrote:
Do either of you (or does anyone) have a good mental grasp of how
map handles and offsets are used and manipulated in the X server and
in DRI clients? In particular, I'm interested to know under what
circumstances map handles are generated by arithmetic on other map
handles
On Thu, Jun 30, 2005 at 04:19:45 +0200, Egbert Eich wrote:
> Alan Hourihane writes:
> > On Thu, Jun 30, 2005 at 03:23:52 +0200, Egbert Eich wrote:
> > > Alan Hourihane writes:
> > > > On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote:
> > > >
> > > > For i810 and i830 it can j
Alan Hourihane writes:
> On Thu, Jun 30, 2005 at 03:23:52 +0200, Egbert Eich wrote:
> > Alan Hourihane writes:
> > > On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote:
> > >
> > > For i810 and i830 it can just be removed as it isn't even used. The
> > other
> > > drivers j
On 6/30/05, Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
> >
> >>Please note that I havent tested this with current xorg cvs because of
> >>various inconveniences.
> >>What about the 2560 limit?
> >>I noticed that with the new RADEONDoAdjustFrame I can have
> >>1280x1024-1280x1
On Thu, Jun 30, 2005 at 03:23:52 +0200, Egbert Eich wrote:
> Alan Hourihane writes:
> > On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote:
> >
> > For i810 and i830 it can just be removed as it isn't even used. The other
> > drivers just need a little tweaking to remove it's use.
Alex Deucher wrote:
Please note that I havent tested this with current xorg cvs because of various
inconveniences.
What about the 2560 limit?
I noticed that with the new RADEONDoAdjustFrame I can have 1280x1024-1280x1024
setup if I remove the limits.
I assume you are talking about the limi
Paul Mackerras writes:
> Egbert Eich writes:
>
> > Exactly. If we want 32 and 64-bit pices to work together we need 32bit
> > handles. If you pass a 64bit handle to a 32-bit client it's useless
> > as mmap() cannot deal with a value in offset that doesn't fit into
> > 32 bit. - at least unle
Alan Hourihane writes:
> There's another issue here.
>
> And that's drmAddress in the 2D DDX drivers.
>
> On 32bit arches it's 32bits, on 64bit arches it's 64bit. And because
> drmAddress is passed in the *DRIRec things break.
>
> The client-side 3D driver gets the *DRIRec and as it's a
Alan Hourihane writes:
> On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote:
>
> For i810 and i830 it can just be removed as it isn't even used. The other
> drivers just need a little tweaking to remove it's use.
>
How about casting it to drm_handle_t?
Cheers,
Egbert.
On 6/30/05, Aapo Tahkola <[EMAIL PROTECTED]> wrote:
> On Wed, 29 Jun 2005 22:07:35 -0400
> Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> > On 6/29/05, Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> > > Hamish Marson wrote:
> > > > Fixed it.
> > > >
> > > > Sorry. It isn't an r300 problem... Or at l
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2229
[EMAIL PROTECTED] changed:
What|Removed |Added
--
Paul Mackerras writes:
> Egbert Eich writes:
>
> > ... and reinvented the weel repeating the same errors that I have
> > already been thru.
>
> What errors do you refer to?
>
Well, I've added a few points to Eric's wiki page.
http://dri.freedesktop.org/wiki/DrmMapHandling
I wou
Egbert Eich writes:
> Exactly. If we want 32 and 64-bit pices to work together we need 32bit
> handles. If you pass a 64bit handle to a 32-bit client it's useless
> as mmap() cannot deal with a value in offset that doesn't fit into
> 32 bit. - at least unless we set -D_FILE_OFFSET_BITS=64. However
I had originally posted this on the xorg-devel mailing list, but didn't get
much response, so thought I'd try my luck here...
I was just wondering if there was any progress or planned work to
update the server's GLX implementation to 1.3.? It looks like about
half of the work is already done, sin
On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote:
> There's another issue here.
>
> And that's drmAddress in the 2D DDX drivers.
>
> On 32bit arches it's 32bits, on 64bit arches it's 64bit. And because
> drmAddress is passed in the *DRIRec things break.
>
> The client-side 3D drive
There's another issue here.
And that's drmAddress in the 2D DDX drivers.
On 32bit arches it's 32bits, on 64bit arches it's 64bit. And because
drmAddress is passed in the *DRIRec things break.
The client-side 3D driver gets the *DRIRec and as it's a different size
things are a mess when using a 3
Eric Anholt writes:
>
> I've taken a look, and started writing down my understanding of handles
> and offsets here:
> http://dri.freedesktop.org/wiki/DrmMapHandling
Thanks for putting together this page!
>
> As far as I could tell, math was not being done on handles. This makes
> sense,
Paul Mackerras writes:
> > Haven't I mentined that it does? Handles that fit into 32bit
> > should be handed to userspace unchanged, therefore if there is any
> > code left that does arithmetic with these handles should continue
> > to work. Handles that are used as real bases should be 32bit
27 matches
Mail list logo
