On Thu, May 06, 2004 at 05:50:40PM -0700, Jon Smirl wrote:
--- James Simmons [EMAIL PROTECTED] wrote:
2) Ben suggestion that we mount userland inside the kernel during early
boot and use a userland library. If we would use a library then it MUST
be OpenGL. This would be the forced
Ville Syrjälä wrote:
On Fri, May 14, 2004 at 11:40:04AM -0700, Jon Smirl wrote:
--- Ville Syrjälä [EMAIL PROTECTED] wrote:
I said OpenGL is the only accelerated API available on Linux. Can you name
another?
DirectFB.
Does DirectFB work on anything beside Matrox now?
It works on any card with a
On Fri, May 14, 2004 at 10:51:35AM -0700, Jon Smirl wrote:
Just look at this picture and you can see the trend of 2D vs 3D (coprocessor
based) graphics.
http://www.de.tomshardware.com/graphic/20040504/images/architecture.gif
Within one or two generations the 2D box is going to be gone.
Sorry,
On Mon, May 17, 2004 at 10:38:50AM +0200, [EMAIL PROTECTED] wrote:
Hello,
Here's my BUG report following in REPORTING-BUGS form
I found davej and dri mailing list as most apropriate recipients from MAINTENERS
file.
May 17 07:29:18 localhost kernel: Linux agpgart interface v0.100
On Mon, May 17, 2004 at 01:00:19PM +0200, [EMAIL PROTECTED] wrote:
Andi cleaned up the Intel GART driver detection code somewhat in the AGP patches
in -mm, but it broke somewhat. Unless we figure out why in the next day or two
then I'll back out his patch. Dropping the bk-agpgart patch
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=1368
[EMAIL PROTECTED] changed:
What|Removed |Added
On Mon, 17 May 2004, Dave Jones wrote:
On Mon, May 17, 2004 at 10:38:50AM +0200, [EMAIL PROTECTED] wrote:
Hello,
Here's my BUG report following in REPORTING-BUGS form
I found davej and dri mailing list as most apropriate recipients from MAINTENERS
file.
May 17 07:29:18
Hi,
I'm playing around with my G400 using mmio access. Can someone tell me
what I'm doing wrong? Writing to the registers doesn't produce a seg
fault (so it seems that it would be mapped correctly), but reading back
from them afterwards gives me either strange values or zero.
(Ignore the
--- Andy Ritger [EMAIL PROTECTED] wrote:
[snip]
- A Video Overlay Xv Adaptor is obviously fundamentally incompatible
with Damage/Composite. Should X drivers no longer advertise
Video Overlay Xv adaptors if they are running in an X server that
includes Composite support?
Many
On Mon, 17 May 2004, Alex Deucher wrote:
--- Andy Ritger [EMAIL PROTECTED] wrote:
[snip]
- A Video Overlay Xv Adaptor is obviously fundamentally incompatible
with Damage/Composite. Should X drivers no longer advertise
Video Overlay Xv adaptors if they are running in an X
I've given some thought to how best to integrate direct rendering
clients with Damage/Composite. For the below discussion, I'll focus
on GLX as the direct rendering client but the same concepts should
apply to XvMC or any other direct rendering client.
For anyone not already familiar with the
Around 11 o'clock on May 17, Andy Ritger wrote:
How should a direct rendering client interact with Damage/Composite?
There seem to be two pieces to this: damage notification, and
synchronization.
Thanks for getting this topic started.
When a direct rendering client damages the X screen, it
On Mon, 2004-05-17 at 11:41, Andy Ritger wrote:
I've given some thought to how best to integrate direct rendering
clients with Damage/Composite. For the below discussion, I'll focus
on GLX as the direct rendering client but the same concepts should
apply to XvMC or any other direct rendering
--- Andy Ritger [EMAIL PROTECTED] wrote:
On Mon, 17 May 2004, Alex Deucher wrote:
--- Andy Ritger [EMAIL PROTECTED] wrote:
[snip]
- A Video Overlay Xv Adaptor is obviously fundamentally
incompatible
with Damage/Composite. Should X drivers no longer advertise
On Mon, 2004-05-17 at 11:02, Alex Deucher wrote:
--- Keith Packard [EMAIL PROTECTED] wrote:
Around 9 o'clock on May 17, Alex Deucher wrote:
Many video overlays support alpha blending with the graphics layer,
it's just that support was never implemented since xfree86 never
As I've said, I don't have a deep grasp of the requirements of a putative
future mode-setting API, but in the course of other reading I came across
MLdc, which is a part of the OpenML environment. This is a library API which
seems to give comprehensive control of mode-setting to an
Around 15 o'clock on May 17, Andy Ritger wrote:
Even for front buffered flushes I would be inclined to just say that it
damages the whole drawable, rather than try to compute a smaller bounding
region.
That's certainly fine for now; if people really get excited about
optimizing this case,
--- Eric Anholt [EMAIL PROTECTED] wrote:
On Mon, 2004-05-17 at 11:02, Alex Deucher wrote:
--- Keith Packard [EMAIL PROTECTED] wrote:
Around 9 o'clock on May 17, Alex Deucher wrote:
Many video overlays support alpha blending with the graphics
layer,
it's just that support
I'm looking at the OpenML spec and it covers the areas that we have been
discussing plus a lot more. But the Khronos Group doesn't appear to be very Open
Source friendly. It seems that I have to apply for membership and return signed
documents to get a Linux SDK. But some of their other projects
Jon Smirl wrote:
I'm looking at the OpenML spec and it covers the areas that we have been
discussing plus a lot more. But the Khronos Group doesn't appear to be very Open
Source friendly. It seems that I have to apply for membership and return signed
documents to get a Linux SDK. But some of
Jon Smirl wrote:
I'm looking at the OpenML spec and it covers the areas that we have been
discussing plus a lot more. But the Khronos Group doesn't appear to be very Open
Source friendly. It seems that I have to apply for membership and return signed
documents to get a Linux SDK. But some of
On Llu, 2004-05-17 at 18:49, Keith Packard wrote:
Composite doesn't really expose things in a way that would make this
hardware capability usable.
Instead, it expects the video to be painted into the window pixmap so that
those pixels can be composed to form the screen image.
For Xv that
Around 18 o'clock on May 17, Alan Cox wrote:
For Xv that seems to involve working server side GL and using GL to
take Xv data (as a texture) and putting it to the video visible buffer.
I've been looking at exactly this for Voodoo2 although I'm still trying
to get the 3D init code right (its
On Mon, 17 May 2004 16:57:38 +0200
[EMAIL PROTECTED] wrote:
hi
I have a notebook with a Athlon and 'SiS 650' video
When I was using Debian/stable, I installed the packages for Debian
by [EMAIL PROTECTED] (alongside XFree 4.1 ) they worked fine:
I had excellent 3D acceleration, could
On Iau, 2004-05-13 at 01:58, Jon Smirl wrote:
--- Alan Cox [EMAIL PROTECTED] wrote:
argument for _good_ console support becomes that after boot you run a
graphical user space console app built with OpenGL, antialiased true
When I proposed this a couple of months back both you and Linus
On Gwe, 2004-05-14 at 19:40, Jon Smirl wrote:
Does DirectFB work on anything beside Matrox now?
Most cards, accelerated on quite a few including VIA. This is getting
into detail. If your 3D sucks you dont us OpenGL as the basis of your
whizzo console driver - just as MS plan to support the older
--- Keith Packard [EMAIL PROTECTED] wrote:
Around 18 o'clock on May 17, Alan Cox wrote:
For Xv that seems to involve working server side GL and using GL to
take Xv data (as a texture) and putting it to the video visible
buffer.
I've been looking at exactly this for Voodoo2 although
On Mon, 17 May 2004, Keith Packard wrote:
Around 11 o'clock on May 17, Andy Ritger wrote:
How should a direct rendering client interact with Damage/Composite?
There seem to be two pieces to this: damage notification, and
synchronization.
Thanks for getting this topic started.
On Mon, 17 May 2004, Jim Gettys wrote:
On Mon, 2004-05-17 at 11:41, Andy Ritger wrote:
I've given some thought to how best to integrate direct rendering
clients with Damage/Composite. For the below discussion, I'll focus
on GLX as the direct rendering client but the same concepts should
On Sat, 2004-05-15 at 14:23, Felix Kühling wrote:
Hi,
I'm using a few spare hours to get started working on the Savage DRM
driver. I'm going to have to rewrite it from scratch. The current sarea
definition is essentially copied from the MGA driver and the only 3
driver-specific ioctls are
Take a not atypial card - the sis6326
Frame buffer within the low 4Mb
Z buffer within the low 4Mb or AGP or main memory
Xv buffers in the low 4Mb
Textures in main memory, agp or any of 8Mb but all parts must be in the
same type of RAM
Alan, perhaps I am missing something, but 4Mb seems a little
--- Alan Cox [EMAIL PROTECTED] wrote:
On Iau, 2004-05-13 at 01:58, Jon Smirl wrote:
--- Alan Cox [EMAIL PROTECTED] wrote:
argument for _good_ console support becomes that after boot you run a
graphical user space console app built with OpenGL, antialiased true
When I proposed this a
On Mon, 2004-05-17 at 16:03, Andy Ritger wrote:
2) some damage occurs, composite manager sends composite request,
additional rendering is performed, part of which the composite
operation picks up, but the rest of the rendering is not
composited until the next
33 matches
Mail list logo
