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.
On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
On Sat, 18 Jun 2005, Johannes Berg wrote:
Any idea where I should start looking for the source of the lockups or what
else to do?
The problem is likely either due to the radeon memory controller - in
particular registers like
On Tuesday 21 June 2005 10:54, Jerome Glisse wrote:
On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
On Sat, 18 Jun 2005, Johannes Berg wrote:
Any idea where I should start looking for the source of the lockups or
what else to do?
The problem is likely either due to the radeon
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote:
While this will probably work today it will leave little room for future
applications of DRI.
Can XvMC needs be handled via the V4L interface? I would expect an
some point relevant V4L drivers will also get integrated into the
DRM/fbdev
On Thu, 16 Jun 2005 14:22:36 +0200
Nicolai Haehnle [EMAIL PROTECTED] wrote:
On Thursday 16 June 2005 13:41, Aapo Tahkola wrote:
Update of /cvsroot/r300/r300_driver/r300
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333
Modified Files:
r300_reg.h r300_state.c
Log
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bernardo Innocenti wrote:
Hello,
I extracted this patch by Egbert Eich from SuSe's kernel
source package:
http://www.develer.com/drm-ioctl32.patch
It allows running 32bit DRI clients on 64bit systems,
which is a very common situation due
On 6/21/05, Johannes Berg [EMAIL PROTECTED] wrote:
Hi,
I mainly used r300 on ppc so far thus yes it works.
Good to know.
I am using it on x86 for
the 9800 lockup. But as i used a g5 i don't know if there is an issue with
the
agp of g4, don't think so... And IIRC someone told me that
Hi,
I mainly used r300 on ppc so far thus yes it works.
Good to know.
I am using it on x86 for
the 9800 lockup. But as i used a g5 i don't know if there is an issue with the
agp of g4, don't think so... And IIRC someone told me that it worked on a
powerbook which is, i presume, what
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote:
While this will probably work today it will leave little room for future
applications of DRI.
Can XvMC needs be handled via the V4L interface? I would expect an
some point relevant V4L drivers will also get integrated into the
DRM/fbdev
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote:
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote:
While this will probably work today it will leave little room for future
applications of DRI.
Can XvMC needs be handled via the V4L interface? I would expect an
some point
On 6/21/05, Jon Smirl [EMAIL PROTECTED] wrote:
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote:
While this will probably work today it will leave little room for future
applications of DRI.
Can XvMC needs be handled via the V4L interface? I would expect an
some point relevant V4L
This lets new non-root apps avoid calling AddMap for sarea. The AddMap
call has to stay marked as root only.
Any objections to why this won't work?
I think this is a good idea, though it might be better to allow each
separate DRM driver its own SAREA size. Since drm drivers and Mesa 3d
On Sat, 18 Jun 2005 22:18:43 +0200
Jerome Glisse [EMAIL PROTECTED] wrote:
On 6/18/05, Adam Jackson [EMAIL PROTECTED] wrote:
On Saturday 18 June 2005 13:38, Jerome Glisse wrote:
On 6/18/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
On Sat, 18 Jun 2005, Jerome Glisse wrote:
On 6/21/05, Nicolai Haehnle [EMAIL PROTECTED] wrote:
On Tuesday 21 June 2005 10:54, Jerome Glisse wrote:
On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
On Sat, 18 Jun 2005, Johannes Berg wrote:
Any idea where I should start looking for the source of the lockups or
what else to
On Tuesday 21 June 2005 18:06, Aapo Tahkola wrote:
On Thu, 16 Jun 2005 14:22:36 +0200
Nicolai Haehnle [EMAIL PROTECTED] wrote:
On Thursday 16 June 2005 13:41, Aapo Tahkola wrote:
Update of /cvsroot/r300/r300_driver/r300
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333
On 6/21/05, Alex Deucher [EMAIL PROTECTED] wrote:
On 6/21/05, Jon Smirl [EMAIL PROTECTED] wrote:
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote:
While this will probably work today it will leave little room for future
applications of DRI.
Can XvMC needs be handled via the V4L
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2241
--- Additional Comments From [EMAIL PROTECTED] 2005-06-21 05:51 ---
Jerome Glisse wrote:
I can remember from the top of my head but there is maybe some patch
that could be revealent for ppc not included in this snapshot. Thus i think
you should consider trying building xorg from cvs. Anyway with a g4 it will
compiles a lot faster than on dumb x86 ;)
Ok,
Hi!
On 6/21/05, Alex Deucher [EMAIL PROTECTED] wrote:
On 6/21/05, Jon Smirl [EMAIL PROTECTED] wrote:
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote:
While this will probably work today it will leave little room for
future
applications of DRI.
Can XvMC needs be handled via the
Now that the driver paints usable pictures without lockups on many cards,
including AGP versions of X800 and Mobility M10, it would make sense to
ready it for inclusion into main DRI codebase.
I do not think that elusive lockups of Radeon 9800 cards, or issues with
PowerPC will require any
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote:
Hi!
On 6/21/05, Alex Deucher [EMAIL PROTECTED] wrote:
On 6/21/05, Jon Smirl [EMAIL PROTECTED] wrote:
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote:
While this will probably work today it will leave little room for
future
Aapo Tahkola wrote:
On Thu, 16 Jun 2005 14:22:36 +0200
Nicolai Haehnle [EMAIL PROTECTED] wrote:
On Thursday 16 June 2005 13:41, Aapo Tahkola wrote:
Update of /cvsroot/r300/r300_driver/r300
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333
Modified Files:
r300_reg.h r300_state.c
On 6/21/05, Alex Deucher [EMAIL PROTECTED] wrote:
Exactly. v4l is basically just an analog video capture API.
Here is the V4L API spec:
http://v4l2spec.bytesex.org/spec/
It supports much more than analog video capature.
--
Jon Smirl
[EMAIL PROTECTED]
On 6/21/05, Alex Deucher [EMAIL PROTECTED] wrote:
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote:
Hi!
On 6/21/05, Alex Deucher [EMAIL PROTECTED] wrote:
On 6/21/05, Jon Smirl [EMAIL PROTECTED] wrote:
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote:
While this will
driver out of it.
Exactly. v4l is basically just an analog video capture API.
It would be nice to have a v4l compatible interface to the radeon
capture interface for AIW and VIVO cards; this would require the drm
as well. That's another potential user.
The radeon v4l driver km is now
On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
driver out of it.
Exactly. v4l is basically just an analog video capture API.
It would be nice to have a v4l compatible interface to the radeon
capture interface for AIW and VIVO cards; this would require the drm
as well.
On 6/21/05, Alex Deucher [EMAIL PROTECTED] wrote:
Exactly. v4l is basically just an analog video capture API.
It would be nice to have a v4l compatible interface to the radeon
capture interface for AIW and VIVO cards; this would require the drm
as well. That's another potential user.
v4l
On Tue, 2005-06-21 at 14:57 -0400, Vladimir Dergachev wrote:
/* Texture offset is dangerous and needs more checking */
ADD_RANGE(R300_TX_OFFSET_0, 16);
I don't think texture offsets are ever written to, however if they
point in the wrong place they can
On Tue, 21 Jun 2005, Eric Anholt wrote:
On Tue, 2005-06-21 at 14:57 -0400, Vladimir Dergachev wrote:
/* Texture offset is dangerous and needs more checking */
ADD_RANGE(R300_TX_OFFSET_0, 16);
I don't think texture offsets are ever written to, however if they
On Tue, 2005-06-21 at 16:56 -0400, Vladimir Dergachev wrote:
On Tue, 21 Jun 2005, Eric Anholt wrote:
On Tue, 2005-06-21 at 14:57 -0400, Vladimir Dergachev wrote:
/* Texture offset is dangerous and needs more checking */
ADD_RANGE(R300_TX_OFFSET_0, 16);
I don't
On Tuesday 21 June 2005 21:15, Rune Petersen wrote:
Aapo Tahkola wrote:
*snip*
+if (info-ChipFamily = CHIP_FAMILY_R300) {
+ unsigned char *RADEONMMIO = info-MMIO;
+ OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
0x180 is defined as R300_MC_INIT_MISC_LAT_TIME in r300_reg.h.
This
On Tuesday 21 June 2005 20:57, Vladimir Dergachev wrote:
Now that the driver paints usable pictures without lockups on many cards,
including AGP versions of X800 and Mobility M10, it would make sense to
ready it for inclusion into main DRI codebase.
I do not think that elusive lockups of
I'm working on changing DRM such that the master node does not need to
run as root and instead can be a normal user. Because of this I can't
leave AddMap the way it is. The security hole is that a normal user
could allocate multi/large shared areas, consume all of kernel VM
space and crash
Jon Smirl wrote:
When I first boot it's fine, but when the laptop comes back from S3,
even if everything else works, the serial console just prints a couple
of characters of garbage and then dies. :(
You do get the nice serial console printout at boot right, it's only
not working on resume?
On 6/21/05, Dave Airlie [EMAIL PROTECTED] wrote:
I think we should have a root master process to be honest, it can run from
init and also have it do any mode setting type business... it can operate
like the DDXes do today, except it won't do any mode settting or anything
until prompted by the
I don't see this process adding huge amounts of code to the drivers,
I'm halfway through and I don't think I've added hardly any code at
all. Mostly I just rearrange what is already there.
Linux already has existing fbdev drivers for mode setting. I am
choosing to use those now since I
On Wed, 2005-06-22 at 02:48 +0100, Dave Airlie wrote:
I don't see this process adding huge amounts of code to the drivers,
I'm halfway through and I don't think I've added hardly any code at
all. Mostly I just rearrange what is already there.
Linux already has existing fbdev drivers
On 6/21/05, Dave Airlie [EMAIL PROTECTED] wrote:
I don't see this process adding huge amounts of code to the drivers,
I'm halfway through and I don't think I've added hardly any code at
all. Mostly I just rearrange what is already there.
Linux already has existing fbdev drivers for
On 6/21/05, Jon Smirl [EMAIL PROTECTED] wrote:
Second choice would be to make a new map type, DRM_VSHM. The specific
driver would initmap the needed space at load time. The code
implementing it would be identical to DRM_SHM, you just need another
map type defined so that you can tell them
On Wed, 2005-06-22 at 00:46 +0100, Dave Airlie wrote:
At the moment I'm having similiar issues with Radeon XvMC it initially
will require root as I'm not sure how to submit the command streams
outside of indirect buffers which are a root only thing...
Can't it be done the same way as for 3D
At the moment I'm having similiar issues with Radeon XvMC it initially
will require root as I'm not sure how to submit the command streams
outside of indirect buffers which are a root only thing...
Can't it be done the same way as for 3D commands, using specialized
ioctls?
Eventually
On Tue, 2005-06-21 at 23:27 -0400, Jon Smirl wrote:
On 6/21/05, Jon Smirl [EMAIL PROTECTED] wrote:
Second choice would be to make a new map type, DRM_VSHM. The specific
driver would initmap the needed space at load time. The code
implementing it would be identical to DRM_SHM, you just need
On 6/21/05, Eric Anholt [EMAIL PROTECTED] wrote:
Could you send the diff to the list for review first? I've got a patch
to clean up map handling that I'm working on, and I'd like to avoid more
mess. I'm not clear on why you need a new map type, if it's going to be
treated like DRM_SHM
On Wednesday 22 June 2005 03:09, Rune Petersen wrote:
Nicolai Haehnle wrote:
Also I remember seeing that the values
are different depending on chip family. Is this safe?
Well, I have tested this on three different chips (R300, rv350 (mobile)
and
R420, which is quite a nice
44 matches
Mail list logo
