A packed pixel format stores the component fields or index for each pixel together in a single image plane, with successive pixels following one another in that plane. A planar pixel format instead separates component or bit planes. Packed does not necessarily mean one byte per pixel or the absence of row padding: the Linux frame-buffer API explicitly permits end-of-row padding in its packed storage type.[ref]
The Frame Buffer Device API in the Linux Kernel documentation. §2, FB_TYPE_PACKED_PIXELS, FB_TYPE_PLANES and line_length
Consider an original 16-bit encoding with 4-bit fields in the order red, green, blue, alpha from most significant to least significant:The bit fields for give . Extracting components by integer arithmetic givesThe same extraction can be implemented with bitwise operations. Declaring endianness is a separate step: this word occupies successive bytes
C5 A3 in little-endian storage, and A3 C5 in big-endian storage. A component order in a word does not by itself specify the byte sequence.If a row contains 100 of these two-byte pixels, its active data occupy 200 bytes. With framebuffer stride 208 bytes, the next row begins 208 bytes later, leaving eight padding bytes. A pixel-buffer consumer therefore needs the exact pixel format, dimensions and framebuffer stride, as well as any alpha channel convention and color space.
New to topics? Read the docs here!