Hi!
Is it possible to use the heavyweight drm locking mechanisms for other
locks than the global hardware lock?
What I'm after is a mechanism to suspend drm-aware processes until a
display resource gets available and then wake them up on a FIFO basis when
the process that currently holds the
official drm code
with some minor mods) and put together a patch against current dri cvs
( programs/Xserver/hw/xfree86/os-support/linux/drm/kernel )
post it, and hopefully get some feedback on how to proceed.
Best regards
Thomas Hellström
Thomas Hellstrom wrote:
Hi!
Here comes the via drm module patch against current (at least as of
today :-) CVS
(/usr/local/src/dri-cvs/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm)
What we've done is the following:
1. Base. Via:s drm Module 0038.
2. Added vblank_wait IOCTL
the new cvs drm module and the via patch I sent
previously applies cleanly with
patch -p1
in drm/linux.
Also compiles cleanly under both 2.4 and 2.6
Regards,
Thomas Hellström
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux
Are there any objections to checking it in? I'll tag CVS before the check
in to
make it easy to undo.
=
Jon Smirl
[EMAIL PROTECTED]
Hmm, I might have missed something important, but I checked out latest drm
cvs and applied your patch, and I get the following error when I try
make -f
Hi!
Following the previous mailing list discussion I've replaced the via
3d client subdir in the xc tree with a corresponding unichrome one,
which makes it possible to compile the unichrome 3d client driver in the
xc tree.
In order to make it compile, a small patch is needed to the Mesa
Hi!
I'm trying to compile the unichrome_dri.so driver in the xc tree with
latest Mesa cvs. When the driver is loaded I get a missing symbol
_tnl_init_c_codegen.
Something new I've left out?
Best regards
Thomas
---
This SF.Net email sponsored
Hi!
On Mer, 2004-08-11 at 02:20, Dave Airlie wrote:
the VIA/mach64/savage DRM when setup by the current DDXs all allow evil
things from my current understanding, that is why they're DDXs haven't
got
the DRI support turned on by default in Xorg, so those DRMs are not to
be
built into a
Hi, Erdi.
This patch adds two new ioctl's to the VIA Unichrome/Pro DRM driver:
DRM_IOCTL_VIA_DMA_INIT
DRM_IOCTL_VIA_CMDBUFFER
The first call sets up an area in AGP memory that will be used as the
ring buffer. The second call copies a command buffer from user space
memory to
Hi!
Erdi Chen wrote:
Thomas Hellström wrote:
I just noticed that you are using a 2d BITBLT to temporarily stall the
command regulator for a moment.
I believe the XAA implementation in all current via 2d X server drivers
out there assume that they are reasonably alone in using the 2d
engine
Hi, list!
As some of you might have read on another thread, there is a discussion
how to handle the X server (and possibly other) 2d contexts in the via /
unichrome family of drivers that expects certain 2d engine register
values to stay the same even when other contexts or DMA commands have
Erdi Chen wrote:
Thomas Hellström wrote:
I just noticed that you are using a 2d BITBLT to temporarily stall the
command regulator for a moment.
I believe the XAA implementation in all current via 2d X server drivers
out there assume that they are reasonably alone in using the 2d
engine
Hi!
Mike Mestnik wrote:
--- Eric Anholt [EMAIL PROTECTED] wrote:
On Mon, 2004-08-23 at 15:24, Ian Romanick wrote:
Thomas Hellstrm wrote:
As some of you might have read on another thread, there is a
discussion
On Mon, 2004-08-23 at 22:58, Thomas Hellström wrote:
Hi!
Mike Mestnik wrote:
--- Eric Anholt [EMAIL PROTECTED] wrote:
On Mon, 2004-08-23 at 15:24, Ian Romanick wrote:
Thomas Hellström wrote:
As some of you might have read on another thread
Hi, Erdi.
Thomas Hellström wrote:
I just noticed that you are using a 2d BITBLT to temporarily stall the
command regulator for a moment.
I believe the XAA implementation in all current via 2d X server drivers
out there assume that they are reasonably alone in using the 2d engine
Also had a guy at the unichrome lists that reported a kernel panic within
the via modules on a 2.4.20 kernel. I have checked on 2.6.3, and it seems
OK. Have you checked 2.4?
I just checked with 2.4.27 and it all seems OK. I will update the
Unichrome project's
DDX to initialize the ring buffer
Hi!
Yes.. Works nice. :-).
I'm able to program the blitter from the user space XvMC lib, but as
expected not the video engine nor the mpeg player.
I've requested info from VIA about this. Let's see what happens.
What approx size of the ringbuffer would the 3d lib need?
/Thomas
Erdi Chen wrote:
Thomas Hellström wrote:
Hi!
Yes.. Works nice. :-).
I'm able to program the blitter from the user space XvMC lib, but as
expected not the video engine nor the mpeg player.
I've requested info from VIA about this. Let's see what happens.
What approx size of the ringbuffer would
Thomas Hellström wrote:
Also, The irq enable IOCTL returns an error with your patch applied. Not
before. The via specific IRQ setup routines are never called. Could you
have a look into this?
/Thomas
You need to call drmVIAInitMAP/DRM_IOCTL_VIA_MAP_INIT to setup
dev-dev_priv before you
Erdi Chen wrote:
Thomas Hellström wrote:
Thomas Hellström wrote:
Also, The irq enable IOCTL returns an error with your patch
applied. Not
before. The via specific IRQ setup routines are never called. Could
you
have a look into this?
/Thomas
You need to call drmVIAInitMAP/DRM_IOCTL_VIA_MAP_INIT
Hi.
Jon Smirl wrote:
I can't reproduce this, but I think I found the bug from inspection. In
the vesafb detection code a pointer wasn't set to NULL correctly. I
checked a fix into CVS. Let me know if that didn't fix it.
Yes, it fixed that particular problem, but after rmmoding and
On Sun, 29 Aug 2004 09:51:41 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
OK, this means you will have to enable debug info and recompile as
shown in the last post.
Im not sure to which post you refer?
These mailing lists...
Please enable
#define DEBUG_PRINT
#define XV_DEBUG
Hi!
In order to be able for dri clients to write to certain registers when
direct write-access to the MMIO area of the unichrome is shut down, I've
added an IOCTL to Erdi's dma interface.
It has a very simple parser that denies access to register areas that
might be dangerous. The 2d blitter can
Hi!
Just verified that latest CVS works.
Thanks.
/Thomas
I finally found this problem and fixed it in CVS. When using
pci_get_subsys() with the last parameter NULL, you have to do
pci_dev_put() manually. When I changed the loop to detect multiple
indentical cards I started using the last
Hi!
I think I found this one. Could you try latest CVS?
/Thomas
Julius wrote:
On Thu, 2 Sep 2004 10:45:03 +0200 (CEST)
Thomas Hellstrm [EMAIL PROTECTED] wrote:
Hi.
Still clueless, but I will try to fire up my KM400 this week and try to
reproduce your settings; in particlar
Hi, Julius.
According to the logs, it seems to run fine. Could you perhaps try
another video stream?
Still any other videoplayer working? Xine etc.
Julius wrote:
On Wed, 8 Sep 2004 16:09:53 +0200 (CEST)
Thomas Hellstrm [EMAIL PROTECTED] wrote:
Hi, Julius.
It does not seem
Hi!
current CVS doesn't compile for me, see below.
In addition, one user who checked out the code one to a couple of days
ago reports that
the X server cannot open the dri device anymore, although the drm module
loads fine into the kernel.
Cannot check, though :-(.
sh
Hi!
Sorry for the double posting. This is a thing that needs to be discussed
in both communities.
The via DRM has started it's journey into the linus kernel, but the 3D
driver / DDX still suffers
from a security flaw:
When the MMIO area is exported read-write it is assumed possible for a
dri
Hi, Keith!
Thomas Hellström wrote:
Hi!
Sorry for the double posting. This is a thing that needs to be discussed
in both communities.
The via DRM has started it's journey into the linus kernel, but the 3D
driver / DDX still suffers
from a security flaw:
When the MMIO area is exported
Hi, Dave.
Dave Airlie wrote:
AllowInsecureDRI is less secure than forcing users to run things as root
or fix the code. And we want that code in kernel and causing pain in
order to make people fix it 8)
I'm really with Keiths don't let them do anything until someone fixes
Hi, Ian!
Ian Romanick wrote:
Thomas Hellström wrote:
Also, the people on the unichrome site including me are totally lost
when it comes to 3D, and you'll need
a quite detailed documentation to fix things up. I guess the 3D
command verification will be
quite some work. The best would
Hi!
is DRM_WRITEMEMORYBARRIER() the right way to make sure data has been
flushed to AGP memory before firing it off to the DMA engine? If so, are
there performance implications?
/Thomas
---
This SF.net email is sponsored by: IT Product
Hi, Erdi!
I have been testing the ring-buffer quite extensively since there is an
option in the unichrome X driver to use it for 2D acceleration and for
XvMC mpeg. I and other people have had some problems with short hangs
and above all total screen confusion (sometimes recoverable) every once
Hi!
How is VT switching normally handled when a DRI client is active?
Meaning, for example, switching from the X display to a virtual text console?
Looking in the i810 driver, it seems like the ringbuffer is flushed and
disabled until the X server calls EnterVT again, and AGP memory is
unbound.
Thomas Hellström wrote:
Hi!
How is VT switching normally handled when a DRI client is active?
Meaning, for example, switching from the X display to a virtual text
console?
Looking in the i810 driver, it seems like the ringbuffer is flushed and
disabled until the X server calls EnterVT
Hi!
Attached is a patch, that based on the info I have should make the via DRM
ok to go into the mainstream kernel, (save 64-bit problems in the memory
manager?)
It implements a simple command verifier for agp and pci writes to the
MMIO area.
Currently no 3D commands are implemented, but since
Hi!
Jon Smirl wrote:
On Thu, 07 Oct 2004 08:56:30 +0200, Thomas Hellstrom
[EMAIL PROTECTED] wrote:
Hi!
Ok, now the rmmod oops is gone, and I'm back at the previous state...
Oops the fourth time the via module is loaded. No X server activity:
Give this patch a try and
Hi!
I've commited the rudimentary command verifyer in the via drm now, and
also altered the
Unichrome DDX to export MMIO read-only. Hopefully we'll update Xorg with
the Unichrome
driver soon as well.
So from my point of view it should be safe for the via drm to go into
the kernel.
The Mesa
Hi!
Just tried out the core-based drm today, and I notice that
drmOpen(via) does not work anymore.
What is the correct way to fix up this? I suspect my client should be using
drmOpenByBusID ?
Regards
Thomas
---
This SF.net email is sponsored
Hi, Dave.
Hi,
Okay the VIA DRM people have asked to include it in the kernel, it
only allows accelerated XvMC for non-root users, and 3d for root users
(the 3d paths are still not secure)...
The bk tree at
bk://drm.bkbits.net/drm-via
the patch against Linus latest (along with
Hi.
Jon Smirl wrote:
On Sat, 9 Oct 2004 10:59:35 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
On Sat, 9 Oct 2004, [ISO-8859-1] Thomas Hellstrm wrote:
Just tried out the core-based drm today, and I notice that
drmOpen("via") does not work anymore.
What
Hi!
Tried to compile recent CVS under a 2.4 series kernel yesterday and got
In file included from drm_core.h:33,
from via_drv.c:31:
drm_drv.h: In function `drm_init':
drm_drv.h:568: warning: implicit declaration of function `pci_dev_get'
drm_vm.h: At top level:
drm_stub.h:37:
Anyone?
This was introduced after 1st of October.
/Thomas
Hi!
Tried to compile recent CVS under a 2.4 series kernel yesterday and got
In file included from drm_core.h:33,
from via_drv.c:31:
drm_drv.h: In function `drm_init':
drm_drv.h:568: warning: implicit declaration
Anyone?
This was introduced after 1st of October.
/Thomas
Forgot to mention, of course, that this leeds to an unresolved symbol in
the binary:
pci_dev_get.
Hi!
Tried to compile recent CVS under a 2.4 series kernel yesterday and got
In file included from drm_core.h:33,
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've find the need for more
than one hardware lock. I've done a simple implementation for the mpeg
decoder of the via
Jon Smirl wrote:
On Sun, 31 Oct 2004 16:52:35 +0100, Thomas Hellstrm
[EMAIL PROTECTED] wrote:
1. A separate sarea to contain these locks, to avoid messing up the
current sarea with binary incompatibilities as a consequence.
It would probably be better to extend the
Jon Smirl wrote:
On Sun, 31 Oct 2004 18:41:42 +0100, Thomas Hellstrm
[EMAIL PROTECTED] wrote:
The idea of using a separate sarea is that it would be easy to extend the
number of locks and more suitable for more drivers than via. Otherwise one
idea would be to
fill the private
Keith Whitwell wrote:
Thomas Hellström wrote:
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've find the need for more
than one hardware lock.
The first question
Mike Mestnik wrote:
--- Thomas Hellstrm [EMAIL PROTECTED] wrote:
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've find the need for more
than
Jon Smirl wrote:
On Sun, 31 Oct 2004 19:41:03 +0100, Thomas Hellstrm
[EMAIL PROTECTED] wrote:
/* For now the mapping works by using a fixed size defined
* in the SAREA header
*/
if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) SAREA_MAX) {
Jon Smirl wrote:
On Sun, 31 Oct 2004 22:54:25 +0100, Thomas Hellstrm
[EMAIL PROTECTED] wrote:
Wouldn't this severely break backwards binary compatibility with dri clients
compiled with the old size of drm_sarea_t?
You can't put them in drm_sarea_t. There is definitely
--- Thomas Hellström [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
The typical case here:
I want a DRI client to flip a video frame to screen, using a hardware
entity called the HQV. This is a rather time critical operation. To do
this I have to take the hardware lock.
While
On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote:
Keith Whitwell wrote:
Thomas Hellström wrote:
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've
Hi,
Currently files in linux[-2.6] and linux-core directories have different
formating (and shared* dirs too of course). This is only causing
unnecessary pain to people trying to change something. Everything has to
be done twice, as even simple patch may not apply against those dirs,
due to
Nicolai Haehnle wrote:
On Monday 01 November 2004 07:01, Thomas Hellstrm wrote:
You are probably right, and it would be quite easy to implement such
checks in the via command verifier as long as each lock is associated with
a certain hardware address range.
However, I don't quite
Hi!
I've come across a problem with drm-core.
When a drm device is opened by the X server, it opens the first drm
device that does not have a busid assigned to it, since that means it is
busy. It then assigns a busid to that device.
Now, if the server is exited and restarted, the server cannot
--- Thomas Hellström [EMAIL PROTECTED] wrote:
You are probably right, and it would be quite easy to implement such
checks in the via command verifier as long as each lock is associated
with
a certain hardware address range.
However, I don't quite see the point in plugging such a security
As of via version 2.0.4, the VIA drm now seems fully operational even with
2D and mpeg DMA, where it previously sometimes either hang or reran the
ring-buffer command stream on rewind.
Also the lock-held-by-caller security bug is fixed.
/Thomas
Hi, Tony!
Le mer 03/11/2004 à 14:43, Thomas Hellström a écrit :
As of via version 2.0.4, the VIA drm now seems fully operational even
with
2D and mpeg DMA, where it previously sometimes either hang or reran the
ring-buffer command stream on rewind.
Also the lock-held-by-caller security bug
Hi!
Could somebody with CVS access to the Mesa tree bump the drm version
number that the unichrome_dri driver expects from 1.1.x to 2.0.x?
We had to bump the via drm major version a couple of weeks ago due to a
fix on a bad IOCTL interface.
Also I think the unichrome_dri driver needs to update
Keith Whitwell wrote:
Thomas Hellström wrote:
Hi!
Could somebody with CVS access to the Mesa tree bump the drm version
number that the unichrome_dri driver expects from 1.1.x to 2.0.x?
We had to bump the via drm major version a couple of weeks ago due to a
fix on a bad IOCTL interface.
Also I
Hi!
Jon Smirl wrote:
I think this is happening for Thomas because he is running an older X
server that isn't negotiating to the most current DRM interface. I
believe the attached patch will fix the problem but we all need to
test it to make sure it doesn't have unintended side effects. I don' t
Hi!
Following up on Felix's mail on this issue:
Is it a correct understanding that for a 32-bit userspace app to work with
an AMD64 64bit drm, the following needs to be fulfilled:
* IOCTL args must have the same size and layout in 64- and 32 bit models,
in particular pointers to user space
Egbert Eich wrote a patch to handle this that's pending review:
https://bugs.freedesktop.org/show_bug.cgi?id=943
To work on this stuff my advice is to have a 32-bit machine and a 64-bit
machine and have XFree86 4.3 and latest Xorg and make sure all the
backwards combinations works or at
Hi!
I made an attempt to make the unichrome dri mesa driver use the AGP
ring-buffer in recent via drm. (2.1.0)
I've filed the result on Mesa bugzilla
https://bugs.freedesktop.org/show_bug.cgi?id=1950.
Still, the command buffer verifyer in drm won't let any 3d commands
through, so if you want to
* THE UNICHROME PROJECT, AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
* OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*
* Author: Thomas Hellström 2004
On Maw, 2004-11-30 at 20:09, Thomas Hellström wrote:
Textures in AGP memory is currently not allowed, but they are disabled
in the Mesa driver as well, for some reason. If they are allowed in the
future, Texture address checks probably have to be implemented but that
should be a minor task
Hi.
On Maw, 2004-11-30 at 20:09, Thomas Hellström wrote:
Textures in AGP memory is currently not allowed, but they are disabled
in the Mesa driver as well, for some reason. If they are allowed in the
future, Texture address checks probably have to be implemented but that
should be a minor
Hi!
The Mesa update of November the 27th breaks the Unichrome driver.
The screen hangs while playing Tuxracer or Chromium while for example
glxgears and glplanet screensaver still work.
The computer is still, alive though, so it might be a HW lock that is
taken and
never released?
An earlier
Hi.
Brian Paul wrote:
Thomas
Hellstrm wrote:
Thomas Hellstrm wrote:
Hi!
The Mesa update of November the 27th breaks the Unichrome driver.
The screen hangs while playing Tuxracer or Chromium while for example
glxgears and glplanet screensaver
Hi!
Is it possible to commit rights for the Mesa tree, or have someone commit
the work done in bug 1950 to port the unichrome driver to the new security
policy implemented in the Via DRM?
I won't be doing much 3D development, but will focus on the 3D driver /
DRM interface; fixing bugs and
Hi!
I just verified that I still have the problem with spontaneously dying X
server or application (mostly mozilla) with latest CVS linux-core and
the via driver.
(Invalid argument from select)
I've just upgraded my kernel so there is no chance of an old drm module
lying around somewhere.
Am
On Sun, 30 Jan 2005, [ISO-8859-1] Thomas Hellström wrote:
Hi!
I just verified that I still have the problem with spontaneously dying X
server or application (mostly mozilla) with latest CVS linux-core and
the
via driver.
(Invalid argument from select)
I've just upgraded my kernel so
Michel Dnzer wrote:
On Mon, 2005-01-31 at 13:22 +0100, Thomas Hellstrm wrote:
The thing is that I don't see this with the old drm (Running for a
reasonable amount of time), but on the other hand I can't see what in drm
CVS could be causing this.
Could be
Hi!
Good point. That's my change in non-core which hasn't been propogated
to
core. It's just a cleanup I wouldn't have expected either version to
be
crash-prone.
I don't think the irq handler gets much of a workout unless you
sync-to-vblank
at the moment.
it may not be that.. but I
Hi!
Benno Schulenberg wrote:
Felix Khling wrote:
Should I
rephrase the message to clearly state that this is *not an error*
or just not print anything if the file can't be read?
Preferably rephrase, something like "(this is just a note)", as it
is good to know that it
Dave Jones wrote:
We got a bug report in our bugzilla from a user that saw
SiS DRM crashing when he restarted X.
The crash seems to be two things.
First, a page allocation failure.
Mar 11 17:52:29 localhost kernel: X: page allocation failure. order:4, mode:0xd0
Mar 11 17:52:29 localhost kernel:
http://sourceforge.net/tracker/index.php?func=detailaid=1172117group_id=102048atid=630969
/Thomas
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products
Adam Jackson wrote:
On Monday 28 March 2005 16:21, Thomas Hellstrom wrote:
CVSROOT: /cvs/dri
Module name: drm
Repository: drm/shared-core/
Changes by: [EMAIL PROTECTED] 05/03/28 13:21:42
Log message:
Via updates:
* New PCI command parser. Moved from via_dma.c to
Hi!
Benno Schulenberg wrote:
Hi list,
Using CVS of today (and of the past few weeks I can't get the via
module to work, it doesn't do anything, and it oopses either when
loaded or removed.
After booting, with agpgart as a module:
# modprobe -v via
insmod
Benno Schulenberg wrote:
Thomas Hellstrm wrote:
Benno Schulenberg wrote:
Using CVS of today (and of the past few weeks I can't get the
via module to work, it doesn't do anything, and it oopses
either when loaded or removed.
Working fine here with
to the correct drm.ko
and the
/lib/modules/xxx/kernel/drivers/char/drm lib was never created during
kernel install.
Something else I might be missing?
/Thomas
On Wed, 30 Mar 2005, Thomas Hellström wrote:
Thomas Hellström wrote:
Benno Schulenberg wrote:
Hi Thomas,
You wrote:
OK
Thomas Hellstrm wrote:
Benno Schulenberg wrote:
Hi Thomas,
You wrote:
OK, could you mail me your kernel config,
Attached.
and also make sure the
via_agp (via-agp?) module gets loaded properly.
Ehm, I disabled that in
Hi!
If one were to consider borrowing a Unichrome texture unit for Xv, is
there some sort of locking mechanism or is the texture source address
and stride accompanied with each command buffer it is used?
Regards
Thomas
---
This SF.net email
Hi all!
Trying to make unichrome XvMC using the dri extension as opposed to now
only the xf86drm API, I've ended up using
1) xf86drm.h and corresponding c files that now make up or will make up
libdrm.so
2) xf86dri.h and XF86dri.c that are part of mesa.
3) Some of the dri utils from mesa,
Hi!
The macro DRM_WAIT_ON changed behaviour.
In earlier DRMs it checked every HZ for condition in case it was
slightly missed.
This doesn't happen anymore, which means some applications freezes for
about 3 secs, when they
just missed an interrupt.
This in itself is a little bit strange since,
Alan Cox wrote:
This in itself is a little bit strange since, if the following occurs:
* Check condition
* if false, go to sleep
and DRM_WAKEUP is called by the interrupt handler in between those two,
the sleep should never occur, which now it seems to do anyway.
Is the
Hi!
I have an application that takes the hardware DRI lock and then does an
usleep(1) while polling hardware status. Entering the polling function,
I've verified that the lock is indeed taken
0x8002, with 2 corresponding to the correct DRM context. Upon exit
from the polling function,
Thomas Hellström wrote:
Hi!
I'm not sure what causes this, but IMHO it's quite serious.
OK, Easy to reproduce also with Mesa DRI.
I did the following alteration to via_context.h, so that it sleeps just
before and just after it takes the
hardware lock: The sleep before is necessary so that other
Hi!
Dave Airlie wrote:
I have an application that takes the hardware DRI lock and then does an
usleep(1) while polling hardware status. Entering the polling function, I've
verified that the lock is indeed taken
0x8002, with 2 corresponding to the correct DRM context. Upon exit
Thomas Hellstrm wrote:
I don't think this is the cause of the problem, since what you're
referring to above is IIRC a drawable spinlock, not the heavyweight
hardware lock.
If a client takes the heavyweight lock and then sleeps even for a
couple of seconds, the X server should freeze
Dave Airlie wrote:
I agree, patch should be reverted. The difference between my change and
the previous code, fundamentally, is that mine slept as long as possible
relative to the passed in timeout until either a signal or wait-queue
event happened; the original code, in contrast,
Hi!
I'm attempting to run fgfs (FlightGear) using the VIA/Unichrome driver.
When I do so, fgfs fails at startup saying:
fire_buffer: DRM_VIA_CMDBUFFER returned -22
dmesg reports:
[drm:investigate_hazard] *ERROR* Illegal DMA data: 0xfff0
Other programs like glxgears seem to work
Thomas Hellstrm wrote:
Since the error messages I get indicate that indeed the filp associated
with the HW lock has changed, the stealing has probably occured in the
kernel DRM code.
Hmm, This is a nasty one.
What seems to happen is that when the X server waits in the kernel for
Hi,
I've commited the proposed fix for the DRI locking bug now,
since noone objected.
Please test for odd behaviour.
/Thomas
---
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce
Hi!
Keith Whitwell wrote:
get lock
while (timestamp mismatch) {
release lock
request new cliprects and timestamp
get lock
}
Note that is the contended case only. What's the worst that could
happen - somebody's wizzing windows around and our 3d client sits in
Keith Whitwell wrote:
Thomas Hellström wrote:
Hi!
Keith Whitwell wrote:
get lock
while (timestamp mismatch) {
release lock
request new cliprects and timestamp
get lock
}
Note that is the contended case only. What's the worst that could
happen - somebody's
Keith Whitwell wrote:
Thomas Hellström wrote:
Keith Whitwell wrote:
Thomas Hellström wrote:
Hi!
Keith Whitwell wrote:
get lock
while (timestamp mismatch) {
release lock
request new cliprects and timestamp
get lock
}
Note that is the contended case only. What's
Ian Romanick wrote:
The problem with the SAREA is that user-mode can request an SAREA
*larger* than the kernel knows about. For example, the user-mode
drivers can add extra fields for the DDX and client-side drivers to
communicate. The kernel doesn't need to know anything about what's in
Hi!
Jon Smirl wrote:
Looking at driver/server all of the drivers are effectively creating
an sarea of size SAREA_MAX. I also grepped through x.org and could not
find any place where it is set to anything besides SAREA_MAX. There is
code that sets it to other values but it is ifdef'd out.
1 - 100 of 514 matches
Mail list logo
