drm_hwcomposer: fix headings formatting

1 files changed, 4 insertions, 3 deletions

diff --git a/Projects/drm_hwcomposer/Overview.mdwn b/Projects/drm_hwcomposer/Overview.mdwn
index ed8b6c98..6ee2f595 100644
--- a/Projects/drm_hwcomposer/Overview.mdwn
+++ b/Projects/drm_hwcomposer/Overview.mdwn
@@ -5,20 +5,21 @@ The drm_hwcomposer (AKA drm_hwc, DRM HWComposer, DRM Hardware Composer, drm_hwc,
 
 A bit of history: drm_hwcomposer was started early 2015 by Sean Paul to allow Android to run on the Pixel C. Instead of using a HWC supplied by the vendor for their SoC like most HWCs, it was decided that it would be better to build one that would work on top of DRM. In theory, this would have made a HWC that would work on any Chrome OS device because they use DRM for display. The drm_hwcomposer project started life as a C library, then C++ because the HWC interface is rather object oriented, and finally to C++11 because it has makes resource management a bit more consistent and easy.
 At present day, drm_hwcomposer is being change to support the second HWC interface (HWC2). This document doesn't cover those changes, as they are still very very work in progress (WIP).
-Life of a Frame
+
+## Life of a Frame
 
 Regardless of HWC implementation, frames consist of a two calls into the HWC module (hwc_composer_device_1): 
 
     int (*prepare)(struct hwc_composer_device_1 *dev, size_t numDisplays, hwc_display_contents_1_t** displays);
     int (*set)(struct hwc_composer_device_1 *dev, size_t numDisplays, hwc_display_contents_1_t** displays);
 
-## Prepare
+### Prepare
 
 The hwc_display_contents_1 structure contains the contents of one display in the form of an array of layers (hwc_layer_1), a retire fence (int, file descriptor), and some flags. Each layer has a type, flags, and some layer type specific fields. The purpose of the prepare call of the HWC interface is to negotiate the types of each layer. For instance, a layer may get passed to prepare with type HWC_FRAMEBUFFER, indicating that SF expects to composite that layer down into the framebuffer target, but HWC can decide to set the type to HWC_OVERLAY indicating that HWC will handle putting that layer onto the screen. Traditionally that means the layer will be put into a real hardware overlay plane.
 
 In the case of drm_hwcomposer, we lie and say every layer is HWC_OVERLAY regardless of if we have enough overlays for them all. We do this because SurfaceFlinger's GLES fallback wasn't well optimized and we thought we could do better. However, there are layers we can't composite ever, like the ones flagged HWC_SKIP_LAYER. A non-obvious consequence of this is that HWC composite any layers sandwiched between HWC_SKIP_LAYER flagged layers, as it's impossible to perform blending properly when the skip layers end up in the framebuffer target.
 
-## Set
+### Set
 
 On set, the HWC is expected to display all the layers that were marked NOT marked HWC_FRAMEBUFFER. Those layers will have all be squashed into the layer with type HWC_FRAMEBUFFER_TARGET. Traditionally the HWC has done things in a somewhat synchronous manner in that after set returns, SF wouldn't have to maintain any references passed into set. SF only promises not to reuse any buffers passed in until the buffer's corresponding release fence is triggered. In fact, SF seems to cheat a little bit and starts recycling buffers after about a second, but more on that later.