On Tue, Nov 15, 2005 at 09:17:14PM +0100, Radek Kujawa wrote:
> 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!

Linux has a framebuffer abstraction which is quite widely used and has
many drivers (I used it on a m68k Mac for example, it provided a color
framebuffer to XFree86 which ran on it without any hardware-specific
driver).

There were also proposals to implement it under NetBSD, see

http://mail-index.netbsd.org/tech-x11/2002/09/13/0000.html
http://mail-index.netbsd.org/tech-kern/2002/09/25/0018.html

Having separate device node (/dev/fb*) has the advantage that mmap() and
read()/write() can be consistent and you can write to framebuffer using
shell utilities or take a screenshot.

Pavel Cahyna