Add terasic_mtl vt(4) framebuffer driver

[emaste]

Summary

terasic_mtl can be built with syscons(4) and vt(4) attachments, selected at compile time.

[emaste]

sys/dev/terasic/mtl/terasic_mtl_vt.c

109

The display is RGBx instead of xRGB.

Somehow I'll have to pass this information to xf86-video-scfb -- should we hoist the masks and offsets info struct fb_info?

[ray]

Patch looks good to me (only OF_getpropenc to look).

sys/dev/terasic/mtl/terasic_mtl_vt.c

71

Please look for possibility to use OF_getpropenc here, to not manually swap value.

109

Yeah, looks like we have to add optional ioctl which will return set of masks and offsets.

[emaste]

sys/dev/terasic/mtl/terasic_mtl_vt.c

109

Actually it's an endianness issue, which I did not notice until r269783 went in
http://svnweb.freebsd.org/changeset/base/269783

It's actually an ARGB little-endian framebuffer, or BGRA when viewed as big-endian data.

canonical source:

inline u_int32_t
fb_colour(int r, int g, int b)
{
  return ((r&0xff)<<8) | ((g&0xff)<<16) | ((b&0xff)<<24);
}

[emaste]

Improve terasic_mtl_vt fdt parsing

• Use OF_getencprop to avoid need for explicit endian handling (submitted by [e-mail])
• Check for expected length and correct pointer type

[emaste]

I did not actually revert the dts change - just a phabricator misuse.

[ray]

In D568#5, @emaste wrote:

Actually it's an endianness issue, which I did not notice until r269783 went in
http://svnweb.freebsd.org/changeset/base/269783

It's actually an ARGB little-endian framebuffer, or BGRA when viewed as big-endian data.

canonical source:

inline u_int32_t
fb_colour(int r, int g, int b)
{
  return ((r&0xff)<<8) | ((g&0xff)<<16) | ((b&0xff)<<24);
}

Always better to pack into required format, instead of pack into standard one and then swap it. Fill FB is heavy operation, we should not do steps that can be omitted.

[emaste]

Was committed in rS274823