vasilito
f31522130f
Build system (5 gaps hardened): - COOKBOOK_OFFLINE defaults to true (fork-mode) - normalize_patch handles diff -ruN format - New 'repo validate-patches' command (25/25 relibc patches) - 14 patched Qt/Wayland/display recipes added to protected list - relibc archive regenerated with current patch chain Boot fixes (fixable): - Full ISO EFI partition: 16 MiB → 1 MiB (matches mini, BIOS hardcoded 2 MiB offset) - D-Bus system bus: absolute /usr/bin/dbus-daemon path (was skipped) - redbear-sessiond: absolute /usr/bin/redbear-sessiond path (was skipped) - daemon framework: silenced spurious INIT_NOTIFY warnings for oneshot_async services (P0-daemon-silence-init-notify.patch) - udev-shim: demoted INIT_NOTIFY warning to INFO (expected for oneshot_async) - relibc: comprehensive named semaphores (sem_open/close/unlink) replacing upstream todo!() stubs - greeterd: Wayland socket timeout 15s → 30s (compositor DRM wait) - greeter-ui: built and linked (header guard unification, sem_compat stubs removed) - mc: un-ignored in both configs, fixed glib/libiconv/pcre2 transitive deps - greeter config: removed stale keymapd dependency from display/greeter services - prefix toolchain: relibc headers synced, _RELIBC_STDLIB_H guard unified Unfixable (diagnosed, upstream): - i2c-hidd: abort on no-I2C-hardware (QEMU) — process::exit → relibc abort - kded6/greeter-ui: page fault 0x8 — Qt library null deref - Thread panics fd != -1 — Rust std library on Redox - DHCP timeout / eth0 MAC — QEMU user-mode networking - hwrngd/thermald — no hardware RNG/thermal in VM - live preload allocation — BIOS memory fragmentation, continues on demand
41 lines
1.9 KiB
ReStructuredText
41 lines
1.9 KiB
ReStructuredText
.. _drag_3fg:
|
|
|
|
==============================================================================
|
|
Three-finger drag
|
|
==============================================================================
|
|
|
|
Three-finger drag is a feature available on touchpads that emulates logical
|
|
button presses if three fingers are moving on the touchpad.
|
|
|
|
Three-finger drag is independent from :ref:`tapping` though some specific
|
|
behaviors may change when both features are enabled. For example, with
|
|
tapping *disabled* a three-finger gesture will virtually always be a three-finger
|
|
drag. With tapping *enabled* a three finger gesture may be a three finger drag
|
|
and a short delay is required to disambiguate between the two.
|
|
|
|
|
|
The exact behavior of three-finger drag is implementation defined and may
|
|
subtly change. As a general rule, the following constraints can be expected:
|
|
|
|
- three fingers down and movement trigger a button down and subsequent motion
|
|
events (i.e. a drag)
|
|
- releasing one finger while keeping two fingers down will keep the drag
|
|
and *not* switch to :ref:`twofinger_scrolling`.
|
|
- releasing two fingers while keeping one finger down will end the drag
|
|
(and thus release the button) and switch to normal pointer motion
|
|
- releasing all three fingers and putting three fingers back on the touchpad
|
|
immediately will keep the drag (i.e. behave as if the fingers were
|
|
never lifted)
|
|
|
|
- if tapping is enabled: a three finger tap immediately after a three-finger
|
|
drag will *not* tap, the user needs to wait past the timeout to
|
|
three-finger tap
|
|
|
|
- releasing all three fingers and putting one or two fingers back on
|
|
the touchpad will end the drag (and thus release the button)
|
|
and proceed with pointer motion or two-finger scrolling, if applicable
|
|
|
|
- if tapping is enabled: a one or two finger tap immediately after a
|
|
three-finger drag will trigger a one or two finger tap. The user does
|
|
not have to wait past the drag release timeout
|