One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATCH(FUNC, ARGS, MESSAGE) \
(_glapi_Dispatch->FUNC) ARGS
The slides contain some pretty detailed information on composition and text
formatting. You probably need to boot windows to see these...
http://www.eightypercent.net/Archive/2004/05/18.html#a185
Greg Schecter: Avalon Graphics Stack Overview [682 KB]
Joe Beda (me): Avalon Graphics - 2D, 3D, Imag
--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> I'm currently unable to define a clone mode where one screen is
> smaller
> then the other. My thoughts are "1024x768_1024x768" == "1024x768" vs
> "1024x768-1024x768".
You can, but you can't mix and match multi-sized clone modes with
multi-sized dual
Nicolai Haehnle wrote:
I think the simplest solution would look something like this:
Whenever DRM(lock) is called by a privileged client (i.e. the X server), and
it needs to sleep because the lock is held by an unprivileged client, a
watchdog timer is started before we schedule. DRM(unlock) uncon
I'm currently unable to define a clone mode where one screen is smaller
then the other. My thoughts are "1024x768_1024x768" == "1024x768" vs
"1024x768-1024x768".
The problem I have is that my settup is lopsided, one monitor has better
modes than the other. The *larger* monitor is on the right, t
On Sat, 2004-05-22 at 14:04, Nicolai Haehnle wrote:
>
> It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking
> whether the caller actually holds the global lock. There is no
> LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has
> no check in it either.
Hello,
I have just started looking into DRI development and I have been experiencing
some difficulties using gdb. For example, I cannot currently step into
functions of libGL (it was compiled with debug info and LD_LIBRARY_PATH is
set correctly). Another thing is that the symbols from r200_dri.s
André Ventura Lemos wrote:
Not at all...
This only happens with 2.6 kernels. Prior do the lockup, everything
works (I can see it through ssh), but the display gets blank, and never
comes back.
On Fri, 2004-05-21 at 18:07, Keith Whitwell wrote:
Do you mind if I take this to dri-devel?
What happens p
Also, when the VT is switched away from the X server, I believe that the
hardware lock remains grabbed - for minutes or hours at a time.
This is a multi-user OS bug. I'l not even pretend it's a feature that we
should keep.
Just making you aware of the issues.
Keith
--
On Fri, 21 May 2004 15:20:27 -0700
"Mark Cass" <[EMAIL PROTECTED]> wrote:
> guys,
>
> after reading documentation and looking in the code i noticed that the savage chip
> has two texture units. when does the second texture unit do its thing? i placed
> printfs in both sections of code (tex0 and
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
> > Lets just say that this is good fault tolorance. What ever can go
> wrong
> > will, all drivers are faulty. This sounds like a good idea and should
> be
> > implemented for ordinary use or something like it.
> >
> > Unless
Mike Mestnik wrote:
Lets just say that this is good fault tolorance. What ever can go wrong
will, all drivers are faulty. This sounds like a good idea and should be
implemented for ordinary use or something like it.
Unless you thing we should KP on a lock being held for more then a given
time(30
Lets just say that this is good fault tolorance. What ever can go wrong
will, all drivers are faulty. This sounds like a good idea and should be
implemented for ordinary use or something like it.
Unless you thing we should KP on a lock being held for more then a given
time(30 seconds)?
--- Keit
Yes the GART swap, if it needs to be done with memcpys, should be posponed
untill the user has SOME type of interface. Thats the important thing,
allowing the user to interact is above hardware based rendering.
I never liked the way GLapps froze when they where not on the current VT.
I think the
Yes the GART swap, if it needs to be done with memcpys, should be posponed
untill the user has SOME type of interface. Thats the important thing,
allowing the user to interact is above hardware based rendering.
I never liked the way GLapps froze when they where not on the current VT.
I think the
Nicolai Haehnle wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking
whether the caller actually holds the global lock. There is no
LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has
no check in it ei
Can the GART apperture be moved physicaly? I don't think a logical move
would be much help.
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Michel Dänzer wrote:
> > On Sat, 2004-05-22 at 01:45, Mike Mestnik wrote:
> >
> >>--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> >>
> >>>There are two types of
Michel DÃnzer wrote:
On Sat, 2004-05-22 at 01:45, Mike Mestnik wrote:
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
There are two types of VTs - text and graphical. It is only practical to
have a
single graphical VT because of the complexity of state swapping a
graphical VT
at VT swap.
Right now we can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking
whether the caller actually holds the global lock. There is no
LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has
no check in it either.
Did I miss somet
19 matches
Mail list logo
