Re: mga_vid directions (was: insmod error)

On Tue, 2005-03-08 at 21:41 +0100, Attila Kinali wrote:
> Well it is somewhat official. It's just that i am not sure
> what to do in future. I'd like to get mga_vid into the
> kernel, but that needs a lot of clean up and i dont have
> currently the time for it. (Note that my 1st priority 
> DMA code is also still missing).

I've had a look at your version of the driver, and it looks clean and
compact to me. I can't test the actual driver right now as I don't have
my matrox card handy (I'm at a vacation address). To have this included
in the kernel (though I honestly doubt the kernel devs will accept such
an ugly hack :-) I think a few things need to be done:

- Documentation/CodingStyle
- SysFS support needs to be put back in
- udev support
- Makefile
- Kernel configuration

All of which aren't too hard to do. The first item is just cosmetic, but
to get anything included into the kernel it's very important. I'm not a
great C coder, but isn't a lot of the stuff which now is in mga_vid.c
supposed to reside in the mga_vid.h file? I mean the definitions,
macros, and all that...In other words, a good cosmetic cleanup of the
code and comments (comment blocks should be enclosed by /* ... */, for
instance) would be welcome.

The second item was already there in a crude form, but you seem to have
removed it (even though it worked fine). I noticed most (if not all) the
#ifdef's and such have disappeared, which is a good thing. That's
probably why sysfs also got axed. Though not a great priority (nor do I
think it's actually a requirement for drivers), sysfs can be used to
provide information about the hardware. udev has about the same status,
I don't think it's a requirement for drivers (yet), but still it would
be nice to have it included.

The last two items are more "kernel integration" work. I.e. stuff which
will make the driver be part of the kernel.

I'd be willing to pick some of this stuff as they're likely small
changes and not too specific to the hardware (which I really know
nothing about...). Thoughts?

> In the mean time i'd like to get the code into the
> cvs, but we have the nice problem that the kernel
> changes it API like people their underwear. To provide
> backwards compatibility for older kernel versions 
> (2 or 3 minors back) is a must which cannot be easily
> done with cvs, that's why i develop it in my own
> svn repo and put snapshots up.

Yeah, it's quite annoying to have to follow the whims of the kernel
developers. And it doesn't get easier either, now they want to go to 4
digit kernel versioning. I wonder what they've been smoking lately. Oh
well...the choice is to keep seperate versions around, or again start
using #if's to cater to small changes. Not a very appealing solution. I
don't have any ideas on how to deal with such things. Maybe keeping it
in your SVN and then pushing the latest snapshot to mplayer CVS would be
acceptable?

Anyway, bedtime for bonzo.

Ferdinand O. Tempel