Single genfb or multiple fbs?

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 <jmmv84gmail.com>

I'd say to warrant it's own driver the driver has to at
least do something
special about the hardware - like use a blitter.

If all we are talking about are tons of special cases during
attach or
when switching modes I'd leave it as a single generic
driver.

But obviously there is a broad range for personal taste
here.

Martin

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)

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