mirror of
https://github.com/hyprwm/wlroots-hyprland.git
synced 2024-12-22 09:59:48 +01:00
A read-only mirror of https://github.com/hyprwm/wlroots-hyprland
3fc66d4525
Per comments in util/box.h, the width and height of a wlr_box are
exclusive; that is, for a 100x100 box at (0,0), the point (99,99) is
inside it while the point (100,100) is outside it.
Thus mathematically, there exists no single closest point to the
bottom-right corner of the box while remaining inside it. You can
construct an infinite series approaching the limit, such as {(99,99),
(99.9,99.9), (99.99,99.99)...}, but since the intervals are half-open,
there is no "last" point.
wlr_box_closest_point() must therefore define an arbitrary "closest"
point. For points below and to the right of the box, the current
implementation returns (box.x + width - 1, box.y + height - 1). Let's
continue to do this.
However, the current implementation is non-linear: with the example
100x100 box, it will return an input point of (99.9,99.9) unchanged, but
for an input point (100.1,100.1) the returned point will jump back to
(99.0,99.0).
In practice, this non-linearity results in strange behaviors when
driving the mouse cursor to a screen corner. On a 1920x1080 display for
example, driving the cursor quickly to the bottom-left corner results in
a position of exactly (0,1079). Continuing to slowly nudge the cursor
downward results in the position jumping between (0,1079) and other,
fractional coordinates such as (0,1079.88).
The fractional coordinates expose some client/toolkit-side bugs (which,
to be clear, should be fixed on the client side), but IMHO the wlroots
behavior is also inconsistent and wrong -- when I drive the mouse cursor
into the corner of the screen, it should come to a stop at a fixed
position, not jitter around.
|
||
|---|---|---|
| .builds | ||
| .gitlab/issue_templates | ||
| backend | ||
| docs | ||
| examples | ||
| include | ||
| protocol | ||
| render | ||
| tinywl | ||
| types | ||
| util | ||
| xcursor | ||
| xwayland | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mailmap | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| meson.build | ||
| meson_options.txt | ||
| README.md | ||
| wlroots.syms | ||
wlroots
Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway.
- wlroots provides backends that abstract the underlying display and input hardware, including KMS/DRM, libinput, Wayland, X11, and headless backends, plus any custom backends you choose to write, which can all be created or destroyed at runtime and used in concert with each other.
- wlroots provides unopinionated, mostly standalone implementations of many Wayland interfaces, both from wayland.xml and various protocol extensions. We also promote the standardization of portable extensions across many compositors.
- wlroots provides several powerful, standalone, and optional tools that implement components common to many compositors, such as the arrangement of outputs in physical space.
- wlroots provides an Xwayland abstraction that allows you to have excellent Xwayland support without worrying about writing your own X11 window manager on top of writing your compositor.
- wlroots provides a renderer abstraction that simple compositors can use to avoid writing GL code directly, but which steps out of the way when your needs demand custom rendering code.
wlroots implements a huge variety of Wayland compositor features and implements them right, so you can focus on the features that make your compositor unique. By using wlroots, you get high performance, excellent hardware compatibility, broad support for many wayland interfaces, and comfortable development tools - or any subset of these features you like, because all of them work independently of one another and freely compose with anything you want to implement yourself.
Check out our wiki to get started with wlroots. Join our IRC channel: #wlroots on Libera Chat.
A variety of wrapper libraries are available for using it with your favorite programming language.
Building
Install dependencies:
- meson
- wayland
- wayland-protocols
- EGL and GLESv2 (optional, for the GLES2 renderer)
- Vulkan loader, headers and glslang (optional, for the Vulkan renderer)
- libdrm
- GBM (optional, for the GBM allocator)
- libinput (optional, for the libinput backend)
- xkbcommon
- udev (optional, for the session)
- pixman
- libseat (optional, for the session)
- hwdata (optional, for the DRM backend)
- libdisplay-info (optional, for the DRM backend)
- libliftoff (optional, for the DRM backend)
If you choose to enable X11 support:
- xwayland (build-time only, optional at runtime)
- libxcb
- libxcb-render-util
- libxcb-wm
- libxcb-errors (optional, for improved error reporting)
Run these commands:
meson setup build/
ninja -C build/
Install like so:
sudo ninja -C build/ install
Contributing
See CONTRIBUTING.md.