Hi!
On 6/28/05, Ian Romanick [EMAIL PROTECTED] wrote:
3) Can the driver pre-build the AGP/PCI gart maps? If these maps are
marked differently it is way for my driver to tell AGP from PCI cards.
I would advise against that. There are (rare) cases where user-mode
wants to select AGP
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
Hamish Marson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hamish Marson wrote:
Just as a status report...
On my thinkpad r50p which has an rv350 (FireGL-T2) when using the
current CVS xorg, CVS Mesa and the tagged r300 driver
'the_perfect_frag') it all works, 1600fps on glxgears,
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
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, or obtained from a
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.
On 6/29/03, Rune Petersen [EMAIL PROTECTED] wrote:
Hamish Marson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hamish Marson wrote:
Just as a status report...
On my thinkpad r50p which has an rv350 (FireGL-T2) when using the
current CVS xorg, CVS Mesa and the tagged r300
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
On 6/29/05, Thomas Hellström [EMAIL PROTECTED] wrote:
Currently the drivers are AddMap'ing multiple little maps over the AGP
area, but the area is basically split into two area: private for the
master and public for the DRI clients to write to.
So to get around the root priv requirement
Hi all,
I am new to linux. I am intesrested in developing
drivers for graphics cards.
I want to setup a debugging environment for DRM/DRI. I
have a RADEON 9600 PRO card. And, I have the card on a
m/c which has linux kernel 2.6.7( compiled with KGDB
enabled). I also have X11( 6.8.2) installed on
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 6/29/05, Paul Mackerras [EMAIL PROTECTED] 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
On 6/29/05, Prashanth Hegde [EMAIL PROTECTED] wrote:
Hi all,
I am new to linux. I am intesrested in developing
drivers for graphics cards.
Hopefully I've not misread your email. As far as I know, the 'radeon'
driver should support 2D well enough, but you'll need the
(still-beta?) driver from
On 6/29/05, Jon Smirl [EMAIL PROTECTED] wrote:
drmAgpAlloc() allocs drm_agp_mem structures which track the agp
allocs. I could change the map system to allow a single map to be
paired with each struct drm_agp_mem.
The 2MB restricted you are using was allocated with a call to
drmAgpAlloc(),
In i810/server/i810_dri.c there is a call to agp alloc without the
type set to zero:
drmAgpAlloc(ctx-drmFD, 4096 * 1024, 1, NULL, dcacheHandle);
A type of one translates into U16_APER_SIZE which doesn't match the
request size of 4MB.
Is this a bug or do I not understand the type parameter on agp
Jon Smirl wrote:
In i810/server/i810_dri.c there is a call to agp alloc without the
type set to zero:
drmAgpAlloc(ctx-drmFD, 4096 * 1024, 1, NULL, dcacheHandle);
A type of one translates into U16_APER_SIZE which doesn't match the
request size of 4MB.
Is this a bug or do I not understand the
On 6/29/05, Keith Whitwell [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
In i810/server/i810_dri.c there is a call to agp alloc without the
type set to zero:
drmAgpAlloc(ctx-drmFD, 4096 * 1024, 1, NULL, dcacheHandle);
A type of one translates into U16_APER_SIZE which doesn't match the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir Dergachev wrote:
On Wed, 29 Jun 2005, Hamish Marson wrote:
Hamish Marson wrote:
Just as a status report...
On my thinkpad r50p which has an rv350 (FireGL-T2) when using
the current CVS xorg, CVS Mesa and the tagged r300 driver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher wrote:
On 6/29/03, Rune Petersen [EMAIL PROTECTED] wrote:
Hamish Marson wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Hamish Marson wrote:
Just as a status report...
On my thinkpad r50p which has an rv350 (FireGL-T2)
On 6/29/05, Hamish Marson [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher wrote:
On 6/29/03, Rune Petersen [EMAIL PROTECTED] wrote:
Hamish Marson wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Hamish Marson wrote:
Just as a
On Wed, 2005-06-29 at 13:36 -0400, Jon Smirl wrote:
On 6/29/05, Keith Whitwell [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
In i810/server/i810_dri.c there is a call to agp alloc without the
type set to zero:
drmAgpAlloc(ctx-drmFD, 4096 * 1024, 1, NULL, dcacheHandle);
A type of one
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher wrote:
On 6/29/05, Hamish Marson [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
On 6/29/03, Rune Petersen [EMAIL PROTECTED] wrote:
Hamish Marson wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Hamish Marson wrote:
Just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher wrote:
On 6/29/05, Hamish Marson [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
On 6/29/03, Rune Petersen [EMAIL PROTECTED] wrote:
Hamish Marson wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Hamish Marson wrote:
Just
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
Hamish Marson wrote:
Fixed it.
Sorry. It isn't an r300 problem... Or at least doesn't LOOK like an
r300 problem. I changed the xorg.conf set
Option EnablePageFlip on # [bool]
to
Option EnablePageFlip off # [bool]
and the flickering went away...
On 6/29/05, Roland Scheidegger [EMAIL PROTECTED] wrote:
Hamish Marson wrote:
Fixed it.
Sorry. It isn't an r300 problem... Or at least doesn't LOOK like an
r300 problem. I changed the xorg.conf set
Option EnablePageFlip on # [bool]
to
Option
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 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 least doesn't LOOK like an
r300 problem. I changed the xorg.conf set
38 matches
Mail list logo
