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 626Implement a new DUMB_CREATE2 ioctl 627---------------------------------- 628 629The current DUMB_CREATE ioctl is not well defined. Instead of a pixel and 630framebuffer format, it only accepts a color mode of vague semantics. Assuming 631a linear framebuffer, the color mode gives an idea of the supported pixel 632format. But userspace effectively has to guess the correct values. It really 633only works reliably with framebuffers in XRGB8888. Userspace has begun to 634workaround these limitations by computing arbitrary format's buffer sizes and 635calculating their sizes in terms of XRGB8888 pixels. 636 637One possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM 638format and a format modifier to resolve the color mode's ambiguity. As 639framebuffers can be multi-planar, the new ioctl has to return the buffer size, 640pitch and GEM handle for each individual color plane. 641 642In the first step, the new ioctl can be limited to the current features of 643the existing DUMB_CREATE. Individual drivers can then be extended to support 644multi-planar formats. Rockchip might require this and would be a good candidate. 645 646It might also be helpful to userspace to query information about the size of 647a potential buffer, if allocated. Userspace would supply geometry and format; 648the kernel would return minimal allocation sizes and scanline pitch. There is 649interest to allocate that memory from another device and provide it to the 650DRM driver (say via dma-buf). 651 652Another requested feature is the ability to allocate a buffer by size, without 653format. Accelators use this for their buffer allocation and it could likely be 654generalized. 655 656In addition to the kernel implementation, there must be user-space support 657for the new ioctl. There's code in Mesa that might be able to use the new 658call. 659 660Contact: Thomas Zimmermann <tzimmermann@suse.de> 661 662Level: Advanced 663 664Better Testing 665============== 666 667Add unit tests using the Kernel Unit Testing (KUnit) framework 668-------------------------------------------------------------- 669 670The `KUnit <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_ 671provides a common framework for unit tests within the Linux kernel. Having a 672test suite would allow to identify regressions earlier. 673 674A good candidate for the first unit tests are the format-conversion helpers in 675``drm_format_helper.c``. 676 677Contact: Javier Martinez Canillas <javierm@redhat.com> 678 679Level: Intermediate 680 681Clean up and document former selftests suites 682--------------------------------------------- 683 684Some KUnit test suites (drm_buddy, drm_cmdline_parser, drm_damage_helper, 685drm_format, drm_framebuffer, drm_dp_mst_helper, drm_mm, drm_plane_helper and 686drm_rect) are former selftests suites that have been converted over when KUnit 687was first introduced. 688 689These suites were fairly undocumented, and with different goals than what unit 690tests can be. Trying to identify what each test in these suites actually test 691for, whether that makes sense for a unit test, and either remove it if it 692doesn't or document it if it does would be of great help. 693 694Contact: Maxime Ripard <mripard@kernel.org> 695 696Level: Intermediate 697 698Enable trinity for DRM 699---------------------- 700 701And fix up the fallout. Should be really interesting ... 702 703Level: Advanced 704 705Make KMS tests in i-g-t generic 706------------------------------- 707 708The i915 driver team maintains an extensive testsuite for the i915 DRM driver, 709including tons of testcases for corner-cases in the modesetting API. It would 710be awesome if those tests (at least the ones not relying on Intel-specific GEM 711features) could be made to run on any KMS driver. 712 713Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass- 714converting things over. For modeset tests we also first need a bit of 715infrastructure to use dumb buffers for untiled buffers, to be able to run all 716the non-i915 specific modeset tests. 717 718Level: Advanced 719 720Extend virtual test driver (VKMS) 721--------------------------------- 722 723See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal 724internship task, since it only requires a virtual machine and can be sized to 725fit the available time. 726 727Level: See details 728 729Backlight Refactoring 730--------------------- 731 732Backlight drivers have a triple enable/disable state, which is a bit overkill. 733Plan to fix this: 734 7351. Roll out backlight_enable() and backlight_disable() helpers everywhere. This 736 has started already. 7372. In all, only look at one of the three status bits set by the above helpers. 7383. Remove the other two status bits. 739 740Contact: Simona Vetter 741 742Level: Intermediate 743 744Driver Specific 745=============== 746 747AMD DC Display Driver 748--------------------- 749 750AMD DC is the display driver for AMD devices starting with Vega. There has been 751a bunch of progress cleaning it up but there's still plenty of work to be done. 752 753See drivers/gpu/drm/amd/display/TODO for tasks. 754 755Contact: Harry Wentland, Alex Deucher 756 757Bootsplash 758========== 759 760There is support in place now for writing internal DRM clients making it 761possible to pick up the bootsplash work that was rejected because it was written 762for fbdev. 763 764- [v6,8/8] drm/client: Hack: Add bootsplash example 765 https://patchwork.freedesktop.org/patch/306579/ 766 767- [RFC PATCH v2 00/13] Kernel based bootsplash 768 https://lore.kernel.org/r/20171213194755.3409-1-mstaudt@suse.de 769 770Contact: Sam Ravnborg 771 772Level: Advanced 773 774Brightness handling on devices with multiple internal panels 775============================================================ 776 777On x86/ACPI devices there can be multiple backlight firmware interfaces: 778(ACPI) video, vendor specific and others. As well as direct/native (PWM) 779register programming by the KMS driver. 780 781To deal with this backlight drivers used on x86/ACPI call 782acpi_video_get_backlight_type() which has heuristics (+quirks) to select 783which backlight interface to use; and backlight drivers which do not match 784the returned type will not register themselves, so that only one backlight 785device gets registered (in a single GPU setup, see below). 786 787At the moment this more or less assumes that there will only 788be 1 (internal) panel on a system. 789 790On systems with 2 panels this may be a problem, depending on 791what interface acpi_video_get_backlight_type() selects: 792 7931. native: in this case the KMS driver is expected to know which backlight 794 device belongs to which output so everything should just work. 7952. video: this does support controlling multiple backlights, but some work 796 will need to be done to get the output <-> backlight device mapping 797 798The above assumes both panels will require the same backlight interface type. 799Things will break on systems with multiple panels where the 2 panels need 800a different type of control. E.g. one panel needs ACPI video backlight control, 801where as the other is using native backlight control. Currently in this case 802only one of the 2 required backlight devices will get registered, based on 803the acpi_video_get_backlight_type() return value. 804 805If this (theoretical) case ever shows up, then supporting this will need some 806work. A possible solution here would be to pass a device and connector-name 807to acpi_video_get_backlight_type() so that it can deal with this. 808 809Note in a way we already have a case where userspace sees 2 panels, 810in dual GPU laptop setups with a mux. On those systems we may see 811either 2 native backlight devices; or 2 native backlight devices. 812 813Userspace already has code to deal with this by detecting if the related 814panel is active (iow which way the mux between the GPU and the panels 815points) and then uses that backlight device. Userspace here very much 816assumes a single panel though. It picks only 1 of the 2 backlight devices 817and then only uses that one. 818 819Note that all userspace code (that I know off) is currently hardcoded 820to assume a single panel. 821 822Before the recent changes to not register multiple (e.g. video + native) 823/sys/class/backlight devices for a single panel (on a single GPU laptop), 824userspace would see multiple backlight devices all controlling the same 825backlight. 826 827To deal with this userspace had to always picks one preferred device under 828/sys/class/backlight and will ignore the others. So to support brightness 829control on multiple panels userspace will need to be updated too. 830 831There are plans to allow brightness control through the KMS API by adding 832a "display brightness" property to drm_connector objects for panels. This 833solves a number of issues with the /sys/class/backlight API, including not 834being able to map a sysfs backlight device to a specific connector. Any 835userspace changes to add support for brightness control on devices with 836multiple panels really should build on top of this new KMS property. 837 838Contact: Hans de Goede 839 840Level: Advanced 841 842Buffer age or other damage accumulation algorithm for buffer damage 843=================================================================== 844 845Drivers that do per-buffer uploads, need a buffer damage handling (rather than 846frame damage like drivers that do per-plane or per-CRTC uploads), but there is 847no support to get the buffer age or any other damage accumulation algorithm. 848 849For this reason, the damage helpers just fallback to a full plane update if the 850framebuffer attached to a plane has changed since the last page-flip. Drivers 851set &drm_plane_state.ignore_damage_clips to true as indication to 852drm_atomic_helper_damage_iter_init() and drm_atomic_helper_damage_iter_next() 853helpers that the damage clips should be ignored. 854 855This should be improved to get damage tracking properly working on drivers that 856do per-buffer uploads. 857 858More information about damage tracking and references to learning materials can 859be found in :ref:`damage_tracking_properties`. 860 861Contact: Javier Martinez Canillas <javierm@redhat.com> 862 863Level: Advanced 864 865Querying errors from drm_syncobj 866================================ 867 868The drm_syncobj container can be used by driver independent code to signal 869complection of submission. 870 871One minor feature still missing is a generic DRM IOCTL to query the error 872status of binary and timeline drm_syncobj. 873 874This should probably be improved by implementing the necessary kernel interface 875and adding support for that in the userspace stack. 876 877Contact: Christian König 878 879Level: Starter 880 881Outside DRM 882=========== 883 884Convert fbdev drivers to DRM 885---------------------------- 886 887There are plenty of fbdev drivers for older hardware. Some hardware has 888become obsolete, but some still provides good(-enough) framebuffers. The 889drivers that are still useful should be converted to DRM and afterwards 890removed from fbdev. 891 892Very simple fbdev drivers can best be converted by starting with a new 893DRM driver. Simple KMS helpers and SHMEM should be able to handle any 894existing hardware. The new driver's call-back functions are filled from 895existing fbdev code. 896 897More complex fbdev drivers can be refactored step-by-step into a DRM 898driver with the help of the DRM fbconv helpers [4]_. These helpers provide 899the transition layer between the DRM core infrastructure and the fbdev 900driver interface. Create a new DRM driver on top of the fbconv helpers, 901copy over the fbdev driver, and hook it up to the DRM code. Examples for 902several fbdev drivers are available in Thomas Zimmermann's fbconv tree 903[4]_, as well as a tutorial of this process [5]_. The result is a primitive 904DRM driver that can run X11 and Weston. 905 906 .. [4] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv 907 .. [5] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c 908 909Contact: Thomas Zimmermann <tzimmermann@suse.de> 910 911Level: Advanced 912