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)