Jon Smirl wrote:
On 6/22/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
Jon Smirl wrote:
I'll add a new map type DRM_VSHM. When initializing, the chip specific
driver needs to do something like this:
if ((ret = drm_initmap(dev, 0, video_size, 0, _DRM_VSHM, 0)))
goto err_g1;
The map
Jon Smirl wrote:
2) How is a non-root drmAddMap for shared memory a bigger security risc
than shmget? I understand why SAREA containing the lock needs to be
permanent, but not subsequent ones. Why can't they be created on demand by
the master?
The memory being allocated by the drivers is
On 6/22/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> 1) How is allocating a second fixed sarea different from splitting the
> first SAREA in two parts? The problem is not space but future expandability
> and generality.
Both the DRM and driver sarea structs go into the first SHM. You can
use
Jon Smirl wrote:
On 6/22/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
Hi.
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 co
On 6/22/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > Adding a new map type "so that you can tell them apart" doesn't make a
> > lot of sense to me. Won't two different maps have different offsets?
> > Isn't that enough to differentiate between them?
>
> Yes the offsets will be different. But how
On 6/22/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > I'll add a new map type DRM_VSHM. When initializing, the chip specific
> > driver needs to do something like this:
> >
> > if ((ret = drm_initmap(dev, 0, video_size, 0, _DRM_VSHM, 0)))
> > goto err_g1;
> >
> > The map
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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_SH
On 6/22/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Hi.
>
> 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
Eric Anholt wrote:
On Wed, 2005-06-22 at 02:48 +0100, Dave Airlie wrote:
After talking with Ben a few days back, I'm getting the idea we are going
to need a user-space server process that does all of this, call it 0
(zero) as X-X = 0, this 0 process is started by init and has card specific
lo
> >
> > Eventually yes, but that VHA stuff sets a load of registers in indirect
> > buffer, fills up an indirect buffer and sends it the card... to do this
> > without indirect buffers would require a fair lot of sending commands
> > between blocks to make sure the card is back in a known state ...
Hi.
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 another
map type de
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 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
>
> 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 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]
-
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
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
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
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
> 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
>
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
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 ifdef's have this commen
37 matches
Mail list logo
