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 as
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, since
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
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 driver gets
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,
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
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 would be
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
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 unless we set
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
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.
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-1280x1024 setup if I
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 just need a
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 just be removed as
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
-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-fd);
-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, Alan
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:
Alan
http://bugzilla.kernel.org/show_bug.cgi?id=3192
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|DEFERRED|CLOSED
--- Additional Comments
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
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
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.
Wait, the
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-1280x1024 setup if I
23 matches
Mail list logo
