inputtestdrv

title: inputtestdrv(4)

summary: An X.Org input driver for testing

text:
# inputtestdrv(4)

## NAME
inputtest - An X.Org input driver for testing

## SYNOPSIS

```
Section "InputDevice"
  Identifier "devname"
  Driver "inputtest"
  Option "SocketPath"   "path"
  ...
EndSection
```

## DESCRIPTION
inputtest is an Xorg input driver that passes events received over a socket on to the server as input events. It supports the full set of the xf86 driver APIs exposed by Xorg. The primary use cases of this input driver are various integration tests that need to interface with the input subsystem.

## CONFIGURATION DETAILS
Please refer to xorg.conf(5) for general configuration details and for options that can be used with all input drivers. This section only covers configuration details specific to this driver.

External process can communicate with the input driver via a named socket that is created after the driver is initialized. The paths to the socket is passed via input driver options.

The following driver Options are supported:

Option "SocketPath" "string"

Sets the path where the driver will create a named socket. Any existing file at that location will be removed.

Option "DeviceType" "string"

Sets the type of the device to be emulated.

Keyboard Initializes a keyboard device.

Pointer Initializes a relative-mode pointer device. It will have four valuators - a "Rel X" valuator at axis 0 and a "Rel Y" valuator at axis 1. A horizontal scroll valuator will be set up at axis 2. A vertical scroll valuator will be set up at axis 3.

PointerAbsolute Initializes an absolute-mode pointer device. It will have four valuators - an "Abs X" valuator at axis 0 and an "Abs Y" valuator at axis 1. A horizontal scroll valuator will be set up at axis 2. A vertical scroll valuator will be set up at axis 3.

PointerAbsoluteProximity Initializes an absolute-mode pointer device with proximity support. The valuators are initialized in the same way as for PointerAbsolute type.

Touch Initializes a touch device. It will have 5 valuators: an "Abs MT Position X" at axis 0, an "Abs MT Position Y" valuator at axis 1, a horizontal scroll valuator on axis 2, a vertical scroll valuator on axis 3 and an "Abs MT Pressure" valuator at axis 4.

Option "TouchCount" "int"

Sets the maximum number of simultaneous touches for touch devices.

Option "PointerButtonCount" "int"

Sets the maximum number of buttons in pointer devices.

Option "PointerHasPressure" "bool"

Selects whether "Abs Pressure" is available at the axis 4 in pointer devices.

## INTERFACE WITH THE DRIVER
The communication with the driver is a binary protocol defined in include/xf86-input-inputtest-protocol.h

At the beginning, the client process that communicates with the driver must connect to the socket that is created by the driver at SocketPath. Once the connection is established, it must write a xf86ITEventClientVersion event and read a xf86ITResponseServerVersion response where the driver specifies the protocol version supported by it. If this version is lower than requested by the client, then the driver will disconnect.

After receiving xf86ITResponseServerVersion message the client may send events to the driver. Each event is an instance of one of the xf86ITEvent* structs. The length field defines the full length of the struct in bytes and the event field defines the type of the struct.

The responses from the server follow the same structure. Each response is an instance of one of the xf86ITResponse* structs. The length field defines the full length of the struct in bytes and the event field defines the type of the struct.

The synchronization with Xorg is performed via xf86ITEventWaitForSync event. After sending such event, the client must read of a xf86ITResponseSyncFinishedeventfromthesocketwithoutsendingadditional events. The completion of the read operation indicates that Xorg has fully processed all input events sent to it so far.

## AUTHORS
Povilas Kanapickas <povilas@radix.lt>

## SEE ALSO
Xorg(1), xorg.conf(5), Xserver(1), X(7)


modesetting

package: xorg-server

title: modesetting(4)

summary: video driver for framebuffer device

text:
# modesetting(4)

## NAME
modesetting - video driver for framebuffer device

## SYNOPSIS

```
Section "Device"
  Identifier "devname"
  Driver "modesetting"
  BusID  "pci:bus:dev:func"
  ...
EndSection
```

## DESCRIPTION
modesetting is an Xorg driver for KMS devices. This driver supports TrueColor visuals at framebuffer depths of 15, 16, 24, and 30. RandR 1.2 is supported for multi-head configurations. Acceleration is available through glamor for devices supporting at least OpenGL ES 2.0 or OpenGL 2.1. If glamor is not enabled, a shadow framebuffer is configured based on the KMS drivers' preference (unless the framebuffer is 24 bits per pixel, in which case the shadow framebuffer is always used).

## SUPPORTED HARDWARE
The modesetting driver supports all hardware where a KMS driver is available. modesetting uses the Linux DRM KMS ioctls and dumb object create/map.

## CONFIGURATION DETAILS
Please refer to xorg.conf(5) for general configuration details. This section only covers configuration details specific to this driver.

For this driver it is not required to specify modes in the screen section of the config file. The modesetting driver can pick up the currently used video mode from the kernel driver and will use it if there are no video modes configured.

For PCI boards you might have to add a BusID line to the Device section. See above for a sample line.

The following driver Options are supported:

Option "SWcursor" "boolean"

Selects software cursor. The default is off.

Option "kmsdev" "string"

The framebuffer device to use. Default: /dev/dri/card0.

Option "ShadowFB" "boolean"

Enable or disable use of the shadow framebuffer layer. Default: on.

Option "DoubleShadow" "boolean"

Double-buffer shadow updates. When enabled, the driver will keep two copies of the shadow framebuffer. When the shadow framebuffer is flushed, the old and new versions of the shadow are compared, and only tiles that have actually changed are uploaded to the device. This is an optimization for server-class GPUs with a remote display function (typically VNC), where remote updates are triggered by any framebuffer write, so minimizing the amount of data uploaded is crucial. This defaults to enabled for ASPEED and Matrox G200 devices, and disabled otherwise.

Option "AccelMethod" "string"

One of "glamor" or "none". Default: glamor.

Option "PageFlip" "boolean"

Enable DRI3 page flipping. The default is on.

Option "VariableRefresh" "boolean"

Enables support for enabling variable refresh on the Screen's CRTCs when an suitable application is flipping via the Present extension.

The default is off.

Option "AsyncFlipSecondaries" "boolean"

Use async flips for secondary video outputs on multi-display setups. If a screen has multiple displays attached and DRI3 page flipping is used, then only one of the displays will have its page flip synchronized to vblank for tear-free presentation. This is the display that is used for presentation timing and timestamping, usually the one covering the biggest pixel area of the screen. All other displays ("Secondaries") will not synchronize their flips. This may cause some tearing on these displays, but it prevents a permanent or periodic slowdown or irritating judder of animations if not all video outputs are running synchronized with each other and with the same refresh rate. There is no perfect solution apart from perfectly synchronized outputs, but this option may give preferrable results if the displays in a multi-display setup mirror or clone each other. The default is off.

Option "ZaphodHeads" "string"

Specify the RandR output(s) to use with zaphod mode for a particular driver instance. If you use this option you must use this option for all instances of the driver.

For example: Option "ZaphodHeads" "LVDS,VGA-0" will assign xrandr outputs LVDS and VGA-0 to this instance of the driver.

Option "UseGammaLUT" "boolean"

Enable or disable use of the GAMMA_LUT property, when available. When enabled, this option allows the driver to use gamma ramps with more entries, if supported by the kernel. By default, GAMMA_LUT will be used for kms drivers which are known to be safe for use of GAMMA_LUT.

## SEE ALSO
Xorg(1), xorg.conf(5), Xserver(1), X(7)

## AUTHORS
Authors include: Dave Airlie

branch: sisyphus


spl

package: zfs-utils

title: spl(4)

summary: parameters of the SPL kernel module

text:
# spl(4)

## NAME
spl — parameters of the SPL kernel module

## DESCRIPTION
spl_kmem_cache_kmem_threads=4 (uint)

The number of threads created for the spl_kmem_cache task queue. This task queue is responsible for allocating new slabs for use by the kmem caches. For the majority of systems and workloads only a small number of threads are required.

spl_kmem_cache_obj_per_slab=8 (uint)

The preferred number of objects per slab in the cache. In general, a larger value will increase the caches memory footprint while decreasing the time required to perform an allocation. Conversely, a smaller value will minimize the footprint and improve cache reclaim time but individual allocations may take longer.

spl_kmem_cache_max_size=32 (64-bit) or 4 (32-bit) (uint)

The maximum size of a kmem cache slab in MiB. This effectively limits the maximum cache object size to spl_kmem_cache_max_size/spl_kmem_cache_obj_per_slab. Caches may not be created with object sized larger than this limit.

spl_kmem_cache_slab_limit=16384 (uint)

For small objects the Linux slab allocator should be used to make the most efficient use of the memory. However, large objects are not supported by the Linux slab and therefore the SPL implementation is preferred. This value is used to determine the cutoff between a small and large object. Objects of size spl_kmem_cache_slab_limit or smaller will be allocated using the Linux slab allocator, large objects use the SPL allocator. A cutoff of 16K was determined to be optimal for architectures using 4K pages.

spl_kmem_alloc_warn=32768 (uint)

As a general rule kmem_alloc() allocations should be small, preferably just a few pages, since they must by physically contiguous. Therefore, a rate limited warning will be printed to the console for any kmem_alloc() which exceeds a reasonable threshold. The default warning threshold is set to eight pages but capped at 32K to accommodate systems using large pages. This value was selected to be small enough to ensure the largest allocations are quickly noticed and fixed. But large enough to avoid logging any warnings when a allocation size is larger than optimal but not a serious concern. Since this value is tunable, developers are encouraged to set it lower when testing so any new largish allocations are quickly caught. These warnings may be disabled by setting the threshold to zero.

spl_kmem_alloc_max=KMALLOC_MAX_SIZE/4 (uint)

Large kmem_alloc() allocations will fail if they exceed KMALLOC_MAX_SIZE. Allocations which are marginally smaller than this limit may succeed but should still be avoided due to the expense of locating a contiguous range of free pages. Therefore, a maximum kmem size with reasonable safely margin of 4x is set. kmem_alloc() allocations larger than this maximum will quickly fail. vmem_alloc() allocations less than or equal to this value will use kmalloc(), but shift to vmalloc() when exceeding this value.

spl_kmem_cache_magazine_size=0 (uint)

Cache magazines are an optimization designed to minimize the cost of allocating memory. They do this by keeping a per-CPU cache of recently freed objects, which can then be reallocated without taking a lock. This can improve performance on highly contended caches. However, because objects in magazines will prevent otherwise empty slabs from being immediately released this may not be ideal for low memory machines. For this reason, spl_kmem_cache_magazine_size can be used to set a maximum magazine size. When this value is set to 0 the magazine size will be automatically determined based on the object size. Otherwise magazines will be limited to 2-256 objects per magazine (i.e. per CPU). Magazines may never be entirely disabled in this implementation.

spl_hostid=0 (ulong)

The system hostid, when set this can be used to uniquely identify a system. By default this value is set to zero which indicates the hostid is disabled. It can be explicitly enabled by placing a unique non-zero value in /etc/hostid.

spl_hostid_path=/etc/hostid (charp)

The expected path to locate the system hostid when specified. This value may be overridden for non-standard configurations.

spl_panic_halt=0 (uint)

Cause a kernel panic on assertion failures. When not enabled, the thread is halted to facilitate further debugging. Set to a non-zero value to enable.

spl_taskq_kick=0 (uint)

Kick stuck taskq to spawn threads. When writing a non-zero value to it, it will scan all the taskqs. If any of them have a pending task more than 5 seconds old, it will kick it to spawn more threads. This can be used if you find a rare deadlock occurs because one or more taskqs didn't spawn a thread when it should.

spl_taskq_thread_bind=0 (int)

Bind taskq threads to specific CPUs. When enabled all taskq threads will be distributed evenly across the available CPUs. By default, this behavior is disabled to allow the Linux scheduler the maximum flexibility to determine where a thread should run.

spl_taskq_thread_dynamic=1 (int)

Allow dynamic taskqs. When enabled taskqs which set the TASKQ_DYNAMIC flag will by default create only a single thread. New threads will be created on demand up to a maximum allowed number to facilitate the completion of outstanding tasks. Threads which are no longer needed will be promptly destroyed. By default this behavior is enabled but it can be disabled to aid performance analysis or troubleshooting.

spl_taskq_thread_priority=1 (int)

Allow newly created taskq threads to set a non-default scheduler priority. When enabled, the priority specified when a taskq is created will be applied to all threads created by that taskq. When disabled all threads will use the default Linux kernel thread priority. By default, this behavior is enabled.

spl_taskq_thread_sequential=4 (int)

The number of items a taskq worker thread must handle without interruption before requesting a new worker thread be spawned. This is used to control how quickly taskqs ramp up the number of threads processing the queue. Because Linux thread creation and destruction are relatively inexpensive a small default value has been selected. This means that normally threads will be created aggressively which is desirable. Increasing this value will result in a slower thread creation rate which may be preferable for some configurations.

spl_taskq_thread_timeout_ms=5000 (uint)

Minimum idle threads exit interval for dynamic taskqs. Smaller values allow idle threads exit more often and potentially be respawned again on demand, causing more churn.