OK, we keep getting a little closer on this … 
We’re using the banshee driver programatically (other drivers as well) to
display stuff on a display, and have found that vga, vesa, rage all work
pretty much as expected, but the banshee is causing us problems. We create
a surface to draw on, and then draw into directly; ie, we are setting byte
values in the surface memory. This works great for all the other drivers,
but for the banshee it’s actually drawing in greyscale, as opposed to color.
The sample we have draws a bunch of stuff in color.
I just can’t rationalize this in my head. It’s like the palette is screwed,
but I’ve checked, and it doesn’t seem to be. Note we calling the mode set
palette as opposed to misc, since it has a mode version.
Does this ring a bell with anyone?
We need to do a backing store version of our program anyway, so will try
this when we get it limping (using core->blit2(), for instance). I can see
colors when I run bench, so I know the adapter is working (runs Photon fine
as well), and the main difference between our code and bench is that we
touch the display memory directly whereas bench uses APIs to update the
display …
–
Patrick Mueller <patrick_mueller@oti.com> wrote:
OK, we keep getting a little closer on this … >
We’re using the banshee driver programatically (other drivers as well) to
display stuff on a display, and have found that vga, vesa, rage all work
pretty much as expected, but the banshee is causing us problems. We create
a surface to draw on, and then draw into directly; ie, we are setting byte
values in the surface memory. This works great for all the other drivers,
but for the banshee it’s actually drawing in greyscale, as opposed to color.
The sample we have draws a bunch of stuff in color.
I just can’t rationalize this in my head. It’s like the palette is screwed,
but I’ve checked, and it doesn’t seem to be. Note we calling the mode set
palette as opposed to misc, since it has a mode version.
Does this ring a bell with anyone?
No… I don’t have any ideas really, any chance you could post the
relevant parts of the code?
Dave
We’ve actually built this as a library, so there’s no small sample I can
give you. When I get a round tuit, I’ll whip one up and post it …
Should I be able to set bytes directly in the surface for the banshee? I
assume for some display adapters you can’t do this, but was hoping you could
for banshee. Again, we’ll be doing a backing store version of this later
anyway, and use blit2() to copy the image to the real surface …
–
“David Donohoe” <ddonohoe@qnx.com> wrote in message
news:9mgf4s$sal$1@nntp.qnx.com…
Patrick Mueller <> patrick_mueller@oti.com> > wrote:
OK, we keep getting a little closer on this … >
We’re using the banshee driver programatically (other drivers as well)
to
display stuff on a display, and have found that vga, vesa, rage all work
pretty much as expected, but the banshee is causing us problems. We
create
a surface to draw on, and then draw into directly; ie, we are setting
byte
values in the surface memory. This works great for all the other
drivers,
but for the banshee it’s actually drawing in greyscale, as opposed to
color.
The sample we have draws a bunch of stuff in color.
I just can’t rationalize this in my head. It’s like the palette is
screwed,
but I’ve checked, and it doesn’t seem to be. Note we calling the mode
set
palette as opposed to misc, since it has a mode version.
Does this ring a bell with anyone?
No… I don’t have any ideas really, any chance you could post the
relevant parts of the code?
Dave
BTW, found my problem. I was sending the mode value from the mode_info as
the mode, instead of the value from the mode_list. Works for non-generic
mode, since the values are the same, but the mode value in the mode_info
field appears to be random garbage for Banshee …
–
“Patrick Mueller” <patrick_mueller@oti.com> wrote in message
news:9mgom9$4tk$1@nntp.qnx.com…
We’ve actually built this as a library, so there’s no small sample I can
give you. When I get a round tuit, I’ll whip one up and post it …
Should I be able to set bytes directly in the surface for the banshee? I
assume for some display adapters you can’t do this, but was hoping you
could
for banshee. Again, we’ll be doing a backing store version of this later
anyway, and use blit2() to copy the image to the real surface …
–
“David Donohoe” <> ddonohoe@qnx.com> > wrote in message
news:9mgf4s$sal$> 1@nntp.qnx.com> …
Patrick Mueller <> patrick_mueller@oti.com> > wrote:
OK, we keep getting a little closer on this … >
We’re using the banshee driver programatically (other drivers as well)
to
display stuff on a display, and have found that vga, vesa, rage all
work
pretty much as expected, but the banshee is causing us problems. We
create
a surface to draw on, and then draw into directly; ie, we are setting
byte
values in the surface memory. This works great for all the other
drivers,
but for the banshee it’s actually drawing in greyscale, as opposed to
color.
The sample we have draws a bunch of stuff in color.
I just can’t rationalize this in my head. It’s like the palette is
screwed,
but I’ve checked, and it doesn’t seem to be. Note we calling the mode
set
palette as opposed to misc, since it has a mode version.
Does this ring a bell with anyone?
No… I don’t have any ideas really, any chance you could post the
relevant parts of the code?
Dave