On Mon, 6 Nov 2000, Michael Schmitz wrote: > > > Happens sometime, for reasons yet unknown. What seems to happen is > > > that the cursor changes color to black. Feel free to look up where > > > the cursor color gets set, and pepper the fbcon code with printk to find > > > where it goes wrong. > > > > However, the reason is known: the fbcon-* code draws the cursor by xor'ing > > the > > pixel values with a mask consisting of all 1's. This is not correct for > > directcolor modes (e.g. 16, 24 and 32 bpp on ATI Mach64), where the color of > > the cursor depends on what leftovers are present in the palette registers. > > Thanks for the correction :-) > > What should we initialize the palette registers to, in order to make the > cursor visible again?
Ah, that's another possible approach: initialize the palette such that inverting the pixel value inverts the color. But I see one problem with that: how to know you're in 16-color text console emulation mode or not? You don't want to mess with other palette entries when e.g. running X. > > The fix is to make fbcon-* use a mask in the 17th entry of > > display->dispsw_data[], and to make drivers fill in this field where > > appropriate. > > > > About one month ago, Takashi Oe said that he was willing to work on this... > > What would the proper mask to use be, and would it be the same for all > cards and bpp's? It would depend on the card and bpp. For atyfb (yes, I'm to lazy to calculate the hex values): - depth 15: (15 << 10) | (15 << 5) | 15 - depth 16 (not yet supported): (15 << 11) | (15 << 5) | 15 - depth 24: (15 << 16) | (15 << 8) | 15 - depth 32: (15 << 24) | (15 << 16) | (15 << 8) | 15 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds