3
7
Fork
You've already forked channel
0
input config for river
  • Zig 99.9%
  • C 0.1%
2026年07月08日 11:37:03 +02:00
src move globbing to tributary 2026年07月05日 16:54:27 +02:00
.gitignore correctly merge list config 2026年04月25日 17:50:05 +02:00
build.zig update to libtributary-0.4.0 2026年06月21日 19:49:59 +02:00
build.zig.zon tag a small release with some fixes 2026年07月08日 11:37:03 +02:00
config.rh implement binding devices to outputs by name and description 2026年04月26日 10:59:40 +02:00
CONTRIBUTORS.md add CONTRIBUTORS.md 2026年05月27日 14:26:16 +02:00
LICENSE add license, resolve #1 2026年03月16日 12:41:29 +01:00
README.asciidoc fix type (thx Vess) 2026年05月31日 14:39:35 +02:00
TODO.md overhaul a bunch of things 2026年04月14日 16:22:24 +02:00 

in order to tame a river, one must channel it

Channel: input config for river

channel sources a file called config.rh from your river config directory and example is found in this repo.

This config file is shared with the rhine window manager. The relevant config options are entirely independent and the two programs do not interfere.

The config is reapplied, whenever a new device is added or the file changes.

Configuration options

Channel uses the rhine config format. This means your config consists of a bunch of keys, sub-configs and lists. There is an example config in config.rh but here are the most important details: The config is reloaded whenever it is changed for as long as channel keeps running.

All channel options live in one big block called input, so your config will look something like

input {
 profiles {
 # you could have profiles here
 }
 rules [
 # you could have rules here
 ]
}

The idea is the following: we define our input configuration in a collection of profiles and then provide a list of rules to figure out which devices a profile gets applied to.

Profiles

The profiles block contains a number of profile definitions which are of the form

<name> {
 keyboard {
 # keyboard options go here
 }
 pointer {
 # pointer config goes here
 }
 libinput {
 # libinput config goes here
 }
}

You may omit any of these blocks and it will be treated as if the block were empty. The profile name <name> can be any whitespace-less ASCII string except for any, type or name.

Keyboard

The keyboard block contains configuration options pertaining to keyboards. It contains the following options:

Option Description

rules <option>

model <option>

layout <option>

variant <option>

options <option>

repeat

key repetition options
Repeat

The aforementioned repeat block consists of the following options:

Option Description

rate <rate>

The rate in Hz at which a held-down key gets repeated

delay <delay>

the delay in milisecond after which a held-down key starts getting repeated

Pointer

The pointer block specifies options pertaining to mice and similar devices.

Option Description

scroll_factor <factor>

The factor at which scroll speed gets increased or decreased. A factor of 3 would triple scroll speed, 0.5 would half it.

map_to <mapping>

maps a mouse, touchpad, drawing tablet, touchscreen to the specified subsection of the screen. see Mapping

Mapping

The parameter to map_to can be of the following form:

Option Description

rect <x>, <y>, <w>, <h>

restricts the input device to a rectangle whose top left corner is at <x>, <y> and whose width and height are given by <w> and <h>. The coordinates are in compositor-space (i.e the same ones used by wlr-randr or kanshi).

output name, <glob>

restricts the input device to the first output found whose name matches the given wildcard.

output description, <glob>

restricts the input device to the first output found whose description matches the given wildcard.

Libinput

This blocks specifies options that are specific to libinput (a massive input device configuration library). An option will only be applied to a device that supports it and if omitted be set to the default value for that device. If you want more details on what these options do, check out link:https://wayland.freedesktop.org/libinput/doc/latest/features.html

Here <Button> refers to a mouse button, which is one of

  • Left

  • Right

  • Middle

  • Side

  • Extra

  • Forward

  • Back

  • Task

Option Description

natural_scroll <bool>

if <bool> is true, then this enabled natural scrolling (i.e. for touchpads).

tap_to_click <bool>

if <bool> is true, then this enabled tap to click

disable_while_typing <bool>

if <bool> is true then the device gets disabled while typing

disable_while_trackpointing <bool>

if <bool> is true then the device gets disabled while trackpointing

left_handed <bool>

if <bool> is true, this enabled left-handed mode

middle_mouse_emulation <bool>

if <bool> is true, this enabled middle_mouse_emulation

rotation <rot>

set the rotation anlge of the device to <rot> degrees clockwise from a neutral position

three_finger_drag_mode <mode>

sets three finger drag mode to <mode> which can be one of disabled, enabled_3fg and enabled_4fg

accel_profile <profile>

sets acceleration profile to <profile> which can be one of none, flat or adaptive

accel_speed <speed>

sets acceleration speed to <speed> which is a floating point number clamped to [-1, 1]

scroll_method <meth>

sets the scroll method to <meth> which is one of no_scroll, two_finger, edge or on_button

scroll_button <Button>

the button to use when the scroll method is on_button

click_method <meth>

sets click method to <meth> which is one of none, button_areas or clickfinger

Rules

The rules list is where we actually apply out profiles to an input device. Each line in this section is a rule. Rules are of the following form

<matches>, <profile>

here <profile> is to be substituted with the name of the profile you’d like to apply. <matches> is a , separated list of matching rules, matching rules can be any of the following:

Rule Description

any

this always matches and is the same as not having that match in the list. it is provided purely for aesthetic reasons.

type, <deviceType>

This matches <deviceType> against the type of the device which can be one of keyboard, pointer, touch or tablet.

name, <name_glob>

This matches <name_glob> against the name of the device, refer to the Globbing section.

If a device matches all rules in <matches>. The profile <profile> is applied to it. If a device matches multiple profiles specifying conflicting options either may get applied.

Globbing

Channel supports primitive string globbing. A glob is simply a string which may contain one or more *. A string matches a glob, if all occurences of * in the glob could be replaced by one or more characters in order to obtain the string.

Examples

  • the glob Touchpad only matches the string Touchpad

  • the glob *ouchpad matches touchpad, Touchpad, my Touchpad but not ouchpad

  • the glob ** matches Hi, Hello but not a

Dependencies

Protocols bound

channel binds the following wayland protocols:

  • river-input-management-v1

  • river-libinput-config-v1

  • river-xkb-config-v1

Shared libraries

channel links the following shared libraries:

  • libwayland-client

  • libc

  • libxkbcommon (0.12 or later)

Static Dependencies

channel uses the zig build system to statically depend on tributary a small helper library that facilitates code sharing between rhine and channel.