요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
==================================
2
udlfb - DisplayLink USB 2.0 driver
3
==================================
5
This is a driver for DisplayLink USB 2.0 era graphics chips.
7
DisplayLink chips provide simple hline/blit operations with some compression,
8
pairing that with a hardware framebuffer (16MB) on the other end of the
9
USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI
10
monitor with no CPU involvement until a pixel has to change.
12
The CPU or other local resource does all the rendering; optionally compares the
13
result with a local shadow of the remote hardware framebuffer to identify
14
the minimal set of pixels that have changed; and compresses and sends those
15
pixels line-by-line via USB bulk transfers.
17
Because of the efficiency of bulk transfers and a protocol on top that
18
does not require any acks - the effect is very low latency that
19
can support surprisingly high resolutions with good performance for
20
non-gaming and non-video applications.
22
Mode setting, EDID read, etc are other bulk or control transfers. Mode
23
setting is very flexible - able to set nearly arbitrary modes from any timing.
25
Advantages of USB graphics in general:
27
* Ability to add a nearly arbitrary number of displays to any USB 2.0
28
capable system. On Linux, number of displays is limited by fbdev interface
29
(FB_MAX is currently 32). Of course, all USB devices on the same
30
host controller share the same 480Mbs USB 2.0 interface.
32
Advantages of supporting DisplayLink chips with kernel framebuffer interface:
34
* The actual hardware functionality of DisplayLink chips matches nearly
35
one-to-one with the fbdev interface, making the driver quite small and
36
tight relative to the functionality it provides.
37
* X servers and other applications can use the standard fbdev interface
38
from user mode to talk to the device, without needing to know anything
39
about USB or DisplayLink's protocol at all. A "displaylink" X driver
40
and a slightly modified "fbdev" X driver are among those that already do.
42
Disadvantages:
44
* Fbdev's mmap interface assumes a real hardware framebuffer is mapped.
45
In the case of USB graphics, it is just an allocated (virtual) buffer.
46
Writes need to be detected and encoded into USB bulk transfers by the CPU.
47
Accurate damage/changed area notifications work around this problem.
48
In the future, hopefully fbdev will be enhanced with an small standard
49
interface to allow mmap clients to report damage, for the benefit
50
of virtual or remote framebuffers.
51
* Fbdev does not arbitrate client ownership of the framebuffer well.
52
* Fbcon assumes the first framebuffer it finds should be consumed for console.
53
* It's not clear what the future of fbdev is, given the rise of KMS/DRM.
55
How to use it?
56
==============
58
Udlfb, when loaded as a module, will match against all USB 2.0 generation
59
DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID
60
of the monitor, and set the best common mode between the DisplayLink device
61
and the monitor's capabilities.
63
If the DisplayLink device is successful, it will paint a "green screen" which
64
means that from a hardware and fbdev software perspective, everything is good.
66
At that point, a /dev/fb? interface will be present for user-mode applications
67
to open and begin writing to the framebuffer of the DisplayLink device using
68
standard fbdev calls. Note that if mmap() is used, by default the user mode
69
application must send down damage notifications to trigger repaints of the
70
changed regions. Alternatively, udlfb can be recompiled with experimental
71
defio support enabled, to support a page-fault based detection mechanism
72
that can work without explicit notification.
74
The most common client of udlfb is xf86-video-displaylink or a modified
75
xf86-video-fbdev X server. These servers have no real DisplayLink specific
76
code. They write to the standard framebuffer interface and rely on udlfb
77
to do its thing. The one extra feature they have is the ability to report
78
rectangles from the X DAMAGE protocol extension down to udlfb via udlfb's
79
damage interface (which will hopefully be standardized for all virtual
80
framebuffers that need damage info). These damage notifications allow
81
udlfb to efficiently process the changed pixels.
83
Module Options
84
==============
86
Special configuration for udlfb is usually unnecessary. There are a few
87
options, however.
89
From the command line, pass options to modprobe::
91
modprobe udlfb fb_defio=0 console=1 shadow=1
93
Or change options on the fly by editing
94
/sys/module/udlfb/parameters/PARAMETER_NAME ::
96
cd /sys/module/udlfb/parameters
97
ls # to see a list of parameter names
98
sudo nano PARAMETER_NAME
99
# change the parameter in place, and save the file.
101
Unplug/replug USB device to apply with new settings.
103
Or to apply options permanently, create a modprobe configuration file
104
like /etc/modprobe.d/udlfb.conf with text::
106
options udlfb fb_defio=0 console=1 shadow=1
108
Accepted boolean options:
110
=============== ================================================================
111
fb_defio Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel
112
module to track changed areas of the framebuffer by page faults.
113
Standard fbdev applications that use mmap but that do not
114
report damage, should be able to work with this enabled.
115
Disable when running with X server that supports reporting
116
changed regions via ioctl, as this method is simpler,
117
more stable, and higher performance.
118
default: fb_defio=1
120
console Allow fbcon to attach to udlfb provided framebuffers.
121
Can be disabled if fbcon and other clients
122
(e.g. X with --shared-vt) are in conflict.
123
default: console=1
125
shadow Allocate a 2nd framebuffer to shadow what's currently across
126
the USB bus in device memory. If any pixels are unchanged,
127
do not transmit. Spends host memory to save USB transfers.
128
Enabled by default. Only disable on very low memory systems.
129
default: shadow=1
130
=============== ================================================================
132
Sysfs Attributes
133
================
135
Udlfb creates several files in /sys/class/graphics/fb?
136
Where ? is the sequential framebuffer id of the particular DisplayLink device
138
======================== ========================================================
139
edid If a valid EDID blob is written to this file (typically
140
by a udev rule), then udlfb will use this EDID as a
141
backup in case reading the actual EDID of the monitor
142
attached to the DisplayLink device fails. This is
143
especially useful for fixed panels, etc. that cannot
144
communicate their capabilities via EDID. Reading
145
this file returns the current EDID of the attached
146
monitor (or last backup value written). This is
147
useful to get the EDID of the attached monitor,
148
which can be passed to utilities like parse-edid.
150
metrics_bytes_rendered 32-bit count of pixel bytes rendered
152
metrics_bytes_identical 32-bit count of how many of those bytes were found to be
153
unchanged, based on a shadow framebuffer check
155
metrics_bytes_sent 32-bit count of how many bytes were transferred over
156
USB to communicate the resulting changed pixels to the
157
hardware. Includes compression and protocol overhead
159
metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the
160
above pixels (in thousands of cycles).
162
metrics_reset Write-only. Any write to this file resets all metrics
163
above to zero. Note that the 32-bit counters above
164
roll over very quickly. To get reliable results, design
165
performance tests to start and finish in a very short
166
period of time (one minute or less is safe).
167
======================== ========================================================
169
Bernie Thompson <[email protected]>
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
DisplayLink USB 2.0 렌더링 경로
1-24`udlfb`는 DisplayLink USB 2.0 세대 그래픽 칩용 드라이버입니다. DisplayLink 칩은 압축을 곁들인 단순한 horizontal-line과 blit 연산을 제공하고, USB 반대편에 16 MB 하드웨어 framebuffer를 둡니다. 이 원격 framebuffer는 픽셀이 바뀔 때까지 CPU 개입 없이 VGA, DVI 또는 HDMI monitor를 구동합니다.
CPU나 다른 로컬 자원이 모든 rendering을 수행합니다. 선택적으로 결과를 원격 하드웨어 framebuffer의 로컬 shadow와 비교해 변경된 최소 픽셀 집합을 찾고, 그 픽셀을 압축해 USB bulk transfer로 한 줄씩 보냅니다.
bulk transfer의 효율성과 acknowledgement를 요구하지 않는 상위 protocol 덕분에 latency가 매우 낮습니다. 게임과 비디오가 아닌 응용에서는 예상보다 높은 해상도에서도 좋은 성능을 낼 수 있습니다.
mode setting과 EDID 읽기 역시 bulk 또는 control transfer로 수행합니다. mode setting은 임의의 timing에서 거의 모든 mode를 만들 수 있을 정도로 유연합니다.
CPU가 로컬 buffer에 rendering→선택적으로 16 MB 원격 shadow와 비교→변경된 최소 픽셀 집합 식별→변경 line 압축→USB bulk transfer→DisplayLink hardware framebuffer가 VGA/DVI/HDMI 출력
로컬 rendering 결과를 변경 영역만 압축해 원격 framebuffer로 전송합니다.
==================================
udlfb - DisplayLink USB 2.0 driver
==================================
This is a driver for DisplayLink USB 2.0 era graphics chips.
DisplayLink chips provide simple hline/blit operations with some compression,
pairing that with a hardware framebuffer (16MB) on the other end of the
USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI
monitor with no CPU involvement until a pixel has to change.
The CPU or other local resource does all the rendering; optionally compares the
result with a local shadow of the remote hardware framebuffer to identify
the minimal set of pixels that have changed; and compresses and sends those
pixels line-by-line via USB bulk transfers.
Because of the efficiency of bulk transfers and a protocol on top that
does not require any acks - the effect is very low latency that
can support surprisingly high resolutions with good performance for
non-gaming and non-video applications.
Mode setting, EDID read, etc are other bulk or control transfers. Mode
setting is very flexible - able to set nearly arbitrary modes from any timing.
USB 그래픽과 fbdev의 장단점
25-54USB 그래픽의 일반적인 장점은 USB 2.0 시스템에 거의 임의의 수만큼 display를 추가할 수 있다는 점입니다. Linux에서는 fbdev의 `FB_MAX` 때문에 현재 32개로 제한됩니다. 같은 host controller의 모든 USB 장치는 480 Mbit/s USB 2.0 interface를 공유합니다.
DisplayLink 기능은 fbdev interface와 거의 일대일로 대응하므로 제공 기능에 비해 드라이버가 작고 간결합니다. X server와 다른 사용자 공간 응용은 USB나 DisplayLink protocol을 몰라도 표준 fbdev로 장치를 사용할 수 있습니다. `displaylink` X driver와 약간 수정된 `fbdev` X driver가 이 방식을 이미 사용합니다.
단점은 fbdev의 `mmap` interface가 실제 하드웨어 framebuffer mapping을 가정한다는 점입니다. USB 그래픽에서는 할당된 가상 buffer일 뿐이므로 CPU가 쓰기를 감지해 USB bulk transfer로 encode해야 합니다. 정확한 damage/changed-area notification이 이 문제를 보완합니다. 장기적으로는 virtual 또는 remote framebuffer를 위해 mmap client가 damage를 보고하는 작은 표준 interface가 fbdev에 추가되길 기대합니다.
또한 fbdev는 framebuffer client ownership을 잘 중재하지 못하고, `fbcon`은 처음 발견한 framebuffer를 console로 사용한다고 가정합니다. KMS/DRM이 성장하는 상황에서 fbdev의 미래도 불확실합니다.
영역장점/문제
display 확장USB 2.0 display 추가, fbdev `FB_MAX=32`
대역폭host controller당 480 Mbit/s 공유
interfaceDisplayLink 기능과 fbdev가 거의 일대일
`mmap`가상 buffer 쓰기를 damage로 변환해야 함
ownership/consoleclient 중재 부족, `fbcon`의 첫 fb 선점
장기 방향KMS/DRM 성장으로 fbdev 미래 불확실
Advantages of USB graphics in general:
* Ability to add a nearly arbitrary number of displays to any USB 2.0
capable system. On Linux, number of displays is limited by fbdev interface
(FB_MAX is currently 32). Of course, all USB devices on the same
host controller share the same 480Mbs USB 2.0 interface.
Advantages of supporting DisplayLink chips with kernel framebuffer interface:
* The actual hardware functionality of DisplayLink chips matches nearly
one-to-one with the fbdev interface, making the driver quite small and
tight relative to the functionality it provides.
* X servers and other applications can use the standard fbdev interface
from user mode to talk to the device, without needing to know anything
about USB or DisplayLink's protocol at all. A "displaylink" X driver
and a slightly modified "fbdev" X driver are among those that already do.
Disadvantages:
* Fbdev's mmap interface assumes a real hardware framebuffer is mapped.
In the case of USB graphics, it is just an allocated (virtual) buffer.
Writes need to be detected and encoded into USB bulk transfers by the CPU.
Accurate damage/changed area notifications work around this problem.
In the future, hopefully fbdev will be enhanced with an small standard
interface to allow mmap clients to report damage, for the benefit
of virtual or remote framebuffers.
* Fbdev does not arbitrate client ownership of the framebuffer well.
* Fbcon assumes the first framebuffer it finds should be consumed for console.
* It's not clear what the future of fbdev is, given the rise of KMS/DRM.
장치 탐지와 사용자 공간 client
55-82모듈로 로드된 `udlfb`는 Alex와 Ollie 계열을 포함한 모든 USB 2.0 세대 DisplayLink 칩과 match합니다. monitor EDID를 읽고 DisplayLink 장치와 monitor 능력이 공통으로 지원하는 최적 mode를 설정합니다.
초기화가 성공하면 녹색 화면을 그립니다. 이는 하드웨어와 fbdev 소프트웨어 관점에서 정상이라는 뜻입니다. 이어서 사용자 공간 응용이 열 수 있는 `/dev/fb?`가 생기며 표준 fbdev call로 DisplayLink framebuffer에 쓸 수 있습니다.
기본 설정에서 `mmap()`을 쓰는 응용은 바뀐 영역을 다시 그리도록 damage notification을 보내야 합니다. 또는 experimental defio를 켜 다시 컴파일하면 명시적 notification 없이 page fault로 변경을 감지할 수 있습니다.
가장 일반적인 client는 `xf86-video-displaylink` 또는 수정된 `xf86-video-fbdev` X server입니다. DisplayLink 전용 코드는 거의 없고 표준 framebuffer에 쓴 뒤 `udlfb`에 맡깁니다. 추가 기능은 X DAMAGE protocol extension의 rectangle을 `udlfb` damage interface로 보고하는 것이며, 이를 통해 변경 픽셀만 효율적으로 처리합니다.
Alex/Ollie 계열 USB 장치 match→monitor EDID 읽기→공통 최적 mode 설정→성공 시 green screen→`/dev/fb?` 생성→X DAMAGE rectangle을 `udlfb` damage interface로 전달
USB 탐지부터 X DAMAGE 기반 갱신까지의 흐름입니다.
How to use it?
==============
Udlfb, when loaded as a module, will match against all USB 2.0 generation
DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID
of the monitor, and set the best common mode between the DisplayLink device
and the monitor's capabilities.
If the DisplayLink device is successful, it will paint a "green screen" which
means that from a hardware and fbdev software perspective, everything is good.
At that point, a /dev/fb? interface will be present for user-mode applications
to open and begin writing to the framebuffer of the DisplayLink device using
standard fbdev calls. Note that if mmap() is used, by default the user mode
application must send down damage notifications to trigger repaints of the
changed regions. Alternatively, udlfb can be recompiled with experimental
defio support enabled, to support a page-fault based detection mechanism
that can work without explicit notification.
The most common client of udlfb is xf86-video-displaylink or a modified
xf86-video-fbdev X server. These servers have no real DisplayLink specific
code. They write to the standard framebuffer interface and rely on udlfb
to do its thing. The one extra feature they have is the ability to report
rectangles from the X DAMAGE protocol extension down to udlfb via udlfb's
damage interface (which will hopefully be standardized for all virtual
framebuffers that need damage info). These damage notifications allow
udlfb to efficiently process the changed pixels.
모듈 설정과 불리언 옵션
83-131대부분 특별한 설정은 필요 없습니다. 명령행에서는 `modprobe udlfb fb_defio=0 console=1 shadow=1`처럼 전달합니다. 실행 중에는 `/sys/module/udlfb/parameters/PARAMETER_NAME`을 편집하고 USB 장치를 뺐다가 다시 꽂아 새 설정을 적용합니다.
영구 설정은 `/etc/modprobe.d/udlfb.conf` 같은 파일에 `options udlfb fb_defio=0 console=1 shadow=1`을 기록합니다.
`fb_defio`는 `CONFIG_FB_DEFERRED_IO`의 `fb_defio`를 사용해 page fault로 변경 영역을 추적합니다. mmap을 쓰면서 damage를 보고하지 않는 표준 fbdev 응용도 동작할 수 있습니다. 변경 영역을 ioctl로 보고하는 X server와 함께라면 더 단순하고 안정적이며 빠른 명시적 방식을 쓰도록 이 옵션을 끕니다. 기본값은 `fb_defio=1`입니다.
`console`은 `fbcon`이 `udlfb` framebuffer에 붙도록 허용합니다. `fbcon`과 `--shared-vt`를 쓰는 X 같은 다른 client가 충돌하면 끌 수 있습니다. 기본값은 `console=1`입니다.
`shadow`는 USB 반대편 device memory의 현재 내용을 추적하는 두 번째 framebuffer를 할당합니다. 변하지 않은 픽셀은 보내지 않으므로 host memory를 사용해 USB transfer를 줄입니다. 기본값은 `shadow=1`이며 메모리가 매우 적은 시스템에서만 끕니다.
옵션기본역할/비용
`fb_defio`1page fault damage 탐지, ioctl damage X server에서는 비활성 권장
`console`1`fbcon` 연결 허용, shared VT 충돌 시 비활성
`shadow`1host memory로 원격 상태를 shadow해 USB 전송 절약
Module Options
==============
Special configuration for udlfb is usually unnecessary. There are a few
options, however.
From the command line, pass options to modprobe::
modprobe udlfb fb_defio=0 console=1 shadow=1
Or change options on the fly by editing
/sys/module/udlfb/parameters/PARAMETER_NAME ::
cd /sys/module/udlfb/parameters
ls # to see a list of parameter names
sudo nano PARAMETER_NAME
# change the parameter in place, and save the file.
Unplug/replug USB device to apply with new settings.
Or to apply options permanently, create a modprobe configuration file
like /etc/modprobe.d/udlfb.conf with text::
options udlfb fb_defio=0 console=1 shadow=1
Accepted boolean options:
=============== ================================================================
fb_defio Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel
module to track changed areas of the framebuffer by page faults.
Standard fbdev applications that use mmap but that do not
report damage, should be able to work with this enabled.
Disable when running with X server that supports reporting
changed regions via ioctl, as this method is simpler,
more stable, and higher performance.
default: fb_defio=1
console Allow fbcon to attach to udlfb provided framebuffers.
Can be disabled if fbcon and other clients
(e.g. X with --shared-vt) are in conflict.
default: console=1
shadow Allocate a 2nd framebuffer to shadow what's currently across
the USB bus in device memory. If any pixels are unchanged,
do not transmit. Spends host memory to save USB transfers.
Enabled by default. Only disable on very low memory systems.
default: shadow=1
=============== ================================================================
EDID와 성능 metric sysfs
132-169`udlfb`는 각 DisplayLink 장치의 순차 framebuffer ID에 따라 `/sys/class/graphics/fb?` 아래에 파일을 만듭니다.
`edid`에 유효한 EDID blob을 쓰면, 연결 monitor의 실제 EDID 읽기가 실패할 때 backup으로 사용합니다. EDID로 능력을 알리지 못하는 fixed panel 등에 유용합니다. 파일을 읽으면 현재 monitor EDID 또는 마지막 backup 값을 반환하며 `parse-edid` 같은 도구에 전달할 수 있습니다.
`metrics_bytes_rendered`는 rendering한 픽셀 byte, `metrics_bytes_identical`은 shadow 비교에서 변하지 않은 byte, `metrics_bytes_sent`는 압축과 protocol overhead를 포함해 USB로 전송한 byte의 32비트 count입니다. `metrics_cpu_kcycles_used`는 처리에 쓴 CPU cycle을 천 cycle 단위 32비트 값으로 셉니다.
write-only `metrics_reset`에 무엇이든 쓰면 모든 metric이 0으로 reset됩니다. 32비트 counter는 빠르게 wraparound하므로 신뢰할 수 있는 성능 시험은 매우 짧게, 안전하게는 1분 이하로 설계해야 합니다. 작성자는 Bernie Thompson입니다.
속성의미
`edid`현재/backup EDID 읽기·쓰기
`metrics_bytes_rendered`rendering한 픽셀 byte
`metrics_bytes_identical`shadow에서 동일했던 byte
`metrics_bytes_sent`압축·protocol 포함 USB 전송 byte
`metrics_cpu_kcycles_used`사용 CPU cycle / 1,000
`metrics_reset`write 시 모든 metric 0
Sysfs Attributes
================
Udlfb creates several files in /sys/class/graphics/fb?
Where ? is the sequential framebuffer id of the particular DisplayLink device
======================== ========================================================
edid If a valid EDID blob is written to this file (typically
by a udev rule), then udlfb will use this EDID as a
backup in case reading the actual EDID of the monitor
attached to the DisplayLink device fails. This is
especially useful for fixed panels, etc. that cannot
communicate their capabilities via EDID. Reading
this file returns the current EDID of the attached
monitor (or last backup value written). This is
useful to get the EDID of the attached monitor,
which can be passed to utilities like parse-edid.
metrics_bytes_rendered 32-bit count of pixel bytes rendered
metrics_bytes_identical 32-bit count of how many of those bytes were found to be
unchanged, based on a shadow framebuffer check
metrics_bytes_sent 32-bit count of how many bytes were transferred over
USB to communicate the resulting changed pixels to the
hardware. Includes compression and protocol overhead
metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the
above pixels (in thousands of cycles).
metrics_reset Write-only. Any write to this file resets all metrics
above to zero. Note that the 32-bit counters above
roll over very quickly. To get reliable results, design
performance tests to start and finish in a very short
period of time (one minute or less is safe).
======================== ========================================================
Bernie Thompson <[email protected]>
요약·해설
udlfb.rst:1-169`udlfb`는 로컬 rendering의 변경 픽셀만 압축해 USB 2.0 DisplayLink framebuffer로 보내며, damage notification·shadow buffer·defio와 sysfs metric으로 전송 비용을 관리합니다.
rendering과 전송을 분리해 USB 대역폭을 절약합니다.