[haiku-appserver] overlay in CMAP8 - change needed

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 09 May 2006 10:02:32 +0200 CEST

Good morning from Holland :)

Come to think of it, you're absolutely right. Here is what I found:
-nVidia, Matrox and Neomagic all need the color that's fetched from the 
palette. This means you definately need to make sure the driver gets 
this color, as it's exactly in the palette.
-VIA, and (as you now said) Intel need the palette index instead! 
Apparantly this is a 'new' way of doing things, which didn't exist in 
the Be days.

This means that we need to update the info sent to the card one day: we 
need to send _both_ the index and actual magic color!

As a workaround (maybe you don't even need to call it that if we find a 
suitable magic color) you must make sure we now have only _one_ index 
that matches the exact magic color: in the VIA driver I let the overlay 
code search for the index in the palette that matches the send magic 
color. Unfortunately there are two entries that match that color, and 
only one is the correct one.
If there would be just one matching entry, this would work OK (but 
still is ugly I think).

---

Your remark about that index triggered the memory in the back of my 
head.. ;-)

I hope I didn't miss anything here. It would be cool if it would be 
possible to send both the index and magic color somehow, without 
breaking R5/Zeta compatibility. How about sending it in the alpha 
field? (sorry for even suggesting.. ;-)

Bye!

Rudolf.


------------

> > > That's simple, the overlay color is currently drawn on screen - 
> > > but 
> > > that one doesn't translate to the magic overlay color yet for 
> > > B_CMAP8. 
> > > I think we'd need to handle this case specifically.
> > The palette needs an entry that carries the magic color fed to the 
> > driver as well. It's a normal 24bit entry as far as the driver is 
> > concerned: a 'copy' of RGB32 mode. (since the hardware looks at the 
> > DAC 
> > outputs, not the framebuffer, for the keying mechanism.)
> 
> Actually, I think it's a bit more complicated. The overlay color in 
> BeOS is just white (255, 255, 255, same as the magic transparency 
> value) - at index 255 (not the other white at some earlier index).
> I don't know how it's done on other graphics cards, but the Intel 
> Extreme 2 needs the actual index, not the color on screen, there, the 
> white at index 255 is really different from the other one (for 
> overlay).
> Under Haiku, I cannot specify this yet, AFAICT (or can I?).
> 
> Bye,
>    Axel.
> 
> 
> 


Other related posts: