Hi,

I'm looking at preserving the firmware console across the KMS handoff. Unlike the other Sun framebuffer drivers, we have KMS to account for.

Allocating a new framebuffer through the existing kernel and DRM console code still seems the simplest and most maintainable approach.

To preserve the firmware framebuffer instead, I think we need to:

- Select the DRM format from the firmware depth, as Mark suggested.
- Keep its address and layout consistent with DRM, and protect its memory from reuse.
- Retain the console state so output continues normally, although replaying the boot messages might be simpler.
- Restore the palette when returning from X or switching consoles.
- Handle any firmware configuration we can't reuse, though I don't have a concrete example in mind.

Mark's original implementation handled some of this. The question is how much adaptation is worthwhile. My concern is the dependency between firmware state and DRM internals: it has already broken, and there are few people testing this hardware. Over the last five years, I've seen only a few other bug reports alongside my own testing.

There's definitely something to be said for an eight-bit console framebuffer instead of a 32-bit one. At 1920x1080, that saves about 6 MiB of VRAM, which isn't insignificant on these cards.

Ted