2018-10-14 16:48:51 +02:00
|
|
|
sway-output(5)
|
|
|
|
|
|
|
|
# NAME
|
|
|
|
|
|
|
|
sway-output - output configuration commands for sway
|
|
|
|
|
|
|
|
# DESCRIPTION
|
|
|
|
|
|
|
|
You may combine output commands into one, like so:
|
|
|
|
|
2019-10-02 23:20:05 +02:00
|
|
|
output HDMI-A-1 mode 1920x1080 pos 1920 0 bg ~/wallpaper.png stretch
|
2018-10-14 16:48:51 +02:00
|
|
|
|
2019-01-27 17:27:34 +01:00
|
|
|
You can get a list of output names with *swaymsg -t get_outputs*. You may also
|
2019-07-18 01:48:28 +02:00
|
|
|
match any output by using the output name "\*". Additionally, "-" can be used
|
|
|
|
to match the focused output by name and "--" can be used to match the focused
|
|
|
|
output by its identifier.
|
2018-10-14 16:48:51 +02:00
|
|
|
|
2018-10-25 10:08:29 +02:00
|
|
|
Some outputs may have different names when disconnecting and reconnecting. To
|
|
|
|
identify these, the name can be substituted for a string consisting of the make,
|
2019-01-27 17:27:34 +01:00
|
|
|
model and serial which you can get from *swaymsg -t get_outputs*. Each value
|
2018-10-25 10:08:29 +02:00
|
|
|
must be separated by one space. For example:
|
|
|
|
|
2019-10-02 23:20:05 +02:00
|
|
|
output "Some Company ABC123 0x00000000" pos 1920 0
|
2018-10-25 10:08:29 +02:00
|
|
|
|
2018-10-14 16:48:51 +02:00
|
|
|
# COMMANDS
|
|
|
|
|
2019-10-26 22:36:49 +02:00
|
|
|
*output* <name> mode|resolution|res [--custom] <WIDTHxHEIGHT>[@<RATE>[Hz]]
|
2018-10-14 16:48:51 +02:00
|
|
|
Configures the specified output to use the given mode. Modes are a
|
|
|
|
combination of width and height (in pixels) and a refresh rate that your
|
|
|
|
display can be configured to use. For a list of available modes for each
|
2019-01-27 17:27:34 +01:00
|
|
|
output, use *swaymsg -t get_outputs*.
|
2018-10-14 16:48:51 +02:00
|
|
|
|
2019-10-26 22:36:49 +02:00
|
|
|
To set a custom mode not listed in the list of available modes, use
|
|
|
|
*--custom*. You should probably only use this if you know what you're
|
|
|
|
doing.
|
|
|
|
|
2018-10-14 16:48:51 +02:00
|
|
|
Examples:
|
|
|
|
|
|
|
|
output HDMI-A-1 mode 1920x1080
|
|
|
|
|
|
|
|
output HDMI-A-1 mode 1920x1080@60Hz
|
|
|
|
|
|
|
|
*output* <name> position|pos <X> <Y>
|
|
|
|
Places the specified output at the specific position in the global
|
2019-01-28 23:33:01 +01:00
|
|
|
coordinate space. The cursor may only be moved between immediately
|
|
|
|
adjacent outputs. If scaling is active, it has to be considered when
|
|
|
|
positioning. For example, if the scaling factor for the left output is
|
|
|
|
2, the relative position for the right output has to be divided by 2.
|
|
|
|
The reference point is the top left corner so if you want the bottoms
|
|
|
|
aligned this has to be considered as well.
|
2018-12-27 17:25:48 +01:00
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
output HDMI1 scale 2
|
|
|
|
|
2019-01-02 09:04:12 +01:00
|
|
|
output HDMI1 pos 0 1020 res 3200x1800
|
2018-12-27 17:25:48 +01:00
|
|
|
|
|
|
|
output eDP1 pos 1600 0 res 1920x1080
|
|
|
|
|
2019-02-27 11:48:30 +01:00
|
|
|
Note that the left x-pos of eDP1 is 1600 = 3200/2 and the bottom y-pos is
|
2019-01-02 09:04:12 +01:00
|
|
|
1020 + (1800 / 2) = 1920 = 0 + 1920
|
2018-10-14 16:48:51 +02:00
|
|
|
|
|
|
|
*output* <name> scale <factor>
|
|
|
|
Scales the specified output by the specified scale _factor_. An integer is
|
|
|
|
recommended, but fractional values are also supported. If a fractional
|
|
|
|
value are specified, be warned that it is not possible to faithfully
|
|
|
|
represent the contents of your windows - they will be rendered at the next
|
2020-01-10 05:16:46 +01:00
|
|
|
highest integer scale factor and downscaled. You may be better served by
|
|
|
|
setting an integer scale factor and adjusting the font size of your
|
2019-01-04 11:34:16 +01:00
|
|
|
applications to taste. HiDPI isn't supported with Xwayland clients (windows
|
|
|
|
will blur).
|
2018-10-14 16:48:51 +02:00
|
|
|
|
2019-11-13 19:23:36 +01:00
|
|
|
*output* <name> scale_filter linear|nearest|smart
|
|
|
|
Indicates how to scale application buffers that are rendered at a scale
|
|
|
|
lower than the output's configured scale, such as lo-dpi applications on
|
|
|
|
hi-dpi screens. Linear is smoother and blurrier, nearest (also known as
|
|
|
|
nearest neighbor) is sharper and blockier. Setting "smart" will apply
|
|
|
|
nearest scaling when the output has an integer scale factor, otherwise
|
|
|
|
linear. The default is "smart".
|
|
|
|
|
2019-02-11 01:56:57 +01:00
|
|
|
*output* <name> subpixel rgb|bgr|vrgb|vbgr|none
|
|
|
|
Manually sets the subpixel hinting for the specified output. This value is
|
|
|
|
usually auto-detected, but some displays may misreport their subpixel
|
|
|
|
geometry. Using the correct subpixel hinting allows for sharper text.
|
|
|
|
Incorrect values will result in blurrier text. When changing this via
|
|
|
|
*swaymsg*, some applications may need to be restarted to use the new value.
|
|
|
|
|
2019-01-27 17:27:34 +01:00
|
|
|
*output* <name> background|bg <file> <mode> [<fallback_color>]
|
2018-10-14 16:48:51 +02:00
|
|
|
Sets the wallpaper for the given output to the specified file, using the
|
|
|
|
given scaling mode (one of "stretch", "fill", "fit", "center", "tile"). If
|
|
|
|
the specified file cannot be accessed or if the image does fill the entire
|
|
|
|
output, a fallback color may be provided to cover the rest of the output.
|
2019-09-10 19:13:12 +02:00
|
|
|
_fallback_color_ should be specified as _#RRGGBB_. Alpha is not supported.
|
2018-10-14 16:48:51 +02:00
|
|
|
|
2019-01-27 17:27:34 +01:00
|
|
|
*output* <name> background|bg <color> solid_color
|
2018-10-14 16:48:51 +02:00
|
|
|
Sets the background of the given output to the specified color. _color_
|
|
|
|
should be specified as _#RRGGBB_. Alpha is not supported.
|
|
|
|
|
2018-10-31 22:06:49 +01:00
|
|
|
*output* <name> transform <transform> [clockwise|anticlockwise]
|
2018-10-14 16:48:51 +02:00
|
|
|
Sets the background transform to the given value. Can be one of "90", "180",
|
|
|
|
"270" for rotation; or "flipped", "flipped-90", "flipped-180", "flipped-270"
|
2020-02-10 18:29:44 +01:00
|
|
|
to apply a rotation and flip, or "normal" to apply no transform. The
|
|
|
|
rotation is performed clockwise. If a single output is chosen and a
|
|
|
|
rotation direction is specified (_clockwise_ or _anticlockwise_) then the
|
|
|
|
transform is added or subtracted from the current transform.
|
2018-10-14 16:48:51 +02:00
|
|
|
|
|
|
|
*output* <name> disable|enable
|
|
|
|
Enables or disables the specified output (all outputs are enabled by
|
|
|
|
default).
|
|
|
|
|
2019-05-11 08:57:53 +02:00
|
|
|
*output* <name> toggle
|
|
|
|
Toggle the specified output.
|
|
|
|
|
2019-02-27 11:48:30 +01:00
|
|
|
*output* <name> dpms on|off
|
|
|
|
Enables or disables the specified output via DPMS. To turn an output off
|
|
|
|
(ie. blank the screen but keep workspaces as-is), one can set DPMS to off.
|
|
|
|
|
2019-09-25 12:58:27 +02:00
|
|
|
*output* <name> max_render_time off|<msec>
|
|
|
|
When set to a positive number of milliseconds, enables delaying output
|
|
|
|
rendering to reduce latency. The rendering is delayed in such a way as
|
|
|
|
to leave the specified number of milliseconds before the next
|
|
|
|
presentation for rendering.
|
|
|
|
|
|
|
|
The output rendering normally takes place immediately after a
|
|
|
|
presentation (vblank, buffer flip, etc.) and the frame callbacks are
|
|
|
|
sent to surfaces immediately after the rendering to give surfaces the
|
|
|
|
most time to draw their next frame. This results in slightly below 2
|
|
|
|
frames of latency between the surface rendering and committing new
|
|
|
|
contents, and the contents being shown on screen, on average. When the
|
|
|
|
output rendering is delayed, the frame callbacks are sent immediately
|
|
|
|
after presentation, and the surfaces have a small timespan (1 /
|
|
|
|
(refresh rate) - max_render_time) to render and commit new contents to
|
|
|
|
be shown on the next presentation, resulting in below 1 frame of
|
|
|
|
latency.
|
|
|
|
|
|
|
|
To set this up for optimal latency:
|
|
|
|
. Launch some _full-screen_ application that renders continuously, like
|
|
|
|
*glxgears*.
|
|
|
|
. Start with *max_render_time 1*. Increment by *1* if you see frame
|
|
|
|
drops.
|
|
|
|
|
2019-09-25 16:35:41 +02:00
|
|
|
To achieve even lower latency, see the *max_render_time* surface
|
|
|
|
property in *sway*(5).
|
|
|
|
|
2019-11-17 11:54:05 +01:00
|
|
|
Note that this property has an effect only on backends which report the
|
|
|
|
presentation timestamp and the predicted output refresh rate—the DRM
|
|
|
|
and the Wayland backends. Furthermore, under the Wayland backend the
|
|
|
|
optimal max_render_time value may vary based on the parent compositor
|
|
|
|
rendering timings.
|
|
|
|
|
2018-10-14 16:48:51 +02:00
|
|
|
# SEE ALSO
|
|
|
|
|
|
|
|
*sway*(5) *sway-input*(5)
|