-
Notifications
You must be signed in to change notification settings - Fork 67
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
vt(4) integration: New
vt_drmfb
backend to integrate with `drm_fb_h…
…elper` [Why] The goal is to make the framebuffer behavior closer to what happens on Linux. One major difference is that on FreeBSD, we used to pass the screen base address to `vt_fb` during initialization, then `vt_fb` would write directly to that memory region. This worked fine for years. Unfortunately, this broke somehow with the backport of DRM from Linux 5.17. At that point, the screen was not refreshed anymore, even though `vt_fb` wrote pixels to the correct memory region. The only time the screen was refreshed, it was during a vt-switch. The screen then displayed the content of the tty we just switched away, but still, something happened on the screen. And that's the only operation we called into `drm_fb_helper` from `vt_fb`. On Linux, `fbcon` calls into `fbdev`, emulated by `drm_fb_helper` for each access (read & write) to the framebuffer. It never reads or writes to the memory region on its own. [How] Therefore we need a new integration layer to make sure vt(4) calls into `drm_fb_helper` like Linux' fbcon does. We do this by adding a new vt(4) backend called `vt_drmfb`, which replaces `vt_fb`. `vt_drmfb` bridges between: * DRM's `drm_fb_helper` emulation of Linux' fbdev below, and * vt(4) console handling above In other words, it maps fbdev callbacks to vt(4)'s backend expected callbacks. `vt_drmfb` takes care of converting the vt(4) callbacks arguments to whatever is expected by the underlying fbdev emulation. Then, when it's time to write to the actual framebuffer memory, the implementation of `cfb_*` functions are derived from the `vt_fb` "setpixel" code. `vt_drmfb` is maintained inside drm-kmod and is compiled inside drm(4). It is not under `sys/dev/vt/hw`. The reason is that `vt_drmfb` needs to know the `drm_fb_helper` API and must evolve with it. `vt_drmfb` has another difference: it doesn't use a taskqueue(9) to call into `drm_fb_helper as `vt_fb` did. It performs the calls synchronously. `drm_fb_helper` already uses a Linux workqueue to make updates asynchronous with the underlying driver. This simplifies the integration a lot because the whole `fb_mode_task`-related machinery is removed from `drm_os_freebsd.c` and `linux_fb.c`. Because we don't need that taskqueue(9) anymore, this patch also gets rid of the `struct vt_kms_softc` indirection. Now, the `struct drm_fb_helper` pointed is stored directly into FreeBSD's `struct fb_info->fb_priv`.
- Loading branch information
Showing
7 changed files
with
582 additions
and
86 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.