What would be the method for submiting a patch to to move this into
non-OS_specific code?
Here is the current diff from Linux to BSD...
-/**
- * Compute size order. Returns the exponent of the smaller power of two
which
- * is greater or equal to given number.
- *
- * \param size size.
- * \retu
This should fix it in general for all cards and make it into Linux
specific code. I gave it a minimal test and it works for me.
If it's working right cat /proc/iomem /proc/ioports will show the
driver as owning the resources. pci_request_regions() will fail if
called in stealth mode so it needs
>
> request/release regions is what Linux drivers are supposed to do to
> mark that they have a resource in use. There's a pci_request_region()
> available that hides whether it is IO or memory so I should switch to
> that one. All drivers should implement these functions. You can't do
> this as pa
José Fonseca wrote:
Hi,
Doxygen documentation of DRM and Mesa is generated every night from CVS
into http://freedesktop.org/~dri/doxygen/ .
Enjoy,
Thanks, José. I added new sections for the glapi and shader modules
and tweaked a few other things. Hopefully I didn't break anything.
-Brian
-
Neither of these have anything to do with the addmap/initmap change.
request/release regions is what Linux drivers are supposed to do to
mark that they have a resource in use. There's a pci_request_region()
available that hides whether it is IO or memory so I should switch to
that one. All drivers
> I'm not sure why this stuff is directly called from radeon_cp.c (and only this
> driver) and not from within the common code path. Isn't this also done via
becase the DRM is undergoing experimental surgery at the moment, and the
radeon is the crash test dummy ... I think two drivers need to be
On 09.09.2004, at 19:37, Jon Smirl wrote:
This is what I'm talking about with hotplug support and BSD not
supporting hotplug. On Linux there are rules for dealing with all of
the resources so that you don't get conflicts with new devices when
they are plugged in. It's the region code that is causin
Hi,
Doxygen documentation of DRM and Mesa is generated every night from CVS
into http://freedesktop.org/~dri/doxygen/ .
Enjoy,
José Fonseca
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Ap
On Thu, Sep 09, 2004 at 05:03:27PM +0200, Philipp Klaus Krause wrote:
> Brian Paul schrieb:
> >Pasi Kärkkäinen wrote:
> >
> >>Hi all!
> >>
> >>>From the www.opengl.org:
> >>
> >>
> >>OpenGL 2.0 specification available for download
> >>
> >>http://www.opengl.org/documentation/opengl_current_version.
This is what I'm talking about with hotplug support and BSD not
supporting hotplug. On Linux there are rules for dealing with all of
the resources so that you don't get conflicts with new devices when
they are plugged in. It's the region code that is causing problems
right? If so, register/release
Philipp Klaus Krause wrote:
Brian Paul schrieb:
Pasi Kärkkäinen wrote:
Hi all!
From the www.opengl.org:
OpenGL 2.0 specification available for download
http://www.opengl.org/documentation/opengl_current_version.html
http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf
Any plans for 2.
Hey,
as I'm slowly ploughing through the last changes to get BSD support
working again... the radeon-pre-2 patch added linux-only code to
radeon_cp.h, somehow to establish permanent mappings for framebuffer
and mmio, as it seems.
this is not good. is there an OS independent way to do this? mayb
Brian Paul schrieb:
Pasi Kärkkäinen wrote:
Hi all!
From the www.opengl.org:
OpenGL 2.0 specification available for download
http://www.opengl.org/documentation/opengl_current_version.html
http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf
Any plans for 2.0 support in Mesa? I think t
On 09.09.2004, at 15:02, Alan Cox wrote:
So, what happens in x86-64 where sizeof(unsigned long) is 4 bytes for
IA-32 apps and 8 bytes for x86-64 apps? I guess since it's a
parameter
to the ioctl (rather than embedded in a structure) it should be okay,
but I just want to be sure...
Be cautious her
Pasi Kärkkäinen wrote:
Hi all!
From the www.opengl.org:
OpenGL 2.0 specification available for download
http://www.opengl.org/documentation/opengl_current_version.html
http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf
Any plans for 2.0 support in Mesa? I think the biggest "todo" is
On Iau, 2004-09-09 at 00:45, Ian Romanick wrote:
> So, what happens in x86-64 where sizeof(unsigned long) is 4 bytes for
> IA-32 apps and 8 bytes for x86-64 apps? I guess since it's a parameter
> to the ioctl (rather than embedded in a structure) it should be okay,
> but I just want to be sure.
Hi all,
I'm using a 3D prophet Radeon 8500LE and the lastest DRI drivers from
CVS + S3TC patch .
I've noticed that I can't play to ArmyOps , because after few time
I've started the game the game image simply freeze . I can hear the
sound of the game, but I can't do anything. CTRL + ALT + BACKSPAC
Hi all!
>From the www.opengl.org:
OpenGL 2.0 specification available for download
http://www.opengl.org/documentation/opengl_current_version.html
http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf
Any plans for 2.0 support in Mesa? I think the biggest "todo" is the
sw-emulation o
18 matches
Mail list logo
