A command buffer interface (either mmap()'d buffers or buffers copied
using standardized ioctls) with a common command set might be a general
approach working on all architectures -- not all card drivers would need
to implement all command opcodes, a capability ioctl can return a bitfield
of su
http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=652
Summary: dri/xc has an empty lib/Xau
Product: DRI
Version: DRI CVS
Platform: All
URL: http://freedesktop.org/cgi-
bin/viewcvs.cgi/dri/xc/xc/lib/Xau/
>
> Doesn't this work with the i830 driver? AFAIK i830 and i845G both use the same
> graphic core (intel extreme graphics). i855G/i852G/i865G use intel extreme
> graphics 2, which afaik is exactly the same, except it's clocked slightly
> higher (266Mhz vs. 200Mhz). At least some people have docs...
Everything else is best done as device-specific with the true API
belonging in user-space.
Comments ?
Just to say that bitblt covers a lot of ground; ie. there's lots of varieties
of blits with quite a few parameters - are you talking about just a simple
copy within a single framebuffer, or can
Playing AA2 on my FC2 box with a radeon 7500 I noticed that the skin
color on people is way to light. Everything else looks normal. Anyone
have suggestions?
--Thanks
X.org-X11-6.7.0
kernel-2.4.5
---
This SF.Net email is sponsored by: Oracle
Holger Waechtler wrote:
Keith Whitwell wrote:
I don't think this needs to be that complex. We only need a few
working functions in the kernel:
* identification (In particular unique identifier to pass via X to
apps
so they can find the head again)
* event reporting (i.e. IRQs and anythi
Keith Whitwell wrote:
I don't think this needs to be that complex. We only need a few
working functions in the kernel:
* identification (In particular unique identifier to pass via X to apps
so they can find the head again)
* event reporting (i.e. IRQs and anything else that is relevant)
On Thu, 20 May 2004, Keith Whitwell wrote:
> Dave Airlie wrote:
> > It has been pointed out to me by Andrew and Fernando Pablo Lopez-Lezcano
> > that we do a lot of sleeping in code that probably should reschedule
> > rather than sleep,radeon_do_wait_for_idle being a prime example, this has
> >
I don't think this needs to be that complex. We only need a few working
functions in the kernel:
* identification (In particular unique identifier to pass via X to apps
so they can find the head again)
* event reporting (i.e. IRQs and anything else that is relevant)
* mode setting
*
1. Add a device independent version. Device independent code could be
written that would test the version number the same way device dependent code
does today. The drawback is that in order to advertise version X.N
functionality, you also have to adverteise version [1.1, 1.N-1]
functionality.
Hey,
It's a good question, my impression was that they are not aiming to the
opensource market and only using it as a starting point.
They had discussion if you release the SDK in free source or not and
although they decided that they would still no one say they still would
next time.
Usually when
Dave Airlie wrote:
Hi,
I've just gotten an i865 system are there any docs out there for
programming the 3d end of this? Intels site for that chipset has no
programmers reference beyond the datasheet which doesn't say muc about 3D
stuff..
Are these docs available non-NDA?
Doesn't this work w
Jon Smirl wrote:
Any ideas about what this is? It is from the Redhat -2 xorg rpm's. All of these
programs ran fine on SW mesa and R128 driver.
[EMAIL PROTECTED] cairogears]$ ./cairogears -glx COMP
cairogears: r200_cmdbuf.c:295: r200EmitBlit: Assertion `(src_offset & 1023) == 0
' failed.
Aborted
>
Am Donnerstag, 20. Mai 2004 06:52 schrieb Dave Airlie:
> It has been pointed out to me by Andrew and Fernando Pablo Lopez-Lezcano
> that we do a lot of sleeping in code that probably should reschedule
> rather than sleep,radeon_do_wait_for_idle being a prime example, this has
> a DRM_UDELAY(1), th
Dave Airlie wrote:
It has been pointed out to me by Andrew and Fernando Pablo Lopez-Lezcano
that we do a lot of sleeping in code that probably should reschedule
rather than sleep,radeon_do_wait_for_idle being a prime example, this has
a DRM_UDELAY(1), this messes up audio latencys,
Now I'm not sur
15 matches
Mail list logo
