Mode setting is a software operation that activates a display mode (screen resolution,color depth, and refresh rate) for a computer's display controller.
In kernel mode-setting (KMS), the display mode is set by the kernel. In user-space mode-setting (UMS), the display mode is set by auserlandprocess.
Kernel mode-setting is more flexible and allows displaying of an error in the case of afatal error in the kernel, even when using a user-space display server.
User-space mode setting would require superuser privileges for direct hardware access, so kernel-based mode setting shuns such requirement for the user-space graphics server.
Contents
Implementation
Microsoft Windows
Microsoft Windows versions that areNT-based use kernel mode setting. The kernel error display made possible by kernel mode setting is known as theBlue Screen of Death.
Linux
The Linux kernel got the prerequisite for kernel-based mode setting by accepting IntelGEM in version 2.6.28, released in December 2008.[1] This will be[needs update] replaced by Tungstens Graphics TTM (Translation Table Maps) memory manager which supports the GEM API.[2] TTM was developed for thefree and open-source drivers forRadeon and S3 Graphics graphic chipsets (see Free and open-source graphics device driver).[3] Support forIntel GMA graphic chipsets was accepted in version 2.6.29, released on March 23, 2009.[4] Support for pre-R600 ATI Radeon graphics cards was accepted in version 2.6.31, released on September 9, 2009.[5] Support for R600 and R700 was in development within DRM and was merged in version 2.6.32.[6] Support for Evergreen (R800) was merged in version 2.6.34. As Nvidia did not release all the needed documentation for its graphics chip, development proceeded under thenouveau project, which uses reverse engineering to build a working open-source driver for Nvidia cards. Nouveau was accepted in version 2.6.33 of the kernel, released on December 10, 2009. Kernel-based mode setting is not only supported by the nouveau driver, it is required.[7]Wayland compositors (e.g. Weston) and kmscon depend on kernel mode setting via ioctl.
FreeBSD
FreeBSD has support for both kernel-based mode setting and GEM for later generations of Intel GPUs (IronLake, SandyBridge, and IvyBridge) starting with version 9.1.[8]
NetBSD
NetBSD has support for kernel-based mode setting and accelerated graphics for Intel and Radeon devices. This implementation was introduced in version 7.0 by porting the Linux 3.15 DRM/KMS code.[9]
OpenBSD
OpenBSD has kernel-based mode setting support for Intel and Radeon GPUs. Starting with version 5.4 of OpenBSD, support for Intel GPUs is available. With the release of version 5.5, the implementation has been extended to add support for Radeon chipsets as well.
Alternatives
| This section needs to be updated. (August 2014) |
The following alternatives have been presented during the Linux Plumbers Conference 2013:
- It was suggested to split GEM and KMS.[10]
- Atomic Display Framework, by Google's Android-Team.[11][12]
- Common Display Framework.[13]
See also
References
- "Linux 2 6 28". Linux Kernel Newbies. Retrieved 2013-02-14.
- Larabel, Michael (2008-08-26)."A GEM-ified TTM Manager For Radeon". Phoronix. Retrieved2013-02-14.
- Larabel, Michael (2009-06-10)."TTM Memory Manager Gets Ready For Release". Phoronix. Retrieved2013-02-14.
- "Linux 2 6 29". Linux Kernel Newbies. Retrieved 2013-02-14.
- "Linux 2 6 31". Linux Kernel Newbies. 2009-09-09. Retrieved2013-02-14.
- Larabel, Michael (2009-09-30)."AMD R600/700 2D Performance: Open vs. Closed Drivers". Phoronix. Retrieved2013-02-14.
- "nouveau/ KernelModeSetting". freedesktop.org. 24 August 2013. Retrieved 2014-08-11.
- "FreeBSD 9.1-RELEASE Release Notes".FreeBSD Foundation. 30 December 2012.
- "Announcing NetBSD 7.0". The NetBSD Project. 25 September 2015. Retrieved 25 April 2016.
- http://www.linuxplumbersconf.org/2013/ocw/sessions/1107
- http://www.linuxplumbersconf.org/2013/ocw/proposals/1551
- http://www.linuxplumbersconf.org/2013/ocw/sessions/1467
- http://www.linuxplumbersconf.org/2013/ocw/sessions/1317
External links
- Mode Setting on the X.org wiki
- Intel Graphics Driver on the X.org wiki
- ATI Radeon driver on the X.org wiki
- Kernel Mode Setting on the Fedora project wiki
Atomic Display Framework
| From: | Greg Hackmann <ghackmann@google.com> | |
| To: | dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org | |
| Subject: | [RFC 0/4] Atomic Display Framework | |
| Date: | Wed, 28 Aug 2013 18:51:17 -0700 | |
| Message-ID: | <1377741081-30189-1-git-send-email-ghackmann@google.com> | |
| Cc: | konkers@google.com | |
| Archive-link: | Article |
Hi,
ADF is an experimental display framework that I designed after experimenting
with a KMS-based hardware composer for Android. ADF started as an
proof-of-concept implemented from scratch, so right now it's a separate
framework rather than a patchstack on top of KMS. If there's community
interest, moving forward I'd like to merge its functionality into KMS rather
than keep it as a separate thing.
I'm going to talk about ADF at the Android and Graphics session at Linux
Plumbers. The documentation's not done but I wanted to post these patches to
people a heads-up about ADF. If there's interest I can write up some more
formal documentation ahead of Plumbers.
I designed ADF to deal with some serious issues I had working with KMS:
1. The API is geared toward updating one object at a time. Android's
graphics stack needs the entire screen updated atomically to avoid tearing,
and on some SoCs to avoid wedging the display hardware. Rob Clark's atomic
modeset patchset worked, but copy/update/commit design meant the driver had
to keep a lot more internal state.
2. Some SoCs don't map well to KMS's CRTC + planes + encoders + connector
model. At the time I was dealing with hardware where the blending engines
didn't have their own framebuffer (they could only scan out constant colors
or mix the output of other blocks), and you needed to gang several mixers
together to drive high-res displays.
3. KMS doesn't support custom pixel formats, which a lot of newer SoCs use
internally to cut down on bandwidth between hardware blocks.
4. KMS doesn't have a way to exchange sync fences. As a hack I managed to
pass sync fences into the kernel as properties of the atomic pageflip, but
there was no good way to get them back out of the kernel without a side
channel.
ADF represents display devices as collections of overlay engines and
interfaces. Overlay engines (struct adf_overlay_engine) scan out images and
interfaces (struct adf_interface) display those images. Overlay engines and
interfaces can be connected in any n-to-n configuration that the hardware
supports.
Clients issue atomic updates to the screen by passing in a list of buffers
(struct adf_buffer) consisting of dma-buf handles, sync fences, and basic
metadata like format and size. If this involves composing multiple buffers,
clients include a block of custom data describing the actual composition
(scaling, z-order, blending, etc.) in a driver-specific format.
Drivers provide hooks to validate these custom data blocks and commit the new
configuration to hardware. ADF handles importing the dma-bufs and fences,
waiting on incoming sync fences before committing, advancing the display's
sync timeline, and releasing dma-bufs once they're removed from the screen.
ADF represents pixel formats using DRM-style fourccs, and automatically
sanity-checks buffer sizes when using one of the formats listed in
drm_fourcc.h. Drivers can support custom fourccs if they provide hooks to
validate buffers that use them.
ADF also provides driver hooks for modesetting, managing and reporting
hardware events like vsync, and changing DPMS state. These are documented in
struct adf_{obj,overlay_engine,interface,device}_ops, and are similar to the
equivalent DRM ops.
Greg Hackmann (3):
video: add atomic display framework
video: adf: add display core helper
video: adf: add memblock helper
Laurent Pinchart (1):
video: Add generic display entity core
drivers/video/Kconfig | 2 +
drivers/video/Makefile | 2 +
drivers/video/adf/Kconfig | 15 +
drivers/video/adf/Makefile | 14 +
drivers/video/adf/adf.c | 1013
++++++++++++++++++++++++++++++++++
drivers/video/adf/adf.h | 49 ++
drivers/video/adf/adf_client.c | 853 ++++++++++++++++++++++++++++
drivers/video/adf/adf_display.c | 123 +++++
drivers/video/adf/adf_fops.c | 982
++++++++++++++++++++++++++++++++
drivers/video/adf/adf_fops.h | 37 ++
drivers/video/adf/adf_fops32.c | 217 ++++++++
drivers/video/adf/adf_fops32.h | 78 +++
drivers/video/adf/adf_memblock.c | 150 +++++
drivers/video/adf/adf_sysfs.c | 291 ++++++++++
drivers/video/adf/adf_sysfs.h | 33 ++
drivers/video/adf/adf_trace.h | 93 ++++
drivers/video/display/Kconfig | 4 +
drivers/video/display/Makefile | 1 +
drivers/video/display/display-core.c | 362 ++++++++++++
include/video/adf.h | 743 +++++++++++++++++++++++++
include/video/adf_client.h | 61 ++
include/video/adf_display.h | 31 ++
include/video/adf_format.h | 282 ++++++++++
include/video/adf_memblock.h | 20 +
include/video/display.h | 150 +++++
25 files changed, 5606 insertions(+)
create mode 100644 drivers/video/adf/Kconfig
create mode 100644 drivers/video/adf/Makefile
create mode 100644 drivers/video/adf/adf.c
create mode 100644 drivers/video/adf/adf.h
create mode 100644 drivers/video/adf/adf_client.c
create mode 100644 drivers/video/adf/adf_display.c
create mode 100644 drivers/video/adf/adf_fops.c
create mode 100644 drivers/video/adf/adf_fops.h
create mode 100644 drivers/video/adf/adf_fops32.c
create mode 100644 drivers/video/adf/adf_fops32.h
create mode 100644 drivers/video/adf/adf_memblock.c
create mode 100644 drivers/video/adf/adf_sysfs.c
create mode 100644 drivers/video/adf/adf_sysfs.h
create mode 100644 drivers/video/adf/adf_trace.h
create mode 100644 drivers/video/display/Kconfig
create mode 100644 drivers/video/display/Makefile
create mode 100644 drivers/video/display/display-core.c
create mode 100644 include/video/adf.h
create mode 100644 include/video/adf_client.h
create mode 100644 include/video/adf_display.h
create mode 100644 include/video/adf_format.h
create mode 100644 include/video/adf_memblock.h
create mode 100644 include/video/display.h
--
1.8.0
KMS HWComposer issues, the Atomic Display Framework and other KMS Extentions
One Line Summary
Discussion around issues with a KMS based HWComposer, the Atomic Display Framework, and other KMS extentions
Abstract
Various folks have been looking at implementing a KMS based HWComposer, but there are a number of issues that need to be resolved. This will be a round-table discussion between Android developers and key upstream community members to discuss the limitations of KMS and possible solutions. Greg Hackmann will also discuss the Atomic Display Framework, which Android developers have recently created to try to work around the current limitations ofKMS.
Finally, we’ll have a brief discussion on other proposed KMS extentions:
- Non-memory-backed pipeline sources
- Memory write-back
- Chained composers
- Non-linear pipelines (multiple encoders, …)
- Root plane that doesn’t span the whole display
Speakers
-
Greg Hackmann
GoogleBiography
Greg Hackmann is a software engineer on the Android systems team at Google. Since joining Google in 2012, his work has focused on Linux kernel support for display hardware.
Greg earned a PhD in computer science from Washington University in St. Louis.
Sessions
John Stultz
Linaro.orgBiography
John Stultz has worked on x86 server enablement, Enterprise Realtime Linux, and now as a member of the Linaro.org effort. In the Linux community, he has worked mostly as maintainer of the timekeeping subsystem, but has also worked on stability and scalability issues with the PREEMPT_RT patch, and most recently has been working to upstream Android functionality into the mainline kernel.
Sessions
关于ADF(Atomic Display Framework)是Google新推出的一个关于Display驱动的框架。
首先上一张自己画的ADF的结构图
接下来就简单说一下这些文件的作用。
Driver：即使用ADF框架的custom编写的程序
adf_fops.c：负责与user space交互的一个文件，实现了一些方法(open release read poll等)
adf_fobs32.c：用于兼容32位的一个文件，具体实现会在掉用到adf_fops.c这个文件。
adf_fbdev.c：fb设备对外的接口类，负责与fb设备兼容。
adf.c：这是整个ADF模块的核心文件，会提供模块内部的各种服务，主要提供了消息机制、同步机制(fence)以及整体ADF的初始化工作。
adf_client.c：主要用于调用custom编写的驱动代码以及唤醒(wake up)等。相当于整个fromwork的消息最终出口。
adf_format.c：用于描述本启动支持哪些图像格式(RBG YUV以及具体的格式定义)。
adf_sysfs.c：与sysfs交互的一个文件。
adf_memblock.c：与内存管理的一个文件，实现了一些DMA的ops然后注册到DMA模块中，实现对内存的操作。
整体来说ADF模块还是比较简单的，其中比较重要的内容就是关于模块的消息通讯机制。
首先来看一个关于设置消息机制整体的一个流程图。
这个流程可能画的不太好，是三个流程嵌套在一起描述的。
从左边数地一个流程其实就是使用read方法在kernel中的实现，通过这个图可以看到这里有两个个意义
1.user mode 调用read时，会sleep，直到有event才会继续执行。
2.当kernel mode内产生任意一个消息都需要通知user space。
中间的那个流程其实是ADF消息通讯的主干，或者所示消息的产生者。
右边的那个时序是post时序。关于post时序首先简单介绍一下什么是post时序。
Post时序就是将需要显示的内容由user space 传递给 kernel space，然后等待一个特殊的信号过来后，送给显示屏显示（Display Conctrler）。
等待的这个信号其实就是屏幕刷新信号（vblank、vsync……）。
这条时序大概就是说当user space希望将一个图片刷新到屏幕上，首先将这个图片传给kernel space，然后在kernel中等待屏幕刷新信号（一般由timer触发），当检测到屏幕刷新信号后，将图片送给显示设备。
以上这三个时序基本介绍了在显示的时候针对消息最重要的三个时序。基于这三个时序在简单介绍一下post时序，首先贴出一个流程图：
这个流程与上一个图中最右边的流程一起看，就能看明白了，具体的说明感觉图上已经画的挺明白了，如果不明白的在问我吧。
在这里只是简单介绍了一下ADF的基本的东西，还有一些没有在这里细说，主要是看当前国内针对ADF相关的介绍比较少，也算是抛砖引玉吧，希望各位指出我在这里的缺陷以及不足，谢谢。
4851
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
