nanogui: Thread: DrawPixel

I'm curious how a pixel gets drawn if I compile microwindows with linux framebuffer support.  The scr_fb.c driver doesn't appear to fill in the DrawPixel function in it's scrdev struct.  But the engine appears to call the DrawPixel function from the scrdev struct.  So what function is it actually calling?

The reason I'm asking is that I'm attempting to interface with a Hantronix lcd panel that appears to require lots of nibble-flipping.  We got the kernel to write to it correctly, and are trying to get microwindows to do the same.

Thanks,

Dave Muse
####@####.####

Hi,

scr_fb.c is the generic framebuffer driver, but DrawImage is part
of the pixel-format-specific subdriver.  See genmem.c for the code
which initializes this field, based on the subdriver chosen by fb.c.
The actual implementation of DrawPixel is in fblin*.c (e.g fblin4.c
for 4bpp, fblin16.c for 16bpp).

Kind regards,

Jon Foster
--






I'm curious how a pixel gets drawn if I compile microwindows with linux framebuffer support.  The scr_fb.c driver doesn't appear to fill in the DrawPixel function in it's scrdev struct.  But the engine appears to call the DrawPixel function from the
scrdev struct.  So what function is it actually calling?

The reason I'm asking is that I'm attempting to interface with a Hantronix lcd panel that appears to require lots of nibble-flipping.  We got the kernel to write to it correctly, and are trying to get microwindows to do the same.

Thanks,

Dave Muse
####@####.####

---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####

: I'm curious how a pixel gets drawn if I compile microwindows with linux
framebuffer support.  The scr_fb.c driver doesn't appear to fill in the
DrawPixel function in it's scrdev struct.  But the engine appears to call
the DrawPixel function from the scrdev struct.  So what function is it
actually calling?

The scr_fb.c driver selects a "subdriver" using select_fb_subdriver
that fills in the PSD entry points with the actual functions to
draw, based on the framebuffer bits per pixel, etc.  These
subdrivers are named fblin*.c; for instance, fblin32.c is the
subdriver for 32bpp.




:
: The reason I'm asking is that I'm attempting to interface with a Hantronix
lcd panel that appears to require lots of nibble-flipping.  We got the
kernel to write to it correctly, and are trying to get microwindows to do
the same.

Take a look at the fblin4*.c, I think I've got a couple that
write nibbles each way.  Let me know if you need more help.

Regards,

Greg



:
: Thanks,
:
: Dave Muse
: ####@####.####

On Fri, Oct 18, 2002 at 01:44:00PM -0400, David Muse wrote:
> I'm curious how a pixel gets drawn if I compile microwindows with
> linux framebuffer support.  The scr_fb.c driver doesn't appear to fill
> in the DrawPixel function in it's scrdev struct.  But the engine
> appears to call the DrawPixel function from the scrdev struct.  So
> what function is it actually calling?

as you've observed, the core engine routines call the functions listed
in the screen's PSD structure, so your question becomes "how do the
routines get attached to the PSD structure, and which routines are
getting attached?"

for a generic framebuffer of [x] bitdepth, the routines are listed in a
SUBDRIVER structure named fblinear[x].  IE for 4bpp, the subdriver is
fblinear4; for 8bpp, fblinear8, etc.  selection of the subdriver can be
done manually, or performed by select_fb_subdriver().  the subdriver is
then attached to your device's PSD structure by set_subdriver().  all of
this occurs in your device's open() function.

walk through (either by debugger or editor and eyeball) linux'
fb_open(), paying close attention to select_fb_subdriver() and
set_subdriver() and you will find what you are looking for.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  ####@####.####