From: Jon S. <jon...@gm...> - 2005-06-21 02:28:15
|
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 comment... /* FIXME: Need to extend DRI protocol to pass this size back to * client for SAREA mapping that includes a device private record */ [jonsmirl@jonsmirl dri]$ grep -rI SAREASize * | grep =3D fb/fb_dri.c: ctx->shared.SAREASize =3D SAREA_MAX; i810/server/i810_dri.c: ctx->shared.SAREASize =3D 0x2000; mga/server/mga_dri.c: ctx->shared.SAREASize =3D SAREA_MAX; r128/server/r128_dri.c: ctx->shared.SAREASize =3D SAREA_MAX; r200/server/radeon_dri.c: ctx->shared.SAREASize =3D SAREA_MAX; r200/server/radeon_egl.c: disp->SAREASize =3D SAREA_MAX; radeon/server/radeon_dri.c: ctx->shared.SAREASize =3D SAREA_MAX; radeon/server/radeon_egl.c: disp->SAREASize =3D SAREA_MAX; tdfx/server/tdfx_dri.c: ctx->shared.SAREASize =3D SAREA_MAX; unichrome/server/via_dri.c: ctx->shared.SAREASize =3D ((sizeof(drm_sarea_t) + 0xfff) & 0x1000); unichrome/server/via_dri.c: ctx->shared.SAREASize =3D SAREA_MAX; Exception is i810 at 0x2000 which is what SAREA_MAX is minimally defined too so i810 can be changed. The odd line in the via driver is if'd out and SAREA_MAX is used. Given that everyone is using SAREA_MAX I can modify DRM to pre-create a SAREA_MAX region and return it from AddMap instead of making a new one. Doing it that way will keep the old binaries working. New apps use a loop similar to this instead of doing AddMap: for (i =3D 0;; i++) { if ((rc =3D drmGetMap(display->drmFD, i, &offset, &size, &type, &flags, &handle, &mtrr)) !=3D 0) break; if (type =3D=3D DRM_SHM { drmMap(fd, handle, size, (drmAddressPtr)&display->sarea); break; } } 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? --=20 Jon Smirl jon...@gm... |
From: <uni...@sh...> - 2005-06-21 07:44:34
|
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 ifdef's have this comment... >/* FIXME: Need to extend DRI protocol to pass this size back to > * client for SAREA mapping that includes a device private record > */ > >[jonsmirl@jonsmirl dri]$ grep -rI SAREASize * | grep = >fb/fb_dri.c: ctx->shared.SAREASize = SAREA_MAX; >i810/server/i810_dri.c: ctx->shared.SAREASize = 0x2000; >mga/server/mga_dri.c: ctx->shared.SAREASize = SAREA_MAX; >r128/server/r128_dri.c: ctx->shared.SAREASize = SAREA_MAX; >r200/server/radeon_dri.c: ctx->shared.SAREASize = SAREA_MAX; >r200/server/radeon_egl.c: disp->SAREASize = SAREA_MAX; >radeon/server/radeon_dri.c: ctx->shared.SAREASize = SAREA_MAX; >radeon/server/radeon_egl.c: disp->SAREASize = SAREA_MAX; >tdfx/server/tdfx_dri.c: ctx->shared.SAREASize = SAREA_MAX; >unichrome/server/via_dri.c: ctx->shared.SAREASize = >((sizeof(drm_sarea_t) + 0xfff) & 0x1000); >unichrome/server/via_dri.c: ctx->shared.SAREASize = SAREA_MAX; > >Exception is i810 at 0x2000 which is what SAREA_MAX is minimally >defined too so i810 can be changed. The odd line in the via driver is >if'd out and SAREA_MAX is used. > >Given that everyone is using SAREA_MAX I can modify DRM to pre-create >a SAREA_MAX region and return it from AddMap instead of making a new >one. Doing it that way will keep the old binaries working. > >New apps use a loop similar to this instead of doing AddMap: > >for (i = 0;; i++) { > if ((rc = drmGetMap(display->drmFD, i, &offset, &size, &type, >&flags, &handle, &mtrr)) != 0) > break; > if (type == DRM_SHM { > drmMap(fd, handle, size, (drmAddressPtr)&display->sarea); > break; > } >} > >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? > > > While this will probably work today it will leave little room for future applications of DRI. A concrete example is the Unichrome driver. XvMC and OpenGL were developed in parallell and to some extent entered entries in the SAREA one after another with what information was available then. In later hardware VIA has added more mpeg decoders and video engines which increases the needs for XvMC locks. Today this will either fragment the SAREA or break all forms of binary compatibility. One possibility to avoid this in the future is to have a separate SAREA for XvMC specific stuff. Whatever DRI is used for in the future either than OpenGL the developer will very early encounter the problem how to share data between clients and master. Keeping this in a fixed sized SAREA is one solution, being able to put it in a _application specific_ shared memory region mappable only by authenticated clients is another. Given the mentioned experience and expansion plans for the via drm, IMHO the latter capability of drm needs being kept. /Thomas |
From: Jon S. <jon...@gm...> - 2005-06-21 18:13:56
|
On 6/21/05, Thomas Hellstr=F6m <uni...@sh...> 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 composite driver. Is 8K of memory not enough for VIA? Or is the problem that there are three structures being placed in sarea: DRM, via DRM, via XvMC. With three structures you can't tell the offset to load the third one at. Could the three structures problem be fixed by just combining the structure defs for via DRM and via XvMC? Another solution is to create another shared memory type. --=20 Jon Smirl jon...@gm... |
From: Thomas <uni...@sh...> - 2005-06-21 16:45:06
|
> On 6/21/05, Thomas Hellstr=F6m <uni...@sh...> wrote: >> While this will probably work today it will leave little room for futu= re >> 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 composite driver. > I haven't actually looked into the V4L interface, but in VIA's own solution they end up with a proprietary decoder interface that uses their V4L kernel driver and needs to be run as root. Imagine a vulnerable media player that accesses remote URLs and needs to be run as root. i810 XvMC (from which the unichrome driver initially was derived) is also using drm, but I think nobody is really using it. > Is 8K of memory not enough for VIA? Or is the problem that there are > three structures being placed in sarea: DRM, via DRM, via XvMC. With > three structures you can't tell the offset to load the third one at. > Could the three structures problem be fixed by just combining the > structure defs for via DRM and via XvMC? It is sufficient today. My point is that we'll be restricting the generality of drm. After som continous development of OpenGL and XvMC the private part of th= e sarea would look like ------------- OpenGL stuff ------------- XvMC stuff ------------- XvmC lock array ------------- More OpenGL stuff ------------- Continuation of XvMC lock array _____________ Even More OpenGL stuff ______________ and therefore IMHO the cleanest solution is to have an XvMC private sarea of it's own, and I'd like to be able to reserve shared memory pages for authenticated clients only, and I believe the DRM is the right place for this. Since nobody AFAIK is using this possibility today, it might not worth preserving and I can of course always implement a driver-specific IOCTL for this when / if it's going into the unichrome drivers. /Thomas > > Another solution is to create another shared memory type. > > -- > Jon Smirl > jon...@gm... > |
From: Jon S. <jon...@gm...> - 2005-06-21 18:26:08
|
On 6/21/05, Thomas Hellstr=F6m <uni...@sh...> wrote: > > On 6/21/05, Thomas Hellstr=F6m <uni...@sh...> wrote: > >> While this will probably work today it will leave little room for futu= re > >> 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 composite driver. > > >=20 > I haven't actually looked into the V4L interface, but in VIA's own > solution they end up with a proprietary decoder interface that uses their > V4L kernel driver and needs to be run as root. Imagine a vulnerable media > player that accesses remote URLs and needs to be run as root. There are other V4L drivers that don't need to run as root. I would suspect that VIA didn't implement something correctly and triggered the need to be root. > i810 XvMC (from which the unichrome driver initially was derived) is also > using drm, but I think nobody is really using it. >=20 > > Is 8K of memory not enough for VIA? Or is the problem that there are > > three structures being placed in sarea: DRM, via DRM, via XvMC. With > > three structures you can't tell the offset to load the third one at. > > Could the three structures problem be fixed by just combining the > > structure defs for via DRM and via XvMC? >=20 > It is sufficient today. My point is that we'll be restricting the > generality of drm. >=20 > After som continous development of OpenGL and XvMC the private part of th= e > sarea would look like >=20 > ------------- > OpenGL stuff > ------------- > XvMC stuff > ------------- > XvmC lock array > ------------- > More OpenGL stuff > ------------- > Continuation of XvMC lock array > _____________ >=20 > Even More OpenGL stuff > ______________ >=20 > and therefore IMHO the cleanest solution is to have an XvMC private sarea > of it's own, and I'd like to be able to reserve shared memory pages for > authenticated clients only, and I believe the DRM is the right place for > this. 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 the kernel. My first choice would be to push these locks into the driver's V4L interfac= e. 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 apart. This scheme does not require anyone to be root and does not have a kernel DOS hole. However, the V4L interface is directly manipulable by the user - it does not have a driver library driving it. I don't see how you are going to be able to build V4L if the locks are managed through DRM. --=20 Jon Smirl jon...@gm... |
From: Dave A. <ai...@li...> - 2005-06-21 23:46:29
|
> > 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 the kernel. > > 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 apart. This scheme does not > require anyone to be root and does not have a kernel DOS hole. 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... I'd also like to have a separate sarea for storing this stuff, I don't care for V4L, XvMC is what is supported out there now and NVIDIA provide it and don't provide v4l... also there is no need for this to be in-kernel, its only a DMA stream and a sync point... 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 user app... I just feel in-kernel is going to become bloated with what is the DDX _dri.x file now ... just because MS put lots of things in kernel doesn't mean we have to... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG |
From: Jon S. <jon...@gm...> - 2005-06-22 01:31:46
|
On 6/21/05, Dave Airlie <ai...@li...> wrote: > I think we should have a root master process to be honest, it can run fro= m > 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 user app... I just feel in-kernel is going to becom= e > bloated with what is the DDX _dri.x file now ... just because MS put lots > of things in kernel doesn't mean we have to... Getting rid of the root requirement is driven by the desire to lower the amount of code running with root priv. In the x.org tree there are 17,618,401 lines of source and lots of it is running as root. I can not say for sure that all of that code is free from security holes. It is much easier to audit a limited set of driver code that is around 100,000 lines. Whole Linux kernel is 6.7M. 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 wasted a year messing around trying to add mode setting directly to DRM. I now realize that there are vocal, powerful supporters behind using the fbdev code. I want to get my server working so I am choosing the path of least resistance and using fbdev. --=20 Jon Smirl jon...@gm... |
From: Dave A. <ai...@li...> - 2005-06-22 01:48:27
|
> > 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 wasted a year messing around trying > to add mode setting directly to DRM. I now realize that there are > vocal, powerful supporters behind using the fbdev code. I want to get > my server working so I am choosing the path of least resistance and > using fbdev. But there are also people who are against it and my thinking is that with benh now thinking we should avoid using fbdev, we should maybe start to think about it.. My presentation at desktopcon is an effort to cover this, I'll give the same one to KS in a slightly modified form.... We can't mode set in the kernel for every chip, we know this, intelfb doesn't modeset in the kernel if you aren't using a single CRT (i.e. BIOS isn't needed)... this can't be fixed in the current fb architecture so we need something new... 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 loadable modules, that just init the in-kernel driver with some info from a file in /etc and maybe some other stuff.. you have it reading a kernel netlink or something similiar for kernel mode change events from a kernel side driver, (so your mode change API can still happen), at startup it can just setup the memory manager, detect monitors (could also wakeup every so often if needed for monitor hotplug detection), it woudln't need to do an initial modeset I don't think, until someone else comes along and asks for it.. so a userspace console would just be an app like anything else.. things like Xegl and KAA/Shiny would use the same basic infrastructure and not care ... this process would run as root so you can then audit it, it would be much smaller than X, and it would run in userspace so we wouldn't have to audit it as much for doing evil things.. the less code in the kernel the less code I have to review ;-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG |
From: Eric A. <et...@lc...> - 2005-06-22 01:57:04
|
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 for mode setting. I am > > choosing to use those now since I wasted a year messing around trying > > to add mode setting directly to DRM. I now realize that there are > > vocal, powerful supporters behind using the fbdev code. I want to get > > my server working so I am choosing the path of least resistance and > > using fbdev. > > But there are also people who are against it and my thinking is that with > benh now thinking we should avoid using fbdev, we should maybe start to > think about it.. > > My presentation at desktopcon is an effort to cover this, I'll give the > same one to KS in a slightly modified form.... > > We can't mode set in the kernel for every chip, we know this, intelfb > doesn't modeset in the kernel if you aren't using a single CRT (i.e. BIOS > isn't needed)... this can't be fixed in the current fb architecture so we > need something new... > > 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 > loadable modules, that just init the in-kernel driver with some info from > a file in /etc and maybe some other stuff.. you have it reading a kernel > netlink or something similiar for kernel mode change events from a kernel > side driver, (so your mode change API can still happen), > > at startup it can just setup the memory manager, detect monitors (could > also wakeup every so often if needed for monitor hotplug detection), it > woudln't need to do an initial modeset I don't think, until someone else > comes along and asks for it.. so a userspace console would just be an app > like anything else.. things like Xegl and KAA/Shiny would use the same > basic infrastructure and not care ... > > this process would run as root so you can then audit it, it would be much > smaller than X, and it would run in userspace so we wouldn't have to audit > it as much for doing evil things.. the less code in the kernel the less > code I have to review ;-) This is the best thing I've heard in this discussion so far! I'm still concerned by the handwaving involved in how apps are going to interact with mode setting (yes, I do want to be able to have my video game switch to 1280x1024), but I have nothing concrete to offer either. -- Eric Anholt et...@lc... http://people.freebsd.org/~anholt/ anholt@FreeBSD.org |
From: Keith W. <ke...@tu...> - 2005-06-22 08:28:40
|
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 >>loadable modules, that just init the in-kernel driver with some info from >>a file in /etc and maybe some other stuff.. you have it reading a kernel >>netlink or something similiar for kernel mode change events from a kernel >>side driver, (so your mode change API can still happen), >> >>at startup it can just setup the memory manager, detect monitors (could >>also wakeup every so often if needed for monitor hotplug detection), it >>woudln't need to do an initial modeset I don't think, until someone else >>comes along and asks for it.. so a userspace console would just be an app >>like anything else.. things like Xegl and KAA/Shiny would use the same >>basic infrastructure and not care ... >> >>this process would run as root so you can then audit it, it would be much >>smaller than X, and it would run in userspace so we wouldn't have to audit >>it as much for doing evil things.. the less code in the kernel the less >>code I have to review ;-) > > > This is the best thing I've heard in this discussion so far! > > I'm still concerned by the handwaving involved in how apps are going to > interact with mode setting (yes, I do want to be able to have my video > game switch to 1280x1024), but I have nothing concrete to offer either. > I agree - this sounds like the most workable proposal so far. Keith |
From: Jon S. <jon...@gm...> - 2005-06-22 03:16:44
|
On 6/21/05, Dave Airlie <ai...@li...> 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 mode setting. I am > > choosing to use those now since I wasted a year messing around trying > > to add mode setting directly to DRM. I now realize that there are > > vocal, powerful supporters behind using the fbdev code. I want to get > > my server working so I am choosing the path of least resistance and > > using fbdev. >=20 > But there are also people who are against it and my thinking is that with > benh now thinking we should avoid using fbdev, we should maybe start to > think about it.. I wish you luck in chasing this. I have wasted far, far, far too much time fighting various people over the mode setting API. I have thousands of lines of rejected patches sitting on my disk. I have learned my lesson and the code I am currently writing calls fbdev. --=20 Jon Smirl jon...@gm... |
From: Jon S. <jon...@gm...> - 2005-06-22 03:27:46
|
On 6/21/05, Jon Smirl <jon...@gm...> 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 apart. This scheme does not > require anyone to be root and does not have a kernel DOS hole. So back to the original topic. I'll add a new map type DRM_VSHM. When initializing, the chip specific driver needs to do something like this: if ((ret =3D drm_initmap(dev, 0, video_size, 0, _DRM_VSHM, 0))) =09goto err_g1; The map needs to be created in the driver. Opening it up to a normal user is a DOS hole where the kernel can be run out of memory. Use getmap to find the map from user space. --=20 Jon Smirl jon...@gm... |
From: Michel <mi...@da...> - 2005-06-22 03:36:37
|
On Wed, 2005-06-22 at 00:46 +0100, Dave Airlie wrote: >=20 > 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? --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: <uni...@sh...> - 2005-06-22 06:46:38
|
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 >>ioctls? >> >> > >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 ... > > > Could you have an IOCTL set upp the indirect buffer and fire it based on data it is handled? Or maybe that was what Michael asked. Running a video player as root is really a bad thing and VIA has received a lot of bashing for their solution. >I think it will at any rate .. at the moment I've no memory manager so I'm >going to do a gross hack initially anyways as I need to allocate 5 * max >video size at startup time .. uggh... waste of good VRAM... > > > The XvMC capable players out there needs 8 surfaces to run smoothly. At least xine does. >Dave. > > > /Thomas |
From: Dave A. <ai...@li...> - 2005-06-22 08:06:11
|
> > > > 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 ... I suppose I could do that if I did it properly.. my initial implementation will be root only but I won't release it .. :-) > The XvMC capable players out there needs 8 surfaces to run smoothly. At least > xine does. ahh crap ... need memory manager... I suppose I could do something like the transition to 3d code to get memory.. don't think it'll work too well though.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG |
From: Alex D. <ale...@gm...> - 2005-06-21 18:28:11
|
On 6/21/05, Jon Smirl <jon...@gm...> wrote: > On 6/21/05, Thomas Hellstr=F6m <uni...@sh...> wrote: > > While this will probably work today it will leave little room for futur= e > > applications of DRI. >=20 > 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 composite driver. the problem is v4l is linux specific while XvMC is X specific and hence multi-platform, plus it has ties to Xv, which would need to be handled as well. >=20 > Is 8K of memory not enough for VIA? Or is the problem that there are > three structures being placed in sarea: DRM, via DRM, via XvMC. With > three structures you can't tell the offset to load the third one at. > Could the three structures problem be fixed by just combining the > structure defs for via DRM and via XvMC? >=20 > Another solution is to create another shared memory type. >=20 > -- > Jon Smirl > jon...@gm... >=20 > |
From: Vladimir D. <vo...@mi...> - 2005-06-21 18:29:57
|
> > 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 drivers have to match or at least know about each other the number can be hardcoded in DRM driver. best Vladimir Dergachev > > -- > Jon Smirl > jon...@gm... > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Jon S. <jon...@gm...> - 2005-06-21 18:40:53
|
On 6/21/05, Alex Deucher <ale...@gm...> wrote: > On 6/21/05, Jon Smirl <jon...@gm...> wrote: > > On 6/21/05, Thomas Hellstr=F6m <uni...@sh...> wrote: > > > While this will probably work today it will leave little room for fut= ure > > > 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 composite driver. >=20 > the problem is v4l is linux specific while XvMC is X specific and > hence multi-platform, plus it has ties to Xv, which would need to be > handled as well. Don't we already have an Xv for V4L driver for X?=20 Can't XvMC follow the same model? --=20 Jon Smirl jon...@gm... |
From: Thomas <uni...@sh...> - 2005-06-21 18:57:17
|
Hi! > On 6/21/05, Alex Deucher <ale...@gm...> wrote: >> On 6/21/05, Jon Smirl <jon...@gm...> wrote: >> > On 6/21/05, Thomas Hellstr=F6m <uni...@sh...> 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 composite driver. >> >> the problem is v4l is linux specific while XvMC is X specific and >> hence multi-platform, plus it has ties to Xv, which would need to be >> handled as well. > > Don't we already have an Xv for V4L driver for X? > Can't XvMC follow the same model? Correct me if I'm wrong, but isn't V4L primarily for video capture? besides there is no way I'm going to redesign everything and make a V4L driver out of it. XvMC is very similar to OpenGL in it's use of the hardware. It uses the same DMA command engine and it renders directly to the frame buffer, either to an offscreen area which is then communicated to the video engines, or directly to the visible frame-buffer and hence needs the DRI drawable management. There is very little logical difference between "render this texture" or "render this macroblock". Besides, if V4L needs to use the same DMA command engine it still would need to talk to DRM. Still, this isn't really the point. I'd like to see drm available for other applications than OpenGL in the future. If drmAddMap goes away, I can live with that, but I'd probably would have to implement a device-specific non-root "Hi, I'm the master, get me a handle to clean sarea that other clients can map" IOCTL when it's needed, and, as I see it, that wouldn't interfer with your work. /Thomas > > -- > Jon Smirl > jon...@gm... > |
From: Alex D. <ale...@gm...> - 2005-06-21 19:01:34
|
On 6/21/05, Thomas Hellstr=F6m <uni...@sh...> wrote: > Hi! >=20 > > On 6/21/05, Alex Deucher <ale...@gm...> wrote: > >> On 6/21/05, Jon Smirl <jon...@gm...> wrote: > >> > On 6/21/05, Thomas Hellstr=F6m <uni...@sh...> 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 composite driver. > >> > >> the problem is v4l is linux specific while XvMC is X specific and > >> hence multi-platform, plus it has ties to Xv, which would need to be > >> handled as well. > > > > Don't we already have an Xv for V4L driver for X? > > Can't XvMC follow the same model? >=20 > Correct me if I'm wrong, but isn't V4L primarily for video capture? > besides there is no way I'm going to redesign everything and make a V4L > driver out of it. Exactly. v4l is basically just an analog video capture API. >=20 > XvMC is very similar to OpenGL in it's use of the hardware. It uses the > same DMA command engine and it renders directly to the frame buffer, > either to an offscreen area which is then communicated to the video > engines, or directly to the visible frame-buffer and hence needs the DRI > drawable management. There is very little logical difference between > "render this texture" or "render this macroblock". Besides, if V4L needs > to use the same DMA command engine it still would need to talk to DRM. >=20 > Still, this isn't really the point. I'd like to see drm available for > other applications than OpenGL in the future. If drmAddMap goes away, I > can live with that, but I'd probably would have to implement a > device-specific non-root "Hi, I'm the master, get me a handle to clean > sarea that other clients can map" IOCTL when it's needed, and, as I see > it, that wouldn't interfer with your work. >=20 > /Thomas >=20 >=20 >=20 > > > > -- > > Jon Smirl > > jon...@gm... > > >=20 >=20 > |
From: Jon S. <jon...@gm...> - 2005-06-21 19:07:41
|
On 6/21/05, Alex Deucher <ale...@gm...> 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. --=20 Jon Smirl jon...@gm... |
From: Alex D. <ale...@gm...> - 2005-06-21 19:08:11
|
On 6/21/05, Alex Deucher <ale...@gm...> wrote: > On 6/21/05, Thomas Hellstr=F6m <uni...@sh...> wrote: > > Hi! > > > > > On 6/21/05, Alex Deucher <ale...@gm...> wrote: > > >> On 6/21/05, Jon Smirl <jon...@gm...> wrote: > > >> > On 6/21/05, Thomas Hellstr=F6m <uni...@sh...> wrote: > > >> > > While this will probably work today it will leave little room fo= r > > >> 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 composite driver. > > >> > > >> the problem is v4l is linux specific while XvMC is X specific and > > >> hence multi-platform, plus it has ties to Xv, which would need to be > > >> handled as well. > > > > > > Don't we already have an Xv for V4L driver for X? > > > Can't XvMC follow the same model? > > > > Correct me if I'm wrong, but isn't V4L primarily for video capture? > > besides there is no way I'm going to redesign everything and make a V4L > > driver out of it. >=20 > 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. Alex >=20 > > > > XvMC is very similar to OpenGL in it's use of the hardware. It uses the > > same DMA command engine and it renders directly to the frame buffer, > > either to an offscreen area which is then communicated to the video > > engines, or directly to the visible frame-buffer and hence needs the DR= I > > drawable management. There is very little logical difference between > > "render this texture" or "render this macroblock". Besides, if V4L need= s > > to use the same DMA command engine it still would need to talk to DRM. > > > > Still, this isn't really the point. I'd like to see drm available for > > other applications than OpenGL in the future. If drmAddMap goes away, I > > can live with that, but I'd probably would have to implement a > > device-specific non-root "Hi, I'm the master, get me a handle to clean > > sarea that other clients can map" IOCTL when it's needed, and, as I see > > it, that wouldn't interfer with your work. > > > > /Thomas > > > > > > > > > > > > -- > > > Jon Smirl > > > jon...@gm... > > > > > > > > > > |
From: Jon S. <jon...@gm...> - 2005-06-21 19:36:29
|
On 6/21/05, Alex Deucher <ale...@gm...> wrote: > > Exactly. v4l is basically just an analog video capture API. >=20 > 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 is a kernel interface. A radeon v4l driver needs to coordinate with DRM via driver entry points, not a user space IOCTL. --=20 Jon Smirl jon...@gm... |
From: Vladimir D. <vo...@mi...> - 2005-06-21 19:23:53
|
>>> 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 maintained and developed by Antti Ajanki. The cooperation of drm is needed for acknowledging interrupts, otherwise they are pretty much orthogonal - km uses RADEON_GUI_DMA registers for transfers from video memory to system ram. best Vladimir Dergachev > > Alex > >> >>> >>> XvMC is very similar to OpenGL in it's use of the hardware. It uses the >>> same DMA command engine and it renders directly to the frame buffer, >>> either to an offscreen area which is then communicated to the video >>> engines, or directly to the visible frame-buffer and hence needs the DRI >>> drawable management. There is very little logical difference between >>> "render this texture" or "render this macroblock". Besides, if V4L needs >>> to use the same DMA command engine it still would need to talk to DRM. >>> >>> Still, this isn't really the point. I'd like to see drm available for >>> other applications than OpenGL in the future. If drmAddMap goes away, I >>> can live with that, but I'd probably would have to implement a >>> device-specific non-root "Hi, I'm the master, get me a handle to clean >>> sarea that other clients can map" IOCTL when it's needed, and, as I see >>> it, that wouldn't interfer with your work. >>> >>> /Thomas >>> >>> >>> >>>> >>>> -- >>>> Jon Smirl >>>> jon...@gm... >>>> >>> >>> >>> >> > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Jon S. <jon...@gm...> - 2005-06-21 19:34:09
|
On 6/21/05, Vladimir Dergachev <vo...@mi...> 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. That's another potential user. >=20 > The radeon v4l driver "km" is now maintained and developed by Antti Ajank= i. >=20 > The cooperation of drm is needed for acknowledging interrupts, otherwise > they are pretty much orthogonal - km uses RADEON_GUI_DMA registers for > transfers from video memory to system ram. I'm working towards a model where there are multiple device specific driver= s: radeonfb/fbdev - lowest layer binds to PCI ID, interupts, etc radeon/DRM - coordinates things like memory management and interrupts by linking to fbdev km/v4L - would coordinate interrupts by tying into fbdev like DRM fbdev, DRM, v4L all expose their own device nodes. It should be safe for a normal user to access any of these device nodes instead of requiring root. A variation on the model is: radeon_base radeonfb/fbdev radeon/DRM km/v4L radeon_base is a platform the other drivers load on top of.=20 It is constructed by splitting the existing radeonfb. --=20 Jon Smirl jon...@gm... |