← Documents Documentation/gpu/introduction.rst GitHub 원문 ↗

Linux 6.18.37 · GPU·DRM

Introduction

DRM architecture, documentation, contribution process와 학습 자료를 다루는 전문 번역입니다.

Source pathDocumentation/gpu/introduction.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

introduction.rst:1-176

DRM layer의 목적, kerneldoc style과 kAPI 공개 범위, contribution deadline·행동 규범, tiny driver 예제와 외부 학습 자료를 설명하는 전문 번역입니다.

Introduction 핵심
단계내용
ArchitectureDRM userspace·core·driver·hardware stack
DocumentationMarkup·locking assertion·public kAPI
ContributionProcess·-rc6/-rc7 deadline·CoC
ExamplesTiny DRM simple display pipe
Learning18개 conference·article reference

새 DRM contributor가 확인할 순서입니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 ============
2 Introduction
3 ============
4
5 The Linux DRM layer contains code intended to support the needs of
6 complex graphics devices, usually containing programmable pipelines well
7 suited to 3D graphics acceleration. Graphics drivers in the kernel may
8 make use of DRM functions to make tasks like memory management,
9 interrupt handling and DMA easier, and provide a uniform interface to
10 applications.
11
12 A note on versions: this guide covers features found in the DRM tree,
13 including the TTM memory manager, output configuration and mode setting,
14 and the new vblank internals, in addition to all the regular features
15 found in current kernels.
16
17 [Insert diagram of typical DRM stack here]
18
19 Style Guidelines
20 ================
21
22 For consistency this documentation uses American English. Abbreviations
23 are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so
24 on. To aid in reading, documentations make full use of the markup
25 characters kerneldoc provides: @parameter for function parameters,
26 @member for structure members (within the same structure), &struct structure to
27 reference structures and function() for functions. These all get automatically
28 hyperlinked if kerneldoc for the referenced objects exists. When referencing
29 entries in function vtables (and structure members in general) please use
30 &vtable_name.vfunc. Unfortunately this does not yet yield a direct link to the
31 member, only the structure.
32
33 Except in special situations (to separate locked from unlocked variants)
34 locking requirements for functions aren't documented in the kerneldoc.
35 Instead locking should be check at runtime using e.g.
36 ``WARN_ON(!mutex_is_locked(...));``. Since it's much easier to ignore
37 documentation than runtime noise this provides more value. And on top of
38 that runtime checks do need to be updated when the locking rules change,
39 increasing the chances that they're correct. Within the documentation
40 the locking rules should be explained in the relevant structures: Either
41 in the comment for the lock explaining what it protects, or data fields
42 need a note about which lock protects them, or both.
43
44 Functions which have a non-\ ``void`` return value should have a section
45 called "Returns" explaining the expected return values in different
46 cases and their meanings. Currently there's no consensus whether that
47 section name should be all upper-case or not, and whether it should end
48 in a colon or not. Go with the file-local style. Other common section
49 names are "Notes" with information for dangerous or tricky corner cases,
50 and "FIXME" where the interface could be cleaned up.
51
52 Also read the :ref:`guidelines for the kernel documentation at large <doc_guide>`.
53
54 Documentation Requirements for kAPI
55 -----------------------------------
56
57 All kernel APIs exported to other modules must be documented, including their
58 datastructures and at least a short introductory section explaining the overall
59 concepts. Documentation should be put into the code itself as kerneldoc comments
60 as much as reasonable.
61
62 Do not blindly document everything, but document only what's relevant for driver
63 authors: Internal functions of drm.ko and definitely static functions should not
64 have formal kerneldoc comments. Use normal C comments if you feel like a comment
65 is warranted. You may use kerneldoc syntax in the comment, but it shall not
66 start with a /** kerneldoc marker. Similar for data structures, annotate
67 anything entirely private with ``/* private: */`` comments as per the
68 documentation guide.
69
70 Getting Started
71 ===============
72
73 Developers interested in helping out with the DRM subsystem are very welcome.
74 Often people will resort to sending in patches for various issues reported by
75 checkpatch or sparse. We welcome such contributions.
76
77 Anyone looking to kick it up a notch can find a list of janitorial tasks on
78 the :ref:`TODO list <todo>`.
79
80 Contribution Process
81 ====================
82
83 Mostly the DRM subsystem works like any other kernel subsystem, see :ref:`the
84 main process guidelines and documentation <process_index>` for how things work.
85 Here we just document some of the specialities of the GPU subsystem.
86
87 Feature Merge Deadlines
88 -----------------------
89
90 All feature work must be in the linux-next tree by the -rc6 release of the
91 current release cycle, otherwise they must be postponed and can't reach the next
92 merge window. All patches must have landed in the drm-next tree by latest -rc7,
93 but if your branch is not in linux-next then this must have happened by -rc6
94 already.
95
96 After that point only bugfixes (like after the upstream merge window has closed
97 with the -rc1 release) are allowed. No new platform enabling or new drivers are
98 allowed.
99
100 This means that there's a blackout-period of about one month where feature work
101 can't be merged. The recommended way to deal with that is having a -next tree
102 that's always open, but making sure to not feed it into linux-next during the
103 blackout period. As an example, drm-misc works like that.
104
105 Code of Conduct
106 ---------------
107
108 As a freedesktop.org project, dri-devel, and the DRM community, follows the
109 Contributor Covenant, found at: https://www.freedesktop.org/wiki/CodeOfConduct
110
111 Please conduct yourself in a respectful and civilised manner when
112 interacting with community members on mailing lists, IRC, or bug
113 trackers. The community represents the project as a whole, and abusive
114 or bullying behaviour is not tolerated by the project.
115
116 Simple DRM drivers to use as examples
117 =====================================
118
119 The DRM subsystem contains a lot of helper functions to ease writing drivers for
120 simple graphic devices. For example, the `drivers/gpu/drm/tiny/` directory has a
121 set of drivers that are simple enough to be implemented in a single source file.
122
123 These drivers make use of the `struct drm_simple_display_pipe_funcs`, that hides
124 any complexity of the DRM subsystem and just requires drivers to implement a few
125 functions needed to operate the device. This could be used for devices that just
126 need a display pipeline with one full-screen scanout buffer feeding one output.
127
128 The tiny DRM drivers are good examples to understand how DRM drivers should look
129 like. Since are just a few hundreds lines of code, they are quite easy to read.
130
131 External References
132 ===================
133
134 Delving into a Linux kernel subsystem for the first time can be an overwhelming
135 experience, one needs to get familiar with all the concepts and learn about the
136 subsystem's internals, among other details.
137
138 To shallow the learning curve, this section contains a list of presentations
139 and documents that can be used to learn about DRM/KMS and graphics in general.
140
141 There are different reasons why someone might want to get into DRM: porting an
142 existing fbdev driver, write a DRM driver for a new hardware, fixing bugs that
143 could face when working on the graphics user-space stack, etc. For this reason,
144 the learning material covers many aspects of the Linux graphics stack. From an
145 overview of the kernel and user-space stacks to very specific topics.
146
147 The list is sorted in reverse chronological order, to keep the most up-to-date
148 material at the top. But all of them contain useful information, and it can be
149 valuable to go through older material to understand the rationale and context
150 in which the changes to the DRM subsystem were made.
151
152 Conference talks
153 ----------------
154
155 * `An Overview of the Linux and Userspace Graphics Stack <https://www.youtube.com/watch?v=wjAJmqwg47k>`_ - Paul Kocialkowski (2020)
156 * `Getting pixels on screen on Linux: introduction to Kernel Mode Setting <https://www.youtube.com/watch?v=haes4_Xnc5Q>`_ - Simon Ser (2020)
157 * `Everything Great about Upstream Graphics <https://www.youtube.com/watch?v=kVzHOgt6WGE>`_ - Simona Vetter (2019)
158 * `An introduction to the Linux DRM subsystem <https://www.youtube.com/watch?v=LbDOCJcDRoo>`_ - Maxime Ripard (2017)
159 * `Embrace the Atomic (Display) Age <https://www.youtube.com/watch?v=LjiB_JeDn2M>`_ - Simona Vetter (2016)
160 * `Anatomy of an Atomic KMS Driver <https://www.youtube.com/watch?v=lihqR9sENpc>`_ - Laurent Pinchart (2015)
161 * `Atomic Modesetting for Drivers <https://www.youtube.com/watch?v=kl9suFgbTc8>`_ - Simona Vetter (2015)
162 * `Anatomy of an Embedded KMS Driver <https://www.youtube.com/watch?v=Ja8fM7rTae4>`_ - Laurent Pinchart (2013)
163
164 Slides and articles
165 -------------------
166
167 * `The Linux graphics stack in a nutshell, part 1 <https://lwn.net/Articles/955376/>`_ - Thomas Zimmermann (2023)
168 * `The Linux graphics stack in a nutshell, part 2 <https://lwn.net/Articles/955708/>`_ - Thomas Zimmermann (2023)
169 * `Understanding the Linux Graphics Stack <https://bootlin.com/doc/training/graphics/graphics-slides.pdf>`_ - Bootlin (2022)
170 * `DRM KMS overview <https://wiki.st.com/stm32mpu/wiki/DRM_KMS_overview>`_ - STMicroelectronics (2021)
171 * `Linux graphic stack <https://studiopixl.com/2017-05-13/linux-graphic-stack-an-overview>`_ - Nathan Gauër (2017)
172 * `Atomic mode setting design overview, part 1 <https://lwn.net/Articles/653071/>`_ - Simona Vetter (2015)
173 * `Atomic mode setting design overview, part 2 <https://lwn.net/Articles/653466/>`_ - Simona Vetter (2015)
174 * `The DRM/KMS subsystem from a newbie’s point of view <https://bootlin.com/pub/conferences/2014/elce/brezillon-drm-kms/brezillon-drm-kms.pdf>`_ - Boris Brezillon (2014)
175 * `A brief introduction to the Linux graphics stack <https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/>`_ - Iago Toral (2014)
176 * `The Linux Graphics Stack <https://blog.mecheye.net/2012/06/the-linux-graphics-stack/>`_ - Jasper St. Pierre (2012)
177

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

DRM layer와 Linux graphics stack

1-19

Linux DRM layer는 보통 3D graphics acceleration에 적합한 programmable pipeline을 포함하는 복잡한 graphics device를 지원하기 위한 code를 제공합니다.

Kernel graphics driver는 DRM function을 사용해 memory management, interrupt handling과 DMA 같은 작업을 단순화하고 application에 통일된 interface를 제공할 수 있습니다.

이 guide는 현재 kernel의 일반 DRM 기능뿐 아니라 DRM tree에 있는 TTM memory manager, output configuration·mode setting과 새로운 vblank internal도 다룹니다.

원문에는 전형적인 DRM stack diagram을 삽입하라는 placeholder가 있습니다. 아래 흐름은 그 의도를 application, UAPI, core subsystem과 hardware 계층으로 구조화한 것입니다.

전형적인 DRM stack
Application·compositor·display serverMesa·libdrm 등 userspace graphics driverDRM ioctl·mmap·syncobj·KMS uAPIDRM core + GEM/TTM memory manager + KMS helpersHardware-specific DRM driverGPU render engine·display controller·connector

Userspace rendering/display 요청이 kernel과 hardware로 전달되는 계층입니다.

DRM core가 공통화하는 기능
기능역할
Memory managementBuffer object와 residency·address-space 관리
InterruptGPU·display event 처리
DMADevice와 memory 사이 data 이동
KMSOutput configuration과 mode setting
vblankFrame timing과 page-flip synchronization

복잡한 graphics driver가 재사용하는 대표 기반입니다.

============
Introduction
============

The Linux DRM layer contains code intended to support the needs of
complex graphics devices, usually containing programmable pipelines well
suited to 3D graphics acceleration. Graphics drivers in the kernel may
make use of DRM functions to make tasks like memory management,
interrupt handling and DMA easier, and provide a uniform interface to
applications.

A note on versions: this guide covers features found in the DRM tree,
including the TTM memory manager, output configuration and mode setting,
and the new vblank internals, in addition to all the regular features
found in current kernels.

[Insert diagram of typical DRM stack here]

Style Guidelines

Documentation style guideline

20-54

일관성을 위해 이 문서는 American English를 사용합니다. DRM, KMS, IOCTL, CRTC 같은 abbreviation은 모두 uppercase로 씁니다.

가독성과 자동 hyperlink를 위해 kerneldoc markup을 적극적으로 사용합니다. Function parameter는 `@parameter`, 같은 structure의 member는 `@member`, structure reference는 `&struct structure`, function은 `function()` 형식으로 표기합니다.

Function vtable entry나 일반 structure member를 참조할 때는 `&vtable_name.vfunc`를 사용합니다. 현재 이 표기는 member 자체가 아니라 structure로만 link된다는 한계가 있습니다.

Locked·unlocked variant를 구분하는 특수 상황을 제외하면 function locking requirement를 kerneldoc에 적지 않습니다. 대신 `WARN_ON(!mutex_is_locked(...));` 같은 runtime check를 사용합니다.

Runtime warning은 무시하기 쉬운 문서보다 눈에 띄고 locking rule이 바뀔 때 code도 update해야 하므로 정확할 가능성이 높습니다. 문서 안의 locking rule은 관련 lock comment에서 보호 대상을 설명하거나 data field에 어떤 lock이 보호하는지 표시하거나 둘 다 수행해야 합니다.

Non-`void` return value가 있는 function은 상황별 expected value와 의미를 설명하는 `Returns` 절을 가져야 합니다. 대문자 표기나 colon 사용은 합의가 없으므로 file-local style을 따릅니다.

다른 공통 section은 위험하거나 까다로운 corner case를 설명하는 `Notes`, interface cleanup 가능성을 표시하는 `FIXME`입니다. 전체 kernel documentation 지침은 `doc_guide` 참조를 함께 읽어야 합니다.

Kerneldoc 표기
대상표기
Function parameter@parameter
Structure member@member
Structure&struct structure
Functionfunction()
Vtable member&vtable_name.vfunc
Non-void resultReturns section
Corner caseNotes
Cleanup candidateFIXME

DRM 문서가 사용하는 주요 reference syntax입니다.

Locking 문서화
Lock이 보호하는 structure·field를 comment에 명시Function 진입 시 WARN_ON 등 runtime lock assertionLocking rule 변경 시 assertion과 structure comment updateLocked·unlocked variant가 특별히 필요할 때만 function kerneldoc에 추가 설명

Runtime assertion과 structure comment를 함께 유지하는 방식입니다.

================

For consistency this documentation uses American English. Abbreviations
are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so
on. To aid in reading, documentations make full use of the markup
characters kerneldoc provides: @parameter for function parameters,
@member for structure members (within the same structure), &struct structure to
reference structures and function() for functions. These all get automatically
hyperlinked if kerneldoc for the referenced objects exists. When referencing
entries in function vtables (and structure members in general) please use
&vtable_name.vfunc. Unfortunately this does not yet yield a direct link to the
member, only the structure.

Except in special situations (to separate locked from unlocked variants)
locking requirements for functions aren't documented in the kerneldoc.
Instead locking should be check at runtime using e.g.
``WARN_ON(!mutex_is_locked(...));``. Since it's much easier to ignore
documentation than runtime noise this provides more value. And on top of
that runtime checks do need to be updated when the locking rules change,
increasing the chances that they're correct. Within the documentation
the locking rules should be explained in the relevant structures: Either
in the comment for the lock explaining what it protects, or data fields
need a note about which lock protects them, or both.

Functions which have a non-\ ``void`` return value should have a section
called "Returns" explaining the expected return values in different
cases and their meanings. Currently there's no consensus whether that
section name should be all upper-case or not, and whether it should end
in a colon or not. Go with the file-local style. Other common section
names are "Notes" with information for dangerous or tricky corner cases,
and "FIXME" where the interface could be cleaned up.

Also read the :ref:`guidelines for the kernel documentation at large <doc_guide>`.

Documentation Requirements for kAPI

kAPI documentation requirement

55-70

다른 module에 export되는 모든 kernel API는 data structure와 전체 concept를 설명하는 짧은 introduction을 포함해 문서화해야 합니다. 가능한 범위에서 문서는 code 안의 kerneldoc comment로 작성합니다.

모든 symbol을 무차별적으로 문서화해서는 안 됩니다. Driver author에게 관련 있는 API만 formal kerneldoc 대상입니다. `drm.ko`의 internal function과 특히 static function에는 formal kerneldoc comment를 쓰지 않습니다.

내부 code에 설명이 필요하면 일반 C comment를 사용합니다. Kerneldoc syntax를 쓸 수는 있지만 `/**` kerneldoc marker로 시작하면 안 됩니다.

Data structure도 완전히 private인 부분은 documentation guide에 따라 `/* private: */` comment로 표시합니다.

kAPI 문서화 경계
대상문서화 방식
다른 module에 export된 APIFormal kerneldoc 필수
Exported data structureFormal kerneldoc + concept introduction
drm.ko internal function필요할 때 일반 C comment
Static functionFormal kerneldoc 제외
Private structure field/* private: */ marker

Exported API와 internal implementation을 구분합니다.

API 문서 작성
Cross-module 공개 여부 확인Overall concept introduction 작성Public function·structure contract를 code의 kerneldoc에 작성Internal detail은 일반 C comment로 제한Private data boundary 표시

Driver author에게 필요한 public contract를 우선합니다.

-----------------------------------

All kernel APIs exported to other modules must be documented, including their
datastructures and at least a short introductory section explaining the overall
concepts. Documentation should be put into the code itself as kerneldoc comments
as much as reasonable.

Do not blindly document everything, but document only what's relevant for driver
authors: Internal functions of drm.ko and definitely static functions should not
have formal kerneldoc comments. Use normal C comments if you feel like a comment
is warranted. You may use kerneldoc syntax in the comment, but it shall not
start with a /** kerneldoc marker. Similar for data structures, annotate
anything entirely private with ``/* private: */`` comments as per the
documentation guide.

Getting Started

DRM contribution 시작

71-80

DRM subsystem 기여에 관심 있는 developer는 환영받습니다. Checkpatch나 sparse가 보고한 여러 문제를 고치는 patch가 흔한 시작점이며 이런 contribution도 유용합니다.

더 큰 작업을 찾는 contributor는 `todo` reference의 janitorial task 목록을 확인할 수 있습니다.

첫 contribution
checkpatch·sparse warning 선택관련 driver와 coding rule 확인작고 검증 가능한 patch 작성Review feedback 반영TODO list에서 더 큰 cleanup task 탐색

작은 정적 검사 수정에서 subsystem task로 확장하는 경로입니다.

시작 자료
자료용도
checkpatch·sparse report범위가 작은 correctness·style 개선
TODO listJanitorial·subsystem improvement task

초기 contributor가 사용할 두 진입점입니다.

===============

Developers interested in helping out with the DRM subsystem are very welcome.
Often people will resort to sending in patches for various issues reported by
checkpatch or sparse. We welcome such contributions.

Anyone looking to kick it up a notch can find a list of janitorial tasks on
the :ref:`TODO list <todo>`.

Contribution Process

Contribution process, deadline과 행동 규범

81-116

DRM subsystem은 대부분 다른 kernel subsystem과 같은 contribution process를 따릅니다. 일반 절차는 `process_index`를 참조하고 이 문서는 GPU subsystem의 특수 사항만 설명합니다.

모든 feature work는 현재 release cycle의 `-rc6` release까지 `linux-next` tree에 들어가야 합니다. 그렇지 않으면 다음 merge window에 들어갈 수 없고 연기해야 합니다.

모든 patch는 늦어도 `-rc7`까지 `drm-next`에 들어가야 합니다. Branch가 linux-next에 없다면 이 시점도 이미 `-rc6`이어야 합니다.

그 뒤에는 upstream merge window가 `-rc1`로 닫힌 뒤와 마찬가지로 bugfix만 허용합니다. 새 platform enablement와 새 driver는 허용하지 않습니다.

결과적으로 약 한 달의 feature merge blackout 기간이 생깁니다. 권장 방식은 항상 열린 `-next` tree를 유지하되 blackout 동안 linux-next에 feed하지 않는 것입니다. `drm-misc`가 이런 방식으로 운영됩니다.

Feature merge deadline
Feature branch 개발·review-rc6까지 linux-next에 포함늦어도 -rc7까지 drm-next에 포함Blackout 기간에는 bugfix만 merge다음 merge window에서 upstream 반영

현재 cycle에서 다음 merge window로 이어지는 제한입니다.

Merge 가능 범위
시점허용
-rc6 이전Feature·platform·driver와 bugfix
-rc6linux-next 미포함 feature의 다음 window 진입 마감
-rc7이미 linux-next인 patch의 drm-next 최종 마감
BlackoutBugfix만 허용

Release-cycle 시점별 허용 change입니다.

dri-devel과 DRM community는 freedesktop.org project로서 Contributor Covenant를 따릅니다. Mailing list, IRC, bug tracker에서 community member를 존중하고 문명적으로 대해야 하며 abusive·bullying behavior는 허용되지 않습니다.

Code of Conduct
항목내용
규범Contributor Covenant
공식 위치https://www.freedesktop.org/wiki/CodeOfConduct
적용 공간Mailing list·IRC·bug tracker
금지Abusive 또는 bullying behavior

Community interaction에 적용되는 기준입니다.

====================

Mostly the DRM subsystem works like any other kernel subsystem, see :ref:`the
main process guidelines and documentation <process_index>` for how things work.
Here we just document some of the specialities of the GPU subsystem.

Feature Merge Deadlines
-----------------------

All feature work must be in the linux-next tree by the -rc6 release of the
current release cycle, otherwise they must be postponed and can't reach the next
merge window. All patches must have landed in the drm-next tree by latest -rc7,
but if your branch is not in linux-next then this must have happened by -rc6
already.

After that point only bugfixes (like after the upstream merge window has closed
with the -rc1 release) are allowed. No new platform enabling or new drivers are
allowed.

This means that there's a blackout-period of about one month where feature work
can't be merged. The recommended way to deal with that is having a -next tree
that's always open, but making sure to not feed it into linux-next during the
blackout period. As an example, drm-misc works like that.

Code of Conduct
---------------

As a freedesktop.org project, dri-devel, and the DRM community, follows the
Contributor Covenant, found at: https://www.freedesktop.org/wiki/CodeOfConduct

Please conduct yourself in a respectful and civilised manner when
interacting with community members on mailing lists, IRC, or bug
trackers. The community represents the project as a whole, and abusive
or bullying behaviour is not tolerated by the project.

Simple DRM drivers to use as examples

Simple DRM driver와 학습 자료

117-152

DRM subsystem에는 단순한 graphics device driver 작성을 돕는 helper가 많습니다. `drivers/gpu/drm/tiny/`에는 source file 하나로 구현할 수 있을 만큼 단순한 driver가 모여 있습니다.

이 driver들은 `struct drm_simple_display_pipe_funcs`를 사용해 DRM subsystem의 복잡성을 숨기고 device operation에 필요한 소수 function만 구현합니다. Full-screen scanout buffer 하나가 output 하나를 공급하는 display pipeline에 적합합니다.

Tiny DRM driver는 수백 줄에 불과해 읽기 쉽고 DRM driver가 어떤 구조여야 하는지 배우기 좋은 예제입니다.

Simple display pipeline
Framebuffer의 full-screen scanout bufferdrm_simple_display_pipe helperDriver의 enable·disable·update function단일 encoder·connector output

Tiny driver가 구현하는 최소 display data path입니다.

Tiny driver 학습 가치
특징이점
Single-source-file 규모전체 lifecycle을 한 번에 읽기 쉬움
drm_simple_display_pipe_funcs필수 callback 경계가 명확
Helper 중심 구현DRM core boilerplate 감소
단일 scanout·output복잡한 composition 없이 KMS 기본 학습

새 driver author가 확인할 요소입니다.

External reference 절은 DRM 진입 동기가 fbdev porting, 새 hardware driver 작성, graphics userspace stack의 bug 수정 등 다양하다는 점을 설명합니다.

자료는 kernel·userspace stack overview부터 특정 주제까지 폭넓게 다루며 최신 자료가 위에 오도록 역시간순으로 정렬됩니다. 오래된 자료도 DRM 변화의 rationale과 당시 context를 이해하는 데 가치가 있습니다.

=====================================

The DRM subsystem contains a lot of helper functions to ease writing drivers for
simple graphic devices. For example, the `drivers/gpu/drm/tiny/` directory has a
set of drivers that are simple enough to be implemented in a single source file.

These drivers make use of the `struct drm_simple_display_pipe_funcs`, that hides
any complexity of the DRM subsystem and just requires drivers to implement a few
functions needed to operate the device. This could be used for devices that just
need a display pipeline with one full-screen scanout buffer feeding one output.

The tiny DRM drivers are good examples to understand how DRM drivers should look
like. Since are just a few hundreds lines of code, they are quite easy to read.

External References
===================

Delving into a Linux kernel subsystem for the first time can be an overwhelming
experience, one needs to get familiar with all the concepts and learn about the
subsystem's internals, among other details.

To shallow the learning curve, this section contains a list of presentations
and documents that can be used to learn about DRM/KMS and graphics in general.

There are different reasons why someone might want to get into DRM: porting an
existing fbdev driver, write a DRM driver for a new hardware, fixing bugs that
could face when working on the graphics user-space stack, etc. For this reason,
the learning material covers many aspects of the Linux graphics stack. From an
overview of the kernel and user-space stacks to very specific topics.

The list is sorted in reverse chronological order, to keep the most up-to-date
material at the top. But all of them contain useful information, and it can be
valuable to go through older material to understand the rationale and context
in which the changes to the DRM subsystem were made.

Conference talks

Conference talk, slide와 article

153-176

Conference talk 목록은 2020년 Linux/userspace graphics stack과 KMS introduction부터 2013년 embedded KMS driver anatomy까지 이어집니다.

Conference talks
제목URL발표자·연도
An Overview of the Linux and Userspace Graphics Stackhttps://www.youtube.com/watch?v=wjAJmqwg47kPaul Kocialkowski (2020)
Getting pixels on screen on Linux: introduction to Kernel Mode Settinghttps://www.youtube.com/watch?v=haes4_Xnc5QSimon Ser (2020)
Everything Great about Upstream Graphicshttps://www.youtube.com/watch?v=kVzHOgt6WGESimona Vetter (2019)
An introduction to the Linux DRM subsystemhttps://www.youtube.com/watch?v=LbDOCJcDRooMaxime Ripard (2017)
Embrace the Atomic (Display) Agehttps://www.youtube.com/watch?v=LjiB_JeDn2MSimona Vetter (2016)
Anatomy of an Atomic KMS Driverhttps://www.youtube.com/watch?v=lihqR9sENpcLaurent Pinchart (2015)
Atomic Modesetting for Drivershttps://www.youtube.com/watch?v=kl9suFgbTc8Simona Vetter (2015)
Anatomy of an Embedded KMS Driverhttps://www.youtube.com/watch?v=Ja8fM7rTae4Laurent Pinchart (2013)

원문 제목·URL·발표자를 보존한 8개 발표입니다.

Slide와 article 목록은 2023년 LWN graphics stack series부터 2012년 overview까지 포함합니다. Driver implementation, DRM/KMS 구조와 atomic mode-setting의 역사적 맥락을 보완합니다.

Slides and articles
제목URL저자·연도
The Linux graphics stack in a nutshell, part 1https://lwn.net/Articles/955376/Thomas Zimmermann (2023)
The Linux graphics stack in a nutshell, part 2https://lwn.net/Articles/955708/Thomas Zimmermann (2023)
Understanding the Linux Graphics Stackhttps://bootlin.com/doc/training/graphics/graphics-slides.pdfBootlin (2022)
DRM KMS overviewhttps://wiki.st.com/stm32mpu/wiki/DRM_KMS_overviewSTMicroelectronics (2021)
Linux graphic stackhttps://studiopixl.com/2017-05-13/linux-graphic-stack-an-overviewNathan Gauër (2017)
Atomic mode setting design overview, part 1https://lwn.net/Articles/653071/Simona Vetter (2015)
Atomic mode setting design overview, part 2https://lwn.net/Articles/653466/Simona Vetter (2015)
The DRM/KMS subsystem from a newbie’s point of viewhttps://bootlin.com/pub/conferences/2014/elce/brezillon-drm-kms/brezillon-drm-kms.pdfBoris Brezillon (2014)
A brief introduction to the Linux graphics stackhttps://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/Iago Toral (2014)
The Linux Graphics Stackhttps://blog.mecheye.net/2012/06/the-linux-graphics-stack/Jasper St. Pierre (2012)

원문 제목·URL·저자를 보존한 10개 자료입니다.

----------------

* `An Overview of the Linux and Userspace Graphics Stack <https://www.youtube.com/watch?v=wjAJmqwg47k>`_ - Paul Kocialkowski (2020)
* `Getting pixels on screen on Linux: introduction to Kernel Mode Setting <https://www.youtube.com/watch?v=haes4_Xnc5Q>`_ - Simon Ser (2020)
* `Everything Great about Upstream Graphics <https://www.youtube.com/watch?v=kVzHOgt6WGE>`_ - Simona Vetter (2019)
* `An introduction to the Linux DRM subsystem <https://www.youtube.com/watch?v=LbDOCJcDRoo>`_ - Maxime Ripard (2017)
* `Embrace the Atomic (Display) Age <https://www.youtube.com/watch?v=LjiB_JeDn2M>`_ - Simona Vetter (2016)
* `Anatomy of an Atomic KMS Driver <https://www.youtube.com/watch?v=lihqR9sENpc>`_ - Laurent Pinchart (2015)
* `Atomic Modesetting for Drivers <https://www.youtube.com/watch?v=kl9suFgbTc8>`_ - Simona Vetter (2015)
* `Anatomy of an Embedded KMS Driver <https://www.youtube.com/watch?v=Ja8fM7rTae4>`_ - Laurent Pinchart (2013)

Slides and articles
-------------------

* `The Linux graphics stack in a nutshell, part 1 <https://lwn.net/Articles/955376/>`_ - Thomas Zimmermann (2023)
* `The Linux graphics stack in a nutshell, part 2 <https://lwn.net/Articles/955708/>`_ - Thomas Zimmermann (2023)
* `Understanding the Linux Graphics Stack <https://bootlin.com/doc/training/graphics/graphics-slides.pdf>`_ - Bootlin (2022)
* `DRM KMS overview <https://wiki.st.com/stm32mpu/wiki/DRM_KMS_overview>`_ - STMicroelectronics (2021)
* `Linux graphic stack <https://studiopixl.com/2017-05-13/linux-graphic-stack-an-overview>`_ - Nathan Gauër (2017)
* `Atomic mode setting design overview, part 1 <https://lwn.net/Articles/653071/>`_ - Simona Vetter (2015)
* `Atomic mode setting design overview, part 2 <https://lwn.net/Articles/653466/>`_ - Simona Vetter (2015)
* `The DRM/KMS subsystem from a newbie’s point of view <https://bootlin.com/pub/conferences/2014/elce/brezillon-drm-kms/brezillon-drm-kms.pdf>`_ - Boris Brezillon (2014)
* `A brief introduction to the Linux graphics stack <https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/>`_ - Iago Toral (2014)
* `The Linux Graphics Stack <https://blog.mecheye.net/2012/06/the-linux-graphics-stack/>`_ - Jasper St. Pierre (2012)