Hi guys! Please tell me what the real status is on this then! -from the driver's viewpoint, it should just be sent the correct colorindex along with the magic color! There's no denying that. -if however, from R5, Dano, Zeta, and Haiku app_server viewpoint, it's _quaranteed_ that the correct index is _always_ 255, then you are (upto now, implicitly) stating that all driver authors that need to feed the colorindex into the hardware for B_CMAP8, should _in fact_ hardcode it to be index 255. ---please confirm this.. --- Then, if you indeed confirm this, and you in fact already did (read your mail below), please fix Haiku's app_server to send the color that's sitting in index 255 over to the driver as magic color! There couldn't be a simpler fix for overlay in CMAP8 for numerous drivers.... Thanks! Rudolf. > Stephan Assmus <superstippi@xxxxxx> wrote: > > > 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). > > I don't get it. The magic "white" entry is always 255. It is never > > going to > > change, or any existing B_CMAP8 bitmaps would break. Or could a > > different > > overlay key color be used in B_CMAP8 screen mode? > > Theoretically, yes. But I think we should just stick with it, anyway > :) > > Bye, > Axel. > > >