-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
Michel Dnzer 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
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 VTs - text and
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
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
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)?
---
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
--- 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 you thing we
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 tex1)
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
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
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
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.
Did
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, thus
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)
--- 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 dualhead modes.
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,
18 matches
Mail list logo
