1.. _todo: 2 3========= 4TODO list 5========= 6 7This section contains a list of smaller janitorial tasks in the kernel DRM 8graphics subsystem useful as newbie projects. Or for slow rainy days. 9 10Difficulty 11---------- 12 13To make it easier task are categorized into different levels: 14 15Starter: Good tasks to get started with the DRM subsystem. 16 17Intermediate: Tasks which need some experience with working in the DRM 18subsystem, or some specific GPU/display graphics knowledge. For debugging issue 19it's good to have the relevant hardware (or a virtual driver set up) available 20for testing. 21 22Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem 23and graphics topics. Generally need the relevant hardware for development and 24testing. 25 26Expert: Only attempt these if you've successfully completed some tricky 27refactorings already and are an expert in the specific area 28 29Subsystem-wide refactorings 30=========================== 31 32Remove custom dumb_map_offset implementations 33--------------------------------------------- 34 35All GEM based drivers should be using drm_gem_create_mmap_offset() instead. 36Audit each individual driver, make sure it'll work with the generic 37implementation (there's lots of outdated locking leftovers in various 38implementations), and then remove it. 39 40Contact: Simona Vetter, respective driver maintainers 41 42Level: Intermediate 43 44Convert existing KMS drivers to atomic modesetting 45-------------------------------------------------- 46 473.19 has the atomic modeset interfaces and helpers, so drivers can now be 48converted over. Modern compositors like Wayland or Surfaceflinger on Android 49really want an atomic modeset interface, so this is all about the bright 50future. 51 52There is a conversion guide for atomic [1]_ and all you need is a GPU for a 53non-converted driver. The "Atomic mode setting design overview" series [2]_ 54[3]_ at LWN.net can also be helpful. 55 56As part of this drivers also need to convert to universal plane (which means 57exposing primary & cursor as proper plane objects). But that's much easier to 58do by directly using the new atomic helper driver callbacks. 59 60 .. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html 61 .. [2] https://lwn.net/Articles/653071/ 62 .. [3] https://lwn.net/Articles/653466/ 63 64Contact: Simona Vetter, respective driver maintainers 65 66Level: Advanced 67 68Clean up the clipped coordination confusion around planes 69--------------------------------------------------------- 70 71We have a helper to get this right with drm_plane_helper_check_update(), but 72it's not consistently used. This should be fixed, preferably in the atomic 73helpers (and drivers then moved over to clipped coordinates). Probably the 74helper should also be moved from drm_plane_helper.c to the atomic helpers, to 75avoid confusion - the other helpers in that file are all deprecated legacy 76helpers. 77 78Contact: Ville Syrjälä, Simona Vetter, driver maintainers 79 80Level: Advanced 81 82Improve plane atomic_check helpers 83---------------------------------- 84 85Aside from the clipped coordinates right above there's a few suboptimal things 86with the current helpers: 87 88- drm_plane_helper_funcs->atomic_check gets called for enabled or disabled 89 planes. At best this seems to confuse drivers, worst it means they blow up 90 when the plane is disabled without the CRTC. The only special handling is 91 resetting values in the plane state structures, which instead should be moved 92 into the drm_plane_funcs->atomic_duplicate_state functions. 93 94- Once that's done, helpers could stop calling ->atomic_check for disabled 95 planes. 96 97- Then we could go through all the drivers and remove the more-or-less confused 98 checks for plane_state->fb and plane_state->crtc. 99 100Contact: Simona Vetter 101 102Level: Advanced 103 104Convert early atomic drivers to async commit helpers 105---------------------------------------------------- 106 107For the first year the atomic modeset helpers didn't support asynchronous / 108nonblocking commits, and every driver had to hand-roll them. This is fixed 109now, but there's still a pile of existing drivers that easily could be 110converted over to the new infrastructure. 111 112One issue with the helpers is that they require that drivers handle completion 113events for atomic commits correctly. But fixing these bugs is good anyway. 114 115Somewhat related is the legacy_cursor_update hack, which should be replaced with 116the new atomic_async_check/commit functionality in the helpers in drivers that 117still look at that flag. 118 119Contact: Simona Vetter, respective driver maintainers 120 121Level: Advanced 122 123Rename drm_atomic_state 124----------------------- 125 126The KMS framework uses two slightly different definitions for the ``state`` 127concept. For a given object (plane, CRTC, encoder, etc., so 128``drm_$OBJECT_state``), the state is the entire state of that object. However, 129at the device level, ``drm_atomic_state`` refers to a state update for a 130limited number of objects. 131 132The state isn't the entire device state, but only the full state of some 133objects in that device. This is confusing to newcomers, and 134``drm_atomic_state`` should be renamed to something clearer like 135``drm_atomic_commit``. 136 137In addition to renaming the structure itself, it would also imply renaming some 138related functions (``drm_atomic_state_alloc``, ``drm_atomic_state_get``, 139``drm_atomic_state_put``, ``drm_atomic_state_init``, 140``__drm_atomic_state_free``, etc.). 141 142Contact: Maxime Ripard <mripard@kernel.org> 143 144Level: Advanced 145 146Fallout from atomic KMS 147----------------------- 148 149``drm_atomic_helper.c`` provides a batch of functions which implement legacy 150IOCTLs on top of the new atomic driver interface. Which is really nice for 151gradual conversion of drivers, but unfortunately the semantic mismatches are 152a bit too severe. So there's some follow-up work to adjust the function 153interfaces to fix these issues: 154 155* atomic needs the lock acquire context. At the moment that's passed around 156 implicitly with some horrible hacks, and it's also allocate with 157 ``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating 158 the acquire context explicitly on stack and then also pass it down into 159 drivers explicitly so that the legacy-on-atomic functions can use them. 160 161 Except for some driver code this is done. This task should be finished by 162 adding WARN_ON(!drm_drv_uses_atomic_modeset) in drm_modeset_lock_all(). 163 164* A bunch of the vtable hooks are now in the wrong place: DRM has a split 165 between core vfunc tables (named ``drm_foo_funcs``), which are used to 166 implement the userspace ABI. And then there's the optional hooks for the 167 helper libraries (name ``drm_foo_helper_funcs``), which are purely for 168 internal use. Some of these hooks should be move from ``_funcs`` to 169 ``_helper_funcs`` since they are not part of the core ABI. There's a 170 ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``. 171 172Contact: Simona Vetter 173 174Level: Intermediate 175 176Move Buffer Object Locking to dma_resv_lock() 177--------------------------------------------- 178 179Many drivers have their own per-object locking scheme, usually using 180mutex_lock(). This causes all kinds of trouble for buffer sharing, since 181depending which driver is the exporter and importer, the locking hierarchy is 182reversed. 183 184To solve this we need one standard per-object locking mechanism, which is 185dma_resv_lock(). This lock needs to be called as the outermost lock, with all 186other driver specific per-object locks removed. The problem is that rolling out 187the actual change to the locking contract is a flag day, due to struct dma_buf 188buffer sharing. 189 190Level: Expert 191 192Convert logging to drm_* functions with drm_device parameter 193------------------------------------------------------------ 194 195For drivers which could have multiple instances, it is necessary to 196differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR 197don't do this, drivers used dev_info/warn/err to make this differentiation. We 198now have drm_* variants of the drm print functions, so we can start to convert 199those drivers back to using drm-formatted specific log messages. 200 201Before you start this conversion please contact the relevant maintainers to make 202sure your work will be merged - not everyone agrees that the DRM dmesg macros 203are better. 204 205Contact: Sean Paul, Maintainer of the driver you plan to convert 206 207Level: Starter 208 209Convert drivers to use simple modeset suspend/resume 210---------------------------------------------------- 211 212Most drivers (except i915 and nouveau) that use 213drm_atomic_helper_suspend/resume() can probably be converted to use 214drm_mode_config_helper_suspend/resume(). Also there's still open-coded version 215of the atomic suspend/resume code in older atomic modeset drivers. 216 217Contact: Maintainer of the driver you plan to convert 218 219Level: Intermediate 220 221Reimplement functions in drm_fbdev_fb_ops without fbdev 222------------------------------------------------------- 223 224A number of callback functions in drm_fbdev_fb_ops could benefit from 225being rewritten without dependencies on the fbdev module. Some of the 226helpers could further benefit from using struct iosys_map instead of 227raw pointers. 228 229Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter 230 231Level: Advanced 232 233Benchmark and optimize blitting and format-conversion function 234-------------------------------------------------------------- 235 236Drawing to display memory quickly is crucial for many applications' 237performance. 238 239On at least x86-64, sys_imageblit() is significantly slower than 240cfb_imageblit(), even though both use the same blitting algorithm and 241the latter is written for I/O memory. It turns out that cfb_imageblit() 242uses movl instructions, while sys_imageblit apparently does not. This 243seems to be a problem with gcc's optimizer. DRM's format-conversion 244helpers might be subject to similar issues. 245 246Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion 247helpers. In cases that can be further optimized, maybe implement a different 248algorithm. For micro-optimizations, use movl/movq instructions explicitly. 249That might possibly require architecture-specific helpers (e.g., storel() 250storeq()). 251 252Contact: Thomas Zimmermann <tzimmermann@suse.de> 253 254Level: Intermediate 255 256drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup 257----------------------------------------------------------------- 258 259A lot more drivers could be switched over to the drm_gem_framebuffer helpers. 260Various hold-ups: 261 262- Need to switch over to the generic dirty tracking code using 263 drm_atomic_helper_dirtyfb first (e.g. qxl). 264 265- Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb 266 setup code can't be deleted. 267 268- Need to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for 269 valid formats for atomic drivers. 270 271- Many drivers subclass drm_framebuffer, we'd need a embedding compatible 272 version of the varios drm_gem_fb_create functions. Maybe called 273 drm_gem_fb_create/_with_dirty/_with_funcs as needed. 274 275Contact: Simona Vetter 276 277Level: Intermediate 278 279Generic fbdev defio support 280--------------------------- 281 282The defio support code in the fbdev core has some very specific requirements, 283which means drivers need to have a special framebuffer for fbdev. The main 284issue is that it uses some fields in struct page itself, which breaks shmem 285gem objects (and other things). To support defio, affected drivers require 286the use of a shadow buffer, which may add CPU and memory overhead. 287 288Possible solution would be to write our own defio mmap code in the drm fbdev 289emulation. It would need to fully wrap the existing mmap ops, forwarding 290everything after it has done the write-protect/mkwrite trickery: 291 292- In the drm_fbdev_fb_mmap helper, if we need defio, change the 293 default page prots to write-protected with something like this:: 294 295 vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot); 296 297- Set the mkwrite and fsync callbacks with similar implementions to the core 298 fbdev defio stuff. These should all work on plain ptes, they don't actually 299 require a struct page. uff. These should all work on plain ptes, they don't 300 actually require a struct page. 301 302- Track the dirty pages in a separate structure (bitfield with one bit per page 303 should work) to avoid clobbering struct page. 304 305Might be good to also have some igt testcases for this. 306 307Contact: Simona Vetter, Noralf Tronnes 308 309Level: Advanced 310 311connector register/unregister fixes 312----------------------------------- 313 314- For most connectors it's a no-op to call drm_connector_register/unregister 315 directly from driver code, drm_dev_register/unregister take care of this 316 already. We can remove all of them. 317 318- For dp drivers it's a bit more a mess, since we need the connector to be 319 registered when calling drm_dp_aux_register. Fix this by instead calling 320 drm_dp_aux_init, and moving the actual registering into a late_register 321 callback as recommended in the kerneldoc. 322 323Level: Intermediate 324 325Remove load/unload callbacks 326---------------------------- 327 328The load/unload callbacks in struct &drm_driver are very much midlayers, plus 329for historical reasons they get the ordering wrong (and we can't fix that) 330between setting up the &drm_driver structure and calling drm_dev_register(). 331 332- Rework drivers to no longer use the load/unload callbacks, directly coding the 333 load/unload sequence into the driver's probe function. 334 335- Once all drivers are converted, remove the load/unload callbacks. 336 337Contact: Simona Vetter 338 339Level: Intermediate 340 341Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi 342--------------------------------------------------------------- 343 344Once EDID is parsed, the monitor HDMI support information is available through 345drm_display_info.is_hdmi. Many drivers still call drm_detect_hdmi_monitor() to 346retrieve the same information, which is less efficient. 347 348Audit each individual driver calling drm_detect_hdmi_monitor() and switch to 349drm_display_info.is_hdmi if applicable. 350 351Contact: Laurent Pinchart, respective driver maintainers 352 353Level: Intermediate 354 355Consolidate custom driver modeset properties 356-------------------------------------------- 357 358Before atomic modeset took place, many drivers where creating their own 359properties. Among other things, atomic brought the requirement that custom, 360driver specific properties should not be used. 361 362For this task, we aim to introduce core helpers or reuse the existing ones 363if available: 364 365A quick, unconfirmed, examples list. 366 367Introduce core helpers: 368- audio (amdgpu, intel, gma500, radeon) 369- brightness, contrast, etc (armada, nouveau) - overlay only (?) 370- broadcast rgb (gma500, intel) 371- colorkey (armada, nouveau, rcar) - overlay only (?) 372- dither (amdgpu, nouveau, radeon) - varies across drivers 373- underscan family (amdgpu, radeon, nouveau) 374 375Already in core: 376- colorspace (sti) 377- tv format names, enhancements (gma500, intel) 378- tv overscan, margins, etc. (gma500, intel) 379- zorder (omapdrm) - same as zpos (?) 380 381 382Contact: Emil Velikov, respective driver maintainers 383 384Level: Intermediate 385 386Use struct iosys_map throughout codebase 387---------------------------------------- 388 389Pointers to shared device memory are stored in struct iosys_map. Each 390instance knows whether it refers to system or I/O memory. Most of the DRM-wide 391interface have been converted to use struct iosys_map, but implementations 392often still use raw pointers. 393 394The task is to use struct iosys_map where it makes sense. 395 396* Memory managers should use struct iosys_map for dma-buf-imported buffers. 397* TTM might benefit from using struct iosys_map internally. 398* Framebuffer copying and blitting helpers should operate on struct iosys_map. 399 400Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Simona Vetter 401 402Level: Intermediate 403 404Review all drivers for setting struct drm_mode_config.{max_width,max_height} correctly 405-------------------------------------------------------------------------------------- 406 407The values in struct drm_mode_config.{max_width,max_height} describe the 408maximum supported framebuffer size. It's the virtual screen size, but many 409drivers treat it like limitations of the physical resolution. 410 411The maximum width depends on the hardware's maximum scanline pitch. The 412maximum height depends on the amount of addressable video memory. Review all 413drivers to initialize the fields to the correct values. 414 415Contact: Thomas Zimmermann <tzimmermann@suse.de> 416 417Level: Intermediate 418 419Request memory regions in all fbdev drivers 420-------------------------------------------- 421 422Old/ancient fbdev drivers do not request their memory properly. 423Go through these drivers and add code to request the memory regions 424that the driver uses. This requires adding calls to request_mem_region(), 425pci_request_region() or similar functions. Use helpers for managed cleanup 426where possible. Problematic areas include hardware that has exclusive ranges 427like VGA. VGA16fb does not request the range as it is expected. 428Drivers are pretty bad at doing this and there used to be conflicts among 429DRM and fbdev drivers. Still, it's the correct thing to do. 430 431Contact: Thomas Zimmermann <tzimmermann@suse.de> 432 433Level: Starter 434 435Remove driver dependencies on FB_DEVICE 436--------------------------------------- 437 438A number of fbdev drivers provide attributes via sysfs and therefore depend 439on CONFIG_FB_DEVICE to be selected. Review each driver and attempt to make 440any dependencies on CONFIG_FB_DEVICE optional. At the minimum, the respective 441code in the driver could be conditionalized via ifdef CONFIG_FB_DEVICE. Not 442all drivers might be able to drop CONFIG_FB_DEVICE. 443 444Contact: Thomas Zimmermann <tzimmermann@suse.de> 445 446Level: Starter 447 448Remove disable/unprepare in remove/shutdown in panel-simple and panel-edp 449------------------------------------------------------------------------- 450 451As of commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in 452drm_panel"), we have a check in the drm_panel core to make sure nobody 453double-calls prepare/enable/disable/unprepare. Eventually that should probably 454be turned into a WARN_ON() or somehow made louder. 455 456At the moment, we expect that we may still encounter the warnings in the 457drm_panel core when using panel-simple and panel-edp. Since those panel 458drivers are used with a lot of different DRM modeset drivers they still 459make an extra effort to disable/unprepare the panel themsevles at shutdown 460time. Specifically we could still encounter those warnings if the panel 461driver gets shutdown() _before_ the DRM modeset driver and the DRM modeset 462driver properly calls drm_atomic_helper_shutdown() in its own shutdown() 463callback. Warnings could be avoided in such a case by using something like 464device links to ensure that the panel gets shutdown() after the DRM modeset 465driver. 466 467Once all DRM modeset drivers are known to shutdown properly, the extra 468calls to disable/unprepare in remove/shutdown in panel-simple and panel-edp 469should be removed and this TODO item marked complete. 470 471Contact: Douglas Anderson <dianders@chromium.org> 472 473Level: Intermediate 474 475Transition away from using deprecated MIPI DSI functions 476-------------------------------------------------------- 477 478There are many functions defined in ``drm_mipi_dsi.c`` which have been 479deprecated. Each deprecated function was deprecated in favor of its `multi` 480variant (e.g. `mipi_dsi_generic_write()` and `mipi_dsi_generic_write_multi()`). 481The `multi` variant of a function includes improved error handling and logic 482which makes it more convenient to make several calls in a row, as most MIPI 483drivers do. 484 485Drivers should be updated to use undeprecated functions. Once all usages of the 486deprecated MIPI DSI functions have been removed, their definitions may be 487removed from ``drm_mipi_dsi.c``. 488 489Contact: Douglas Anderson <dianders@chromium.org> 490 491Level: Starter 492 493Remove devm_drm_put_bridge() 494---------------------------- 495 496Due to how the panel bridge handles the drm_bridge object lifetime, special 497care must be taken to dispose of the drm_bridge object when the 498panel_bridge is removed. This is currently managed using 499devm_drm_put_bridge(), but that is an unsafe, temporary workaround. To fix 500that, the DRM panel lifetime needs to be reworked. After the rework is 501done, remove devm_drm_put_bridge() and the TODO in 502drm_panel_bridge_remove(). 503 504Contact: Maxime Ripard <mripard@kernel.org>, 505 Luca Ceresoli <luca.ceresoli@bootlin.com> 506 507Level: Intermediate 508 509Core refactorings 510================= 511 512Make panic handling work 513------------------------ 514 515This is a really varied tasks with lots of little bits and pieces: 516 517* The panic path can't be tested currently, leading to constant breaking. The 518 main issue here is that panics can be triggered from hardirq contexts and 519 hence all panic related callback can run in hardirq context. It would be 520 awesome if we could test at least the fbdev helper code and driver code by 521 e.g. trigger calls through drm debugfs files. hardirq context could be 522 achieved by using an IPI to the local processor. 523 524* There's a massive confusion of different panic handlers. DRM fbdev emulation 525 helpers had their own (long removed), but on top of that the fbcon code itself 526 also has one. We need to make sure that they stop fighting over each other. 527 This is worked around by checking ``oops_in_progress`` at various entry points 528 into the DRM fbdev emulation helpers. A much cleaner approach here would be to 529 switch fbcon to the `threaded printk support 530 <https://lwn.net/Articles/800946/>`_. 531 532* ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and 533 isn't a full solution for panic paths. We need to make sure that it only 534 returns true if there's a panic going on for real, and fix up all the 535 fallout. 536 537* The panic handler must never sleep, which also means it can't ever 538 ``mutex_lock()``. Also it can't grab any other lock unconditionally, not 539 even spinlocks (because NMI and hardirq can panic too). We need to either 540 make sure to not call such paths, or trylock everything. Really tricky. 541 542* A clean solution would be an entirely separate panic output support in KMS, 543 bypassing the current fbcon support. See `[PATCH v2 0/3] drm: Add panic handling 544 <https://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/>`_. 545 546* Encoding the actual oops and preceding dmesg in a QR might help with the 547 dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages 548 transfer using QR codes 549 <https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/>`_ 550 for some example code that could be reused. 551 552Contact: Simona Vetter 553 554Level: Advanced 555 556Clean up the debugfs support 557---------------------------- 558 559There's a bunch of issues with it: 560 561- Convert drivers to support the drm_debugfs_add_files() function instead of 562 the drm_debugfs_create_files() function. 563 564- Improve late-register debugfs by rolling out the same debugfs pre-register 565 infrastructure for connector and crtc too. That way, the drivers won't need to 566 split their setup code into init and register anymore. 567 568- We probably want to have some support for debugfs files on crtc/connectors and 569 maybe other kms objects directly in core. There's even drm_print support in 570 the funcs for these objects to dump kms state, so it's all there. And then the 571 ->show() functions should obviously give you a pointer to the right object. 572 573- The drm_driver->debugfs_init hooks we have is just an artifact of the old 574 midlayered load sequence. DRM debugfs should work more like sysfs, where you 575 can create properties/files for an object anytime you want, and the core 576 takes care of publishing/unpuplishing all the files at register/unregister 577 time. Drivers shouldn't need to worry about these technicalities, and fixing 578 this (together with the drm_minor->drm_device move) would allow us to remove 579 debugfs_init. 580 581Contact: Simona Vetter 582 583Level: Intermediate 584 585Object lifetime fixes 586--------------------- 587 588There's two related issues here 589 590- Cleanup up the various ->destroy callbacks, which often are all the same 591 simple code. 592 593- Lots of drivers erroneously allocate DRM modeset objects using devm_kzalloc, 594 which results in use-after free issues on driver unload. This can be serious 595 trouble even for drivers for hardware integrated on the SoC due to 596 EPROBE_DEFERRED backoff. 597 598Both these problems can be solved by switching over to drmm_kzalloc(), and the 599various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), 600drmm_universal_plane_alloc(), ... and so on. 601 602Contact: Simona Vetter 603 604Level: Intermediate 605 606Remove automatic page mapping from dma-buf importing 607---------------------------------------------------- 608 609When importing dma-bufs, the dma-buf and PRIME frameworks automatically map 610imported pages into the importer's DMA area. drm_gem_prime_fd_to_handle() and 611drm_gem_prime_handle_to_fd() require that importers call dma_buf_attach() 612even if they never do actual device DMA, but only CPU access through 613dma_buf_vmap(). This is a problem for USB devices, which do not support DMA 614operations. 615 616To fix the issue, automatic page mappings should be removed from the 617buffer-sharing code. Fixing this is a bit more involved, since the import/export 618cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over 619this problem for USB devices by fishing out the USB host controller device, as 620long as that supports DMA. Otherwise importing can still needlessly fail. 621 622Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter 623 624Level: Advanced 625 626 627Better Testing 628============== 629 630Add unit tests using the Kernel Unit Testing (KUnit) framework 631-------------------------------------------------------------- 632 633The `KUnit <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_ 634provides a common framework for unit tests within the Linux kernel. Having a 635test suite would allow to identify regressions earlier. 636 637A good candidate for the first unit tests are the format-conversion helpers in 638``drm_format_helper.c``. 639 640Contact: Javier Martinez Canillas <javierm@redhat.com> 641 642Level: Intermediate 643 644Clean up and document former selftests suites 645--------------------------------------------- 646 647Some KUnit test suites (drm_buddy, drm_cmdline_parser, drm_damage_helper, 648drm_format, drm_framebuffer, drm_dp_mst_helper, drm_mm, drm_plane_helper and 649drm_rect) are former selftests suites that have been converted over when KUnit 650was first introduced. 651 652These suites were fairly undocumented, and with different goals than what unit 653tests can be. Trying to identify what each test in these suites actually test 654for, whether that makes sense for a unit test, and either remove it if it 655doesn't or document it if it does would be of great help. 656 657Contact: Maxime Ripard <mripard@kernel.org> 658 659Level: Intermediate 660 661Enable trinity for DRM 662---------------------- 663 664And fix up the fallout. Should be really interesting ... 665 666Level: Advanced 667 668Make KMS tests in i-g-t generic 669------------------------------- 670 671The i915 driver team maintains an extensive testsuite for the i915 DRM driver, 672including tons of testcases for corner-cases in the modesetting API. It would 673be awesome if those tests (at least the ones not relying on Intel-specific GEM 674features) could be made to run on any KMS driver. 675 676Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass- 677converting things over. For modeset tests we also first need a bit of 678infrastructure to use dumb buffers for untiled buffers, to be able to run all 679the non-i915 specific modeset tests. 680 681Level: Advanced 682 683Extend virtual test driver (VKMS) 684--------------------------------- 685 686See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal 687internship task, since it only requires a virtual machine and can be sized to 688fit the available time. 689 690Level: See details 691 692Backlight Refactoring 693--------------------- 694 695Backlight drivers have a triple enable/disable state, which is a bit overkill. 696Plan to fix this: 697 6981. Roll out backlight_enable() and backlight_disable() helpers everywhere. This 699 has started already. 7002. In all, only look at one of the three status bits set by the above helpers. 7013. Remove the other two status bits. 702 703Contact: Simona Vetter 704 705Level: Intermediate 706 707Driver Specific 708=============== 709 710AMD DC Display Driver 711--------------------- 712 713AMD DC is the display driver for AMD devices starting with Vega. There has been 714a bunch of progress cleaning it up but there's still plenty of work to be done. 715 716See drivers/gpu/drm/amd/display/TODO for tasks. 717 718Contact: Harry Wentland, Alex Deucher 719 720Bootsplash 721========== 722 723There is support in place now for writing internal DRM clients making it 724possible to pick up the bootsplash work that was rejected because it was written 725for fbdev. 726 727- [v6,8/8] drm/client: Hack: Add bootsplash example 728 https://patchwork.freedesktop.org/patch/306579/ 729 730- [RFC PATCH v2 00/13] Kernel based bootsplash 731 https://lore.kernel.org/r/20171213194755.3409-1-mstaudt@suse.de 732 733Contact: Sam Ravnborg 734 735Level: Advanced 736 737Brightness handling on devices with multiple internal panels 738============================================================ 739 740On x86/ACPI devices there can be multiple backlight firmware interfaces: 741(ACPI) video, vendor specific and others. As well as direct/native (PWM) 742register programming by the KMS driver. 743 744To deal with this backlight drivers used on x86/ACPI call 745acpi_video_get_backlight_type() which has heuristics (+quirks) to select 746which backlight interface to use; and backlight drivers which do not match 747the returned type will not register themselves, so that only one backlight 748device gets registered (in a single GPU setup, see below). 749 750At the moment this more or less assumes that there will only 751be 1 (internal) panel on a system. 752 753On systems with 2 panels this may be a problem, depending on 754what interface acpi_video_get_backlight_type() selects: 755 7561. native: in this case the KMS driver is expected to know which backlight 757 device belongs to which output so everything should just work. 7582. video: this does support controlling multiple backlights, but some work 759 will need to be done to get the output <-> backlight device mapping 760 761The above assumes both panels will require the same backlight interface type. 762Things will break on systems with multiple panels where the 2 panels need 763a different type of control. E.g. one panel needs ACPI video backlight control, 764where as the other is using native backlight control. Currently in this case 765only one of the 2 required backlight devices will get registered, based on 766the acpi_video_get_backlight_type() return value. 767 768If this (theoretical) case ever shows up, then supporting this will need some 769work. A possible solution here would be to pass a device and connector-name 770to acpi_video_get_backlight_type() so that it can deal with this. 771 772Note in a way we already have a case where userspace sees 2 panels, 773in dual GPU laptop setups with a mux. On those systems we may see 774either 2 native backlight devices; or 2 native backlight devices. 775 776Userspace already has code to deal with this by detecting if the related 777panel is active (iow which way the mux between the GPU and the panels 778points) and then uses that backlight device. Userspace here very much 779assumes a single panel though. It picks only 1 of the 2 backlight devices 780and then only uses that one. 781 782Note that all userspace code (that I know off) is currently hardcoded 783to assume a single panel. 784 785Before the recent changes to not register multiple (e.g. video + native) 786/sys/class/backlight devices for a single panel (on a single GPU laptop), 787userspace would see multiple backlight devices all controlling the same 788backlight. 789 790To deal with this userspace had to always picks one preferred device under 791/sys/class/backlight and will ignore the others. So to support brightness 792control on multiple panels userspace will need to be updated too. 793 794There are plans to allow brightness control through the KMS API by adding 795a "display brightness" property to drm_connector objects for panels. This 796solves a number of issues with the /sys/class/backlight API, including not 797being able to map a sysfs backlight device to a specific connector. Any 798userspace changes to add support for brightness control on devices with 799multiple panels really should build on top of this new KMS property. 800 801Contact: Hans de Goede 802 803Level: Advanced 804 805Buffer age or other damage accumulation algorithm for buffer damage 806=================================================================== 807 808Drivers that do per-buffer uploads, need a buffer damage handling (rather than 809frame damage like drivers that do per-plane or per-CRTC uploads), but there is 810no support to get the buffer age or any other damage accumulation algorithm. 811 812For this reason, the damage helpers just fallback to a full plane update if the 813framebuffer attached to a plane has changed since the last page-flip. Drivers 814set &drm_plane_state.ignore_damage_clips to true as indication to 815drm_atomic_helper_damage_iter_init() and drm_atomic_helper_damage_iter_next() 816helpers that the damage clips should be ignored. 817 818This should be improved to get damage tracking properly working on drivers that 819do per-buffer uploads. 820 821More information about damage tracking and references to learning materials can 822be found in :ref:`damage_tracking_properties`. 823 824Contact: Javier Martinez Canillas <javierm@redhat.com> 825 826Level: Advanced 827 828Querying errors from drm_syncobj 829================================ 830 831The drm_syncobj container can be used by driver independent code to signal 832complection of submission. 833 834One minor feature still missing is a generic DRM IOCTL to query the error 835status of binary and timeline drm_syncobj. 836 837This should probably be improved by implementing the necessary kernel interface 838and adding support for that in the userspace stack. 839 840Contact: Christian König 841 842Level: Starter 843 844Outside DRM 845=========== 846 847Convert fbdev drivers to DRM 848---------------------------- 849 850There are plenty of fbdev drivers for older hardware. Some hardware has 851become obsolete, but some still provides good(-enough) framebuffers. The 852drivers that are still useful should be converted to DRM and afterwards 853removed from fbdev. 854 855Very simple fbdev drivers can best be converted by starting with a new 856DRM driver. Simple KMS helpers and SHMEM should be able to handle any 857existing hardware. The new driver's call-back functions are filled from 858existing fbdev code. 859 860More complex fbdev drivers can be refactored step-by-step into a DRM 861driver with the help of the DRM fbconv helpers [4]_. These helpers provide 862the transition layer between the DRM core infrastructure and the fbdev 863driver interface. Create a new DRM driver on top of the fbconv helpers, 864copy over the fbdev driver, and hook it up to the DRM code. Examples for 865several fbdev drivers are available in Thomas Zimmermann's fbconv tree 866[4]_, as well as a tutorial of this process [5]_. The result is a primitive 867DRM driver that can run X11 and Weston. 868 869 .. [4] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv 870 .. [5] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c 871 872Contact: Thomas Zimmermann <tzimmermann@suse.de> 873 874Level: Advanced 875