DRM graphics subsystem TODO list

목록의 목적·난이도와 dumb mmap offset 정리

이 문서는 커널 DRM graphics subsystem에서 수행할 수 있는 비교적 작은 정리 작업을 모은 TODO 목록입니다. DRM에 입문하는 개발자의 프로젝트나 여유가 있는 날 처리할 유지보수 작업으로 활용할 수 있습니다.

난이도는 네 단계입니다. `Starter`는 DRM subsystem을 처음 다루는 사람에게 적합합니다. `Intermediate`는 DRM 작업 경험이나 특정 GPU/display 지식이 필요하며, 문제를 디버깅하려면 관련 hardware 또는 준비된 virtual driver가 있는 편이 좋습니다. `Advanced`는 DRM과 graphics 주제를 상당히 잘 이해해야 하는 까다로운 작업으로, 보통 개발·시험용 hardware가 필요합니다. `Expert`는 이미 어려운 refactoring을 성공적으로 수행했고 해당 영역의 전문가인 경우에만 시도해야 합니다.

Subsystem-wide refactoring의 첫 과제는 custom `dumb_map_offset` 구현을 제거하는 것입니다. 모든 GEM 기반 driver는 대신 `drm_gem_create_mmap_offset()`을 사용해야 합니다. 각 driver를 감사하여 generic 구현으로 올바르게 동작하는지 확인하고, 여러 구현에 남아 있는 오래된 locking 처리까지 정리한 뒤 custom 구현을 삭제합니다.

담당 연락처는 Simona Vetter와 각 driver maintainer이며 난이도는 `Intermediate`입니다.

.. _todo:

=========
TODO list
=========

This section contains a list of smaller janitorial tasks in the kernel DRM
graphics subsystem useful as newbie projects. Or for slow rainy days.

Difficulty
----------

To make it easier task are categorized into different levels:

Starter: Good tasks to get started with the DRM subsystem.

Intermediate: Tasks which need some experience with working in the DRM
subsystem, or some specific GPU/display graphics knowledge. For debugging issue
it's good to have the relevant hardware (or a virtual driver set up) available
for testing.

Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem
and graphics topics. Generally need the relevant hardware for development and
testing.

Expert: Only attempt these if you've successfully completed some tricky
refactorings already and are an expert in the specific area

Subsystem-wide refactorings
===========================

Remove custom dumb_map_offset implementations
---------------------------------------------

All GEM based drivers should be using drm_gem_create_mmap_offset() instead.
Audit each individual driver, make sure it'll work with the generic
implementation (there's lots of outdated locking leftovers in various
implementations), and then remove it.

Contact: Simona Vetter, respective driver maintainers

Level: Intermediate

Atomic KMS 전환과 plane 좌표·검사 helper

Linux 3.19부터 atomic modeset interface와 helper가 제공되므로 기존 KMS driver를 atomic modesetting으로 전환할 수 있습니다. Wayland나 Android SurfaceFlinger 같은 현대 compositor가 atomic modeset interface를 요구하므로 장기적으로 필요한 전환입니다.

Atomic 전환 안내서는 `https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html`에 있고, LWN.net의 `Atomic mode setting design overview` 연재는 `https://lwn.net/Articles/653071/`과 `https://lwn.net/Articles/653466/`에서 볼 수 있습니다. 아직 전환되지 않은 driver를 위한 GPU가 있으면 작업을 시작할 수 있습니다.

전환 과정에서 primary와 cursor를 정식 plane object로 노출하는 universal plane도 도입해야 합니다. 새 atomic helper driver callback을 직접 사용하면 이 작업은 비교적 간단합니다. 연락처는 Simona Vetter와 해당 driver maintainer이며 난이도는 `Advanced`입니다.

Plane의 clipped coordinate 처리는 `drm_plane_helper_check_update()`가 제공하지만 일관되게 사용되지 않습니다. 이 문제는 가능하면 atomic helper에서 바로잡고 driver를 clipped coordinate 방식으로 옮겨야 합니다. 혼동을 줄이기 위해 helper 자체도 `drm_plane_helper.c`에서 atomic helper 쪽으로 이동하는 것이 좋습니다. 해당 파일의 다른 helper는 모두 deprecated legacy helper입니다. 연락처는 Ville Syrjälä, Simona Vetter와 driver maintainer이며 난이도는 `Advanced`입니다.

현재 plane `atomic_check` helper에는 세 가지 개선점이 있습니다. 첫째, `drm_plane_helper_funcs->atomic_check`는 plane의 활성·비활성 여부와 관계없이 호출됩니다. 비활성 plane에 CRTC가 없으면 driver가 혼란을 겪거나 실패할 수 있습니다. Plane state 값을 초기화하는 유일한 특별 처리는 `drm_plane_funcs->atomic_duplicate_state` 구현으로 옮겨야 합니다.

둘째, 초기화 처리를 옮긴 다음 helper는 비활성 plane에 `->atomic_check`를 호출하지 않아야 합니다. 셋째, 모든 driver에서 `plane_state->fb`와 `plane_state->crtc`를 확인하는 불필요하거나 혼란스러운 검사를 제거할 수 있습니다. 이 과제의 연락처는 Simona Vetter이고 난이도는 `Advanced`입니다.

Convert existing KMS drivers to atomic modesetting
--------------------------------------------------

3.19 has the atomic modeset interfaces and helpers, so drivers can now be
converted over. Modern compositors like Wayland or Surfaceflinger on Android
really want an atomic modeset interface, so this is all about the bright
future.

There is a conversion guide for atomic [1]_ and all you need is a GPU for a
non-converted driver.  The "Atomic mode setting design overview" series [2]_
[3]_ at LWN.net can also be helpful.

As part of this drivers also need to convert to universal plane (which means
exposing primary & cursor as proper plane objects). But that's much easier to
do by directly using the new atomic helper driver callbacks.

  .. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
  .. [2] https://lwn.net/Articles/653071/
  .. [3] https://lwn.net/Articles/653466/

Contact: Simona Vetter, respective driver maintainers

Level: Advanced

Clean up the clipped coordination confusion around planes
---------------------------------------------------------

We have a helper to get this right with drm_plane_helper_check_update(), but
it's not consistently used. This should be fixed, preferably in the atomic
helpers (and drivers then moved over to clipped coordinates). Probably the
helper should also be moved from drm_plane_helper.c to the atomic helpers, to
avoid confusion - the other helpers in that file are all deprecated legacy
helpers.

Contact: Ville Syrjälä, Simona Vetter, driver maintainers

Level: Advanced

Improve plane atomic_check helpers
----------------------------------

Aside from the clipped coordinates right above there's a few suboptimal things
with the current helpers:

- drm_plane_helper_funcs->atomic_check gets called for enabled or disabled
  planes. At best this seems to confuse drivers, worst it means they blow up
  when the plane is disabled without the CRTC. The only special handling is
  resetting values in the plane state structures, which instead should be moved
  into the drm_plane_funcs->atomic_duplicate_state functions.

- Once that's done, helpers could stop calling ->atomic_check for disabled
  planes.

- Then we could go through all the drivers and remove the more-or-less confused
  checks for plane_state->fb and plane_state->crtc.

Contact: Simona Vetter

Level: Advanced

Async commit·atomic state 명명·legacy fallout

Atomic modeset helper의 첫해에는 asynchronous/nonblocking commit 지원이 없어 각 driver가 직접 구현해야 했습니다. 이제 공통 infrastructure가 있으므로 초기 atomic driver의 자체 구현을 새 async commit helper로 전환할 수 있습니다.

Helper를 사용하려면 driver가 atomic commit completion event를 정확히 처리해야 합니다. 이 과정에서 드러나는 오류도 수정할 가치가 있습니다. `legacy_cursor_update` 편법을 확인하는 driver는 이를 새 `atomic_async_check`와 `atomic_async_commit` helper 기능으로 교체해야 합니다. 연락처는 Simona Vetter와 각 driver maintainer이며 난이도는 `Advanced`입니다.

KMS framework의 `state`라는 말은 두 의미로 쓰입니다. `drm_$OBJECT_state`는 plane, CRTC, encoder 같은 특정 object의 전체 상태를 뜻하지만, device 수준의 `drm_atomic_state`는 device 안의 제한된 object 집합에 대한 상태 갱신만 나타냅니다. Device 전체 상태가 아니므로 입문자에게 혼란을 줍니다.

따라서 `drm_atomic_state`를 `drm_atomic_commit`처럼 의미가 분명한 이름으로 바꾸는 것이 제안됩니다. 구조체뿐 아니라 `drm_atomic_state_alloc`, `drm_atomic_state_get`, `drm_atomic_state_put`, `drm_atomic_state_init`, `__drm_atomic_state_free` 등의 관련 함수도 함께 이름을 바꿔야 합니다. 연락처는 Maxime Ripard `<[email protected]>`이고 난이도는 `Advanced`입니다.

`drm_atomic_helper.c`는 새 atomic driver interface 위에 legacy IOCTL을 구현하는 함수들을 제공합니다. 점진적 전환에는 유용하지만 두 interface의 semantic mismatch가 커서 후속 정리가 필요합니다.

Atomic 경로는 lock acquire context가 필요합니다. 현재 일부 경로는 이를 암묵적으로 전달하는 편법과 내부 `GFP_NOFAIL` 할당을 사용합니다. 모든 legacy 경로가 acquire context를 stack에 명시적으로 만들고 driver에 전달해야 legacy-on-atomic 함수가 사용할 수 있습니다. 일부 driver 코드를 제외하면 대부분 완료됐으며, `drm_modeset_lock_all()`에 `WARN_ON(!drm_drv_uses_atomic_modeset)`을 추가해 마무리해야 합니다.

Vtable hook의 위치도 정리해야 합니다. `drm_foo_funcs`라는 core vfunc table은 userspace ABI 구현용이고, 선택적인 `drm_foo_helper_funcs`는 helper library 내부용입니다. Core ABI가 아닌 hook은 `_funcs`에서 `_helper_funcs`로 옮겨야 하며, 해당 항목마다 `drm_crtc.h` kernel-doc에 `FIXME`가 있습니다. 연락처는 Simona Vetter이고 난이도는 `Intermediate`입니다.

Convert early atomic drivers to async commit helpers
----------------------------------------------------

For the first year the atomic modeset helpers didn't support asynchronous /
nonblocking commits, and every driver had to hand-roll them. This is fixed
now, but there's still a pile of existing drivers that easily could be
converted over to the new infrastructure.

One issue with the helpers is that they require that drivers handle completion
events for atomic commits correctly. But fixing these bugs is good anyway.

Somewhat related is the legacy_cursor_update hack, which should be replaced with
the new atomic_async_check/commit functionality in the helpers in drivers that
still look at that flag.

Contact: Simona Vetter, respective driver maintainers

Level: Advanced

Rename drm_atomic_state
-----------------------

The KMS framework uses two slightly different definitions for the ``state``
concept. For a given object (plane, CRTC, encoder, etc., so
``drm_$OBJECT_state``), the state is the entire state of that object. However,
at the device level, ``drm_atomic_state`` refers to a state update for a
limited number of objects.

The state isn't the entire device state, but only the full state of some
objects in that device. This is confusing to newcomers, and
``drm_atomic_state`` should be renamed to something clearer like
``drm_atomic_commit``.

In addition to renaming the structure itself, it would also imply renaming some
related functions (``drm_atomic_state_alloc``, ``drm_atomic_state_get``,
``drm_atomic_state_put``, ``drm_atomic_state_init``,
``__drm_atomic_state_free``, etc.).

Contact: Maxime Ripard <[email protected]>

Level: Advanced

Fallout from atomic KMS
-----------------------

``drm_atomic_helper.c`` provides a batch of functions which implement legacy
IOCTLs on top of the new atomic driver interface. Which is really nice for
gradual conversion of drivers, but unfortunately the semantic mismatches are
a bit too severe. So there's some follow-up work to adjust the function
interfaces to fix these issues:

* atomic needs the lock acquire context. At the moment that's passed around
  implicitly with some horrible hacks, and it's also allocate with
  ``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating
  the acquire context explicitly on stack and then also pass it down into
  drivers explicitly so that the legacy-on-atomic functions can use them.

  Except for some driver code this is done. This task should be finished by
  adding WARN_ON(!drm_drv_uses_atomic_modeset) in drm_modeset_lock_all().

* A bunch of the vtable hooks are now in the wrong place: DRM has a split
  between core vfunc tables (named ``drm_foo_funcs``), which are used to
  implement the userspace ABI. And then there's the optional hooks for the
  helper libraries (name ``drm_foo_helper_funcs``), which are purely for
  internal use. Some of these hooks should be move from ``_funcs`` to
  ``_helper_funcs`` since they are not part of the core ABI. There's a
  ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``.

Contact: Simona Vetter

Level: Intermediate

BO locking·logging·suspend와 fbdev callback

많은 driver가 object마다 `mutex_lock()`을 사용하는 자체 locking scheme을 갖고 있습니다. Buffer를 공유할 때 어느 driver가 exporter이고 importer인지에 따라 lock hierarchy가 뒤집혀 여러 문제가 발생합니다.

표준 per-object locking mechanism으로 `dma_resv_lock()`을 사용해야 합니다. 이 lock은 가장 바깥쪽에서 획득해야 하고 driver 고유의 다른 per-object lock은 제거해야 합니다. 다만 `struct dma_buf` buffer sharing 때문에 실제 locking contract 변경은 모든 관련 코드를 동시에 바꾸는 flag day가 됩니다. 난이도는 `Expert`입니다.

한 driver의 instance가 여러 개일 수 있으면 log가 어느 instance에서 나왔는지 구분해야 합니다. `DRM_INFO`, `DRM_WARN`, `DRM_ERROR`는 이를 제공하지 않아 driver들이 `dev_info`, `dev_warn`, `dev_err`를 사용해 왔습니다. 이제 `drm_device` parameter를 받는 `drm_*` print variant가 있으므로 DRM 형식의 instance-specific log로 되돌릴 수 있습니다.

이 logging 전환을 시작하기 전에는 해당 maintainer에게 merge 의사를 확인해야 합니다. 모든 사람이 DRM dmesg macro가 더 낫다는 데 동의하는 것은 아닙니다. 연락처는 Sean Paul과 전환할 driver의 maintainer이며 난이도는 `Starter`입니다.

`drm_atomic_helper_suspend()`와 `drm_atomic_helper_resume()`을 사용하는 driver 대부분은 i915와 nouveau를 제외하면 `drm_mode_config_helper_suspend()`와 `drm_mode_config_helper_resume()`으로 전환할 수 있습니다. 오래된 atomic modeset driver에는 suspend/resume 코드를 직접 펼쳐 쓴 구현도 남아 있습니다. 연락처는 해당 driver maintainer이며 난이도는 `Intermediate`입니다.

`drm_fbdev_fb_ops`의 여러 callback은 fbdev module 의존성을 없애는 방향으로 다시 구현할 수 있습니다. 일부 helper는 raw pointer 대신 `struct iosys_map`을 사용하면 더 좋아집니다. 연락처는 Thomas Zimmermann `<[email protected]>`와 Simona Vetter이며 난이도는 `Advanced`입니다.

Move Buffer Object Locking to dma_resv_lock()
---------------------------------------------

Many drivers have their own per-object locking scheme, usually using
mutex_lock(). This causes all kinds of trouble for buffer sharing, since
depending which driver is the exporter and importer, the locking hierarchy is
reversed.

To solve this we need one standard per-object locking mechanism, which is
dma_resv_lock(). This lock needs to be called as the outermost lock, with all
other driver specific per-object locks removed. The problem is that rolling out
the actual change to the locking contract is a flag day, due to struct dma_buf
buffer sharing.

Level: Expert

Convert logging to drm_* functions with drm_device parameter
------------------------------------------------------------

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR
don't do this, drivers used dev_info/warn/err to make this differentiation. We
now have drm_* variants of the drm print functions, so we can start to convert
those drivers back to using drm-formatted specific log messages.

Before you start this conversion please contact the relevant maintainers to make
sure your work will be merged - not everyone agrees that the DRM dmesg macros
are better.

Contact: Sean Paul, Maintainer of the driver you plan to convert

Level: Starter

Convert drivers to use simple modeset suspend/resume
----------------------------------------------------

Most drivers (except i915 and nouveau) that use
drm_atomic_helper_suspend/resume() can probably be converted to use
drm_mode_config_helper_suspend/resume(). Also there's still open-coded version
of the atomic suspend/resume code in older atomic modeset drivers.

Contact: Maintainer of the driver you plan to convert

Level: Intermediate

Reimplement functions in drm_fbdev_fb_ops without fbdev
-------------------------------------------------------

A number of callback functions in drm_fbdev_fb_ops could benefit from
being rewritten without dependencies on the fbdev module. Some of the
helpers could further benefit from using struct iosys_map instead of
raw pointers.

Contact: Thomas Zimmermann <[email protected]>, Simona Vetter

Level: Advanced

Blit 최적화·framebuffer helper·generic defio

Display memory에 빠르게 그리는 성능은 많은 application에 중요합니다. 적어도 x86-64에서는 같은 blitting algorithm을 사용하는데도 `sys_imageblit()`이 I/O memory용 `cfb_imageblit()`보다 훨씬 느립니다. `cfb_imageblit()`은 `movl` instruction을 사용하지만 `sys_imageblit()`은 그렇지 않은 것으로 보이며 GCC optimizer 문제일 수 있습니다. DRM format-conversion helper도 비슷한 영향을 받을 수 있습니다.

Fbdev `sys_()` helper와 DRM format-conversion helper를 benchmark하고 최적화해야 합니다. 더 나은 여지가 있으면 다른 algorithm을 구현할 수 있고, 미세 최적화에는 `movl`/`movq` instruction을 명시적으로 사용합니다. 이를 위해 `storel()`이나 `storeq()` 같은 architecture-specific helper가 필요할 수도 있습니다. 연락처는 Thomas Zimmermann `<[email protected]>`이고 난이도는 `Intermediate`입니다.

더 많은 driver를 `drm_gem_framebuffer` helper로 전환할 수 있지만 몇 가지 선행 작업이 있습니다. QXL 같은 driver는 먼저 `drm_atomic_helper_dirtyfb`를 사용하는 generic dirty tracking code로 옮겨야 합니다. `drm_fbdev_generic_setup()`을 사용해야 많은 custom fb setup code를 삭제할 수 있습니다.

그다음 `drm_gem_fb_create()`으로 전환합니다. 이 함수는 이제 atomic driver의 format 유효성을 검사합니다. 많은 driver가 `drm_framebuffer`를 subclass하므로 embedding과 호환되는 `drm_gem_fb_create` 계열도 필요합니다. 필요에 따라 `drm_gem_fb_create`, `_with_dirty`, `_with_funcs` 같은 형태를 고려할 수 있습니다. 연락처는 Simona Vetter이고 난이도는 `Intermediate`입니다.

Fbdev core의 defio 지원은 `struct page` 내부 field를 사용한다는 특수 요구가 있어 shmem GEM object 등을 깨뜨립니다. 영향을 받는 driver는 defio를 위해 shadow buffer를 사용해야 하며 CPU·memory overhead가 생길 수 있습니다.

가능한 해법은 DRM fbdev emulation에 자체 defio mmap code를 작성하는 것입니다. 기존 mmap operation을 완전히 감싸고 write-protect와 `mkwrite` 처리를 한 뒤 나머지 operation을 전달해야 합니다. `drm_fbdev_fb_mmap` helper에서 defio가 필요하면 `vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);`처럼 기본 page protection을 쓰기 금지로 바꿉니다.

Core fbdev defio와 비슷한 `mkwrite`·`fsync` callback을 설정합니다. 이 callback은 plain PTE에서 동작하므로 실제로 `struct page`가 필요하지 않습니다. Dirty page는 `struct page`를 훼손하지 않도록 page마다 1bit를 두는 별도 bitfield 같은 구조에서 추적합니다. 이 기능에는 IGT testcase를 추가하는 것도 좋습니다. 연락처는 Simona Vetter와 Noralf Tronnes이며 난이도는 `Advanced`입니다.

Benchmark and optimize blitting and format-conversion function
--------------------------------------------------------------

Drawing to display memory quickly is crucial for many applications'
performance.

On at least x86-64, sys_imageblit() is significantly slower than
cfb_imageblit(), even though both use the same blitting algorithm and
the latter is written for I/O memory. It turns out that cfb_imageblit()
uses movl instructions, while sys_imageblit apparently does not. This
seems to be a problem with gcc's optimizer. DRM's format-conversion
helpers might be subject to similar issues.

Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion
helpers. In cases that can be further optimized, maybe implement a different
algorithm. For micro-optimizations, use movl/movq instructions explicitly.
That might possibly require architecture-specific helpers (e.g., storel()
storeq()).

Contact: Thomas Zimmermann <[email protected]>

Level: Intermediate

drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
-----------------------------------------------------------------

A lot more drivers could be switched over to the drm_gem_framebuffer helpers.
Various hold-ups:

- Need to switch over to the generic dirty tracking code using
  drm_atomic_helper_dirtyfb first (e.g. qxl).

- Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb
  setup code can't be deleted.

- Need to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for
  valid formats for atomic drivers.

- Many drivers subclass drm_framebuffer, we'd need a embedding compatible
  version of the varios drm_gem_fb_create functions. Maybe called
  drm_gem_fb_create/_with_dirty/_with_funcs as needed.

Contact: Simona Vetter

Level: Intermediate

Generic fbdev defio support
---------------------------

The defio support code in the fbdev core has some very specific requirements,
which means drivers need to have a special framebuffer for fbdev. The main
issue is that it uses some fields in struct page itself, which breaks shmem
gem objects (and other things). To support defio, affected drivers require
the use of a shadow buffer, which may add CPU and memory overhead.

Possible solution would be to write our own defio mmap code in the drm fbdev
emulation. It would need to fully wrap the existing mmap ops, forwarding
everything after it has done the write-protect/mkwrite trickery:

- In the drm_fbdev_fb_mmap helper, if we need defio, change the
  default page prots to write-protected with something like this::

      vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);

- Set the mkwrite and fsync callbacks with similar implementions to the core
  fbdev defio stuff. These should all work on plain ptes, they don't actually
  require a struct page.  uff. These should all work on plain ptes, they don't
  actually require a struct page.

- Track the dirty pages in a separate structure (bitfield with one bit per page
  should work) to avoid clobbering struct page.

Might be good to also have some igt testcases for this.

Contact: Simona Vetter, Noralf Tronnes

Level: Advanced

Connector 생명주기·load callback·modeset property

대부분의 connector에서 driver가 `drm_connector_register()`와 `drm_connector_unregister()`를 직접 호출하는 것은 아무 효과가 없습니다. `drm_dev_register()`와 `drm_dev_unregister()`가 이미 처리하므로 직접 호출을 모두 제거할 수 있습니다.

DisplayPort driver는 `drm_dp_aux_register()`를 호출할 때 connector가 등록돼 있어야 해서 더 복잡합니다. 대신 `drm_dp_aux_init()`을 호출하고 실제 등록을 kernel-doc가 권장하는 `late_register` callback으로 옮겨 해결합니다. 난이도는 `Intermediate`입니다.

`struct drm_driver`의 load/unload callback은 중간 계층이며, 역사적 이유로 `drm_driver` 구조를 설정하는 작업과 `drm_dev_register()` 호출 사이의 순서도 잘못됐습니다. 이 순서는 호환성 때문에 고칠 수 없습니다. Driver의 probe 함수에 load/unload sequence를 직접 작성하여 callback 사용을 없애고, 모든 driver가 전환되면 callback 자체를 삭제합니다. 연락처는 Simona Vetter이고 난이도는 `Intermediate`입니다.

EDID를 parsing한 뒤 monitor의 HDMI 지원 여부는 `drm_display_info.is_hdmi`에서 확인할 수 있습니다. 여전히 같은 정보를 얻으려고 `drm_detect_hdmi_monitor()`를 호출하는 driver를 감사하고 적용 가능한 경우 `drm_display_info.is_hdmi`로 바꿉니다. 연락처는 Laurent Pinchart와 각 driver maintainer이며 난이도는 `Intermediate`입니다.

Atomic modeset 이전에는 많은 driver가 custom property를 만들었습니다. Atomic은 driver-specific custom property를 사용하지 않아야 한다는 요구도 도입했습니다. 이 과제는 core helper를 새로 만들거나 이미 존재하는 helper를 재사용해 property를 통합하는 것입니다.

확인이 더 필요한 예시 중 core helper를 도입할 후보는 audio(amdgpu, intel, gma500, radeon), overlay용으로 보이는 brightness·contrast 등(armada, nouveau), broadcast RGB(gma500, intel), overlay용으로 보이는 colorkey(armada, nouveau, rcar), driver마다 차이가 있는 dither(amdgpu, nouveau, radeon), underscan 계열(amdgpu, radeon, nouveau)입니다.

이미 core에 있는 항목은 colorspace(sti), TV format 이름과 enhancement(gma500, intel), TV overscan과 margin 등(gma500, intel), zorder와 같은 것으로 보이는 zpos(omapdrm)입니다. 연락처는 Emil Velikov와 각 driver maintainer이며 난이도는 `Intermediate`입니다.

connector register/unregister fixes
-----------------------------------

- For most connectors it's a no-op to call drm_connector_register/unregister
  directly from driver code, drm_dev_register/unregister take care of this
  already. We can remove all of them.

- For dp drivers it's a bit more a mess, since we need the connector to be
  registered when calling drm_dp_aux_register. Fix this by instead calling
  drm_dp_aux_init, and moving the actual registering into a late_register
  callback as recommended in the kerneldoc.

Level: Intermediate

Remove load/unload callbacks
----------------------------

The load/unload callbacks in struct &drm_driver are very much midlayers, plus
for historical reasons they get the ordering wrong (and we can't fix that)
between setting up the &drm_driver structure and calling drm_dev_register().

- Rework drivers to no longer use the load/unload callbacks, directly coding the
  load/unload sequence into the driver's probe function.

- Once all drivers are converted, remove the load/unload callbacks.

Contact: Simona Vetter

Level: Intermediate

Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
---------------------------------------------------------------

Once EDID is parsed, the monitor HDMI support information is available through
drm_display_info.is_hdmi. Many drivers still call drm_detect_hdmi_monitor() to
retrieve the same information, which is less efficient.

Audit each individual driver calling drm_detect_hdmi_monitor() and switch to
drm_display_info.is_hdmi if applicable.

Contact: Laurent Pinchart, respective driver maintainers

Level: Intermediate

Consolidate custom driver modeset properties
--------------------------------------------

Before atomic modeset took place, many drivers where creating their own
properties. Among other things, atomic brought the requirement that custom,
driver specific properties should not be used.

For this task, we aim to introduce core helpers or reuse the existing ones
if available:

A quick, unconfirmed, examples list.

Introduce core helpers:
- audio (amdgpu, intel, gma500, radeon)
- brightness, contrast, etc (armada, nouveau) - overlay only (?)
- broadcast rgb (gma500, intel)
- colorkey (armada, nouveau, rcar) - overlay only (?)
- dither (amdgpu, nouveau, radeon) - varies across drivers
- underscan family (amdgpu, radeon, nouveau)

Already in core:
- colorspace (sti)
- tv format names, enhancements (gma500, intel)
- tv overscan, margins, etc. (gma500, intel)
- zorder (omapdrm) - same as zpos (?)


Contact: Emil Velikov, respective driver maintainers

Level: Intermediate

iosys_map·mode_config 한계·fbdev 자원과 설정

공유 device memory pointer는 `struct iosys_map`에 저장합니다. 각 instance는 system memory인지 I/O memory인지 알고 있습니다. DRM 전반의 interface 대부분은 이미 `struct iosys_map`으로 전환됐지만 실제 구현에는 raw pointer가 자주 남아 있습니다.

적절한 곳에서 `struct iosys_map`을 사용해야 합니다. Memory manager는 dma-buf로 import한 buffer에 이를 사용하고, TTM 내부도 이 구조의 이점을 얻을 수 있습니다. Framebuffer copy·blit helper도 `struct iosys_map`을 대상으로 동작해야 합니다. 연락처는 Thomas Zimmermann `<[email protected]>`, Christian König, Simona Vetter이며 난이도는 `Intermediate`입니다.

`struct drm_mode_config`의 `max_width`와 `max_height`는 지원하는 최대 framebuffer 크기, 즉 virtual screen 크기를 나타냅니다. 많은 driver가 이를 physical resolution 제한처럼 잘못 취급합니다. 최대 width는 hardware의 최대 scanline pitch에, 최대 height는 addressable video memory 양에 따라 정해집니다. 모든 driver가 올바른 값으로 초기화하는지 검토해야 합니다. 연락처는 Thomas Zimmermann이고 난이도는 `Intermediate`입니다.

오래된 fbdev driver는 사용하는 memory를 제대로 요청하지 않는 경우가 있습니다. Driver를 순회하며 `request_mem_region()`, `pci_request_region()` 또는 유사 함수를 추가하고 가능한 곳에서는 managed cleanup helper를 사용합니다. VGA처럼 range가 배타적인 hardware는 주의해야 하며, VGA16fb는 해당 range를 요청하지 않는 것이 예상된 동작입니다.

과거 DRM과 fbdev driver 사이에 충돌이 있었고 이 영역의 driver 품질도 좋지 않지만 memory region을 요청하는 것이 올바른 동작입니다. 연락처는 Thomas Zimmermann이고 난이도는 `Starter`입니다.

일부 fbdev driver는 sysfs attribute를 제공하기 때문에 `CONFIG_FB_DEVICE`가 선택돼야 합니다. 각 driver를 검토해 이 의존성을 선택 사항으로 만들 수 있는지 시도합니다. 최소한 관련 코드를 `#ifdef CONFIG_FB_DEVICE`로 조건부 컴파일할 수 있습니다. 모든 driver가 의존성을 완전히 제거할 수 있는 것은 아닙니다. 연락처는 Thomas Zimmermann이고 난이도는 `Starter`입니다.

Use struct iosys_map throughout codebase
----------------------------------------

Pointers to shared device memory are stored in struct iosys_map. Each
instance knows whether it refers to system or I/O memory. Most of the DRM-wide
interface have been converted to use struct iosys_map, but implementations
often still use raw pointers.

The task is to use struct iosys_map where it makes sense.

* Memory managers should use struct iosys_map for dma-buf-imported buffers.
* TTM might benefit from using struct iosys_map internally.
* Framebuffer copying and blitting helpers should operate on struct iosys_map.

Contact: Thomas Zimmermann <[email protected]>, Christian König, Simona Vetter

Level: Intermediate

Review all drivers for setting struct drm_mode_config.{max_width,max_height} correctly
--------------------------------------------------------------------------------------

The values in struct drm_mode_config.{max_width,max_height} describe the
maximum supported framebuffer size. It's the virtual screen size, but many
drivers treat it like limitations of the physical resolution.

The maximum width depends on the hardware's maximum scanline pitch. The
maximum height depends on the amount of addressable video memory. Review all
drivers to initialize the fields to the correct values.

Contact: Thomas Zimmermann <[email protected]>

Level: Intermediate

Request memory regions in all fbdev drivers
--------------------------------------------

Old/ancient fbdev drivers do not request their memory properly.
Go through these drivers and add code to request the memory regions
that the driver uses. This requires adding calls to request_mem_region(),
pci_request_region() or similar functions. Use helpers for managed cleanup
where possible. Problematic areas include hardware that has exclusive ranges
like VGA. VGA16fb does not request the range as it is expected.
Drivers are pretty bad at doing this and there used to be conflicts among
DRM and fbdev drivers. Still, it's the correct thing to do.

Contact: Thomas Zimmermann <[email protected]>

Level: Starter

Remove driver dependencies on FB_DEVICE
---------------------------------------

A number of fbdev drivers provide attributes via sysfs and therefore depend
on CONFIG_FB_DEVICE to be selected. Review each driver and attempt to make
any dependencies on CONFIG_FB_DEVICE optional. At the minimum, the respective
code in the driver could be conditionalized via ifdef CONFIG_FB_DEVICE. Not
all drivers might be able to drop CONFIG_FB_DEVICE.

Contact: Thomas Zimmermann <[email protected]>

Level: Starter

Panel shutdown·MIPI DSI·bridge lifetime

Commit `d2aacaf07395` (`drm/panel: Check for already prepared/enabled in drm_panel`) 이후 DRM panel core는 `prepare`, `enable`, `disable`, `unprepare`가 중복 호출되지 않도록 검사합니다. 장기적으로 이 검사는 `WARN_ON()` 등 더 눈에 띄는 방식으로 바뀔 수 있습니다.

현재 `panel-simple`과 `panel-edp`는 여러 DRM modeset driver에서 사용되므로 shutdown 때 panel을 직접 `disable`·`unprepare`하려고 추가 작업을 수행합니다. Panel driver의 `shutdown()`이 modeset driver보다 먼저 실행되고, modeset driver도 자체 `shutdown()` callback에서 `drm_atomic_helper_shutdown()`을 올바르게 호출하면 panel core 경고가 발생할 수 있습니다.

Device link 등을 사용해 panel이 modeset driver 뒤에 shutdown되도록 보장하면 이런 경고를 피할 수 있습니다. 모든 DRM modeset driver가 올바르게 shutdown한다고 확인되면 `panel-simple`과 `panel-edp`의 remove/shutdown에서 추가 `disable`·`unprepare` 호출을 제거하고 이 TODO를 완료해야 합니다. 연락처는 Douglas Anderson `<[email protected]>`이고 난이도는 `Intermediate`입니다.

`drm_mipi_dsi.c`에는 deprecated 함수가 많이 있습니다. 각 함수는 `multi` variant로 대체됐습니다. 예를 들어 `mipi_dsi_generic_write()` 대신 `mipi_dsi_generic_write_multi()`를 사용합니다. `multi` variant는 error handling이 개선됐고 대부분의 MIPI driver처럼 여러 호출을 연속해서 실행하기 편리합니다.

Driver를 deprecated되지 않은 함수로 전환하고, deprecated MIPI DSI 함수의 사용이 모두 사라지면 `drm_mipi_dsi.c`에서 정의도 제거합니다. 연락처는 Douglas Anderson이고 난이도는 `Starter`입니다.

Panel bridge가 `drm_bridge` object lifetime을 처리하는 방식 때문에 `panel_bridge`를 제거할 때 object를 폐기하도록 특별히 주의해야 합니다. 현재 `devm_drm_put_bridge()`가 이를 관리하지만 안전하지 않은 임시 우회책입니다.

DRM panel lifetime을 다시 설계한 다음 `devm_drm_put_bridge()`와 `drm_panel_bridge_remove()`의 TODO를 제거해야 합니다. 연락처는 Maxime Ripard `<[email protected]>`와 Luca Ceresoli `<[email protected]>`이며 난이도는 `Intermediate`입니다.

Remove disable/unprepare in remove/shutdown in panel-simple and panel-edp
-------------------------------------------------------------------------

As of commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in
drm_panel"), we have a check in the drm_panel core to make sure nobody
double-calls prepare/enable/disable/unprepare. Eventually that should probably
be turned into a WARN_ON() or somehow made louder.

At the moment, we expect that we may still encounter the warnings in the
drm_panel core when using panel-simple and panel-edp. Since those panel
drivers are used with a lot of different DRM modeset drivers they still
make an extra effort to disable/unprepare the panel themsevles at shutdown
time. Specifically we could still encounter those warnings if the panel
driver gets shutdown() _before_ the DRM modeset driver and the DRM modeset
driver properly calls drm_atomic_helper_shutdown() in its own shutdown()
callback. Warnings could be avoided in such a case by using something like
device links to ensure that the panel gets shutdown() after the DRM modeset
driver.

Once all DRM modeset drivers are known to shutdown properly, the extra
calls to disable/unprepare in remove/shutdown in panel-simple and panel-edp
should be removed and this TODO item marked complete.

Contact: Douglas Anderson <[email protected]>

Level: Intermediate

Transition away from using deprecated MIPI DSI functions
--------------------------------------------------------

There are many functions defined in ``drm_mipi_dsi.c`` which have been
deprecated. Each deprecated function was deprecated in favor of its `multi`
variant (e.g. `mipi_dsi_generic_write()` and `mipi_dsi_generic_write_multi()`).
The `multi` variant of a function includes improved error handling and logic
which makes it more convenient to make several calls in a row, as most MIPI
drivers do.

Drivers should be updated to use undeprecated functions. Once all usages of the
deprecated MIPI DSI functions have been removed, their definitions may be
removed from ``drm_mipi_dsi.c``.

Contact: Douglas Anderson <[email protected]>

Level: Starter

Remove devm_drm_put_bridge()
----------------------------

Due to how the panel bridge handles the drm_bridge object lifetime, special
care must be taken to dispose of the drm_bridge object when the
panel_bridge is removed. This is currently managed using
devm_drm_put_bridge(), but that is an unsafe, temporary workaround. To fix
that, the DRM panel lifetime needs to be reworked. After the rework is
done, remove devm_drm_put_bridge() and the TODO in
drm_panel_bridge_remove().

Contact: Maxime Ripard <[email protected]>,
         Luca Ceresoli <[email protected]>

Level: Intermediate

Core panic·debugfs·object lifetime·dma-buf import

Core refactoring의 panic handling 과제는 여러 작은 문제로 나뉩니다. Panic은 hardirq context에서도 발생할 수 있어 관련 callback도 hardirq에서 실행될 수 있지만 현재 panic 경로를 시험할 방법이 없어 계속 깨집니다. DRM debugfs file을 통해 callback을 유발하고 local processor에 IPI를 보내 hardirq context를 만드는 방식으로 적어도 fbdev helper와 driver code를 시험할 수 있으면 좋습니다.

Panic handler가 여러 개라 서로 충돌하는 문제도 있습니다. 오래전에 제거된 DRM fbdev emulation helper의 자체 handler 외에도 fbcon 자체 handler가 있습니다. 현재는 DRM fbdev emulation helper 진입점에서 `oops_in_progress`를 확인해 우회합니다. 더 깔끔한 해법은 fbcon을 `threaded printk support`로 전환하는 것이며 관련 설명은 `https://lwn.net/Articles/800946/`에 있습니다.

`drm_can_sleep()`은 정상 동작의 실제 bug를 숨기고 panic 경로도 완전히 해결하지 못합니다. 실제 panic이 진행 중일 때만 true를 반환하도록 하고 그 영향으로 드러나는 문제를 모두 수정해야 합니다.

Panic handler는 절대 sleep하면 안 되므로 `mutex_lock()`도 호출할 수 없습니다. NMI와 hardirq에서도 panic이 날 수 있어 spinlock을 포함한 다른 lock조차 무조건 획득하면 안 됩니다. 그런 경로를 호출하지 않거나 모든 lock을 trylock 방식으로 처리해야 하므로 매우 까다롭습니다.

깔끔한 해법으로 현재 fbcon을 우회하는 별도의 KMS panic output 지원을 둘 수 있습니다. 제안 patch는 `https://lore.kernel.org/dri-devel/[email protected]/`에서 볼 수 있습니다. 실제 oops와 앞선 dmesg를 QR code로 encoding하면 중요한 내용이 화면 밖으로 밀리는 문제를 줄일 수 있으며 재사용 가능한 예제는 `https://lore.kernel.org/lkml/[email protected]/`에 있습니다. 연락처는 Simona Vetter이고 난이도는 `Advanced`입니다.

Debugfs 지원에는 네 가지 정리가 필요합니다. Driver를 `drm_debugfs_create_files()` 대신 `drm_debugfs_add_files()`로 전환합니다. Connector와 CRTC에도 같은 debugfs pre-register infrastructure를 적용해 late-register를 개선하면 driver가 setup code를 init과 register로 나눌 필요가 없습니다.

CRTC, connector와 다른 KMS object에 직접 debugfs file을 붙이는 core 지원도 고려합니다. 이 object의 funcs에는 KMS state를 출력하는 `drm_print` 지원이 이미 있으므로 `->show()` 함수가 올바른 object pointer를 받게 할 수 있습니다.

`drm_driver->debugfs_init` hook은 오래된 중간 계층 load sequence의 잔재입니다. DRM debugfs는 sysfs처럼 object의 property/file을 언제든 만들 수 있고 core가 register/unregister 때 publish/unpublish를 담당해야 합니다. 이를 `drm_minor`에서 `drm_device`로의 이동과 함께 고치면 `debugfs_init`을 제거할 수 있습니다. 연락처는 Simona Vetter이고 난이도는 `Intermediate`입니다.

Object lifetime에는 서로 연관된 두 문제가 있습니다. 많은 `->destroy` callback은 같은 단순 code를 반복하므로 정리할 수 있습니다. 또 많은 driver가 DRM modeset object를 `devm_kzalloc`으로 잘못 할당해 unload 때 use-after-free를 일으킵니다. SoC 내장 hardware driver도 `EPROBE_DEFERRED` backoff 때문에 심각한 영향을 받을 수 있습니다.

두 문제는 `drmm_kzalloc()`과 `drmm_crtc_alloc_with_planes()`, `drmm_universal_plane_alloc()` 같은 convenience wrapper로 전환해 해결할 수 있습니다. 연락처는 Simona Vetter이고 난이도는 `Intermediate`입니다.

Dma-buf import 시 dma-buf와 PRIME framework는 import된 page를 importer의 DMA area에 자동 mapping합니다. `drm_gem_prime_fd_to_handle()`과 `drm_gem_prime_handle_to_fd()`는 importer가 실제 device DMA 없이 `dma_buf_vmap()`으로 CPU access만 하더라도 `dma_buf_attach()`를 호출하도록 요구합니다. DMA operation을 지원하지 않는 USB device에는 문제가 됩니다.

Buffer-sharing code에서 automatic page mapping을 제거해야 합니다. Import/export cache도 `drm_gem_object.import_attach`에 묶여 있어 수정이 더 복잡합니다. 그동안은 DMA를 지원하는 USB host controller device를 찾아 임시로 우회하지만, 그렇지 않으면 import가 여전히 불필요하게 실패할 수 있습니다. 연락처는 Thomas Zimmermann과 Simona Vetter이며 난이도는 `Advanced`입니다.

Core refactorings
=================

Make panic handling work
------------------------

This is a really varied tasks with lots of little bits and pieces:

* The panic path can't be tested currently, leading to constant breaking. The
  main issue here is that panics can be triggered from hardirq contexts and
  hence all panic related callback can run in hardirq context. It would be
  awesome if we could test at least the fbdev helper code and driver code by
  e.g. trigger calls through drm debugfs files. hardirq context could be
  achieved by using an IPI to the local processor.

* There's a massive confusion of different panic handlers. DRM fbdev emulation
  helpers had their own (long removed), but on top of that the fbcon code itself
  also has one. We need to make sure that they stop fighting over each other.
  This is worked around by checking ``oops_in_progress`` at various entry points
  into the DRM fbdev emulation helpers. A much cleaner approach here would be to
  switch fbcon to the `threaded printk support
  <https://lwn.net/Articles/800946/>`_.

* ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and
  isn't a full solution for panic paths. We need to make sure that it only
  returns true if there's a panic going on for real, and fix up all the
  fallout.

* The panic handler must never sleep, which also means it can't ever
  ``mutex_lock()``. Also it can't grab any other lock unconditionally, not
  even spinlocks (because NMI and hardirq can panic too). We need to either
  make sure to not call such paths, or trylock everything. Really tricky.

* A clean solution would be an entirely separate panic output support in KMS,
  bypassing the current fbcon support. See `[PATCH v2 0/3] drm: Add panic handling
  <https://lore.kernel.org/dri-devel/[email protected]/>`_.

* Encoding the actual oops and preceding dmesg in a QR might help with the
  dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages
  transfer using QR codes
  <https://lore.kernel.org/lkml/[email protected]/>`_
  for some example code that could be reused.

Contact: Simona Vetter

Level: Advanced

Clean up the debugfs support
----------------------------

There's a bunch of issues with it:

- Convert drivers to support the drm_debugfs_add_files() function instead of
  the drm_debugfs_create_files() function.

- Improve late-register debugfs by rolling out the same debugfs pre-register
  infrastructure for connector and crtc too. That way, the drivers won't need to
  split their setup code into init and register anymore.

- We probably want to have some support for debugfs files on crtc/connectors and
  maybe other kms objects directly in core. There's even drm_print support in
  the funcs for these objects to dump kms state, so it's all there. And then the
  ->show() functions should obviously give you a pointer to the right object.

- The drm_driver->debugfs_init hooks we have is just an artifact of the old
  midlayered load sequence. DRM debugfs should work more like sysfs, where you
  can create properties/files for an object anytime you want, and the core
  takes care of publishing/unpuplishing all the files at register/unregister
  time. Drivers shouldn't need to worry about these technicalities, and fixing
  this (together with the drm_minor->drm_device move) would allow us to remove
  debugfs_init.

Contact: Simona Vetter

Level: Intermediate

Object lifetime fixes
---------------------

There's two related issues here

- Cleanup up the various ->destroy callbacks, which often are all the same
  simple code.

- Lots of drivers erroneously allocate DRM modeset objects using devm_kzalloc,
  which results in use-after free issues on driver unload. This can be serious
  trouble even for drivers for hardware integrated on the SoC due to
  EPROBE_DEFERRED backoff.

Both these problems can be solved by switching over to drmm_kzalloc(), and the
various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(),
drmm_universal_plane_alloc(), ... and so on.

Contact: Simona Vetter

Level: Intermediate

Remove automatic page mapping from dma-buf importing
----------------------------------------------------

When importing dma-bufs, the dma-buf and PRIME frameworks automatically map
imported pages into the importer's DMA area. drm_gem_prime_fd_to_handle() and
drm_gem_prime_handle_to_fd() require that importers call dma_buf_attach()
even if they never do actual device DMA, but only CPU access through
dma_buf_vmap(). This is a problem for USB devices, which do not support DMA
operations.

To fix the issue, automatic page mappings should be removed from the
buffer-sharing code. Fixing this is a bit more involved, since the import/export
cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over
this problem for USB devices by fishing out the USB host controller device, as
long as that supports DMA. Otherwise importing can still needlessly fail.

Contact: Thomas Zimmermann <[email protected]>, Simona Vetter

Level: Advanced

KUnit·IGT·VKMS와 backlight 상태 정리

KUnit은 Linux kernel 내부 unit test를 위한 공통 framework이며 문서는 `https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html`에 있습니다. Test suite가 있으면 regression을 더 일찍 찾을 수 있습니다. 첫 unit test 후보로 `drm_format_helper.c`의 format-conversion helper가 적합합니다. 연락처는 Javier Martinez Canillas `<[email protected]>`이고 난이도는 `Intermediate`입니다.

일부 KUnit suite는 KUnit 도입 초기에 기존 selftest에서 변환한 것입니다. 대상은 `drm_buddy`, `drm_cmdline_parser`, `drm_damage_helper`, `drm_format`, `drm_framebuffer`, `drm_dp_mst_helper`, `drm_mm`, `drm_plane_helper`, `drm_rect`입니다.

이 suite들은 문서가 부족하고 unit test와 목표도 달랐습니다. 각 test가 실제로 무엇을 검사하는지, unit test로 적절한지 파악해야 합니다. 적절하지 않으면 제거하고 적절하면 문서화하는 것이 큰 도움이 됩니다. 연락처는 Maxime Ripard `<[email protected]>`이고 난이도는 `Intermediate`입니다.

DRM에 Trinity를 활성화하고 그 결과로 드러나는 문제를 수정하는 과제도 있습니다. 흥미로운 결과가 예상되며 난이도는 `Advanced`입니다.

i915 팀은 modesetting API의 corner case를 포함한 광범위한 IGT test suite를 유지합니다. Intel-specific GEM 기능에 의존하지 않는 test부터 모든 KMS driver에서 실행할 수 있게 generic하게 만들면 좋습니다.

비-i915 환경에서 IGT를 실행하는 기본 작업은 끝났고 이제 많은 test를 일괄 전환해야 합니다. Modeset test에는 untiled buffer로 dumb buffer를 사용하는 infrastructure가 먼저 필요하며, 그래야 i915 전용이 아닌 modeset test를 모두 실행할 수 있습니다. 난이도는 `Advanced`입니다.

Virtual test driver인 VKMS 확장은 `:ref:`VKMS <vkms>`` 문서를 참고합니다. Virtual machine만 필요하고 가용 기간에 맞춰 범위를 조정할 수 있어 internship 과제로 이상적입니다. 난이도는 상세 문서에 따릅니다.

Backlight driver는 세 가지 enable/disable 상태를 갖는데 지나치게 복잡합니다. 정리 계획은 세 단계입니다. 첫째, 이미 시작된 `backlight_enable()`과 `backlight_disable()` helper 적용을 모든 곳으로 확대합니다. 둘째, 모든 코드가 이 helper가 설정한 세 status bit 중 하나만 보게 합니다. 셋째, 나머지 두 status bit를 제거합니다. 연락처는 Simona Vetter이고 난이도는 `Intermediate`입니다.

Better Testing
==============

Add unit tests using the Kernel Unit Testing (KUnit) framework
--------------------------------------------------------------

The `KUnit <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
provides a common framework for unit tests within the Linux kernel. Having a
test suite would allow to identify regressions earlier.

A good candidate for the first unit tests are the format-conversion helpers in
``drm_format_helper.c``.

Contact: Javier Martinez Canillas <[email protected]>

Level: Intermediate

Clean up and document former selftests suites
---------------------------------------------

Some KUnit test suites (drm_buddy, drm_cmdline_parser, drm_damage_helper,
drm_format, drm_framebuffer, drm_dp_mst_helper, drm_mm, drm_plane_helper and
drm_rect) are former selftests suites that have been converted over when KUnit
was first introduced.

These suites were fairly undocumented, and with different goals than what unit
tests can be. Trying to identify what each test in these suites actually test
for, whether that makes sense for a unit test, and either remove it if it
doesn't or document it if it does would be of great help.

Contact: Maxime Ripard <[email protected]>

Level: Intermediate

Enable trinity for DRM
----------------------

And fix up the fallout. Should be really interesting ...

Level: Advanced

Make KMS tests in i-g-t generic
-------------------------------

The i915 driver team maintains an extensive testsuite for the i915 DRM driver,
including tons of testcases for corner-cases in the modesetting API. It would
be awesome if those tests (at least the ones not relying on Intel-specific GEM
features) could be made to run on any KMS driver.

Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass-
converting things over. For modeset tests we also first need a bit of
infrastructure to use dumb buffers for untiled buffers, to be able to run all
the non-i915 specific modeset tests.

Level: Advanced

Extend virtual test driver (VKMS)
---------------------------------

See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal
internship task, since it only requires a virtual machine and can be sized to
fit the available time.

Level: See details

Backlight Refactoring
---------------------

Backlight drivers have a triple enable/disable state, which is a bit overkill.
Plan to fix this:

1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This
   has started already.
2. In all, only look at one of the three status bits set by the above helpers.
3. Remove the other two status bits.

Contact: Simona Vetter

Level: Intermediate

AMD DC와 DRM client bootsplash

Driver-specific 과제 중 AMD DC는 Vega부터의 AMD device를 위한 display driver입니다. 상당한 cleanup이 진행됐지만 아직 할 일이 많습니다. 구체적인 과제는 `drivers/gpu/drm/amd/display/TODO`를 참고합니다. 연락처는 Harry Wentland와 Alex Deucher입니다.

이제 internal DRM client를 작성할 수 있으므로 fbdev 대상으로 작성돼 거절됐던 bootsplash 작업을 다시 진행할 기반이 있습니다.

DRM client bootsplash 예제 patch `[v6,8/8] drm/client: Hack: Add bootsplash example`은 `https://patchwork.freedesktop.org/patch/306579/`에 있습니다. Kernel 기반 bootsplash 제안 `[RFC PATCH v2 00/13] Kernel based bootsplash`는 `https://lore.kernel.org/r/[email protected]`에서 볼 수 있습니다.

Bootsplash 과제의 연락처는 Sam Ravnborg이며 난이도는 `Advanced`입니다.

Driver Specific
===============

AMD DC Display Driver
---------------------

AMD DC is the display driver for AMD devices starting with Vega. There has been
a bunch of progress cleaning it up but there's still plenty of work to be done.

See drivers/gpu/drm/amd/display/TODO for tasks.

Contact: Harry Wentland, Alex Deucher

Bootsplash
==========

There is support in place now for writing internal DRM clients making it
possible to pick up the bootsplash work that was rejected because it was written
for fbdev.

- [v6,8/8] drm/client: Hack: Add bootsplash example
  https://patchwork.freedesktop.org/patch/306579/

- [RFC PATCH v2 00/13] Kernel based bootsplash
  https://lore.kernel.org/r/[email protected]

Contact: Sam Ravnborg

Level: Advanced

다중 panel 밝기·buffer damage·syncobj error

x86/ACPI device에는 ACPI video, vendor-specific interface와 KMS driver가 직접 수행하는 native PWM register programming 등 여러 backlight firmware interface가 있을 수 있습니다.

x86/ACPI용 backlight driver는 `acpi_video_get_backlight_type()`의 heuristic과 quirk로 사용할 interface를 선택합니다. 반환된 type과 맞지 않는 driver는 등록하지 않아 단일 GPU 구성에서는 backlight device 하나만 등록됩니다. 이 설계는 내부 panel이 하나뿐이라고 거의 가정합니다.

Panel이 두 개일 때 선택된 interface에 따라 문제가 달라집니다. `native`이면 KMS driver가 각 backlight device와 output의 관계를 알아야 하므로 정상 동작할 것으로 기대됩니다. `video`는 여러 backlight 제어를 지원하지만 output과 backlight device의 mapping을 만드는 작업이 필요합니다.

두 panel이 같은 backlight interface type을 요구한다는 가정도 있습니다. 한 panel은 ACPI video, 다른 panel은 native control이 필요하면 현재 `acpi_video_get_backlight_type()` 반환값에 따라 필요한 두 device 중 하나만 등록됩니다. 이런 사례가 실제로 나타나면 함수에 device와 connector 이름을 전달하여 개별 panel을 구분하도록 확장하는 방법을 고려할 수 있습니다.

Mux가 있는 dual-GPU laptop에서는 userspace에 panel 두 개처럼 보이는 비슷한 사례가 이미 있습니다. 원문은 이 경우 두 native backlight device를 보게 되는 두 경우를 같은 표현으로 반복해 적고 있습니다. Userspace는 GPU와 panel 사이 mux 방향으로 관련 panel이 활성 상태인지 감지한 뒤 해당 backlight device를 사용하지만, 여전히 panel 하나만 가정하여 두 device 중 하나만 고릅니다.

알려진 userspace 구현은 모두 panel 하나를 가정합니다. 최근 단일 GPU laptop의 panel 하나에 video와 native 같은 여러 `/sys/class/backlight` device를 등록하지 않도록 바뀌기 전에는, userspace가 같은 backlight를 제어하는 여러 device 중 선호하는 하나만 선택하고 나머지는 무시해야 했습니다. 여러 panel의 밝기를 제어하려면 userspace도 갱신해야 합니다.

Panel용 `drm_connector` object에 `display brightness` property를 추가해 KMS API를 통해 밝기를 제어하려는 계획이 있습니다. 이는 sysfs backlight device를 특정 connector에 mapping할 수 없는 문제를 포함해 `/sys/class/backlight` API의 여러 한계를 해결합니다. 다중 panel 밝기를 지원하는 userspace 변경은 이 새 KMS property를 기반으로 해야 합니다. 연락처는 Hans de Goede이고 난이도는 `Advanced`입니다.

Buffer 단위 upload를 하는 driver는 plane·CRTC 단위 frame damage가 아니라 buffer damage 처리가 필요합니다. 하지만 buffer age나 다른 damage accumulation algorithm을 얻을 지원이 없습니다.

현재 damage helper는 plane에 연결된 framebuffer가 마지막 page flip 이후 바뀌면 전체 plane update로 fallback합니다. Driver는 `drm_plane_state.ignore_damage_clips`를 true로 설정하여 `drm_atomic_helper_damage_iter_init()`과 `drm_atomic_helper_damage_iter_next()`에 damage clip을 무시하라고 알립니다. Per-buffer upload driver에서도 damage tracking이 제대로 동작하도록 개선해야 합니다. 학습 자료와 자세한 설명은 `:ref:`damage_tracking_properties``에 있습니다. 연락처는 Javier Martinez Canillas이고 난이도는 `Advanced`입니다.

`drm_syncobj` container는 driver-independent code가 submission completion을 signal하는 데 사용할 수 있습니다. 아직 빠진 작은 기능은 binary와 timeline `drm_syncobj`의 error status를 query하는 generic DRM IOCTL입니다. 필요한 kernel interface를 구현하고 userspace stack에도 지원을 추가해야 합니다. 연락처는 Christian König이고 난이도는 `Starter`입니다.

Brightness handling on devices with multiple internal panels
============================================================

On x86/ACPI devices there can be multiple backlight firmware interfaces:
(ACPI) video, vendor specific and others. As well as direct/native (PWM)
register programming by the KMS driver.

To deal with this backlight drivers used on x86/ACPI call
acpi_video_get_backlight_type() which has heuristics (+quirks) to select
which backlight interface to use; and backlight drivers which do not match
the returned type will not register themselves, so that only one backlight
device gets registered (in a single GPU setup, see below).

At the moment this more or less assumes that there will only
be 1 (internal) panel on a system.

On systems with 2 panels this may be a problem, depending on
what interface acpi_video_get_backlight_type() selects:

1. native: in this case the KMS driver is expected to know which backlight
   device belongs to which output so everything should just work.
2. video: this does support controlling multiple backlights, but some work
   will need to be done to get the output <-> backlight device mapping

The above assumes both panels will require the same backlight interface type.
Things will break on systems with multiple panels where the 2 panels need
a different type of control. E.g. one panel needs ACPI video backlight control,
where as the other is using native backlight control. Currently in this case
only one of the 2 required backlight devices will get registered, based on
the acpi_video_get_backlight_type() return value.

If this (theoretical) case ever shows up, then supporting this will need some
work. A possible solution here would be to pass a device and connector-name
to acpi_video_get_backlight_type() so that it can deal with this.

Note in a way we already have a case where userspace sees 2 panels,
in dual GPU laptop setups with a mux. On those systems we may see
either 2 native backlight devices; or 2 native backlight devices.

Userspace already has code to deal with this by detecting if the related
panel is active (iow which way the mux between the GPU and the panels
points) and then uses that backlight device. Userspace here very much
assumes a single panel though. It picks only 1 of the 2 backlight devices
and then only uses that one.

Note that all userspace code (that I know off) is currently hardcoded
to assume a single panel.

Before the recent changes to not register multiple (e.g. video + native)
/sys/class/backlight devices for a single panel (on a single GPU laptop),
userspace would see multiple backlight devices all controlling the same
backlight.

To deal with this userspace had to always picks one preferred device under
/sys/class/backlight and will ignore the others. So to support brightness
control on multiple panels userspace will need to be updated too.

There are plans to allow brightness control through the KMS API by adding
a "display brightness" property to drm_connector objects for panels. This
solves a number of issues with the /sys/class/backlight API, including not
being able to map a sysfs backlight device to a specific connector. Any
userspace changes to add support for brightness control on devices with
multiple panels really should build on top of this new KMS property.

Contact: Hans de Goede

Level: Advanced

Buffer age or other damage accumulation algorithm for buffer damage
===================================================================

Drivers that do per-buffer uploads, need a buffer damage handling (rather than
frame damage like drivers that do per-plane or per-CRTC uploads), but there is
no support to get the buffer age or any other damage accumulation algorithm.

For this reason, the damage helpers just fallback to a full plane update if the
framebuffer attached to a plane has changed since the last page-flip. Drivers
set &drm_plane_state.ignore_damage_clips to true as indication to
drm_atomic_helper_damage_iter_init() and drm_atomic_helper_damage_iter_next()
helpers that the damage clips should be ignored.

This should be improved to get damage tracking properly working on drivers that
do per-buffer uploads.

More information about damage tracking and references to learning materials can
be found in :ref:`damage_tracking_properties`.

Contact: Javier Martinez Canillas <[email protected]>

Level: Advanced

Querying errors from drm_syncobj
================================

The drm_syncobj container can be used by driver independent code to signal
complection of submission.

One minor feature still missing is a generic DRM IOCTL to query the error
status of binary and timeline drm_syncobj.

This should probably be improved by implementing the necessary kernel interface
and adding support for that in the userspace stack.

Contact: Christian König

Level: Starter

Fbdev driver를 DRM으로 전환

DRM 밖의 과제로 오래된 hardware를 위한 fbdev driver가 많이 남아 있습니다. 일부 hardware는 obsolete됐지만 여전히 충분히 쓸 만한 framebuffer를 제공하는 장치도 있습니다. 유용한 driver는 DRM으로 전환한 뒤 fbdev에서 제거해야 합니다.

매우 단순한 fbdev driver는 새 DRM driver로 시작해 전환하는 것이 좋습니다. Simple KMS helper와 SHMEM이면 기존 hardware를 처리할 수 있고, 새 driver의 callback 함수 구현은 기존 fbdev code에서 가져옵니다.

더 복잡한 fbdev driver는 DRM fbconv helper를 사용해 단계적으로 DRM driver로 refactoring할 수 있습니다. 이 helper는 DRM core infrastructure와 fbdev driver interface 사이의 transition layer를 제공합니다.

Fbconv helper 위에 새 DRM driver를 만들고 기존 fbdev driver code를 복사한 뒤 DRM code에 연결합니다. 여러 fbdev driver의 예시는 Thomas Zimmermann의 fbconv tree `https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv`에 있고, 과정의 tutorial은 `https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c`에 있습니다. 결과물은 X11과 Weston을 실행할 수 있는 기본적인 DRM driver입니다.

연락처는 Thomas Zimmermann `<[email protected]>`이고 난이도는 `Advanced`입니다.

Outside DRM
===========

Convert fbdev drivers to DRM
----------------------------

There are plenty of fbdev drivers for older hardware. Some hardware has
become obsolete, but some still provides good(-enough) framebuffers. The
drivers that are still useful should be converted to DRM and afterwards
removed from fbdev.

Very simple fbdev drivers can best be converted by starting with a new
DRM driver. Simple KMS helpers and SHMEM should be able to handle any
existing hardware. The new driver's call-back functions are filled from
existing fbdev code.

More complex fbdev drivers can be refactored step-by-step into a DRM
driver with the help of the DRM fbconv helpers [4]_. These helpers provide
the transition layer between the DRM core infrastructure and the fbdev
driver interface. Create a new DRM driver on top of the fbconv helpers,
copy over the fbdev driver, and hook it up to the DRM code. Examples for
several fbdev drivers are available in Thomas Zimmermann's fbconv tree
[4]_, as well as a tutorial of this process [5]_. The result is a primitive
DRM driver that can run X11 and Weston.

 .. [4] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv
 .. [5] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c

Contact: Thomas Zimmermann <[email protected]>

Level: Advanced