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