Alan Hourihane writes:
It'd be nice to do something. Using RedHat EL4 the DRM CVS fails to
build because the .compat_ioctl doesn't exist in 2.6.9.
Or, at the very least, we'll need to check if compat_ioctl exists before
allowing compilation.
Well, that may be the way to go. The code
Ian Romanick writes:
-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;
-
+
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
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
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.
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
-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
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
Dave Airlie writes:
Looks like that Dave Airlie has pushed another set of patches
made by Paul Mackerras into the DRM code.
My patches support a wider range of chipsets (Matrox, R128 and Radeon)
and provide a framework which makes it easy to add ioctl32 support
to more chipsets.
Dave, if you cannot test this why do you want to port my code
to Paul's sceme - which seems to be much more error prone than
using my sceme?
As Pauls scheme was written from what I could see from a kernel
developers point of view, it is maintainable for other kernel developers..
reviewing it
Alan Hourihane writes:
I understand the backwards compatibility issues and that's good to have,
but even Paul noted that when the chance arrives that the scheme should
be changed to match more of what Egbert was trying to achieve.
I had been hoping for some more comments from the senior DRI
I had been hoping for some more comments from the senior DRI hackers.
Egbert's patch takes somewhat the opposite approach from mine; where I
extended the RADEONDRIRec structure to have space for 64-bit handles,
Egbert's patch unconditionally makes the drm_handle_t be 32-bit.
Which is fine if
Egbert Eich writes:
My patches support a wider range of chipsets (Matrox, R128 and Radeon)
and provide a framework which makes it easy to add ioctl32 support
to more chipsets.
Unfortunately your macros have the effect of increasing the effort
required by a kernel developer to read and
Egbert Eich writes:
And yes, I know the macros seem to be ugly. However they make writing
ioctl32 support for new drivers really easy as one doesn't have to
understand the macros.
Well, it's really the obfuscation rather than the ugliness which is
the problem. I disagree that one doesn't
Dave Airlie writes:
The changes to types need to clarify what exactly breaks where, I'm not as
worried about the interactions between X and Mesa as I am about old
Xs and new kernels...
And in context, this comes down to the expectations of existing 64-bit
X servers and DRI clients on 64-bit
Egbert Eich writes:
My patches to drm/X are mainly required to make shared structures
identical in size.
To me the main question is whether we should leave space for 64-bit
handles, or whether 32-bit handles will be sufficient under all
circumstances.
Paul.
Dave Airlie wrote:
I had been hoping for some more comments from the senior DRI hackers.
Egbert's patch takes somewhat the opposite approach from mine; where I
extended the RADEONDRIRec structure to have space for 64-bit handles,
Egbert's patch unconditionally makes the drm_handle_t be 32-bit.
Paul Mackerras writes:
Egbert Eich writes:
My patches support a wider range of chipsets (Matrox, R128 and Radeon)
and provide a framework which makes it easy to add ioctl32 support
to more chipsets.
Unfortunately your macros have the effect of increasing the effort
required by
Dave Airlie writes:
I had been hoping for some more comments from the senior DRI hackers.
Egbert's patch takes somewhat the opposite approach from mine; where I
extended the RADEONDRIRec structure to have space for 64-bit handles,
Egbert's patch unconditionally makes the
Paul Mackerras writes:
Egbert Eich writes:
Non of the patches that I've posted had problems with backward
compatibility.
At least not across the kernel/user space interface.
Originally I had one that wasn't however that had been fixed before
I put patches into the fd.o
Paul Mackerras writes:
Dave Airlie writes:
The changes to types need to clarify what exactly breaks where, I'm not as
worried about the interactions between X and Mesa as I am about old
Xs and new kernels...
And in context, this comes down to the expectations of existing 64-bit
On Wed, 2005-06-29 at 21:29 +1000, Paul Mackerras wrote:
Egbert Eich writes:
My patches support a wider range of chipsets (Matrox, R128 and Radeon)
and provide a framework which makes it easy to add ioctl32 support
to more chipsets.
Unfortunately your macros have the effect of
Now I've hacked that code together in little over two hours (while
watching Raiders of the lost Ark) I don't see the advantage adding all the
macros will bring, once you've identified which structs/ioctls need work,
a quick editor macro can generate the code nearly... (granted I'm
Yes a bit of interest from idr, alanh and keithw might help us out here...
(and anyone else who knows this area)
Yes, sorry about this. As it stands I don't have a particularly good
understanding of the issues and will have to spend a bit of time getting up to
speed before I can
Egbert Eich writes:
... and reinvented the weel repeating the same errors that I have
already been thru.
What errors do you refer to?
Paul.
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple
On Tue, Jan 18, 2005 at 12:45:23AM +, Dave Airlie wrote:
Is it possible to run 32bit OpenGL applications on an AMD64 with DRI
support? 64bit applications are working fine, but 32bit apps always
use software rendering on my machine (Radeon 7500).
It looks like an kernel issue. So my
bugzilla 943 on bugs.freedesktopp.org
Egbert is hoping to look at it again, I keep getting hopelessly lost in
types when I start looking at it.. I don't have the hardware to test it
on...
Egbert's patch has been updated and it's looking good.
I'd suggest committing it to CVS now for
On Tue, Jun 28, 2005 at 01:16:14PM +0100, Dave Airlie wrote:
bugzilla 943 on bugs.freedesktopp.org
Egbert is hoping to look at it again, I keep getting hopelessly lost in
types when I start looking at it.. I don't have the hardware to test it
on...
Egbert's patch has been
On Tue, Jun 28, 2005 at 02:02:39PM +0100, Dave Airlie wrote:
I've started pushing the kernel bits to the kernel from Paulus, Linus has
accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and
r128 and whatever other bits are in Egberts patch...
If this stuff is
I was just a little perplexed (as I'm sure Egbert was too) that the bug #943
hadn't been updated by Paul and all of a sudden it appears in the kernel
first without being in the DRM CVS for at least a little while to get
tested here.
Paul and Egbert discussed it on the bug at the time Paul
On Tue, Jun 28, 2005 at 02:20:44PM +0100, Dave Airlie wrote:
I was just a little perplexed (as I'm sure Egbert was too) that the bug #943
hadn't been updated by Paul and all of a sudden it appears in the kernel
first without being in the DRM CVS for at least a little while to get
Alan Hourihane writes:
On Tue, Jan 18, 2005 at 12:45:23AM +, Dave Airlie wrote:
Is it possible to run 32bit OpenGL applications on an AMD64 with DRI
support? 64bit applications are working fine, but 32bit apps always
use software rendering on my machine (Radeon 7500).
It
Dave Airlie writes:
I've started pushing the kernel bits to the kernel from Paulus, Linus has
accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and
r128 and whatever other bits are in Egberts patch...
I have solved the map-handle issue differently in my code.
Also
Dave Airlie writes:
I've started pushing the kernel bits to the kernel from Paulus, Linus has
accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and
r128 and whatever other bits are in Egberts patch...
If this stuff is in the kernel, hasn't it been
Dave Airlie writes:
I was just a little perplexed (as I'm sure Egbert was too) that the bug
#943
hadn't been updated by Paul and all of a sudden it appears in the kernel
first without being in the DRM CVS for at least a little while to get
tested here.
Paul and Egbert
Alan Hourihane writes:
On Tue, Jun 28, 2005 at 02:20:44PM +0100, Dave Airlie wrote:
I was just a little perplexed (as I'm sure Egbert was too) that the bug
#943
hadn't been updated by Paul and all of a sudden it appears in the kernel
first without being in the DRM CVS
Looks like that Dave Airlie has pushed another set of patches
made by Paul Mackerras into the DRM code.
My patches support a wider range of chipsets (Matrox, R128 and Radeon)
and provide a framework which makes it easy to add ioctl32 support
to more chipsets.
Furthermore they have support
On Mon, 17 Jan 2005 21:44:47 +0100, Markus T. [EMAIL PROTECTED] wrote:
Is it possible to run 32bit OpenGL applications on an AMD64 with DRI
support? 64bit applications are working fine, but 32bit apps always
use software rendering on my machine (Radeon 7500).
It looks like an kernel issue. So
Is it possible to run 32bit OpenGL applications on an AMD64 with DRI
support? 64bit applications are working fine, but 32bit apps always
use software rendering on my machine (Radeon 7500).
It looks like an kernel issue. So my question is, if there are any kernel
patches available to solve
48 matches
Mail list logo
