vasilito
10caab7085
Comprehensive boot process improvement across the entire stack: Compositor (NEW): Real Rust Wayland display server (690 lines) - Full XDG shell protocol (15/15 protocols implemented and verified) - wl_shm.format, xdg_wm_base, xdg_surface.get_toplevel support - wl_buffer.release lifecycle, buffer composite to framebuffer - Framebuffer mapping via scheme:memory (Redox) with fallback - PID/status files for greeterd health checks - Integration test suite (3 cases passing) - Diagnostic tool: redbear-compositor-check DRM/KMS Chain: - KWIN_DRM_DEVICES=/scheme/drm/card0 wired through init→greeterd→compositor - session-launch propagates KWIN_DRM_DEVICES (new test, 11/11 pass) - DRM auto-detect + 5s wait loop in compositor wrapper - Boot verified: compositor uses DRM backend in QEMU Intel DRM: - Gen8-Gen12 supported with firmware (SKL/KBL/CNL/ICL/GLK/RKL/DG1/TGL/ADLP/DG2/MTL/ARL/LNL/BMG) - Gen4-Gen7 device IDs recognized, unsupported with clear error message - Linux 7.0 i915 reference for all 200+ device IDs - Display fixes: sticky pipe refresh, PIPE=4/PORT=6, 64-bit page flip, EDID skeleton - 4 durability patches wired into recipe VirtIO GPU Driver (NEW): - 220-line DRM/KMS backend for QEMU virtio-gpu - Full GpuDriver trait implementation (11 methods) - PCI BAR0 framebuffer mapping, connector/mode info, GEM management Kernel: - 4GB RAM hang root cause: MEMORY_MAP overflow at 512 entries → fixed to 1024 - Canary chain R S 1 2 3 4 5 6 7 (9 COM1 checkpoints through boot) - Verified: kernel boots at 4GB with all canaries present - 3 durability patches (P0-canary, P1-memory-overflow) Live ISO: - Preload capped at 1 GiB with partial preload messaging - P5 patch wired into bootloader recipe Greeter: - Startup progress logging (4 checkpoints) - QML crash diagnostic (exit code 1 → specific error message) - greeterd tests: 8/8 pass Boot Daemons: - dhcpd: auto-detect interface from /scheme/netcfg/ifaces/ - i2c-gpio-expanderd: I2C decode retry (3× with 50ms delay) - ucsid: same I2C decode hardening - Compositor: safe framebuffer fallback (prevents crash) Qt6 Toolchain: - -march=x86-64 for CPU compatibility (prevents invalid_opcode on core2duo) - -fpermissive for header compatibility (unlinkat/linkat redefinition) Documentation: - BOOT-PROCESS-IMPROVEMENT-PLAN.md (comprehensive, 320 lines) - PROFILE-MATRIX.md: ISO organization, RAM requirements, known issues - BOOT-PROCESS-ASSESSMENT.md: Phase 7 kernel hang diagnosis - Deleted 4 stale docs (BAREMETAL-LOG, ACPI-FIXES, 02-GAP-ANALYSIS, _CUB_RBPKGBUILD) - Cross-references updated across all docs KWin stubs replaced with real compositor delegation. redbear-kde-session script created for post-login session launch. 30+ files, 10 patches, 3 binaries, 22 tests, 0 errors.
KWayland
KWayland is a Qt-style API to interact with the wayland-client API.
Introduction
The API is Qt-styled removing the needs to interact with a for a Qt developer uncomfortable low-level C-API. For example the callback mechanism from the Wayland API is replaced by signals; data types are adjusted to be what a Qt developer expects, e.g. two arguments of int are represented by a QPoint or a QSize.
KWayland Client
The idea around KWayland Client is to provide a drop-in API for the Wayland client library which at the same time provides convenience Qt-style API. It is not intended to be used as a replacement for the QtWayland QPA plugin, but rather as a way to interact with Wayland in case one needs Qt to use a different QPA plugin or in combination with QtWayland to allow a more low-level interaction without requiring to write C code.
Convenience API
The convenience API in KWayland Client provides one class wrapping a Wayland object. Each class can be casted into the wrapped Wayland type. The API represents events as signals and provides simple method calls for requests.
Classes representing global Wayland resources can be created through the [Registry](@ref KWayland::Client::Registry). This class eases
the interaction with the Wayland registry and emits signals whenever a new global is announced or gets
removed. The Registry has a list of known interfaces (e.g. common Wayland protocols like wl_compositor
or wl_shell) which have dedicated announce/removed signals and objects can be factored by the Registry
for those globals.
Many globals function as a factory for further resources. E.g. the Compositor has a factory method for Surfaces. All objects can also be created in a low-level way interacting directly with the Wayland API, but provide convenience factory methods in addition. This allows both an easy usage or a more low level control of the Wayland API if needed.
Integration with QtWayland QPA
If the QGuiApplication uses the QtWayland QPA, KWayland allows to integrate with it. That is one does
not need to create a new connection to the Wayland server, but can reuse the one used by Qt. If there
is a way to get a Wayland object from Qt, the respective class provides a static method normally called
fromApplication. In addition the API allows to get the Surface from a QWindow.
Using KWayland in your application
With CMake
KWayland installs a CMake Config file which allows to use KWayland as imported targets.
To find the package use for example:
find_package(KWayland CONFIG)
set_package_properties(KWayland PROPERTIES TYPE OPTIONAL )
add_feature_info("KWayland" KWayland_FOUND "Required for the awesome Wayland on Qt demo")
Now to link against the Client library use:
add_executable(exampleApp example.cpp)
target_link_libraries(exampleApp Plasma::KWaylandClient)
Please make sure that your project is configured with C++11 support:
CONFIG += c++11