Hello,

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.

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.  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).

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.

    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.

    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.

I see that 2) has some advantages over 1).  It allows to build  
smaller kernels by selecting only the fb driver that one wants and  
keeps everything more modular.  Furthermore, specific *fb drivers  
could be rewritten in the future to not use genfb, if they needed to  
do so.

However, if not handled correctly, 2) can lead to a lot of code  
duplication among the *fb drivers.  But I guess we can avoid that :-)

I'm currently in favour of 2.  Anyone thinks that 1 could be better?

Thank you,

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>