udlfb.rst 7.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162
  1. ==============
  2. What is udlfb?
  3. ==============
  4. This is a driver for DisplayLink USB 2.0 era graphics chips.
  5. DisplayLink chips provide simple hline/blit operations with some compression,
  6. pairing that with a hardware framebuffer (16MB) on the other end of the
  7. USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI
  8. monitor with no CPU involvement until a pixel has to change.
  9. The CPU or other local resource does all the rendering; optionally compares the
  10. result with a local shadow of the remote hardware framebuffer to identify
  11. the minimal set of pixels that have changed; and compresses and sends those
  12. pixels line-by-line via USB bulk transfers.
  13. Because of the efficiency of bulk transfers and a protocol on top that
  14. does not require any acks - the effect is very low latency that
  15. can support surprisingly high resolutions with good performance for
  16. non-gaming and non-video applications.
  17. Mode setting, EDID read, etc are other bulk or control transfers. Mode
  18. setting is very flexible - able to set nearly arbitrary modes from any timing.
  19. Advantages of USB graphics in general:
  20. * Ability to add a nearly arbitrary number of displays to any USB 2.0
  21. capable system. On Linux, number of displays is limited by fbdev interface
  22. (FB_MAX is currently 32). Of course, all USB devices on the same
  23. host controller share the same 480Mbs USB 2.0 interface.
  24. Advantages of supporting DisplayLink chips with kernel framebuffer interface:
  25. * The actual hardware functionality of DisplayLink chips matches nearly
  26. one-to-one with the fbdev interface, making the driver quite small and
  27. tight relative to the functionality it provides.
  28. * X servers and other applications can use the standard fbdev interface
  29. from user mode to talk to the device, without needing to know anything
  30. about USB or DisplayLink's protocol at all. A "displaylink" X driver
  31. and a slightly modified "fbdev" X driver are among those that already do.
  32. Disadvantages:
  33. * Fbdev's mmap interface assumes a real hardware framebuffer is mapped.
  34. In the case of USB graphics, it is just an allocated (virtual) buffer.
  35. Writes need to be detected and encoded into USB bulk transfers by the CPU.
  36. Accurate damage/changed area notifications work around this problem.
  37. In the future, hopefully fbdev will be enhanced with an small standard
  38. interface to allow mmap clients to report damage, for the benefit
  39. of virtual or remote framebuffers.
  40. * Fbdev does not arbitrate client ownership of the framebuffer well.
  41. * Fbcon assumes the first framebuffer it finds should be consumed for console.
  42. * It's not clear what the future of fbdev is, given the rise of KMS/DRM.
  43. How to use it?
  44. ==============
  45. Udlfb, when loaded as a module, will match against all USB 2.0 generation
  46. DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID
  47. of the monitor, and set the best common mode between the DisplayLink device
  48. and the monitor's capabilities.
  49. If the DisplayLink device is successful, it will paint a "green screen" which
  50. means that from a hardware and fbdev software perspective, everything is good.
  51. At that point, a /dev/fb? interface will be present for user-mode applications
  52. to open and begin writing to the framebuffer of the DisplayLink device using
  53. standard fbdev calls. Note that if mmap() is used, by default the user mode
  54. application must send down damage notifications to trigger repaints of the
  55. changed regions. Alternatively, udlfb can be recompiled with experimental
  56. defio support enabled, to support a page-fault based detection mechanism
  57. that can work without explicit notification.
  58. The most common client of udlfb is xf86-video-displaylink or a modified
  59. xf86-video-fbdev X server. These servers have no real DisplayLink specific
  60. code. They write to the standard framebuffer interface and rely on udlfb
  61. to do its thing. The one extra feature they have is the ability to report
  62. rectangles from the X DAMAGE protocol extension down to udlfb via udlfb's
  63. damage interface (which will hopefully be standardized for all virtual
  64. framebuffers that need damage info). These damage notifications allow
  65. udlfb to efficiently process the changed pixels.
  66. Module Options
  67. ==============
  68. Special configuration for udlfb is usually unnecessary. There are a few
  69. options, however.
  70. From the command line, pass options to modprobe
  71. modprobe udlfb fb_defio=0 console=1 shadow=1
  72. Or modify options on the fly at /sys/module/udlfb/parameters directory via
  73. sudo nano fb_defio
  74. change the parameter in place, and save the file.
  75. Unplug/replug USB device to apply with new settings
  76. Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with text
  77. options udlfb fb_defio=0 console=1 shadow=1
  78. Accepted boolean options:
  79. =============== ================================================================
  80. fb_defio Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel
  81. module to track changed areas of the framebuffer by page faults.
  82. Standard fbdev applications that use mmap but that do not
  83. report damage, should be able to work with this enabled.
  84. Disable when running with X server that supports reporting
  85. changed regions via ioctl, as this method is simpler,
  86. more stable, and higher performance.
  87. default: fb_defio=1
  88. console Allow fbcon to attach to udlfb provided framebuffers.
  89. Can be disabled if fbcon and other clients
  90. (e.g. X with --shared-vt) are in conflict.
  91. default: console=1
  92. shadow Allocate a 2nd framebuffer to shadow what's currently across
  93. the USB bus in device memory. If any pixels are unchanged,
  94. do not transmit. Spends host memory to save USB transfers.
  95. Enabled by default. Only disable on very low memory systems.
  96. default: shadow=1
  97. =============== ================================================================
  98. Sysfs Attributes
  99. ================
  100. Udlfb creates several files in /sys/class/graphics/fb?
  101. Where ? is the sequential framebuffer id of the particular DisplayLink device
  102. ======================== ========================================================
  103. edid If a valid EDID blob is written to this file (typically
  104. by a udev rule), then udlfb will use this EDID as a
  105. backup in case reading the actual EDID of the monitor
  106. attached to the DisplayLink device fails. This is
  107. especially useful for fixed panels, etc. that cannot
  108. communicate their capabilities via EDID. Reading
  109. this file returns the current EDID of the attached
  110. monitor (or last backup value written). This is
  111. useful to get the EDID of the attached monitor,
  112. which can be passed to utilities like parse-edid.
  113. metrics_bytes_rendered 32-bit count of pixel bytes rendered
  114. metrics_bytes_identical 32-bit count of how many of those bytes were found to be
  115. unchanged, based on a shadow framebuffer check
  116. metrics_bytes_sent 32-bit count of how many bytes were transferred over
  117. USB to communicate the resulting changed pixels to the
  118. hardware. Includes compression and protocol overhead
  119. metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the
  120. above pixels (in thousands of cycles).
  121. metrics_reset Write-only. Any write to this file resets all metrics
  122. above to zero. Note that the 32-bit counters above
  123. roll over very quickly. To get reliable results, design
  124. performance tests to start and finish in a very short
  125. period of time (one minute or less is safe).
  126. ======================== ========================================================
  127. Bernie Thompson <bernie@plugable.com>