Implement DMA, DRM for Wayland support rendering layer

[archanaberry]

Thanks for the contribution — this is an ambitious and important step for Fishix. Introducing DMA and a DRM-like rendering layer is a major milestone toward real graphical support and future Wayland compatibility.

However, before this can be properly reviewed or merged, a few things need to be improved so the changes are easier to understand and maintain for reviewers and future contributors.

1. Add a proper PR description
   Please include the goal of the change, the scope of the affected subsystems, a short design overview of the DMA/DRM architecture, the current status of the implementation, and a clear list of what is not implemented yet. Large kernel changes need this context so reviewers can evaluate the design decisions.

2. Reduce the scope
   This change appears to cover too many areas at once. Consider splitting it into smaller logical PRs, such as DMA, DRM core, KMS/display handling, userspace/UAPI, and documentation. Smaller PRs are much easier to review, test, and debug.

3. Adjust documentation claims
   Some of the documentation currently sounds as though Wayland support is fully complete. At this stage, it would be more accurate to describe it as experimental or work in progress until compositor testing and stability validation are done.

4. Explain the architecture
   Please document the buffer ownership model, DMA memory lifecycle, synchronization strategy, userspace interaction model, and how closely this design intends to follow Linux DRM semantics. Without this, future contributors will have a harder time extending or debugging the system.

5. Add a test plan
   Please include steps reviewers can use to validate the change, such as booting Fishix in QEMU, checking DRM device initialization, verifying DMA buffer allocation, running a basic rendering or framebuffer test, and listing the expected logs or output.

6. Keep naming and structure consistent
   Please keep naming conventions consistent and maintain clear subsystem boundaries. Mixing major documentation updates with core kernel implementation in one large change makes the codebase harder to navigate.

Summary
The direction of this work is excellent and fits Fishix’s long-term evolution into a modern graphical OS platform. The main issue is not the idea itself, but the presentation, scope, and reviewability. Once the documentation, structure, and testing details are improved, this will be much easier to review and integrate. Great work pushing Fishix forward.

[archanaberry]

My compiling with additional DRM, DMA

gryzzlay@WIN-PD132L8NF4E:/mnt/c/Users/Administrator/OneDrive/Dokumen/jd$ make
cd kernel && meson setup build
The Meson build system
Version: 1.7.0
Source dir: /mnt/c/Users/Administrator/OneDrive/Dokumen/jd/kernel
Build dir: /mnt/c/Users/Administrator/OneDrive/Dokumen/jd/kernel/build
Build type: native build
Project name: fishix
Project version: undefined
Nasm compiler for the host machine: nasm (nasm 2.16.03)
Nasm linker for the host machine: cc ld.bfd 2.44
C compiler for the host machine: cc (gcc 14.2.0 "cc (Debian 14.2.0-19) 14.2.0")
C linker for the host machine: cc ld.bfd 2.44
C++ compiler for the host machine: c++ (gcc 14.2.0 "c++ (Debian 14.2.0-19) 14.2.0")
C++ linker for the host machine: c++ ld.bfd 2.44
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program ld found: YES (/usr/bin/ld)
Build targets in project: 5

Found ninja-1.12.1 at /usr/bin/ninja
cd kernel && meson compile --jobs 1 -C build                                               
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /mnt/c/Users/Administrator/OneDrive/Dokumen/jd/kernel/build -j 1
ninja: Entering directory `/mnt/c/Users/Administrator/OneDrive/Dokumen/jd/kernel/build'
[79/79] Linking target fishix

[uukelele]

Slop, couldn't even be asked to create a PR description.