On Mon, 17 May 2004, Keith Packard wrote:
Around 15 o'clock on May 17, Andy Ritger wrote:
[snip]
The tricky part here is that the damage event shouldn't be sent to
Damage clients until the hardware has completed the damage, but
that is the vendor's problem... I'm just trying to make
On Mon, May 17, 2004 at 11:21:27PM +0200, Felix K?hling wrote:
On Mon, 17 May 2004 16:57:38 +0200
[EMAIL PROTECTED] wrote:
[snip]
I attach a typescript that shows that there is a problem
when sis_dri.so tries to test SSE support
This is the normal SSE test. The signal is caught by
I only find pci_get_subsys, one time in drm/linux/drm_drv.h !
okay I've checked in some fixes (untested) for 2.4 compat now ..
Dave.
best regards,
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
Keith Packard [EMAIL PROTECTED] writes:
As long as the compositing manager holds the server grabbed (which
presumably locks out direct clients as well) while it updates the screen,
there shouldn't be any tearing. No need to drain the event queue or
anything else so dramatic.
What if
On Tue, 18 May 2004, Soeren Sandmann wrote:
Keith Packard [EMAIL PROTECTED] writes:
As long as the compositing manager holds the server grabbed (which
presumably locks out direct clients as well) while it updates the
screen,
there shouldn't be any tearing. No need to drain the event
On Mon, 17 May 2004, Jim Gettys wrote:
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
On Tue, 2004-05-18 at 10:10, Andy Ritger wrote:
OK, thanks for the explanation. I'm not sure how applicable this
is to the synchronization concerns I have, though. My biggest
concern (new damage occuring inbetween when the composite manager
decides what to recomposite, and when it does the
On Tue, 2004-05-18 at 11:53, Soeren Sandmann wrote:
Andy Ritger [EMAIL PROTECTED] writes:
What if another client has already grabbed the server for whatever
reason? Is screen updating then turned off?
If a client has grabbed the server, then requests from all other
clients
Andy Ritger [EMAIL PROTECTED] writes:
What if another client has already grabbed the server for whatever
reason? Is screen updating then turned off?
If a client has grabbed the server, then requests from all other
clients (including the XGrabServer request) are not processed until
that
Around 10 o'clock on May 18, Jim Gettys wrote:
One strategy is to recomposite *everything* on the screen...
That's pretty much what the current compositing manager does; translucent windows
which are damaged cause any related (underlying) windows to be redrawn
transitively.
Because all of
Around 1 o'clock on May 18, Andy Ritger wrote:
I'm debating whether it is better for the X server to not even know
of the damage until it has completed in hardware, or if it is
better to tell the X server as soon as the rendering has kicked off,
and then require X to wait for completion only
Around 14 o'clock on May 18, Soeren Sandmann wrote:
What if another client has already grabbed the server for whatever
reason? Is screen updating then turned off?
Currently, yes. We need to fix this...
-keith
pgpz4qSyLtMVU.pgp
Description: PGP signature
On Maw, 2004-05-18 at 01:07, Vladimir Dergachev wrote:
Alan, perhaps I am missing something, but 4Mb seems a little low.
1280x1024 at 32bpp takes up 5Mb.
Or is it a really old card ?
Its an old card but happens to have public docs so its one I can
talk about without having to work out if
Around 18 o'clock on May 18, Egbert Eich wrote:
It may in fact be necessary to make some 'priviledged' clients like
the composition manager immune to server grabs.
Yup. Then we'll need some kind of 'super grab' to keep multiple ones of
those from stepping on each other. And recurse.
--- Alan Cox [EMAIL PROTECTED] wrote:
On Maw, 2004-05-18 at 01:13, Jon Smirl wrote:
1) Boot console. This is implement via BIOS support. It is used to printk a
processor initialization failure or failure to find initramfs. Some embedded
systems might have to build one of these into the
On Maw, 2004-05-18 at 21:14, Jon Smirl wrote:
I was thinking ptmx/pty, or do you want to use tty? With ptmx/pty you can get
rid of the tty devices.
You need the tty devices for the boot/kernel console and the code
specifc to them is tiny. For the usermode one its clearly ptmx/pty
I wasn't
Around 19 o'clock on May 18, Alan Cox wrote:
VT switch is easy however. DRI+X already handles that, and we never have
two people using the VT at once. Its one device, multiple handles only
one currently active - like many other drivers
No thoughts to supporting multiple sets of VTs, one per
Jim Gettys writes:
Which is why avoiding server grabs is imporant, as much
as possible. It takes a global lock out on the X server and
needs to be used with great care.
But you cannot rule out that some legacy client apps don't use server
grabs for strange purposes.
It may in fact be
On Tue, 18 May 2004, Keith Packard wrote:
Around 1 o'clock on May 18, Andy Ritger wrote:
I'm debating whether it is better for the X server to not even know
of the damage until it has completed in hardware, or if it is
better to tell the X server as soon as the rendering has kicked
Roland Scheidegger wrote:
Ok, here's a patch to enable separate blend function / equation on r200,
as well as fix glBlendColor. It needs drm changes, I've tried to make it
backward/forward compatible in all ways, except the driver will not
build with old drm sources (so this needs to be applied
Mark Cass wrote:
my next question involves extensions. should the GL_ARB_texture_compression and GL_EXT_texture_compression_s3tc extensions be enabled? the only reason i ask is that i think the complete description of the extension includes the ability for the driver to compress the textures. as
DRI is definitely working in this build, glxgears is 152FPS on a Rage128.
But when I do glxinfo it reports the software driver:
OpenGL renderer string: Mesa GLX Indirect
Or did someone fix the software render? I used to get about 3FPS with it.
Maybe something is broken in the DRI into xorg
But when I do glxinfo it reports the software driver:
OpenGL renderer string: Mesa GLX Indirect
aet LIBGL_DEBUG to all and see if it prints anything..
Dave.
Or did someone fix the software render? I used to get about 3FPS with it.
Maybe something is broken in the DRI into xorg server
It looks like something is not built right...
name of display: :0.0
libGL error: dlopen /usr/X11R6/lib/modules/dri/r128_dri.so failed
(/usr/X11R6/lib/modules/dri/r128_dri.s o: undefined symbol: _glapi_Dispatch)
libGL error: unable to find driver: r128_dri.so
=
Jon Smirl
[EMAIL PROTECTED]
24 matches
Mail list logo
