vasilito
0ec7bd46bb
ROLLUP of all Phase 1-3 work on branch 0.3.0, targeting a production-ready console + full graphical desktop under Intel and Virgl/VirtIO-GPU. === Phase 1 — Stability === - fbcond: Enter key handler (scancode 0x1C→\n), display map buffering, control-char filter in all 7 keymaps, write_event assert - build-redbear.sh: auto-rebuild-prefix when fork timestamps are newer than prefix/x86_64-unknown-redox/sysroot (was warning-only). Added configurable REDBEAR_SKIP_PREFIX_REBUILD guard. - build-redbear.sh: set explicit keymap '-K us' in console activation - config/redbear-device-services.toml: remove spurious init.d service files for redbear-acmd/ecmd/usbaudiod. These USB device daemons are spawned dynamically by pcid-spawner, not as boot-time init services. Starting them without args panicked the boot flow. - relibc: grantpt/unlockpt/ptsname (then deduplicated against stdlib) - userutils: cherry-pick upstream getty commit2834434(standard C ptsname/grantpt/unlockpt) - base fork: Russian (ЙЦУКЕН) keymap + inputd control-char filter (K_ESC/K_BKSP/K_ENTER → \0, commit73e44d81in submodule/base) === Phase 2 — Login & Console === - login.rs: restored to 0.2.5-known-good liner-based prompt - redbear-upower: removed tokio full/signal features → protection fault fix - redbear-power: excluded temporarily (being fixed in other session) - tlc version: updated to 0.3.0 === Phase 3 — GPU/3D Drivers (commit0898332f7a) === Intel i915: FULLY implemented — real ring buffer + MMIO command submission via GEM DMA → GGTT → i915 render ring, with hardware head-pointer polling (2M iterations, 50µs backoff). Zero stubs. VirtIO GPU/Virgl (VirtioTransport): 11 VIRTGPU ioctls (GETPARAM, GET_CAPS, RESOURCE_CREATE, RESOURCE_INFO, CONTEXT_INIT, EXECBUFFER, WAIT, TRANSFER_TO_HOST, TRANSFER_FROM_HOST, MAP, CREATE_BLOB) ported from Linux 7.1 virtgpu_ioctl.c and virtgpu_vq.c. - driver.rs: 8 virgl_* trait methods (default Unsupported) - scheme.rs: 11 ioctl constants + 8 wire structures + dispatch - virtio/transport.rs: PCI capability discovery, feature negotiation, control+cursor virtqueue setup, vring descriptor building - virtio/mod.rs: real implementations for all 8 virgl_* methods - intel/mod.rs: explicit virgl Unsupported stubs Other changes from active sessions: Cargo.toml version bumps, linux-kpi headers, libpciaccess recipe, mesa/recipe.toml, kf6 patches, expat, driver-manager, redbear-sessiond, redbear-compositor, cub, tlc, and many other local recipes.
KWin
KWin is an easy to use, but flexible, compositor for Wayland on Linux. Its primary usage is in conjunction with a Desktop Shell (e.g. KDE Plasma Desktop). KWin is designed to go out of the way; users should not notice that they use a window manager at all. Nevertheless KWin provides a steep learning curve for advanced features, which are available, if they do not conflict with the primary mission. KWin does not have a dedicated targeted user group, but follows the targeted user group of the Desktop Shell using KWin as it's window manager.
KWin is not...
- a standalone Wayland compositor (c.f. labwc, sway) and does not provide any functionality belonging to a Desktop Shell.
- a replacement for window managers designed for use with a specific Desktop Shell (e.g. GNOME Shell)
- a minimalistic window manager
- designed for use with network transparency, though it is possible (with e.g. waypipe).
Contributing to KWin
Please refer to the contributing document for everything you need to know to get started contributing to KWin.
Contacting KWin development team
- mailing list: kwin@kde.org
- IRC: #kde-kwin on irc.libera.chat
- Matrix: #kwin:kde.org
Support
Application Developer
If you are an application developer having questions regarding windowing systems (either X11 or Wayland) please do not hesitate to contact us. Preferable through our mailing list. Ideally subscribe to the mailing list, so that your mail doesn't get stuck in the moderation queue.
End user
Please contact the support channels of your Linux distribution for user support. The KWin development team does not provide end user support.
Reporting bugs
Please use KDE's bugtracker and report for product KWin.
Guidelines for new features
A new Feature can only be added to KWin if:
- it does not violate the primary missions as stated at the start of this document
- it does not introduce instabilities
- it is maintained, that is bugs are fixed in a timely manner (second next minor release) if it is not a corner case.
- it works together with all existing features
- it supports both single and multi screen
- it adds a significant advantage
- it is feature complete, that is supports at least all useful features from competitive implementations
- it is not a special case for a small user group
- it does not increase code complexity significantly
- it does not affect KWin's license (GPLv2+)
All new added features are under probation, that is if any of the non-functional requirements as listed above do not hold true in the next two feature releases, the added feature will be removed again.
The same non functional requirements hold true for any kind of plugins (effects, scripts, etc.). It is suggested to use scripted plugins and distribute them separately.