On Sun, 28 Apr 2002, Vladimir Dergachev wrote: > On Sat, 27 Apr 2002, R C wrote: > > > > > I'll be home next weekend, and probably won't be working for a few days > > at least. I have a question on where development is going, and what's > > best to work on. > > > > 1) Merge km into drm. Is this waiting on permission for the mach64 > > stuff? Do we use the existing DMA engine? Or do we setup a mutex to keep > > 3d and v4l from running simultaneously? This is big, but something I > > want to try.. I really think we can get hardware colorspace conversion > > out of the 3d engine, and I'd like to take a hack at it. However, I'd > > rather do it as part of the eventual port than as a proof of concept to > > be discarded. > > See 2) > > > > > 2) Fixup VBI support. This is mostly waiting for infrastructure.. do I > > try and graft on a third DMA transaction into the current scheme, or do > > we go for a unified DMA (perhaps the drm?). I am thinking about adding a > > simple mmap just for VBI into the module; practically every app seems to > > use mmap. > > 1 and 2 are actually quite related. I was (pondering I guess ??) about > redoing quite a bit of current driver design. Perhaps, it would be > useful to outline this here: > > A) Redo hardware-dependent part of km into general framework that > supports PCI transfers (DMA and cpu driven) and processes PCI > device interrupts. I think I understand what needs to be done here > rather well.. > > B) Upgrade A) to include AGP and ring buffer part of DRM modules and > get DRI people to buy into this. This way there will be only one > thing that messes with DMA, AGP, interrupts and PCI device access. > > C) Write a (small) library that is able to be compiled in _both_ user > space and kernel space. (I.e. with a reasonably neutral interface). > > C) is very important, because we _need_ to have engine initialization > code in both user-space and kernel-space. For example, right now if the > engine locks up and DRM driver finds it the monitor goes blank as the > engine was reset but DRM driver does not know how to set a valid mode. > > Needless to say this is a major overhaul and I am reluctant to start on > it without a solid chunk of time to clean up the bugs.
Maybe you could bring this up again in tomorrow's DRI IRC meeting. This would probably be a good time to get some feedback on your ideas from other DRI maintainers. > The other thing is that Marc Aurele is working on merging the driver into > current XFree86 tree. He is making a lot of changes (in his codebase) and > it would be useful to take a look at his work before doing something like > this. Is this code available for checkout from cvs, or has Marc not committed anything yet? [snip] > > Vladimir Dergachev > > > > > R C > > -- > > Mr. Baggins... I find your lack of sunglasses... disturbing. > > > > _______________________________________________ > > Gatos-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/gatos-devel > > > > > _______________________________________________ > Gatos-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/gatos-devel > -- Leif Delgass http://www.retinalburn.net _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
