View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001335 | UBoot | Display | public | 2012-09-26 16:05 | 2012-09-26 16:05 |
| Reporter | Keller | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | assigned | Resolution | open | ||
| Product Version | armStoneA8-V1.1 | ||||
| Target Version | fss5pv210-V2.1 | ||||
| Summary | 0001335: Add generic framebuffer support | ||||
| Description | In the PicoMOD6/PicoCOM3 version there is already support for framebuffers for LCD devices, including overlay windows. Some simple drawing commands can draw graphic primitives (line, rectangle, circle, bitmap, text) to these LCD windows. On newer boards there are also other devices that make use of framebuffers, for example HDMI/TV outputs, cameras, OpenGL textures, video encoder/decoder buffers, image rotators, scalers, converters, etc. Therefore the current LCD-only framebuffer support should be converted to a more generic framebuffer support that can be used by all these framebuffer devices. | ||||
| Additional Information | The idea is that a framebuffer is a continuous, DMA capable memory region. We also assign a width and height, and a pixel format to this memory. A pixel row consists of horizontally arranged pixels, probably padded by unused space at the end of the row due to alignment reasons. The framebuffer in turn consists of vertically aligned pixel rows, probably padded by unused space at the end of the buffer due to alignment reasons. Then a specific device can be associated with the framebuffer. This device either generates data for the framebuffer (e.g. a camera) or it uses data from the framebuffer (e.g. a window of a display device). The device can either address the full framebuffer, or only a rectangular region of it (cropping region). If the framebuffer is larger than the cropping region and the specific device hardware supports it, this region can even be moved (panned) around. A framebuffer can be associated to different devices at the same time, as long as the pixel format and data alignment is supported by all the devices. For example a framebuffer can be target of a camera imput, used as overlay window 3 on LCD, and used as graphic layer 1 of HDMI output, all at the same time. Then we would see the camera input on the LCD (probably in the top left corner) and on the HDMI output (probably in the bottom right corner). The devices can also be switched from one framebuffer to another framebuffer, for example to support some double buffering. This also means that framebuffers may not associated with any hardware device. Remark: In this new concept, drawing only accesses the framebuffers. It is completely independent of any device hardware. | ||||
| Forum Link | |||||
