Implement Linux framebuffer backend #3
Comments
|
Pull request #15 implements the Linux framebuffer backend for the |
|
With the inclusion of kconfiglib, the build system is now fully configurable like "menuconfig" when building the Linux kernel. This flexibility is also useful for developers to integrate additional backends such as Linux framebuffer and DRM device support. (#18) |
|
LVGL implements both Linux framebuffer and DRM support. See:
awtk-linux-fb is more complete. |
|
Add information of Virtual Terminal (Console) as the Linux framebuffer/DRM backend should also take care of the VT switching: |
|
In GNU/Linux, the user can switch between different virtual terminals using We should deactivate the virtual terminal when |
|
drm-framebuffer is a simple application which can be used to test a Linux DRM device. |
|
pslash, a lightweight framebuffer splashscreen for embedded devices, provides good reference for virtual terminal (VT) management. |
jserv
changed the title
|
Let's focus on Linux framebuffer support for now. DRM support can be considered as a follow-up once the non-SDL display target and VT implementation are merged. |
|
DirectFB uses the event device and udev to manage Human Interface Devices (HIDs), in which the udev is for handling device plug-in and removal. Let's handle the mouse events (i.e., |
Related: #4 |
|
According to Linux 6.12 To Optionally Display A QR Code During Kernel Panics, a new feature allows the display of a QR code within the DRM panic handler infrastructure when a Linux kernel panic occurs. We could consider integrating parts of the Mado codebase into the Linux kernel (as a module) to enhance text rendering capabilities. As a graphical library and window system, Mado does not rely on floating-point operations, making it suitable for Linux kernel integration where no FPU is available. |
This commit adds a Linux framebuffer backend to Mado, utilizing framebuffer and event devices for basic input and display. Note that though TWIN (and by extension, Mado) was designed to operate in single-threaded environments, the Linux framebuffer backend in Mado currently uses POSIX thread to manage input system events. Coroutines could potentially be used as an alternative. Follow-up tasks: 1. Protect mouse event update with mutex (see linux_input.c) 2. Fix an existing unexpected termination bug (see linux_input.c) 3. Support DRM/KMS backend 4. Support hot-pluging and removal of input devices with udev 5. Refine event handling (i.e., remove POSIX thread if possible) Close sysprog21#3
Mado should provide a Linux framebuffer/DRM backend, which is more suitable for embedded systems. In addition, the use of the Linux input subsystem is crucial for integration.
Reference:
The text was updated successfully, but these errors were encountered: