Hi!
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 commands, using specialized
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
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 e
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 ju
> >
> > 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?
E
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
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 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 dr
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
>
> 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
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
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 sample), and:
- fglrx sets this on all the chips and
- setting it in ou
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?
Ben
>
> 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 cr
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 o
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
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);
> >>
> >>
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 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 c
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 use
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
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 mai
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
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]
-
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, 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 li
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 dr
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 Xv
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, I'll
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 ---
Creat
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 hand
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-serv
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
>
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 wrot
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
drive
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 relev
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
> >
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 c
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 Johannes
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 some
-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 situat
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, 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
>
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 t
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 li
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.
x.org
46 matches
Mail list logo
