Subject: "Auxilary" device driver
To: None <tech-kern@netbsd.org>
From: Valeriy E. Ushakov <uwe@ptc.spbu.ru>
List: tech-kern
Date: 11/10/2003 22:25:18
I need to handle the following situation.  hpcsh port currently
attaches wsdisplay with this snippet of config:

hd64461video*	at hd64461if?
hpcfb*		at hd64461video?
wsdisplay*	at hpcfb?


hd64461video(4) is the driver for HD64461 LCD controller.  However,
there are few things related to wsdisplay support (backlight, turning
the screen on/off, etc), that are not handled by the HD64461 LCD
module per se and that I expect to change from one hpcsh model to
another.

So I need an "auxiliary" model-specific driver(s) (effectively, a
"screen" driver), that knows how to handle these things for particular
models and that the hd64461video can call into somehow (or that can
hook into hd64461video).

I'm thinking about:

hd64461video*	at hd64461if?
fooscr*		at hd64461video?	# screen in model "foo"
barscr*		at hd64461video?	# screen in model "bar"
...
hpcfb*		at hd64461video?
wsdisplay*	at hpcfb?

so, if there's a model-specific screen driver attached, hd64461video(4),
when it processes certain wsdisplay ioctls, can call screen driver
hooks to do model-specific things to, e.g., tweak the back light, etc.
If there's no screen driver for some hpcsh model, all will continue to
work as before.

An alternative approach is to interpose a new device between hcpfb(4)
and hd64461video(4) but I like that approach less b/c the auxiliary
functionality is related to few wsdisplay ioctls only, and so an extra
layer to proxy all of the hpcfb interface seems like an overkill.

Thoughts?

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen