Merge branch 'linus' into perfcounters/core (23db9f43) · Commits · e / devices / android_kernel_fairphone_FP3

Documentation/ABI/testing/sysfs-kernel-slab

0 → 100644

+479 −0

Original line number	Diff line number	Diff line
		What: /sys/kernel/slab
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The /sys/kernel/slab directory contains a snapshot of the
		internal state of the SLUB allocator for each cache. Certain
		files may be modified to change the behavior of the cache (and
		any cache it aliases, if any).
		Users: kernel memory tuning tools

		What: /sys/kernel/slab/cache/aliases
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The aliases file is read-only and specifies how many caches
		have merged into this cache.

		What: /sys/kernel/slab/cache/align
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The align file is read-only and specifies the cache's object
		alignment in bytes.

		What: /sys/kernel/slab/cache/alloc_calls
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The alloc_calls file is read-only and lists the kernel code
		locations from which allocations for this cache were performed.
		The alloc_calls file only contains information if debugging is
		enabled for that cache (see Documentation/vm/slub.txt).

		What: /sys/kernel/slab/cache/alloc_fastpath
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The alloc_fastpath file is read-only and specifies how many
		objects have been allocated using the fast path.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/alloc_from_partial
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The alloc_from_partial file is read-only and specifies how
		many times a cpu slab has been full and it has been refilled
		by using a slab from the list of partially used slabs.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/alloc_refill
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The alloc_refill file is read-only and specifies how many
		times the per-cpu freelist was empty but there were objects
		available as the result of remote cpu frees.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/alloc_slab
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The alloc_slab file is read-only and specifies how many times
		a new slab had to be allocated from the page allocator.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/alloc_slowpath
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The alloc_slowpath file is read-only and specifies how many
		objects have been allocated using the slow path because of a
		refill or allocation from a partial or new slab.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/cache_dma
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The cache_dma file is read-only and specifies whether objects
		are from ZONE_DMA.
		Available when CONFIG_ZONE_DMA is enabled.

		What: /sys/kernel/slab/cache/cpu_slabs
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The cpu_slabs file is read-only and displays how many cpu slabs
		are active and their NUMA locality.

		What: /sys/kernel/slab/cache/cpuslab_flush
		Date: April 2009
		KernelVersion: 2.6.31
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The file cpuslab_flush is read-only and specifies how many
		times a cache's cpu slabs have been flushed as the result of
		destroying or shrinking a cache, a cpu going offline, or as
		the result of forcing an allocation from a certain node.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/ctor
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The ctor file is read-only and specifies the cache's object
		constructor function, which is invoked for each object when a
		new slab is allocated.

		What: /sys/kernel/slab/cache/deactivate_empty
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The file deactivate_empty is read-only and specifies how many
		times an empty cpu slab was deactivated.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/deactivate_full
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The file deactivate_full is read-only and specifies how many
		times a full cpu slab was deactivated.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/deactivate_remote_frees
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The file deactivate_remote_frees is read-only and specifies how
		many times a cpu slab has been deactivated and contained free
		objects that were freed remotely.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/deactivate_to_head
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The file deactivate_to_head is read-only and specifies how
		many times a partial cpu slab was deactivated and added to the
		head of its node's partial list.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/deactivate_to_tail
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The file deactivate_to_tail is read-only and specifies how
		many times a partial cpu slab was deactivated and added to the
		tail of its node's partial list.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/destroy_by_rcu
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The destroy_by_rcu file is read-only and specifies whether
		slabs (not objects) are freed by rcu.

		What: /sys/kernel/slab/cache/free_add_partial
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The file free_add_partial is read-only and specifies how many
		times an object has been freed in a full slab so that it had to
		added to its node's partial list.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/free_calls
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The free_calls file is read-only and lists the locations of
		object frees if slab debugging is enabled (see
		Documentation/vm/slub.txt).

		What: /sys/kernel/slab/cache/free_fastpath
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The free_fastpath file is read-only and specifies how many
		objects have been freed using the fast path because it was an
		object from the cpu slab.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/free_frozen
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The free_frozen file is read-only and specifies how many
		objects have been freed to a frozen slab (i.e. a remote cpu
		slab).
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/free_remove_partial
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The file free_remove_partial is read-only and specifies how
		many times an object has been freed to a now-empty slab so
		that it had to be removed from its node's partial list.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/free_slab
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The free_slab file is read-only and specifies how many times an
		empty slab has been freed back to the page allocator.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/free_slowpath
		Date: February 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The free_slowpath file is read-only and specifies how many
		objects have been freed using the slow path (i.e. to a full or
		partial slab).
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/hwcache_align
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The hwcache_align file is read-only and specifies whether
		objects are aligned on cachelines.

		What: /sys/kernel/slab/cache/min_partial
		Date: February 2009
		KernelVersion: 2.6.30
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		David Rientjes <rientjes@google.com>
		Description:
		The min_partial file specifies how many empty slabs shall
		remain on a node's partial list to avoid the overhead of
		allocating new slabs. Such slabs may be reclaimed by utilizing
		the shrink file.

		What: /sys/kernel/slab/cache/object_size
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The object_size file is read-only and specifies the cache's
		object size.

		What: /sys/kernel/slab/cache/objects
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The objects file is read-only and displays how many objects are
		active and from which nodes they are from.

		What: /sys/kernel/slab/cache/objects_partial
		Date: April 2008
		KernelVersion: 2.6.26
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The objects_partial file is read-only and displays how many
		objects are on partial slabs and from which nodes they are
		from.

		What: /sys/kernel/slab/cache/objs_per_slab
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The file objs_per_slab is read-only and specifies how many
		objects may be allocated from a single slab of the order
		specified in /sys/kernel/slab/cache/order.

		What: /sys/kernel/slab/cache/order
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The order file specifies the page order at which new slabs are
		allocated. It is writable and can be changed to increase the
		number of objects per slab. If a slab cannot be allocated
		because of fragmentation, SLUB will retry with the minimum order
		possible depending on its characteristics.

		What: /sys/kernel/slab/cache/order_fallback
		Date: April 2008
		KernelVersion: 2.6.26
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The file order_fallback is read-only and specifies how many
		times an allocation of a new slab has not been possible at the
		cache's order and instead fallen back to its minimum possible
		order.
		Available when CONFIG_SLUB_STATS is enabled.

		What: /sys/kernel/slab/cache/partial
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The partial file is read-only and displays how long many
		partial slabs there are and how long each node's list is.

		What: /sys/kernel/slab/cache/poison
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The poison file specifies whether objects should be poisoned
		when a new slab is allocated.

		What: /sys/kernel/slab/cache/reclaim_account
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The reclaim_account file specifies whether the cache's objects
		are reclaimable (and grouped by their mobility).

		What: /sys/kernel/slab/cache/red_zone
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The red_zone file specifies whether the cache's objects are red
		zoned.

		What: /sys/kernel/slab/cache/remote_node_defrag_ratio
		Date: January 2008
		KernelVersion: 2.6.25
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The file remote_node_defrag_ratio specifies the percentage of
		times SLUB will attempt to refill the cpu slab with a partial
		slab from a remote node as opposed to allocating a new slab on
		the local node. This reduces the amount of wasted memory over
		the entire system but can be expensive.
		Available when CONFIG_NUMA is enabled.

		What: /sys/kernel/slab/cache/sanity_checks
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The sanity_checks file specifies whether expensive checks
		should be performed on free and, at minimum, enables double free
		checks. Caches that enable sanity_checks cannot be merged with
		caches that do not.

		What: /sys/kernel/slab/cache/shrink
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The shrink file is written when memory should be reclaimed from
		a cache. Empty partial slabs are freed and the partial list is
		sorted so the slabs with the fewest available objects are used
		first.

		What: /sys/kernel/slab/cache/slab_size
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The slab_size file is read-only and specifies the object size
		with metadata (debugging information and alignment) in bytes.

		What: /sys/kernel/slab/cache/slabs
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The slabs file is read-only and displays how long many slabs
		there are (both cpu and partial) and from which nodes they are
		from.

		What: /sys/kernel/slab/cache/store_user
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The store_user file specifies whether the location of
		allocation or free should be tracked for a cache.

		What: /sys/kernel/slab/cache/total_objects
		Date: April 2008
		KernelVersion: 2.6.26
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The total_objects file is read-only and displays how many total
		objects a cache has and from which nodes they are from.

		What: /sys/kernel/slab/cache/trace
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		The trace file specifies whether object allocations and frees
		should be traced.

		What: /sys/kernel/slab/cache/validate
		Date: May 2007
		KernelVersion: 2.6.22
		Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
		Description:
		Writing to the validate file causes SLUB to traverse all of its
		cache's objects and check the validity of metadata.

Documentation/filesystems/tmpfs.txt

+1 −1

Original line number	Diff line number	Diff line
		@@ -133,4 +133,4 @@ RAM/SWAP in 10240 inodes and it is only accessible by root.
		Author:
		Christoph Rohland <cr@sap.com>, 1.12.01
		Updated:
		Hugh Dickins <hugh@veritas.com>, 4 June 2007
		Hugh Dickins, 4 June 2007

Documentation/input/multi-touch-protocol.txt

+79 −24

Original line number	Diff line number	Diff line
		@@ -18,8 +18,12 @@ Usage
		Anonymous finger details are sent sequentially as separate packets of ABS
		events. Only the ABS_MT events are recognized as part of a finger
		packet. The end of a packet is marked by calling the input_mt_sync()
		function, which generates a SYN_MT_REPORT event. The end of multi-touch
		transfer is marked by calling the usual input_sync() function.
		function, which generates a SYN_MT_REPORT event. This instructs the
		receiver to accept the data for the current finger and prepare to receive
		another. The end of a multi-touch transfer is marked by calling the usual
		input_sync() function. This instructs the receiver to act upon events
		accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new
		set of events/packets.

		A set of ABS_MT events with the desired properties is defined. The events
		are divided into categories, to allow for partial implementation. The
		@@ -27,11 +31,26 @@ minimum set consists of ABS_MT_TOUCH_MAJOR, ABS_MT_POSITION_X and
		ABS_MT_POSITION_Y, which allows for multiple fingers to be tracked. If the
		device supports it, the ABS_MT_WIDTH_MAJOR may be used to provide the size
		of the approaching finger. Anisotropy and direction may be specified with
		ABS_MT_TOUCH_MINOR, ABS_MT_WIDTH_MINOR and ABS_MT_ORIENTATION. Devices with
		more granular information may specify general shapes as blobs, i.e., as a
		sequence of rectangular shapes grouped together by an
		ABS_MT_BLOB_ID. Finally, the ABS_MT_TOOL_TYPE may be used to specify
		whether the touching tool is a finger or a pen or something else.
		ABS_MT_TOUCH_MINOR, ABS_MT_WIDTH_MINOR and ABS_MT_ORIENTATION. The
		ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a
		finger or a pen or something else. Devices with more granular information
		may specify general shapes as blobs, i.e., as a sequence of rectangular
		shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices
		that currently support it, the ABS_MT_TRACKING_ID event may be used to
		report finger tracking from hardware [5].

		Here is what a minimal event sequence for a two-finger touch would look
		like:

		ABS_MT_TOUCH_MAJOR
		ABS_MT_POSITION_X
		ABS_MT_POSITION_Y
		SYN_MT_REPORT
		ABS_MT_TOUCH_MAJOR
		ABS_MT_POSITION_X
		ABS_MT_POSITION_Y
		SYN_MT_REPORT
		SYN_REPORT


		Event Semantics
		@@ -44,24 +63,24 @@ ABS_MT_TOUCH_MAJOR

		The length of the major axis of the contact. The length should be given in
		surface units. If the surface has an X times Y resolution, the largest
		possible value of ABS_MT_TOUCH_MAJOR is sqrt(X^2 + Y^2), the diagonal.
		possible value of ABS_MT_TOUCH_MAJOR is sqrt(X^2 + Y^2), the diagonal [4].

		ABS_MT_TOUCH_MINOR

		The length, in surface units, of the minor axis of the contact. If the
		contact is circular, this event can be omitted.
		contact is circular, this event can be omitted [4].

		ABS_MT_WIDTH_MAJOR

		The length, in surface units, of the major axis of the approaching
		tool. This should be understood as the size of the tool itself. The
		orientation of the contact and the approaching tool are assumed to be the
		same.
		same [4].

		ABS_MT_WIDTH_MINOR

		The length, in surface units, of the minor axis of the approaching
		tool. Omit if circular.
		tool. Omit if circular [4].

		The above four values can be used to derive additional information about
		the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates
		@@ -70,14 +89,17 @@ different characteristic widths [1].

		ABS_MT_ORIENTATION

		The orientation of the ellipse. The value should describe half a revolution
		clockwise around the touch center. The scale of the value is arbitrary, but
		zero should be returned for an ellipse aligned along the Y axis of the
		surface. As an example, an index finger placed straight onto the axis could
		return zero orientation, something negative when twisted to the left, and
		something positive when twisted to the right. This value can be omitted if
		the touching object is circular, or if the information is not available in
		the kernel driver.
		The orientation of the ellipse. The value should describe a signed quarter
		of a revolution clockwise around the touch center. The signed value range
		is arbitrary, but zero should be returned for a finger aligned along the Y
		axis of the surface, a negative value when finger is turned to the left, and
		a positive value when finger turned to the right. When completely aligned with
		the X axis, the range max should be returned. Orientation can be omitted
		if the touching object is circular, or if the information is not available
		in the kernel driver. Partial orientation support is possible if the device
		can distinguish between the two axis, but not (uniquely) any values in
		between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1]
		[4].

		ABS_MT_POSITION_X

		@@ -98,8 +120,35 @@ ABS_MT_BLOB_ID

		The BLOB_ID groups several packets together into one arbitrarily shaped
		contact. This is a low-level anonymous grouping, and should not be confused
		with the high-level contactID, explained below. Most kernel drivers will
		not have this capability, and can safely omit the event.
		with the high-level trackingID [5]. Most kernel drivers will not have blob
		capability, and can safely omit the event.

		ABS_MT_TRACKING_ID

		The TRACKING_ID identifies an initiated contact throughout its life cycle
		[5]. There are currently only a few devices that support it, so this event
		should normally be omitted.


		Event Computation
		-----------------

		The flora of different hardware unavoidably leads to some devices fitting
		better to the MT protocol than others. To simplify and unify the mapping,
		this section gives recipes for how to compute certain events.

		For devices reporting contacts as rectangular shapes, signed orientation
		cannot be obtained. Assuming X and Y are the lengths of the sides of the
		touching rectangle, here is a simple formula that retains the most
		information possible:

		ABS_MT_TOUCH_MAJOR := max(X, Y)
		ABS_MT_TOUCH_MINOR := min(X, Y)
		ABS_MT_ORIENTATION := bool(X > Y)

		The range of ABS_MT_ORIENTATION should be set to [0, 1], to indicate that
		the device can distinguish between a finger along the Y axis (0) and a
		finger along the X axis (1).


		Finger Tracking
		@@ -109,14 +158,18 @@ The kernel driver should generate an arbitrary enumeration of the set of
		anonymous contacts currently on the surface. The order in which the packets
		appear in the event stream is not important.

		The process of finger tracking, i.e., to assign a unique contactID to each
		The process of finger tracking, i.e., to assign a unique trackingID to each
		initiated contact on the surface, is left to user space; preferably the
		multi-touch X driver [3]. In that driver, the contactID stays the same and
		multi-touch X driver [3]. In that driver, the trackingID stays the same and
		unique until the contact vanishes (when the finger leaves the surface). The
		problem of assigning a set of anonymous fingers to a set of identified
		fingers is a euclidian bipartite matching problem at each event update, and
		relies on a sufficiently rapid update rate.

		There are a few devices that support trackingID in hardware. User space can
		make use of these native identifiers to reduce bandwidth and cpu usage.


		Notes
		-----

		@@ -136,5 +189,7 @@ could be used to derive tilt.
		time of writing (April 2009), the MT protocol is not yet merged, and the
		prototype implements finger matching, basic mouse support and two-finger
		scrolling. The project aims at improving the quality of current multi-touch
		functionality available in the synaptics X driver, and in addition
		functionality available in the Synaptics X driver, and in addition
		implement more advanced gestures.
		[4] See the section on event computation.
		[5] See the section on finger tracking.

Documentation/kernel-parameters.txt

+4 −0

Original line number	Diff line number	Diff line
		@@ -1535,6 +1535,10 @@ and is between 256 and 4096 characters. It is defined in the file
		register save and restore. The kernel will only save
		legacy floating-point registers on task switch.

		noxsave [BUGS=X86] Disables x86 extended register state save
		and restore using xsave. The kernel will fallback to
		enabling legacy floating-point and sse state.

		nohlt [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or
		wfi(ARM) instruction doesn't work correctly and not to
		use it. This is also useful when using JTAG debugger.

Documentation/networking/ip-sysctl.txt

+12 −3

File changed.

Preview size limit exceeded, changes collapsed.