Page MenuHomeFreeBSD

Add terasic_mtl vt(4) framebuffer driver
ClosedPublic

Authored by emaste on Aug 8 2014, 3:55 PM.
Tags
None
Referenced Files
Unknown Object (File)
Nov 12 2023, 12:33 AM
Unknown Object (File)
Nov 11 2023, 1:35 PM
Unknown Object (File)
Nov 10 2023, 9:12 AM
Unknown Object (File)
Nov 8 2023, 9:14 AM
Unknown Object (File)
Nov 7 2023, 4:59 AM
Unknown Object (File)
Nov 4 2023, 4:11 AM
Unknown Object (File)
Oct 10 2023, 11:29 PM
Unknown Object (File)
Oct 10 2023, 12:35 PM
Subscribers
None

Details

Reviewers
ray
emaste
Summary

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

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

emaste retitled this revision from to Add terasic_mtl vt(4) framebuffer driver.
emaste updated this object.
emaste edited the test plan for this revision. (Show Details)
emaste added a reviewer: ray.
emaste added inline comments.
sys/dev/terasic/mtl/terasic_mtl_vt.c
108

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?

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

sys/dev/terasic/mtl/terasic_mtl_vt.c
70

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

108

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

sys/dev/terasic/mtl/terasic_mtl_vt.c
108

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 edited edge metadata.

Improve terasic_mtl_vt fdt parsing

  • Use OF_getencprop to avoid need for explicit endian handling (submitted by ray@freebsd.org)
  • Check for expected length and correct pointer type

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

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 added a reviewer: emaste.

Was committed in rS274823

This revision is now accepted and ready to land.Apr 22 2015, 7:35 PM