The Graphics and Display and Android microconferences share a common slot that focuses on graphics topics related to Android (or Android topics related to graphics).
The schedule of the 2013 Android and Graphics slot is as follows. Note presentation slides can be found on the Plumbers page by following the links to the abstracts:
| 9:00 - 9:05 | Intro & Who's who | |
| 9:05 - 9:45 | Dma-buf fences vs Android sync driver | John Stultz |
| 9:45 - 10:00 | The Atomic Display Framework | John Stultz, Greg Hackmann |
| 10:00 - 11:30 | Tea Break | |
| 10:30 - 10:55 | KMS HWComposer issues and other KMS Extentions | John Stultz, Greg Hackmann |
| 10:55 - 11:30 | ION / dma-buf allocators / Constraint solving | John Stultz |
| 11:30 - 11:45 | Phasing-out of the FBDEV API | John Stultz |
| 11:45 - 12:00 | Overflow buffer | John Stultz |
To let the attendees get familiar with the problems beforehand, here are shorts summaries of the topics that will be discussed.
Display devices traditionally read frames from memory. Some devices, however, include deep pipelines from video capture, video processing or video codec devices to the display device. The video capture, processing or codec devices can usually write their output to memory in addition to pipelining it to the display device, and are thus handled by separate standalone drivers. A KMS API extension is required to select a non memory-backed source, and a kernel framework extension is required to make the device drivers aware of each other. The media controller API could be used here to show the relationship between devices to userspace application.
Some display devices can write composited frames back to memory instead of or in addition to scaning them out to encoders. The KMS API doesn't support this feature. As write-back is similar to video capture from an application point of view, a possible solution would be to use the V4L2 API for this purpose.
The KMS API supports composers through CRTC planes. A CRTC can compose several planes and scan out the result. Chained composers are not supported, the output of a composer can't be used as an input for a CRTC. Chained composers could be considered as a composer acting as a non memory-backed pipeline source for the downstream CRTC. This would however create two devices unrelated from a userspace point of view. Other solutions should thus be considered as well.
The KMS pipeline model supports multiple encoders connected to one CRTC, and multiple connectors connected to one encoder. However, more complex pipeline topologies (such as an encoder splitting a frame to two different connectors, or two CRTCs connected to the same encoder to driver higher resolution displays). Those use cases exist but are not mainstream yet. Supporting them would require API extensions.
For historical reasons KMS requires a main frame buffer to be associated with a CRTC and composes planes on top of that frame buffer. The frame buffer, which can be considered as a root plane, is required to span the whole display. Many display devices don't have such a requirement: they don't differentiate between the root plane and the other planes, and can fill the display with a background color on areas not covered by any plane. We need an API to support this.
Patch Discusion thread: http://thread.gmane.org/gmane.comp.video.dri.devel/90761
KMS HWComposer talk: http://www.youtube.com/watch?v=AuoFABKS_Dk
Android Sync patch thread: http://lists.linaro.org/pipermail/linaro-mm-sig/2013-February/003078.html
dma-buf fences patch: http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=c9453d5f549a4067af1c1a7dcfd990a08b6662af
dmabuf-sync patch thread: http://lists.freedesktop.org/archives/dri-devel/2013-August/043402.html
LWN Discussion Primer: https://lwn.net/Articles/565469/
The session uses an etherpad for live notes.
Links to IRC back-channels and other resources will be available here.
Jesse Barker jesse.barker@arm.com, John Stultz john.stultz@linaro.org and Laurent Pinchart laurent.pinchart@ideasonboard.com.