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