Hi,
On Sun, 13 Nov 2005, Michael wrote:
> You can. Wscons is more about terminal emulation - there's on way to
> access a framebuffer without a (virtual) console defined on it, you get
> lots of weird problems with more than one wsdisplay.

I went through available docs about wsdisplay, read some drivers source
code. Now I'm under impression that it's impossible to write truely
portable program using wsdisplay. There are just too many inconsistencies
between implementations of wsdisplay across different platforms. I think
I don't need to mention our sparc64-specific mmap problem...

We're using world's most portable OS, so we should design portable
programming interfaces too :). The question is, how we're gonna fix it?

I see three options now:

- Hack around wsdisplay, add ioctl(s) returning main framebuffer offset
and format. Don't implement memory views. Remain as simple as possible.
Wsdisplay is brain-dead anyway, so try no to break it more :/.

- Extend /dev/fb functionality and port it to other platforms/drivers.
This would allow us to write better views support and fb interface is
generaly better suited to draw more than terminal. Anyway source
code looks better than wsdisplay, I couldn't test it because I don't have
any supported hardware. Thanks to der Mouse for writing short
introduction to sparc framebuffers (maybe you can put your notes
somewhere on the web?) :).

- Design something entirely new - _portable_ interface dedicated
to drawing graphics, that could coexist with wscons/fb.

Any comments/ideas are apreciated!

BTW. This topic is not related only to sparc64 (anymore). Maybe we should
post to other list now?

Radek