I know it's shunned upon, but since you wanted everybody's opinion, I
agree with what hauke said. Having a 'master' module (genfb) and
several smaller(?) ones for the specific hardware. Makes sense to me,
and will easily get rid of potential spaghetti code.

On 8/31/07, Hauke Fath <hauke@espresso.rhein-neckar.de> wrote:
> At 14:07 Uhr +0200 31.8.2007, Julio M. Merino Vidal wrote:
> >At the moment, the mac68k kernels have two graphics drivers: intvid
> >and macvid.  intvid handles all on-board video cards and macvid
> >handles all NuBus ones.
> >
> >Each of these drivers has a lot of special-cases in the match and
> >attach routines to test for the cards they support.  The drivers are
> >very simple and, basically, this special-cased code is very short and
> >does a similar thing in all cases.  However I'm wondering if this is
> >considered a good "design" as regards NetBSD drivers.
>
> Well, from a cursory look through obio/grf_obio.c and nubus/grf_nubus.c
> what the code does is identify the video hardware, by looking at the
> machine id for intvid, and the Nubus ROM DRHW id for macvid. Then, it goes
> on to disable the video interrupt, which is hw specific. And that's about
> it. No support for palette management, no support for HW acceleration -
> most video adapters are plain jane framebuffers, anyway.
>
> So, as it is now, there's no point in splitting that up any further.
>
> >I have added a single generic genfb driver that can attach to both
> >obio and nubus, and thus replaces (will replace, once it completely
> >works an is committed) intvid and macvid.  The thing is that doing so
> >keeps all these special-cases in the driver.
>
> Right now, there are _two_ special cases: intvid code looks at the machine
> id and hardcodes frame buffer location and size, as well as the interrupt
> disabler. macvid code uses the Nubus ROM information to select the proper
> interrupt disabler. Lumping the two together sounds messy, but I'd have to
> see the code.  ;)
>
> >And following this
> >approach, I need to add even more special-case code to deal with
> >palette registers and probably other features in the future (but I
> >won't touch that yet).
>
> Once you get around to support more video features (palette changes, or
> even switch resolution or depth), this gets a bit messy, yes.
>
> But the thing is - supporting that stuff is hard. Remember, this is not a
> peecee. Since the common, standard interface was the Apple video driver
> API, and not the hardware, each and every adapter will be different.
> Manufacturers have gone out of business long before the Internet Age, and
> what docs there were are in landfills now. That's why I am not too
> optimistic about seeing a flood of video devices' features supported any
> time soon.
>
> >So, basically, we have two approaches to add the *fb devices to
> >mac68k, and I don't really know which is preferred:
> >
> >1) Do as said above: have a single genfb that handles all cards.
> >    The card-specific code is rather short for now, but has the
> >    potential to grow.
> >
> >2) Have a *fb driver for each card.  We'd have a genfb that attaches
> >    to everything not supported by other *fb drivers until we have
> >    added all the *fb drivers necessary to cover all cases.  These
> >    *fb drivers could be based on the genfb code, but wouldn't have
> >    any special-cases in them.
>
> (2) sounds a bit like the i386 ide drivers? Maybe the genfb module could
> export the basic functionality - obtain size and location of the frame
> buffer, and a handler to disable the interrupt - as functions, in place of
> the loooong switch statements now. Those functions could then be used by
> the *fb drivers, too.
>
> >    This is what I've already done for the valkyrie card: remove all
> >    code that handles it from genfb and add a valkyriefb that has
> >    anything required to deal with it.
>
> Hm. I'd prefer genfb to support at least the present functionality (use the
> framebuffer, switch off the interrupts). You need to do the latter anyway
> for any video adapter in the machine, or it will crash.
>
> >    After a quick look at the old intvid, I see we'll need these
> >    drivers: valkyriefb, dafbfb, civicfb, rbvfb and genfb.  Add some
> >    more for what macvid handles now.
>
> As I said, macvid doesn't do anything beyond extracting information from
> the video card's Nubus ROM, and select the proper way to disable the video
> interrupt. _That's it._ Before there's actually code around to support
> anything else, I see little point in fragmenting that base functionality
> into two dozen tiny "drivers".
>
> My 0.02 EUR,
>
>         hauke
>
>
> --
> "It's never straight up and down"     (DEVO)
>
>
>


-- 
 -
  Michael Griffith