m-intf

title: m-intf(4)

text:
# m-intf(4)

## NAME
m-intf - InterFile 3.3 medical image format (MedCon)

## DESCRIPTION

The file consists of two parts, the administrative data in ASCII and the binary image data. It is possible to put both in one file, but we prefer to separate the data into two files. The administrative data in a file with extension `.h33' and the binary data in a file with extension `.i33'.

This is a wonderful feature! Because of the separate header in ASCII you could write your own header for any raw image data you may have. I regularly use InterFile for turning unsupported formats into a supported format. Try to extract the raw image data from the unknown format and add an appropriate header with all information you know about.

The basic defines for the format:

```
---------------------------------------------------------------------------
#define MDC_INTF_MAXKEYCHARS 256
char keystr[MDC_INTF_MAXKEYCHARS];
/* the  data type */
#define MDC_INTF_STATIC      1
#define MDC_INTF_DYNAMIC     2
#define MDC_INTF_GATED       3
#define MDC_INTF_TOMOGRAPH   4
#define MDC_INTF_CURVE       5
#define MDC_INTF_ROI         6
/* the process status */
#define MDC_INTF_ACQUIRED      1
#define MDC_INTF_RECONSTRUCTED 2
/* gated spect nesting outer level */
#define MDC_INTF_NESTING_SPECT 1
#define MDC_INTF_NESTING_GATED 2
typedef struct MdcInterFile_t {

  int data_type, process_status, pixel_type, gspect_nesting;

  Uint32 width, height, images_per_dimension, time_slots;

  Uint32 data_offset, data_blocks, imagesize, number_images;

  Uint32 energy_windows, frame_groups, time_windows, detector_heads;

  float pixel_xsize, pixel_ysize, slice_thickness, centre_centre_separation;

  float study_duration, image_duration, image_pause, group_pause, ext_rot;

  Int8 patient_rot, patient_orient, slice_orient;

  double version;
} MDC_INTERFILE;
---------------------------------------------------------------------------
```

What does the format support or not support:

```
===========================================================================
Item            Supported                             Not Supported
===========================================================================
Color Map     : grayscale                                  -
File Endian   : little or big                              -
Pixeltypes    : 1-bit, all intergers                       -

                float, double, ASCII
===========================================================================
Scaling factors  : quantify & calibrate factors/image  are NOT supported,

                   unless you define your own key-value pairs
---------------------------------------------------------------------------
Dimensions/Image : different dimensions for each image are supported
---------------------------------------------------------------------------
Pixeltypes/Image : different pixeltypes for each image are supported, but

                   decoders are not required to be able to read.

                   MedCon does support different pixeltypes per image.
===========================================================================
```

Underneath you will find a description of the format.

1. ADMINISTRATIVE DATA

===================

a)

The administrative data are only composed of key-value pairs and exist in the form of ASCII text. The administrative data should be terminated with a <Ctrl-Z).

b)

All administrative data are to be supplied in the form of key-value pairs in ASCII with delimiters. A `key' is the name of a parameter taking a specific `value', an example being:

patient name := Elvis Presley <cr><lf>

c)

The maximum permitted number of characters for a key or a value or a comment is 255 characters.

d)

Neither keys nor values are to be treated as case sensitive. The characters <space> <tab> <underscore> <!> may all be treated as white space and ignored.

e)

All relevant keys should be included in the intermediate file. A null value is permitted which will invoke the default where specified. The required keys are preceded by an exclamation mark.

f)

A hole line or key-value pairs may have comments appended to them by preceding the comment with a semicolon <;>.

g)

A required key ("name of data file") is included to point to the image data file, even if the binary data is in the same file of the administrative data.

h)

The two alternate keys ("data starting block") or ("data offset in bytes") are used to indicate the offset of the binary data in the file as specified by the key ("name of data file"). The ("data starting block") represents the offset in number of blocks or 2048 bytes. The use of the key ("data offset in bytes") permits the offset to the binary data to be freely specified.

2. IMAGE DATA

==========

a)

The order of the pixel data shall increment by column from left to right, and then by row, from top to bottom.

b)

Image data shall be in either bit, signed or unsigned integer format, IEEE floating point format (float or double) or ASCII. When the data pixels are written in ASCII, the text line must not exceed 255 characters.

c)

The default value for the key ("imagedata byte order") is BIGENDIAN, but LITTLEENDIAN is allowed. The byte order must be respected for integer and floating point numbers.

d)

Bit data will stored in a single byte, representing 8 pixel values and ordered such that the most significant bit corresponds to the leftmost pixel.

3. LIST OF KEYS - VERSION 3.3 (Updated for Gated SPECT)

==========================

```
!INTERFILE  := <NULL>
;to indicate that this is an Interfile file
!imaging modality := <ASCII> nucmed
;only nucmed is defined for the purpose of this document
!originating system := <ASCII>
;eg.GAMMA-11, MDS, ADAC, etc.
!version of keys := <Numeric> 3.3
;future versions shall increment
date of keys := <DateFormat> 1996:09:26
;date of version 3.3 in date format
conversion program := <ASCII>
;name of program used
program author := <ASCII>
;your chance of fame and fortune
program version := <Numeric>
;to keep track of conversion programs
program date := <DateFormat>
;date of program
!GENERAL DATA := <NULL>
;required but can be treated as comment
original institution := <ASCII>
;name of hospital etc.
contact person := <ASCII>
;another chance of fame (and fortune?)
data description := <ASCII>
;whatever you want
!data starting block := <Numeric> 0
;the value is the offset in blocks of 2048 bytes in either the
;administrative or the data file depending on the key value for
;name of data file (see below)
|      ;OR
!data offset in bytes:= <Numeric> 0
;as above but the offset may be specified freely in bytes
!name of data file := <ASCII> <NULL>
;<NULL> if no image data exists
;key is a name of the file where the data are present, either when
;in a separate binary data file, or when in a combined
;administrative/binary data file
patient name := <ASCII>
;last name, first name (recommended)
!patient ID := <ASCII>
;as used in your hospital
patient dob := <DateFormat>
;date of birth
patient sex := <ASCIIlist> Unknown M|F|Unknown
;default is Unknown!
!study ID := <ASCII>
;as local conditions dictate
exam type := <ASCII>
;description of procedure as above
data compression := <ASCII> none
;name of algorithm if present- e.g. JPEG, etc.
data encode := <ASCII> none
;name of method of encoding if present- e.g. uuencode etc.
organ := <ASCII> none
;ENLF: for mapping with DICOM tag (0018,0015) BodyPartExamined
isotope := <ASCII> | <ASCII>/<ASCII> none
;ENLF: for mapping with DICOM radionuclide/radiopharmaceutical entries.
dose := <Numeric> 0
;ENLF: for mapping with DICOM tag (0018,1074) RadionuclideTotalDose [MBq]
!GENERAL IMAGE DATA := <NULL>
;again required but treated as comment
!type of data := <ASCIIlist>  Other

   Static|Dynamic|Gated|Tomographic|Curve|ROI|GSPECT|Other
;important - this key is used for many conditionals
!total number of images := <Numeric>
;how many images are there altogether in total in the associated
;data file (for all windows etc.). This overrides any other way of
;calculating the total number of images.
study date := <DateFormat>
;date of the first image included in the data file
study time := <TimeFormat>
;time for the start of first image specified
imagedata byte order := <ASCIIlist> BIGENDIAN

        BIGENDIAN|LITTLEENDIAN
;BIGENDIAN is the default if unspecified
process label := <ASCII> none
;ENLF: for mapping with DICOM tag (0008,103E) SeriesDescription
quantification units := +1.696265e-05
;ENLF: global scale factor for mediman dialect
NUD/rescale slope := +1.696265e-05
;ENLF: global scale factor for NUD systems
NUD/rescale intercept := +0.000000e+00
;ENLF: global scale intercept for NUD systems
number of energy windows := <Numeric> 1
;defaulted to one if unspecified
for ( number of energy windows, energy window)
{

      energy window[<energy window>] := <ASCII>

      ;ASCII text- for example "Tc99m"

      ;this starts as "energy window [1]" and then increments to

      ;energy window[2]:= <ASCII>

      ;and then on to

      ;energy window[3]:= <ASCII>

      ;etc. etc.

      energy window lower level [<energy window>] := <Numeric>

      ;value of lower energy level in keV for the corresponding window

      ;starts off as "energy window lower level [1]"

      ;and continues [2],[3] .. as above

      energy window upper level [<energy window>] := <Numeric>

      ;value of upper energy level in keV for the corresponding window

      ;starts off as "energy window upper level [1]"

      ;and continues [2],[3] .. as above

      flood corrected := <ASCIIlist> Y Y|N

      ;corrected if unspecified

      decay corrected := <ASCIIlist> N Y|N

      ;not corrected if unspecified

      if( type of data = "Static"|"ROI")

      {

      !STATIC STUDY (General) := <NULL>

      ;label to indicate that this is the static definition

      number of images/energy window := <Numeric> 1

      ;number of images in THIS energy window

      for ( number of images/energy window )

      {

            !Static Study (each frame) := <NULL>

            ;included at the beginning of the definition of

            ;each new static frame

            !image number := <Numeric>

            ;starting from 1 [see above]

            ;- must be specified!!

            ;starts from 1 and increments though all

            ;windows to its maximum value which equals the

            ;total number of images in the file!!

            !matrix size [1] :=< Numeric>

            ;matrix size across (number of columns)- previously x

            ;32, 64, 128 etc. but not necessarily powers of 2

            !matrix size [2] := <Numeric>

            ;matrix size down (number of rows)- previously y

            ;32, 64, 128 etc. but not necessarily powers of 2

            !number format := <ASCIIlist> unsigned integer

                signed integer|unsigned integer

                |long float|short float|bit|ASCII

            ;as specified

            !number of bytes per pixel := <Numeric>

            ;e.g. 1|2|4.. [this key ignored for bit data]

            scaling factor (mm/pixel) [1]:= <Numeric>

            ;size of pixel across- previously x

            scaling factor (mm/pixel) [2] := <Numeric>

            ;size of pixel down- previously y

            image duration (sec) := <Numeric>

            ;eg. 120.0  i.e. normally a float, for each image

            image start time := <TimeFormat>

            ;time for each image

            label := <ASCII>

            ;eg Anterior

            maximum pixel count := <Numeric>

            ;for scaling purposes, for each image

            total counts := <Numeric>

            ;either an integer or a float, for each image

            }

            ;End of frame loop - Repeat for each subsequent frame

        }

        ;End of static definitions

        if( type of data = "Dynamic")

        {

            !DYNAMIC STUDY (general) := <NULL>

            ;label to indicate that this is a dynamic study

            !number of frame groups := <Numeric> 1

            ;defaults to 1

            for( number of frame groups, frame group number)

            {

                  !Dynamic Study (each frame group) := <NULL>

                  ;Repeated for each group of frames as

                  ;indication of  the start of the

                  ;definition of the new group

                  !frame group number := <Numeric>

                  ;numbering starts from 1 (must be specified)

                  !matrix size [1] := <Numeric>

                  ;matrix size across (number of columns)

                  ;-previously matrix size x

                  ;32, 64, 128 etc. but not necessarily powers of 2

                  !matrix size [2] := <Numeric>

                  ;matrix size down (number of rows)- previously y

                  ;32, 64, 128 etc. but not necessarily powers of 2

                  !number format := <ASCIIlist> unsigned integer

                     signed integer|unsigned integer|

                     long float|short float|bit|ASCII

                  ;as specified

                  !number of bytes per pixel := <Numeric>

                  ;e.g. 1|2|4.. [this key ignored for bit data]

                  scaling factor (mm/pixel) [1]:= <Numeric>

                  ;size of pixel across- previously x

                  scaling factor (mm/pixel) [2] := <Numeric>

                  ;size of pixel down- previously y

                  !number of images this frame group := <Numeric>

                  ;for each frame group

                  ;(for each energy window)

                  !image duration (sec) := <Numeric>

                  ;eg 0.2, for each frame group

                  ;(for each energy window)

                  pause between images (sec) := <Numeric> 0.0

                  ;eg 0.0, default is 0.0

                  pause between frame groups (sec) := <Numeric> 0.0

                  ;eg 5.0 default 0.0, time between last

                  ;frame group (or start of study) and this frame group

                  !maximum pixel count in group := <Numeric>

                  ;eg 1234 (for scaling purposes)

                  ;maximum pixel for all frames in this

                  ;group and this window!!

            }

            ;Repeat for each subsequent frame group

        }

        ; End of dynamic definitions

        if( type of data = "Gated")

        {

        !GATED STUDY (general) := <NULL>

        ;again a flag to indicate a gated study

        !matrix size [1] := <Numeric>

        ;matrix size across (number of columns)- previously x

        ;32, 64, 128 etc. but not necessarily powers of 2

        !matrix size [2] := <Numeric>

        ;matrix size down (number of rows)- previously y

        ;32, 64, 128 etc. but not necessarily powers of 2

        !number format := <ASCIIlist> unsigned integer

           signed integer|unsigned integer|

           long float|short float|bit|ASCII

        ;as specified

        !number of bytes per pixel := <Numeric>

        ;e.g. 1|2|4|..> [this key ignored for bit data]

        scaling factor (mm/pixel) [1]:= <Numeric>

        ;size of pixel across- previously x

        scaling factor (mm/pixel) [2] := <Numeric>

        ;size of pixel down- previously y

        study duration (elapsed) sec := <Numeric>

        ;eg 300, total elapsed time for whole study

        number of cardiac cycles (observed) := <Numeric>

        ;total number of cycles if known, for this

        ;energy window

        number of time windows := <Numeric> 1

        ;defaults to 1 if unspecified- number of different

        ;sets of time intervals

        for ( number of time windows, time window number)

        {

            !Gated Study (each time window) := <NULL>

            !time window number := <Numeric>

            ;starting from 1

            !number of images in time window := <Numeric>

            ;eg 24

            !image duration (sec) := <Numeric>

            ;eg 0.04  for each frame in THIS time window

            framing method := <ASCIIlist> Forward

                    Forward|Backward|Mixed|Other

            ;default is forward

            time window lower limit (sec) := <Numeric>

            ;float normally expected, for THIS time window

            time window upper limit (sec) := <Numeric>

            ;float normally expected

            % R-R cycles acquired this window := <Numeric>

            ;if known

            number of cardiac cycles (acquired) := <Numeric>

            ;eg 356 , if known

            study duration (acquired) sec := <Numeric>

            ;total  acquisition time duration for

            ;this window only (if it can be computed!!) as

            ;opposed to total acquisition time (when different)

            !maximum pixel count := <Numeric>

            ;for scaling purposes for all images in this

            ;time window (and energy window) only

            R-R histogram := <ASCIIlist> N Y|N

            ;flag to indicate that one exists!!

            }

            ;Repeat for each subsequent time window.

        }

        ;end of gated definitions

        if( type of data = "Tomographic")

        {

        !SPECT STUDY (general) := <NULL>

        ;flag to indicate tomographic data with no effect as such

        number of detector heads := <Numeric> 1

        ;default=1 if unspecified

        for ( number of detector heads )

        {

            !number of images/energy window := <Numeric>

            ;total number of images (for all heads) for

            ;THIS energy window!!

            !process status := Reconstructed Acquired|Reconstructed

            ;used below in conditional- MUST be defined

            !matrix size [1] := <Numeric>

            ;matrix size across (number of columns)- previously x

            ;32, 64, 128 etc. but not necessarily powers of 2

            !matrix size [2] := <Numeric>

            ;matrix size down (number of rows)- previously y

            ;32, 64, 128 etc. but not necessarily powers of 2

            !number format := <ASCIIlist> unsigned integer

               signed integer|unsigned integer|

               long float|short float|bit|ASCII

            ;as specified

            !number of bytes per pixel := <Numeric>

            ;e.g. 1|2|4|.. [this key ignored for bit data]

            scaling factor (mm/pixel) [1]:= <Numeric>

            ;size of pixel across- previously x

            scaling factor (mm/pixel) [2] := <Numeric>

            ;size of pixel down- previously y

            !number of projections := <Numeric>

            ;for example- 64

            ;note this is the actual number of images per

            ;head per energy window if

            ;the data are acquired, but NOT if the data are

            ;reconstructed where the number of images is

            ;specified separately as number of slices

            !extent of rotation := <Numeric>

            ;e.g 180, 360

            !time per projection (sec) := <Numeric>

            ;important for Acquired data

            study duration (sec) := <Numeric>

            ;eg 1280.0, for acquired data should be equal

            ;to the product of number of projections and

            ;time per projection, but could be different!!

            !maximum pixel count := <Numeric>

            ;for scaling- in THIS image series( this head

            ;and this energy window)

            patient orientation := <ASCIIlist> head_in

                 head_in|feet_in|other

            patient rotation :=  <ASCIIlist> supine

                 prone|supine|other

            if( process status = "acquired")

            {

               !SPECT STUDY (acquired data):= <NULL>

               !direction of rotation := <ASCIIlist> CW CW|CCW

               ;CW = clockwise, CCW = counter clockwise

               start angle := <Numeric>

               ;0 is top-dead-centre, in degrees

               ;in orientation as specified above

               first projection angle in data set := <Numeric>

               ;in degrees expressed with respect to

               ;anterior-  angles in direction as

               ;specified CW or CCW

               acquisition mode := <ASCIIlist> stepped

               stepped|continuous

               Centre_of_rotation :=  <ASCIIlist> Corrected

               Corrected|Single_value|For_every_angle

               ;default is "Corrected"

               ;"Corrected" corresponds to a null centre of rotation

               ;correction, as previous required by Interfile, that

               ;is, no centre of rotation information is to be

               ;passed. The key "Single value" indicates the

               ;conventional definition of the centre of rotation

               ;offset to be a single value specified for all angles,

               ;specified for each head given a multiple head

               ;acquisition.

               ;The key "For_every_angle" indicates that the centre

               ;of rotation offset will be  specified for each head

               ;and every angle. This is not currently implemented in

               ;this Interfile definition, but will be introduced in

               ;V4.

               ;The mathematical centre of rotation is assumed to be

               ;in the exact middle of the projection for example at

               ;x= 32.5 y=32.5 for a 64x64 image where the count

               ;starts from 1. Note that the choice of coordinates

               ;does not matter, the only constraint being the

               ;assumption that all projections have a length which

               ;is an even number of pixels. The centre of rotation

               ;is specified as the offset from that position to the

               ;perpendicular dropped from a point on the axis of

               ;rotation onto the head.

           if( Centre_of_rotation = "Single_value" )

           {

               !X_offset := <Numeric>

               ;x offset for all angles in mm.

               ;x_offset is the x offset between the perpendicular

               ;dropped from the centre of rotation and the dead

               ;centre of the matrix,

               ;The positive direction for the offset is considered

               ;to be that of the increasing projection index, e.g.

               ;for a projection with pixels of size 6mm, which

               ;should be centred at 32.5, an offset of +6mm

               ;indicates that the centre of rotation is at 33.5

               ;Note that since offset is specified in mm, the pixel

               ;size must be known.

               Y_offset := <Numeric>

               ;y offset for all angles in mm

               ;y_offset is the y offset between that perpendicular

               ;dropped from the centre of rotation from that point

               ;on the axis of rotation where the y_offset is

               ;considered to be zero, and the centre of the camera's

               ;field of view. Thus y_offset is the RELATIVE shift of

               ;the y-axis with respect to some arbitrary position,

               ;normally that from the centre of the filed of view of

               ;the first at the top dead centre position. Thus for

               ;a single head, this value would normally be expected

               ;to be equal to zero.

               Radius := <Numeric>

               ;radial distance to centre of rotation in mm,

               ;for this head.

               }

               ;end of centre of rotation specification

               orbit := <ASCIIlist> Circular Circular|non-circular

               preprocessed := <ASCII>

               ;preprocessing method

            }

            ; end of process status acquired

            if( process status = "reconstructed")

            {

               !SPECT STUDY (reconstructed data) := <NULL>

               method of reconstruction := <ASCII>

               !number of slices := <Numeric>

               ;i.e. number of images in this set for this

               ;head and this energy window

               number of reference frame := <Numeric> 0

               ;if unspecified the frame number

               ;originally used for defining slice positions

               ;0=default [Note- not a very useful key]

               slice orientation := <ASCIIlist> Transverse

                   Transverse|Coronal|Sagittal|Other

               ;default is transverse if unspecified

               slice thickness (pixels) := <Numeric> 1

               ;if unspecified 1=default

               centre-centre slice separation (pixels):=<Numeric> 1

               ;e.g.1,2,3,4...  as distinct from slice thickness

               ;the word centre can also be spelt as center

               filter name :=  <ASCII>

               ;e.g. Hann, Hamming, Butterworth

               filter parameters := <ASCII>

               ;Nyquist freq etc.

               z-axis filter := <ASCII>

               ;method [1,2,1] etc.

               attenuation correction coefficient/cm := <Numeric> 0.0

               ;default 0 means not done if unspecified

               method of attenuation correction :=  <ASCII>  none

               scatter corrected := <ASCIIlist> N Y|N

               method of scatter correction := <ASCII> none

               oblique reconstruction := <ASCIIlist> N Y|N

               oblique orientation := <ASCII>

               ;free text [Note ACR-NEMA convention preferred]

            }

            ;end of reconstructed tomo

       }

      ;End of tomo
*      if( type of data = "GSPECT")

       {
*      !GATED SPECT STUDY (general) := <NULL>

       ;again a flag to indicate a gated SPECT study

       ;MIXTURE OF GATED & TOMO

       !matrix size [1] := <Numeric>

       ;matrix size across (number of columns)- previously x

       ;32, 64, 128 etc. but not necessarily powers of 2

       !matrix size [2] := <Numeric>

       ;matrix size down (number of rows)- previously y

       ;32, 64, 128 etc. but not necessarily powers of 2

       !number format := <ASCIIlist> unsigned integer

        signed integer|unsigned integer|

        long float|short float|bit|ASCII

       ;as specified

       !number of bytes per pixel := <Numeric>

       ;e.g. 1|2|4|..> [this key ignored for bit data]

       !Gated SPECT nesting outer level := SPECT|Gated  Gated

       ; key to indictae order of images, if SPECT is outer level

       ; order is, for every angle give each gated image, if

       ; gated is outer level, then order is, for every gated

       ; time value, vie set of tomographic images

       scaling factor (mm/pixel) [1]:= <Numeric>

       ;size of pixel across- previously x

       scaling factor (mm/pixel) [2] := <Numeric>

       ;size of pixel down- previously y

       study duration (elapsed) sec := <Numeric>

       ;eg 300, total elapsed time for whole study

       number of cardiac cycles (observed) := <Numeric>

       ;total number of cycles if known, for this

       ;energy window

       number of time windows := <Numeric> 1

       ;defaults to 1 if unspecified- number of different

       ;sets of time intervals

       for ( number of time windows, time window number)

       {

            !Gated Study (each time window) := <NULL>

            !time window number := <Numeric>

            ;starting from 1
*           !number of images in time window := <Numeric>

            ;eg 24 NOTE that here in gated SPECT is means images/angle

            !image duration (sec) := <Numeric>

            ;eg 0.04  for each frame in THIS time window

            framing method := <ASCIIlist> Forward

                    Forward|Backward|Mixed|Other

            ;default is forward

            time window lower limit (sec) := <Numeric>

            ;float normally expected, for THIS time window

            time window upper limit (sec) := <Numeric>

            ;float normally expected

            % R-R cycles acquired this window := <Numeric>

            ;if known

            number of cardiac cycles (acquired) := <Numeric>

            ;eg 356 , if known

            study duration (acquired) sec := <Numeric>

            ;total  acquisition time duration for

            ;this window only (if it can be computed!!) as

            ;opposed to total acquisition time (when different)

            !maximum pixel count := <Numeric>

            ;for scaling purposes for all images in this

            ;time window (and energy window) only

            R-R histogram := <ASCIIlist> N Y|N

            ;flag to indicate that one exists!!

        }

        ;Repeat for each subsequent time window.
	;start of tomographic keys

        number of detector heads := <Numeric> 1

        ;default=1 if unspecified

        for ( number of detector heads )

        {

            !number of images/energy window := <Numeric>

            ;total number of images (for all heads) for

            ;THIS energy window!!

            !process status := Reconstructed Acquired|Reconstructed

            ;used below in conditional- MUST be defined

            !number of projections := <Numeric>

            ;for example- 64

            ;note this is the actual number of images per

            ;head per energy window if

            ;the data are acquired, but NOT if the data are

            ;reconstructed where the number of images is

            ;specified separately as number of slices

            !extent of rotation := <Numeric>

            ;e.g 180, 360

            !time per projection (sec) := <Numeric>

            ;important for Acquired data

            patient orientation := <ASCIIlist> head_in

                   head_in|feet_in|other

            patient rotation :=  <ASCIIlist> supine

                   prone|supine|other

            if( process status = "acquired")

            {

               !SPECT STUDY (acquired data):= <NULL>

               !direction of rotation := <ASCIIlist> CW CW|CCW

               ;CW = clockwise, CCW = counter clockwise

               start angle := <Numeric>

               ;0 is top-dead-centre, in degrees

               ;in orientation as specified above

               first projection angle in data set := <Numeric>

               ;in degrees expressed with respect to

               ;anterior-  angles in direction as

               ;specified CW or CCW

               acquisition mode := <ASCIIlist> stepped

                    stepped|continuous

              Centre_of_rotation :=  <ASCIIlist> Corrected

                   Corrected|Single_value|For_every_angle

              ;default is "Corrected"

              ;"Corrected" corresponds to a null centre of rotation

              ;correction, as previous required by Interfile, that

              ;is, no centre of rotation information is to be

              ;passed. The key "Single value" indicates the

              ;conventional definition of the centre of rotation

              ;offset to be a single value specified for all angles,

              ;specified for each head given a multiple head

              ;acquisition.

              ;The key "For_every_angle" indicates that the centre

              ;of rotation offset will be  specified for each head

              ;and every angle. This is not currently implemented in

              ;this Interfile definition, but will be introduced in

              ;V4.

              ;The mathematical centre of rotation is assumed to be

              ;in the exact middle of the projection for example at

              ;x= 32.5 y=32.5 for a 64x64 image where the count

              ;starts from 1. Note that the choice of coordinates

              ;does not matter, the only constraint being the

              ;assumption that all projections have a length which

              ;is an even number of pixels. The centre of rotation

              ;is specified as the offset from that position to the

              ;perpendicular dropped from a point on the axis of

              ;rotation onto the head.

              if( Centre_of_rotation = "Single_value" )

              {

               !X_offset := <Numeric>

               ;x offset for all angles in mm.

              ;x_offset is the x offset between the perpendicular

              ;dropped from the centre of rotation and the dead

              ;centre of the matrix,

              ;The positive direction for the offset is considered

              ;to be that of the increasing projection index, e.g.

              ;for a projection with pixels of size 6mm, which

              ;should be centred at 32.5, an offset of +6mm

              ;indicates that the centre of rotation is at 33.5

              ;Note that since offset is specified in mm, the pixel

              ;size must be known.

               Y_offset := <Numeric>

               ;y offset for all angles in mm

              ;y_offset is the y offset between that perpendicular

              ;dropped from the centre of rotation from that point

              ;on the axis of rotation where the y_offset is

              ;considered to be zero, and the centre of the camera's

              ;field of view. Thus y_offset is the RELATIVE shift of

              ;the y-axis with respect to some arbitrary position,

              ;normally that from the centre of the filed of view of

              ;the first at the top dead centre position. Thus for

              ;a single head, this value would normally be expected

              ;to be equal to zero.

               Radius := <Numeric>

               ;radial distance to centre of rotation in mm,

              ;for this head.

               }

              ;end of centre of rotation specification

               orbit := <ASCIIlist> Circular Circular|non-circular

               preprocessed := <ASCII>

               ;preprocessing method

            }

            ; end of process status acquired

            if( process status = "reconstructed")

            {

               !SPECT STUDY (reconstructed data) := <NULL>

               method of reconstruction := <ASCII>

               !number of slices := <Numeric>

               ;i.e. number of images in this set for this

               ;head and this energy window

               number of reference frame := <Numeric> 0

               ;if unspecified the frame number

               ;originally used for defining slice positions

               ;0=default [Note- not a very useful key]

               slice orientation := <ASCIIlist> Transverse

                   Transverse|Coronal|Sagittal|Other

               ;default is transverse if unspecified

               slice thickness (pixels) := <Numeric> 1

               ;if unspecified 1=default

               centre-centre slice separation (pixels):=<Numeric> 1

               ;e.g.1,2,3,4...  as distinct from slice thickness

               ;the word centre can also be spelt as center

               filter name :=  <ASCII>

               ;e.g. Hann, Hamming, Butterworth

               filter parameters := <ASCII>

               ;Nyquist freq etc.

               z-axis filter := <ASCII>

               ;method [1,2,1] etc.

               attenuation correction coefficient/cm := <Numeric> 0.0

               ;default 0 means not done if unspecified

               method of attenuation correction :=  <ASCII>  none

               scatter corrected := <ASCIIlist> N Y|N

               method of scatter correction := <ASCII> none

               oblique reconstruction := <ASCIIlist> N Y|N

               oblique orientation := <ASCII>

               ;free text [Note ACR-NEMA convention preferred]

            }

            ;end of reconstructed tomo

       }

      ;End of GATED SPECT
}
;end of loop for energy windows
if( type of data = "Curve")

      {

       !CURVE DATA := <NULL>

       ;label to indicate that this is the curve definition

       ;curves should always be kept in separate data files

       ;and not together with the administrative data

       Curve_dimensions := <Numeric> 2

       ;how many dimensions- ONLY 2 is permitted in V3.3.

       ;Even if a single vector of values is required

       ;both matrix size[1] and [2] must be defined

       ;although one of them should take the value 1.

       ;A set of x,y values is 2 dimensional with normally

       ;matrix size[1] or matrix size[2] equal to 2.

       ;and the other matrix size specifying

       ;the number of PAIRS of values present (see Fig 1).

       ;Matrix sizes greater than 2 for BOTH dimensions are not

       ;recommended.

       !matrix size[1] := <Numeric>

       ;matrix size across (number of columns)

       !matrix size[2] := <Numeric>

       ;matrix size down (number of rows)

       !number format := <ASCIIlist> unsigned integer

           signed integer|unsigned integer|

           long float|short float|bit|ASCII

       !number of bytes per pixel := <Numeric>

       ;e.g. 1|2|4|.. [this key ignored for bit data]

       Type_of_curve :=  <ASCII>

       ;what kind of curve is it, for example time activity curve

       ;ROI indicates that this is a list

       ;of vectors corresponding to an ROI.

       for( Curve_dimensions, dimension)

       {

          ;When matrix size[1] or matrix size[2] equals 2 (the normal

          ;case) such that the data comprise pairs of values,

          ;then Label[1],  Units[1] etc. refers to the set of first

          ;values for each pair, and Label[2] etc. refers the set of

          ;second values for each pair.

          Label[<dimension>] :=  <ASCII>

          ;a text label for the corresponding axis  e.g. "counts"

          Units[<dimension>] := <ASCII>

          ;units of measurement for the corresponding axis

          ;e.g. "units[1]:=counts/sec"

          Min[<dimension>] := <Numeric>

          ;Minimum of set of values as indicated in units as defined,

          ;optional

          Max[<dimension>] := <Numeric>

          ;Maximum value as above, optional

      }

     ;End of loop for curve dimensions
}
!END OF INTERFILE := <NULL>
```

## FILES

```
/usr/local/xmedcon/source/m-intf.h      The header file.
/usr/local/xmedcon/source/m-intf.c      The source file.
```

```

```

## SEE ALSO

medcon(1), xmedcon(1), xmedcon-config(1)

m-acr(4), m-anlz(4), m-gif(5), m-inw(4), m-ecat(4)

medcon(3)

## AUTHOR

(X)MedCon project was originally written by Erik Nolf (eNlf) for the former PET-Centre at Ghent University (Belgium).

e-mail:

enlf-at-users.sourceforge.net

www:

http://xmedcon.sourceforge.net


m-inw

package: xmedcon-devel

title: m-inw(4)

text:
# m-inw(4)

## NAME
m-inw - RUG INW1.0 medical image format (MedCon)

## DESCRIPTION

This is a local file format used at the RUG (Ghent, Belgium). The headers and image data are written in one file with extension `.im'.

The basic defines for the format:

```
---------------------------------------------------------------------------
typedef struct Head_start_t {

        Int32 mark;           /* should be HEADER_MARK                */

        Int16 version;        /* high*256 + low                       */

        Int16 size_header;    /* whole header (in bytes)              */

        Int16 size_start;     /* sizeof(Head_start_t)                 */

        Int16 size_gen;       /* sizeof(Head_gen_t)                   */

        Int16 size_spec;      /* sizeof(Head_spec_t)                  */

        char  reserved[10];
} MDC_INW_HEAD_START;         /* current size: 24                     */
#define MDC_INW_HEAD_START_SIZE 24
typedef struct Head_gen_t {

        Int16 no;             /* number of planes                     */

        Int16 sizeX;          /* number of columns                    */

        Int16 sizeY;          /* number of rows                       */

        Int16 pixel_type;     /* sizeof(pixel)                        */

                              /* for compatibility only 2 is allowed  */

        Int16 init_trans;     /* initial translation (mm)             */

        Int16 dummy1;         /* for alignment reasons only           */

        /* Note: We take the positive axis into the gantry !

                 This means, if the patient lies with his head into

                 the gantry, the head has higher translation offset

                 than his feet                                        */

        char  day[12];        /* day of first scan eg. 04-AUG-89      */

        Int32 time;           /* seconds after midnight               */

                              /* first scan or time activity measured */

        float decay_cst;      /* NOT half_life ! (discards log(2))    */

                              /* decay_cst = half_life / log(2)       */

        float pixel_size;     /* sampling distance (mm)               */

        float max;            /* scaled maximum of all images         */

        float min;

        Int16 scanner;        /* EcatII, EcatIV                       */

        char  reconstruction; /* reconFBP, reconMaxLik,...            */

        char  recon_version;  /* reconstruction version (0-99)        */

        char  reserved[24];
} MDC_INW_HEAD_GEN;           /* current size: 72                     */
#define MDC_INW_HEAD_GEN_SIZE 72
typedef struct Head_spec_t {

        Int32 time;           /* time relative to gen.time (secs)     */

        float cal_cst;        /* abs_activ(uCU/ml) = cal_cst*pix_val  */

                              /* cal_cst = calibr_cst * decay_comp    */

                              /* decay_comp = exp(time/decay_cst)     */

        Int32 max;            /* maximum in plane                     */

        Int32 min;            /* minimum in plane                     */

        Int16 trans;          /* translation relative to gen.trans mm */

        char  reserved[6];
} MDC_INW_HEAD_SPEC;          /* current size: 24                     */
#define MDC_INW_HEAD_SPEC_SIZE 24
---------------------------------------------------------------------------
```

What does the format support or not support:

```
===========================================================================
Item            Supported                             Not Supported
===========================================================================
Color Map     : grayscale                                   -
File Endian   : little                                     big
Pixeltypes    : Int16                                       -
===========================================================================
Scaling factors  : quantify or calibrate factors/image are supported
---------------------------------------------------------------------------
Dimensions/Image : different dimensions for each image are NOT supported
---------------------------------------------------------------------------
Pixeltypes/Image : different pixeltypes for each image are NOT supported
===========================================================================
```

## NOTES

The first two structures in the file are HEAD_START and HEAD_GEN. After these data structures, a number of HEAD_SPEC structures follow, as much as there are images in the file. The float values in the headers are stored as VAX floats!

Following the headers are the binary image data. The images are stored from left to right and from top to bottom. The pixel values are Int16, little endian.

## FILES

```
/usr/local/xmedcon/source/m-inw.h     The header file.
/usr/local/xmedcon/source/m-inw.c     The source file.
```

## SEE ALSO

medcon(1), xmedcon(1), xmedcon-config(1)

m-acr(4), m-anlz(4), m-gif(4), m-intf(4), m-ecat(4)

medcon(3)

## AUTHOR

(X)MedCon project was originally written by Erik Nolf (eNlf) for the former PET-Centre at Ghent University (Belgium).

e-mail:

enlf-at-users.sourceforge.net

www:

http://xmedcon.sourceforge.net


amdgpu

package: xorg-drv-amdgpu

title: amdgpu(4)

summary: AMD RADEON GPU video driver

text:
# amdgpu(4)

## NAME
amdgpu - AMD RADEON GPU video driver

## SYNOPSIS

```
Section "Device"
  Identifier "devname"
  Driver "amdgpu"
  ...
EndSection
```

## DESCRIPTION
amdgpu is an Xorg driver for AMD RADEON-based video cards with the following features:

•

Support for 8-, 15-, 16-, 24- and 30-bit pixel depths;

•

RandR support up to version 1.4;

•

3D acceleration;

## SUPPORTED HARDWARE
The amdgpu driver supports SI and newer families' video cards.

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

The following driver Options are supported:

Option "SWcursor" "boolean"

Selects software cursor. The default is off.

Option "Accel" "boolean"

Enables or disables all hardware acceleration.

The default is on.

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 "DRI" "integer"

Define the maximum level of DRI to enable. Valid values are 2 for DRI2 or 3 for DRI3. The default is 3 for DRI3 if the Xorg version is >= 1.18.3, otherwise 2 for DRI2.

Option "EnablePageFlip" "boolean"

Enable DRI2 page flipping. The default is on.

Option "TearFree" "boolean"

Set the default value of the per-output 'TearFree' property, which controls tearing prevention using the hardware page flipping mechanism. TearFree is on for any CRTC associated with one or more outputs with TearFree on. Two separate scanout buffers need to be allocated for each CRTC with TearFree on. If this option is set, the default value of the property is 'on' or 'off' accordingly. If this option isn't set, the default value of the property is auto, which means that TearFree is on for rotated outputs, outputs with RandR transforms applied and for RandR 1.4 secondary outputs, otherwise off.

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 "AccelMethod" "string"

Setting this option to none disables use of the glamor acceleration architecture. In that case, all 2D rendering is done by the CPU, but 3D and video hardware acceleration can still work. This is mainly useful for OpenGL driver bring-up.

The default is to use glamor.

The following driver Option is supported for glamor :

Option "ShadowPrimary" "boolean"

This option enables a so-called "shadow primary" buffer for fast CPU access to pixel data, and separate scanout buffers for each display controller (CRTC). This may improve performance for some 2D workloads, potentially at the expense of other (e.g. 3D, video) workloads. Note in particular that enabling this option currently disables page flipping. The default is off.

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

1.

Wiki page:

https://www.x.org/wiki/radeon

2.

Overview about amdgpu development code:

https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu

3.

Mailing list:

https://lists.freedesktop.org/mailman/listinfo/amd-gfx

4.

IRC channel:

\#radeon on irc.freenode.net

5.

The bugtracker for amdgpu bugs:

https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues

6.

Submit merge requests:

https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/merge_requests

## AUTHORS

```
Authors include:
Michel Dänzer            michel@daenzer.net
Alex Deucher             alexdeucher@gmail.com
```


ati

package: xorg-drv-ati

title: ati(4)

summary: ATI video driver

text:
# ati(4)

## NAME
ati - ATI video driver

## SYNOPSIS

```
Section "Device"
  Identifier "devname"
  Driver "ati"
  ...
EndSection
```

## DESCRIPTION
ati is an Xorg wrapper driver for ATI video cards. It autodetects whether your hardware has a Radeon, Rage 128, or Mach64 or earlier class of chipset, and loads the radeon(4), r128(4), or mach64 driver as appropriate.

## SUPPORTED HARDWARE
The ati driver supports Radeon, Rage 128, and Mach64 and earlier chipsets by loading those drivers. See those manpages for specific cards supported.

## CONFIGURATION DETAILS
Please refer to xorg.conf(5) for general configuration details, and the specific card driver for driver configuration details.

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

## AUTHORS
See the individual driver pages for authors.


cirrus

package: xorg-drv-cirrus

title: cirrus(4)

summary: Cirrus Logic video driver

text:
# cirrus(4)

## NAME
cirrus - Cirrus Logic video driver

## SYNOPSIS

```
Section "Device"
  Identifier "devname"
  Driver "cirrus"
  ...
EndSection
```

## DESCRIPTION
cirrus is an Xorg driver for Cirrus Logic video chips. THIS MAN PAGE NEEDS TO BE FILLED IN.

## SUPPORTED HARDWARE
The cirrus driver supports...

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

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

## AUTHORS
Authors include: Corin Anderson, Egbert Eich, Derek Fawcus, Koen Gadeyne, Harm Hanemaayer, David Monniaux, Itai Nahshon


evdev

package: xorg-drv-evdev

title: evdev(4)

summary: Generic Linux input driver

text:
# evdev(4)

## NAME
evdev - Generic Linux input driver

## SYNOPSIS

```
Section "InputDevice"
  Identifier "devname"
  Driver "evdev"
  Option "Device"   "devpath"
  Option "Emulate3Buttons"     "True"
  Option "Emulate3Timeout"     "50"
  Option "GrabDevice"     "False"
  ...
EndSection
```

## DESCRIPTION
evdev is an Xorg input driver for Linux´s generic event devices. It therefore supports all input devices that the kernel knows about, including most mice, keyboards, tablets and touchscreens. evdev is the default driver on the major Linux distributions.

The evdev driver can serve as both a pointer and a keyboard input device. Multiple input devices are supported by multiple instances of this driver, with one InputDevice section of your xorg.conf for each input device that will use this driver.

It is recommended that evdev devices are configured through the InputClass directive (refer to xorg.conf(5)) instead of manual per-device configuration. Devices configured in the xorg.conf(5) are not hot-plug capable.

## SUPPORTED HARDWARE
In general, any input device that the kernel has a driver for can be accessed through the evdev driver. See the Linux kernel documentation for a complete list.

## 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.

The following driver Options are supported:

Option "ButtonMapping" "string"

Sets the button mapping for this device. The mapping is a space-separated list of button mappings that correspond in order to the physical buttons on the device (i.e. the first number is the mapping for button 1, etc.). The default mapping is "1 2 3 ... 32". A mapping of 0 deactivates the button. Multiple buttons can have the same mapping. For example, a left-handed mouse with deactivated scroll-wheel would use a mapping of "3 2 1 0 0". Invalid mappings are ignored and the default mapping is used. Buttons not specified in the user's mapping use the default mapping.

Option "Device" "string"

Specifies the device through which the device can be accessed. This will generally be of the form "/dev/input/eventX", where X is some integer. The mapping from device node to hardware is system-dependent. Property: "Device Node" (read-only).

Option "DragLockButtons" "L1 B2 L3 B4"

Sets "drag lock buttons" that simulate holding a button down, so that low dexterity people do not have to hold a button down at the same time they move a mouse cursor. Button numbers occur in pairs, with the lock button number occurring first, followed by the button number that is the target of the lock button. Property: "Evdev Drag Lock Buttons".

Option "DragLockButtons" "M1"

Sets a "master drag lock button" that acts as a "Meta Key" indicating that the next button pressed is to be "drag locked". Property: "Evdev Drag Lock Buttons".

Option "Emulate3Buttons" "boolean"

Enable/disable the emulation of the third (middle) mouse button for mice which only have two physical buttons. The third button is emulated by pressing both buttons simultaneously. Default: off. Property: "Evdev Middle Button Emulation".

Option "Emulate3Timeout" "integer"

Sets the timeout (in milliseconds) that the driver waits before deciding if two buttons where pressed "simultaneously" when 3 button emulation is enabled. Default: 50. Property: "Evdev Middle Button Timeout".

Option "Emulate3Button" "integer"

Specifies the physical button number to be emitted if middle button emulation is triggered. Default: 2. Property: "Evdev Middle Button Button".

Option "EmulateWheel" "boolean"

Enable/disable "wheel" emulation. Wheel emulation means emulating button press/release events when the mouse is moved while a specific real button is pressed. Wheel button events (typically buttons 4 and 5) are usually used for scrolling. Wheel emulation is useful for getting wheel-like behaviour with trackballs. It can also be useful for mice with 4 or more buttons but no wheel. See the description of the EmulateWheelButton, EmulateWheelInertia, EmulateWheelTimeout, XAxisMapping, and YAxisMapping options. Default: off. Property "Evdev Wheel Emulation".

Option "EmulateWheelButton" "integer"

Specifies which button must be held down to enable wheel emulation mode. While this button is down, X and/or Y pointer movement will generate button press/release events as specified for the XAxisMapping and YAxisMapping settings. If the button is 0 and EmulateWheel is on, any motion of the device is converted into wheel events. Default: 4. Property: "Evdev Wheel Emulation Button".

Option "EmulateWheelInertia" "integer"

Specifies how far (in pixels) the pointer must move to generate button press/release events in wheel emulation mode. Default: 10. Property: "Evdev Wheel Emulation Inertia".

This value must be set for any device does not resemble a standard mouse. Specifically, on absolute devices such as tablets the value should be set to a reasonable fraction of the expected movement to avoid excess scroll events.

WARNING: the name "inertia" is a misnomer. This option defines the distance required to generate one scroll event similar to the VertScrollDelta and HorizScrollDelta options. It does not enable inertia in the physical sense, scrolling stops immediately once the movement has stopped.

Option "EmulateWheelTimeout" "integer"

Specifies the time in milliseconds the EmulateWheelButton must be pressed before wheel emulation is started. If the EmulateWheelButton is released before this timeout, the original button press/release event is sent. Default: 200. Property: "Evdev Wheel Emulation Timeout".

Option "EmulateThirdButton" "boolean"

Enable third button emulation. Third button emulation emits a right button event (by default) by pressing and holding the first button. The first button must be held down for the configured timeout and must not move more than the configured threshold for the emulation to activate. Otherwise, the first button event is posted as normal. Default: off. Property: "Evdev Third Button Emulation".

Option "EmulateThirdButtonTimeout" "integer"

Specifies the timeout in milliseconds between the initial button press and the generation of the emulated button event. Default: 1000. Property: "Evdev Third Button Emulation Timeout".

Option "EmulateThirdButtonButton" "integer"

Specifies the physical button number to be emitted if third button emulation is triggered. Default: 3. Property: "Evdev Third Button Button".

Option "EmulateThirdButtonMoveThreshold" "integer"

Specifies the maximum move fuzz in device coordinates for third button emulation. If the device moves by more than this threshold before the third button emulation is triggered, the emulation is cancelled and a first button event is generated as normal. Default: 20. Property: "Evdev Third Button Emulation Threshold".

Option "GrabDevice" "boolean"

Force a grab on the event device. Doing so will ensure that no other driver can initialise the same device and it will also stop the device from sending events to /dev/kbd or /dev/input/mice. Events from this device will not be sent to virtual devices (e.g. rfkill or the Macintosh mouse button emulation). Default: disabled.

Option "InvertX" "Bool"

Option "InvertY" "Bool"

Invert the given axis. Default: off. Property: "Evdev Axis Inversion".

Option "IgnoreRelativeAxes" "Bool"

Option "IgnoreAbsoluteAxes" "Bool"

Ignore the specified type of axis. Default: unset. The X server cannot deal with devices that have both relative and absolute axes. Evdev tries to guess wich axes to ignore given the device type and disables absolute axes for mice and relative axes for tablets, touchscreens and touchpad. These options allow to forcibly disable an axis type. Mouse wheel axes are exempt and will work even if relative axes are ignored. No property, this configuration must be set in the configuration.

If either option is set to False, the driver will not ignore the specified axes regardless of the presence of other axes. This may trigger buggy behavior and events from this axis are always forwarded. Users are discouraged from setting this option.

Option "Calibration" "min-x max-x min-y max-y"

Calibrates the X and Y axes for devices that need to scale to a different coordinate system than reported to the X server. This feature is required for devices that need to scale to a different coordinate system than originally reported by the kernel (e.g. touchscreens). The scaling to the custom coordinate system is done in-driver and the X server is unaware of the transformation. Property: "Evdev Axis Calibration".

Option "Mode" "Relative"|"Absolute"

Sets the mode of the device if device has absolute axes. The default value for touchpads is relative, for other absolute. This option has no effect on devices without absolute axes.

Option "SwapAxes" "Bool"

Swap x/y axes. Default: off. Property: "Evdev Axes Swap".

Option "XAxisMapping" "N1 N2"

Specifies which buttons are mapped to motion in the X direction in wheel emulation mode. Button number N1 is mapped to the negative X axis motion and button number N2 is mapped to the positive X axis motion. Default: no mapping. Property: "Evdev Wheel Emulation Axes".

Option "YAxisMapping" "N1 N2"

Specifies which buttons are mapped to motion in the Y direction in wheel emulation mode. Button number N1 is mapped to the negative Y axis motion and button number N2 is mapped to the positive Y axis motion. Default: "4 5". Property: "Evdev Wheel Emulation Axes".

Option "TypeName" "type""

Specify the X Input 1.x type (see XListInputDevices(3)). There is rarely a need to use this option, evdev will guess the device type based on the device's capabilities. This option is provided for devices that need quirks.

Option "VertScrollDelta" "integer"

The amount of motion considered one unit of scrolling vertically. Default: "1". Property: "Evdev Scrolling Distance".

Option "HorizScrollDelta" "integer"

The amount of motion considered one unit of scrolling horizontally. Default: "1". Property: "Evdev Scrolling Distance".

Option "DialDelta" "integer"

The amount of motion considered one unit of turning the dial. Default: "1". Property: "Evdev Scrolling Distance".

Option "Resolution" "integer"

Sets the resolution of the device in dots per inch. The resolution is used to scale relative motion events from mouse devices to 1000 DPI resolution. This can be used to make high resolution mice less sensitive without turning off acceleration. If set to 0 no scaling will be performed. Default: "0".

## SUPPORTED PROPERTIES
The following properties are provided by the evdev driver.

Evdev Axis Calibration

4 32-bit values, order min-x, max-x, min-y, max-y or 0 values to disable in-driver axis calibration.

Evdev Axis Inversion

2 boolean values (8 bit, 0 or 1), order X, Y. 1 inverts the axis.

Evdev Axes Swap

1 boolean value (8 bit, 0 or 1). 1 swaps x/y axes.

Evdev Drag Lock Buttons

8-bit. Either 1 value or pairs of values. Value range 0-32, 0 disables a value.

Evdev Middle Button Emulation

1 boolean value (8 bit, 0 or 1).

Evdev Middle Button Timeout

1 16-bit positive value.

Evdev Middle Button Button

1 8-bit value, allowed range 0-32, 0 disables the button.

Evdev Wheel Emulation

1 boolean value (8 bit, 0 or 1).

Evdev Wheel Emulation Axes

4 8-bit values, order X up, X down, Y up, Y down. 0 disables a value.

Evdev Wheel Emulation Button

1 8-bit value, allowed range 0-32, 0 disables the button.

Evdev Wheel Emulation Inertia

1 16-bit positive value.

Evdev Wheel Emulation Timeout

1 16-bit positive value.

Evdev Scrolling Distance

3 32-bit values: vertical, horizontal and dial.

## AUTHORS
Kristian Høgsberg, Peter Hutterer

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


fbdev

package: xorg-drv-fbdev

title: fbdev(4)

summary: video driver for framebuffer device

text:
# fbdev(4)

## NAME
fbdev - video driver for framebuffer device

## SYNOPSIS

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

## DESCRIPTION
fbdev is an Xorg driver for framebuffer devices. This is a non-accelerated driver, the following framebuffer depths are supported: 8, 15, 16, 24. All visual types are supported for depth 8, and TrueColor visual is supported for the other depths. Multi-head configurations are supported.

## SUPPORTED HARDWARE
The fbdev driver supports all hardware where a framebuffer driver is available. fbdev uses the os-specific submodule fbdevhw(4) to talk to the kernel device driver. Currently a fbdevhw module is available for linux.

## 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 fbdev driver can pick up the currently used video mode from the framebuffer 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 "fbdev" "string"

The framebuffer device to use. Default: /dev/fb0.

Option "ShadowFB" "boolean"

Enable or disable use of the shadow framebuffer layer. Mandatory for 24bpp framebuffers on newer servers. Default: on.

Option "Rotate" "string"

Enable rotation of the display. The supported values are "CW" (clockwise, 90 degrees), "UD" (upside down, 180 degrees) and "CCW" (counter clockwise, 270 degrees). Implies use of the shadow framebuffer layer. Disabled for 24bpp framebuffers. Default: off.

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

## AUTHORS
Authors include: Gerd Knorr, Michel Dänzer, Geert Uytterhoeven


intel

package: xorg-drv-intel

title: intel(4)

summary: Intel integrated graphics chipsets

text:
# intel(4)

## NAME
intel - Intel integrated graphics chipsets

## SYNOPSIS

```
Section "Device"
  Identifier "devname"
  Driver "intel"
  ...
EndSection
```

## DESCRIPTION
intel is an Xorg driver for Intel integrated graphics chipsets. The driver supports depths 8, 15, 16 and 24. All visual types are supported in depth 8. For the i810/i815 other depths support the TrueColor and DirectColor visuals. For the i830M and later, only the TrueColor visual is supported for depths greater than 8. The driver supports hardware accelerated 3D via the Direct Rendering Infrastructure (DRI), but only in depth 16 for the i810/i815 and depths 16 and 24 for the 830M and later.

## SUPPORTED HARDWARE
intel supports the i810, i810-DC100, i810e, i815, i830M, 845G, 852GM, 855GM, 865G, 915G, 915GM, 945G, 945GM, 965G, 965Q, 946GZ, 965GM, 945GME, G33, Q33, Q35, G35, GM45, G45, Q45, G43, G41 chipsets, Pineview-M in Atom N400 series, Pineview-D in Atom D400/D500 series, Intel(R) HD Graphics, Intel(R) Iris(TM) Graphics, Intel(R) Iris(TM) Pro Graphics.

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

The Intel 8xx and 9xx families of integrated graphics chipsets have a unified memory architecture meaning that system memory is used as video RAM. For the i810 and i815 family of chipsets, operating system support for allocating system memory is required in order to use this driver. For the 830M and later, this is required in order for the driver to use more video RAM than has been pre-allocated at boot time by the BIOS. This is usually achieved with an "agpgart" or "agp" kernel driver. Linux, FreeBSD, OpenBSD, NetBSD, and Solaris have such kernel drivers available.

By default, the i810/i815 will use 8 MB of system memory for graphics if AGP allocable memory is < 128 MB, 16 MB if < 192 MB or 24 MB if higher. Use the VideoRam option to change the default value.

For the 830M and later, the driver will automatically size its memory allocation according to the features it will support. Therefore, the VideoRam option, which in the past had been necessary to allow more than some small amount of memory to be allocated, is now ignored.

The following driver Options are supported

Option "ColorKey" "integer"

This sets the default pixel value for the YUV video overlay key.

Default: undefined.

Option "DRI" "string"

Disable or enable DRI support. A driver name to use can be provided instead of simple boolean value, which will be passed to the GL implementation for it to load the appropriate backend. Alternatively the maximum level of DRI to enable (e.g. "1", "2" or "3") can be specified.

Default: All levels of DRI are enabled for configurations where it is supported.

The following driver Options are supported for the i810 and i815 chipsets:

Option "CacheLines" "integer"

This allows the user to change the amount of graphics memory used for 2D acceleration and video when XAA acceleration is enabled. Decreasing this amount leaves more for 3D textures. Increasing it can improve 2D performance at the expense of 3D performance.

Default: depends on the resolution, depth, and available video memory. The driver attempts to allocate space for at 3 screenfuls of pixmaps plus an HD-sized XV video. The default used for a specific configuration can be found by examining the Xorg log file.

Option "DDC" "boolean"

Disable or enable DDC support.

Default: enabled.

Option "Dac6Bit" "boolean"

Enable or disable 6-bits per RGB for 8-bit modes.

Default: 8-bits per RGB for 8-bit modes.

Option "XvMCSurfaces" "integer"

This option enables XvMC. The integer parameter specifies the number of surfaces to use. Valid values are 6 and 7.

Default: XvMC is disabled.

VideoRam integer

This option specifies the amount of system memory to use for graphics, in KB.

The default is 8192 if AGP allocable memory is < 128 MB, 16384 if < 192 MB, 24576 if higher. DRI require at least a value of 16384. Higher values may give better 3D performance, at expense of available system memory.

Option "Accel" "boolean"

Enable or disable acceleration.

Default: acceleration is enabled.

The following driver Options are supported for the 830M and later chipsets:

Option "Accel" "boolean"

Enable or disable acceleration.

Default: acceleration is enabled.

Option "Present" "boolean"

Enable use of hardware counters and flow control for the Present extension.

Default: Enabled

Option "AccelMethod" "string"

Select acceleration method. There are a couple of backends available for accelerating the DDX. "UXA" (Unified Acceleration Architecture) is the mature backend that was introduced to support the GEM driver model. It is in the process of being superseded by "SNA" (Sandybridge's New Acceleration). Until that process is complete, the ability to choose which backend to use remains for backwards compatibility. In addition, there are a pair of sub-options to limit the acceleration for debugging use. Specify "off" or "none" to disable all acceleration, or "blt" to disable render acceleration and only use the BLT engine.

Default: use SNA (render acceleration)

Option "TearFree" "boolean"

Disable or enable TearFree updates. This option forces X to perform all rendering to a backbuffer prior to updating the actual display. It requires an extra memory allocation the same size as a framebuffer, the occasional extra copy, and requires Damage tracking. Thus enabling TearFree requires more memory and is slower (reduced throughput) and introduces a small amount of output latency, but it should not impact input latency. However, the update to the screen is then performed synchronously with the vertical refresh of the display so that the entire update is completed before the display starts its refresh. That is only one frame is ever visible, preventing an unsightly tear between two visible and differing frames. Note that this replicates what the compositing manager should be doing, however TearFree will redirect the compositor updates (and those of fullscreen games) directly on to the scanout thus incurring no additional overhead in the composited case. Also note that not all compositing managers prevent tearing, and if the outputs are rotated, there will still be tearing without TearFree enabled.

Default: TearFree is disabled.

Option "ReprobeOutputs" "boolean"

Disable or enable rediscovery of connected displays during server startup. As the kernel driver loads it scans for connected displays and configures a console spanning those outputs. When the X server starts, we then take the list of connected displays and framebuffer layout and use that for the initial configuration. Sometimes, not all displays are correctly detected by the kernel and so it is useful in a few circumstances for X to force the kernel to reprobe all displays when it starts. To make the X server recheck the status of connected displays, set the "ReprobeOutputs" option to true. Please do file a bug for any circumstances which require this workaround.

Default: reprobing is disabled for a faster startup.

Option "VideoKey" "integer"

This is the same as the "ColorKey" option described above. It is provided for compatibility with most other drivers.

Option "XvPreferOverlay" "boolean"

Make hardware overlay be the first XV adaptor. The overlay behaves incorrectly in the presence of compositing, but some prefer it due to it syncing to vblank in the absence of compositing. While most XV-using applications have options to select which XV adaptor to use, this option can be used to place the overlay first for applications which don't have options for selecting adaptors.

Default: Textured video adaptor is preferred.

Option "Backlight" "string"

Override the probed backlight control interface. Sometimes the automatically selected backlight interface may not correspond to the correct, or simply most useful, interface available on the system. This allows you to override that choice by specifying the entry under /sys/class/backlight to use.

Default: Automatic selection.

Option "CustomEDID" "string"

Override the probed EDID on particular outputs. Sometimes the manufacturer supplied EDID is corrupt or lacking a few usable modes and supplying a corrected EDID may be easier than specifying every modeline. This option allows to pass the path to load an EDID from per output. The format is a comma separated string of output:path pairs, e.g. DP1:/path/to/dp1.edid,DP2:/path/to/dp2.edid

Default: No override, use manufacturer supplied EDIDs.

Option "FallbackDebug" "boolean"

Enable printing of debugging information on acceleration fallbacks to the server log.

Default: Disabled

Option "DebugFlushBatches" "boolean"

Flush the batch buffer after every single operation.

Default: Disabled

Option "DebugFlushCaches" "boolean"

Include an MI_FLUSH at the end of every batch buffer to force data to be flushed out of cache and into memory before the completion of the batch.

Default: Disabled

Option "DebugWait" "boolean"

Wait for the completion of every batch buffer before continuing, i.e. perform synchronous rendering.

Default: Disabled

Option "HWRotation" "boolean"

Override the use of native hardware rotation and force the use of software, but GPU accelerated where possible, rotation. On some platforms the hardware can scanout directly into a rotated output bypassing the intermediate rendering and extra allocations required for software implemented rotation (i.e. native rotation uses less resources, is quicker and uses less power). This allows you to disable the native rotation in case of errors.

Default: Enabled (use hardware rotation)

Option "VSync" "boolean"

This option controls the use of commands to synchronise rendering with the vertical refresh of the display. Some rendering commands have the option to be performed in a "tear-free" fashion by stalling the GPU to wait for the display to be outside of the region to be updated. This slows down all rendering, and historically has been the source of many GPU hangs.

Default: enabled.

Option "PageFlip" "boolean"

This option controls the use of commands to flip the scanout address on a VBlank. This is used by glXSwapBuffers to efficiently perform the back-to-front exchange at the end of a frame without incurring the penalty of a copy, or stalling the render pipeline (the flip is performed asynchronrously to the render command stream by the display engine). However, it has historically been the source of many GPU hangs.

Default: enabled.

Option "SwapbuffersWait" "boolean"

This option controls the behavior of glXSwapBuffers and glXCopySubBufferMESA calls by GL applications. If enabled, the calls will avoid tearing by making sure the display scanline is outside of the area to be copied before the copy occurs. If disabled, no scanline synchronization is performed, meaning tearing will likely occur.

Default: enabled.

Option "TripleBuffer" "boolean"

This option enables the use of a third buffer for page-flipping. The third buffer allows applications to run at vrefresh rates even if they occasionally fail to swapbuffers on time. The effect of such missed swaps is the output jitters between 60fps and 30fps, and in the worst case appears frame-locked to 30fps. The disadvantage of triple buffering is that there is an extra frame of latency, due to the pre-rendered frame sitting in the swap queue, between input and any display update.

Default: enabled.

Option "Tiling" "boolean"

This option controls whether memory buffers for Pixmaps are allocated in tiled mode. In most cases (especially for complex rendering), tiling dramatically improves performance.

Default: enabled.

Option "LinearFramebuffer" "boolean"

This option controls whether the memory for the scanout (also known as the front or frame buffer) is allocated in linear memory. A tiled framebuffer is required for power conservation features, but for certain system configurations you may wish to override this and force a linear layout.

Default: disabled

Option "RelaxedFencing" "boolean"

This option controls whether we attempt to allocate the minimal amount of memory required for the buffers. The reduction in working set has a substantial improvement on system performance. However, this has been demonstrate to be buggy on older hardware (845-865 and 915-945, but ok on PineView and later) so on those chipsets defaults to off.

Default: Enabled for G33 (includes PineView), and later, class machines.

Option "XvMC" "boolean"

Enable XvMC driver. Current support MPEG2 MC on 915/945 and G33 series. User should provide absolute path to libIntelXvMC.so in XvMCConfig file.

Default: Disabled.

Option "Throttle" "boolean"

This option controls whether the driver periodically waits for pending drawing operations to complete. Throttling ensures that the GPU does not lag too far behind the CPU and thus noticeable delays in user responsible at the cost of throughput performance.

Default: enabled.

Option "HotPlug" "boolean"

This option controls whether the driver automatically notifies applications when monitors are connected or disconnected.

Default: enabled.

Option "Virtualheads" "integer"

This option controls specifies the number of fake outputs to create in addition to the normal outputs detected on your hardware. These outputs cannot be assigned to the regular displays attached to the GPU, but do otherwise act as any other xrandr output and share a portion of the regular framebuffer. One use case for these extra heads is for extending your desktop onto a discrete GPU using the Bumblebee project. However, the recommendation here is to use PRIME instead to create a single Xserver that can addresses and coordinate between multiple GPUs.

Default: 0

Option "ZaphodHeads" "string"

Specify the randr output(s) to use with zaphod mode for a particular driver instance. If you set this option you must use it with all instances of the driver. By default, each head is assigned only one CRTC (which limits using multiple outputs with that head to cloned mode). CRTC can be manually assigned to individual heads by preceding the output names with a comma delimited list of pipe numbers followed by a colon. Note that different pipes may be limited in their functionality and some outputs may only work with different pipes.

For example:

Option "ZaphodHeads" "LVDS1,VGA1" will assign xrandr outputs LVDS1 and VGA1 to this instance of the driver.

Option "ZaphodHeads" "0,2:HDMI1,DP2" will assign xrandr outputs HDMI1 and DP2 and CRTCs 0 and 2 to this instance of the driver.

## OUTPUT CONFIGURATION
On 830M and better chipsets, the driver supports runtime configuration of detected outputs. You can use the xrandr tool to control outputs on the command line as follows:

xrandr --output output --set property value

Note that you may need to quote property and value arguments that contain spaces. Each output listed below may have one or more properties associated with it (like a binary EDID block if one is found). Some outputs have unique properties which are described below. See the "MULTIHEAD CONFIGURATIONS" section below for additional information.

### VGA
VGA output port (typically exposed via an HD15 connector).

### LVDS
Low Voltage Differential Signalling output (typically a laptop LCD panel). Available properties:

BACKLIGHT - current backlight level (adjustable)

By adjusting the BACKLIGHT property, the brightness on the LVDS output can be adjusted. In some cases, this property may be unavailable (for example if your platform uses an external microcontroller to control the backlight).

scaling mode - control LCD panel scaling mode

When the currently selected display mode differs from the native panel resolution, various scaling options are available. These include

Center

Simply center the image on-screen without scaling. This is the only scaling mode that guarantees a one-to-one correspondence between native and displayed pixels, but some portions of the panel may be unused (so-called "letterboxing").

Full aspect

Scale the image as much as possible while preserving aspect ratio. Pixels may not be displayed one-to-one (there may be some blurriness). Some portions of the panel may be unused if the aspect ratio of the selected mode does not match that of the panel.

Full

Scale the image to the panel size without regard to aspect ratio. This is the only mode which guarantees that every pixel of the panel will be used. But the displayed image may be distorted by stretching either horizontally or vertically, and pixels may not be displayed one-to-one (there may be some blurriness).

The precise names of these options may differ depending on the kernel video driver, (but the functionality should be similar). See the output of xrandr --prop for a list of currently available scaling modes.

### TV
Integrated TV output. Available properties include:

BOTTOM, RIGHT, TOP, LEFT - margins

Adjusting these properties allows you to control the placement of your TV output buffer on the screen. The options with the same name can also be set in xorg.conf with integer value.

BRIGHTNESS - TV brightness, range 0-255

Adjust TV brightness, default value is 128.

CONTRAST - TV contrast, range 0-255

Adjust TV contrast, default value is 1.0 in chipset specific format.

SATURATION - TV saturation, range 0-255

Adjust TV saturation, default value is 1.0 in chipset specific format.

HUE - TV hue, range 0-255

Adjust TV hue, default value is 0.

TV_FORMAT - output standard

This property allows you to control the output standard used on your TV output port. You can select between NTSC-M, NTSC-443, NTSC-J, PAL-M, PAL-N, and PAL.

TV_Connector - connector type

This config option should be added to xorg.conf TV monitor's section, it allows you to force the TV output connector type, which bypass load detect and TV will always be taken as connected. You can select between S-Video, Composite and Component.

### TMDS-1
First DVI SDVO output

### TMDS-2
Second DVI SDVO output

### TMDS-1 , TMDS-2 , HDMI-1 , HDMI-2
DVI/HDMI outputs. Available common properties include:

BROADCAST_RGB - method used to set RGB color range

Adjusting this property allows you to set RGB color range on each channel in order to match HDTV requirement(default 0 for full range). Setting 1 means RGB color range is 16-235, 0 means RGB color range is 0-255 on each channel. (Full range is 0-255, not 16-235)

SDVO and DVO TV outputs are not supported by the driver at this time.

See xorg.conf(5) for information on associating Monitor sections with these outputs for configuration. Associating Monitor sections with each output can be helpful if you need to ignore a specific output, for example, or statically configure an extended desktop monitor layout.

## MULTIHEAD CONFIGURATIONS
The number of independent outputs is dictated by the number of CRTCs (in X parlance) a given chip supports. Most recent Intel chips have two CRTCs, meaning that two separate framebuffers can be displayed simultaneously, in an extended desktop configuration. If a chip supports more outputs than it has CRTCs (say local flat panel, VGA and TV in the case of many outputs), two of the outputs will have to be "cloned", meaning that they display the same framebuffer contents (or one displays a subset of another's framebuffer if the modes aren't equal).

You can use the "xrandr" tool, or various desktop utilities, to change your output configuration at runtime. To statically configure your outputs, you can use the "Monitor-<type>" options along with additional monitor sections in your xorg.conf to create your screen topology. The example below puts the VGA output to the right of the builtin laptop screen, both running at 1024x768.

```
Section "Monitor"
  Identifier "Laptop FooBar Internal Display"
  Option "Position" "0 0"
EndSection
Section "Monitor"
  Identifier "Some Random CRT"
  Option "Position" "1024 0"
  Option "RightOf" "Laptop FoodBar Internal Display"
EndSection
Section "Device"
  Driver "intel"
  Option "monitor-LVDS" "Laptop FooBar Internal Display"
  Option "monitor-VGA" "Some Random CRT"
EndSection
```

## TEXTURED VIDEO ATTRIBUTES
The driver supports the following X11 Xv attributes for Textured Video. You can use the "xvattr" tool to query/set those attributes at runtime.

### XV_SYNC_TO_VBLANK
XV_SYNC_TO_VBLANK is used to control whether textured adapter synchronizes the screen update to the vblank to eliminate tearing. It is a Boolean attribute with values of 0 (never sync) or 1 (always sync). An historic value of -1 (sync for large windows only) will now be interpreted as 1, (since the current approach for sync is not costly even with small video windows).

## REPORTING BUGS
The xf86-video-intel driver is part of the X.Org and Freedesktop.org umbrella projects. Details on bug reporting can be found at https://01.org/linuxgraphics/documentation/how-report-bugs. Mailing lists are also commonly used to report experiences and ask questions about configuration and other topics. See lists.freedesktop.org for more information (the xorg@lists.freedesktop.org mailing list is the most appropriate place to ask X.Org and driver related questions).

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

## AUTHORS
Authors include: Keith Whitwell, and also Jonathan Bian, Matthew J Sottek, Jeff Hartmann, Mark Vojkovich, Alan Hourihane, H. J. Lu. 830M and 845G support reworked for XFree86 4.3 by David Dawes and Keith Whitwell. 852GM, 855GM, and 865G support added by David Dawes and Keith Whitwell. 915G, 915GM, 945G, 945GM, 965G, 965Q and 946GZ support added by Alan Hourihane and Keith Whitwell. Lid status support added by Alan Hourihane. Textured video support for 915G and later chips, RandR 1.2 and hardware modesetting added by Eric Anholt and Keith Packard. EXA and Render acceleration added by Wang Zhenyu. TV out support added by Zou Nan Hai and Keith Packard. 965GM, G33, Q33, and Q35 support added by Wang Zhenyu.


intel-virtual-output

title: intel-virtual-output(4)

text:
# intel-virtual-output(4)

## NAME
intel-virtual-output - Utility for connecting the Integrated Intel GPU to discrete outputs

## SYNOPSIS

```
intel-virtual-output [<remote display>] <output name>...
```

## DESCRIPTION
intel-virtual-output is a utility for Intel integrated graphics chipsets on hybrid systems. The tool connects local VirtualHeads to a remote output, allowing the primary display to extend onto the remote outputs.

## REPORTING BUGS
The xf86-video-intel driver is part of the X.Org and Freedesktop.org umbrella projects. Details on bug reporting can be found at https://01.org/linuxgraphics/documentation/how-report-bugs. Mailing lists are also commonly used to report experiences and ask questions about configuration and other topics. See lists.freedesktop.org for more information (the xorg@lists.freedesktop.org mailing list is the most appropriate place to ask X.Org and driver related questions).

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


joystick

package: xorg-drv-joystick

title: joystick(4)

summary: Joystick input driver

text:
# joystick(4)

## NAME
joystick - Joystick input driver

## SYNOPSIS
Snipped for xorg.conf.d(5):

```
Section "InputClass"
  Identifier "joystick-all"
  Driver "joystick"
  Option "MatchIsJoystick"   "on"
  Option "MatchDevicePath "/dev/input/event*"
  ...
EndSection
```

## DESCRIPTION
joystick is an Xorg input driver for controlling the pointer with a joystick device.

Use this driver, if you want to

- generate cursor movement, perform button or key events to control desktop and applications - generate cursor key events for playing legacy games, that have no native joystick support

Do not use, if you want to

- play games, that have native joystick support - use XI2 applications. The evdev(4) driver will suffice for those in most cases.

You may mix above scenarios by setting the device floating. The driver reports relative cursor movement, button and key events, as well as raw axis values through valuators.

## SUPPORTED HARDWARE
The joystick input module can be used on top of the following kernel devices:

```
- Linux's evdev device
- Linux's joystick device
- BSD's usbhid device
```

Every joystick supported by the kernel should be supported by the joystick input driver. The joystick is assumed to be calibrated and reporting axis values between -32768 and 32768. See the Linux kernel documentation for a complete list of supported devices.

There is no support for force feedback at the moment.

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

The following Driver Options are supported:

Option "Device" "string"

Option "Path" "string"

Specifies the device through which the joystick can be accessed. This option is mandatory and there is no default setting. In Linux, joysticks are usually accessible through /dev/input/jsX or /dev/input/eventX.

In *BSD, joysticks are usually recognized as /dev/uhidX.

Option "AutoRepeat" "delay rate"

Sets the auto repeat behaviour for key events. delay is the time in milliseconds before a key starts repeating. rate is the number of times a key repeats per second. Default: Xorg default

Option "DebugLevel" "integer"

Controls the verbosity of the driver for debugging purposes. The higher the DebugLevel, the more output is produced. Default: 0

Option "MapButton<number>" "string"

Sets the mapping of a joystick button to the desired action. Button counting starts with 1, Possible options are:

none

Don't do anything

"button=<number>"

Generate a pointer button event with button number (starting with 1).

"axis=[<factor>]<axis>"

Where <axis> is one of: x, y, zx, zy and <factor> is an optional amplifier of the axis, like -, +, -5, 0.4, 1.3, ... Negative values invert the direction. Default: 1.0

"amplify=<factor>"

Amplifies the movement of all axes by the given factor when this button is held down. Different factors can be combined.

"key=<scancode>[,<scancode>[,<scancode>[,<scancode>]]]

When button is pressed, a series of keydown events with the specified scancodes is generated. When the button is released, matching keyup events in the opposite order are generated. You can specify up to 4 scancodes per button. See special section about key events below.

"disable-mouse"

"disable-keys"

"disable-all"

Disables either the generation of mouse events, key events or the generation of all X events by the driver. Press button again to allow the driver to generate events again. You may also set the device floating from client space to prevent it from generating core events.

Option "MapAxis<number>" "string"

Sets the mapping of the axis to the desired action. Axis counting starts with 1, the parameter may contain:

"mode=<string>"

Where <string> can be one of: none, relative, accelerated, absolute

"valuator"

Send extra valuator events for this axis. The valuators will be numbered ascending, starting with 2 (valuator 0 and 1 are reserved for pointer movement). Please consider using the evdev(4) input driver if you are only interested in XI2 features. The range of the valuators is always -32767 to 32768. Neither mode nor axis needs to be set to generate extra valuator events. The axis will be labelled according to its physical axis number, beginning with 1 , e.g. "Axis 1" for the first axis (being the 3rd valuator). Default: not set.

"axis=[<factor>]<axis>"

Where <axis> is one of: x, y, zx, zy, key (see keylow/keyhigh) and <factor> is an optional amplifier of the axis, like -, +, -5, 0.4, 1.3, ... Negative values will invert the movement. Default: 1.0

"keylow=<scancode>[,<scancode>[,<scancode>[,<scancode>]]]

"keyhigh=<scancode>[,<scancode>[,<scancode>[,<scancode>]]]

When the axis is moved out of the deadzone, a series of keydown events according to the direction of the movement is generated. When the axis is released, matching keyup events in opposite order will be generated. You can specify up to 4 scancodes for each direction. keylow defines the keys to be generated when the axis is moved in negative direction (left or up), keyhigh defines the keys to be generated when the axis is moved in positive direction (right or down).

If mode is set to relative: The driver will emulate autorepeat according to the current value of the axis. A keydown and subsequent keyup event will be generated in short time intervals. To modify that interval and the autorepeat speed, supply the "axis=[<factor>]KEY" parameter.

If mode is set to accelerated: Keydown and keyup events will be generated repeatedly. The time between a keydown and a keyup event corresponds to the deflection of the axis. If the axis is deflected by 30%, the key will be considered to be down 300ms out of 1 second. The exact intervals may vary and can be adjusted with the amplify parameter. If the axis is deflected by 100%, there will only be one keydown event, so the key is considered down all the time. The keys will be autorepeated according to the Xorg keyboard settings.

See special section about key events below.

"deadzone=<number>"

Sets the unresponsive range of the axis to <number>. This can be between 0 and 30000. Default: 5000

Option "StartKeysEnabled" "boolean"

Set to False to disable key event generation after startup. You can toggle key event generation with the disable-keys button mapping. Default: enabled

Option "StartMouseEnabled" "boolean"

Set to False to disable mouse event generation after startup. You can toggle mouse event generation with the disable-mouse button mapping. Default: enabled

## DEFAULT CONFIGURATION
The default configuration is as follows:

```
  Option "DebugLevel"        "0"
  Option "StartKeysEnabled"  "True"
  Option "StartMouseEnabled" "True"
  Option "MapButton1"        "button=1"
  Option "MapButton2"        "button=2"
  Option "MapButton3"        "button=3"
  Option "MapButton4"        "none"
  ...
  Option "MapAxis1"          "mode=relative    axis=+1x  deadzone=5000"
  Option "MapAxis2"          "mode=relative    axis=+1y  deadzone=5000"
  Option "MapAxis3"          "mode=relative    axis=+1zx deadzone=5000"
  Option "MapAxis4"          "mode=relative    axis=+1zy deadzone=5000"
  Option "MapAxis5"          "mode=accelerated axis=+1x  deadzone=5000"
  Option "MapAxis6"          "mode=accelerated axis=+1y  deadzone=5000"
  Option "MapAxis7"          "mode=none"
  ...
```

## ACCELERATED AXIS CONFIGURATION
Accelerated mode should be selected, if the axis is a directional pad, which reports only three states: negative, center, positive. It will result in smoothly accelerated movement when the axis is deflected. An optional factor will affect the acceleration and final speed.

This example will set up the axis as scrolling vertically inverted, with half the speed:

```
  Option "MapAxis1"     "mode=accelerated axis=-0.5zy"
```

This example maps four buttons to the four pointer directions, so you can use the buttons like a d-pad. The movement will be accelerated with half the normal speed:

```
  Option "MapButton1"     "axis=+0.5x"
  Option "MapButton2"     "axis=-0.5x"
  Option "MapButton3"     "axis=+0.5y"
  Option "MapButton4"     "axis=-0.5y"
```

## ABSOLUTE AXIS CONFIGURATION
In absolute axis mode, the position of the cursor will match the position of the configured axis, but relative to the previous position of the cursor. You can specify the range in which the cursor can move. The default range is the screen size.

In this example the first axis gets a range from left to the right of the screen. The second axis gets a total range of 200 pixels, 100 to the top and 100 to the bottom:

```
  Option "MapAxis1"     "mode=absolute axis=x"
  Option "MapAxis2"     "mode=absolute axis=200y"
```

## GENERATING KEY EVENTS
Providing a "key=<scancode>[,<scancode>[...]]" option will generate X Events with specified scancodes. When the button/axis is released, the keys will be released in opposite order.

If you want a certain KeySym, look up the matching scancode using xmodmap -pk. The scancodes depend on the configured keyboard layout. You can also use unused keycodes and map them to a KeySym of your choice using xmodmap(1).

You can specify up to 4 scancodes per joystick button/axis, which can be used for modificators to get the KeySym you want.

Examples:

```
  Option "MapButton1"     "key=64,23"
```

will generate Alt_L+Tab when the button is pressed.

```
  Option "MapButton1"     "key=50,40"
```

will generate a Shift_L+d which will result in an uppercase d.

```
  Option "MapButton1"     "key=65"
```

will result in a space key.

```
  Option  "MapAxis1"      "mode=relative    keylow=113  keyhigh=114 axis=0.5key"
  Option  "MapAxis2"      "mode=relative    keylow=111  keyhigh=116"
  Option  "MapAxis3"      "mode=accelerated keylow=113  keyhigh=114"
  Option  "MapAxis4"      "mode=accelerated keylow=111  keyhigh=116"
```

will map the first and third axis to the arrow keys left and right and the second and fourth axis to the arrow keys up and down. The keys for the first two axes will be generated in an interval according to the value of the axis. The autorepeat speed of the first axis will be half the speed of that of the second axis. The keys for the third and fourth axis are generated once when the axis moves out of the deadzone and when it moves back into the deadzone. X.Org will autorepeat those keys according to current keyboard settings.

## XI2 Events
If you only care about raw valuator events instead of using the joystick to control the cursor, consider using the evdev(4) input driver. If you still use the joystick driver for raw events, make sure to unmap all axes/buttons and add the valuator option to the axes:

```
  Option  "MapAxis1"      "mode=none valuator"
  Option  "MapAxis2"      "mode=none valuator"
  Option  "MapAxis3"      "mode=none valuator"
  Option  "MapAxis4"      "mode=none valuator"
  ...
  Option  "MapButton1"      "button=1"
  Option  "MapButton2"      "button=2"
  Option  "MapButton3"      "button=3"
  Option  "MapButton4"      "button=4"
  Option  "MapButton5"      "button=5"
  ...
```

Remember, that valuators 0 and 1 are reserved for pointer movement, additional axes will start with valuator 2.

You might also want to set the device "floating" to stop it from reporting core events:

```
  Option  "Floating"      "true"
```

## NOTES
It is not recommended to enable the joystick input driver by default unless explicitely requested by the user.

Configuration through InputClass sections is recommended in X servers 1.8 and later. See xorg.conf.d(5) for more details. An example xorg.conf.d(5) snipped is provided in ${sourcecode}/config/50-joystick-all.conf

Configuration through hal fdi files is recommended in X servers 1.5, 1.6 and 1.7. An example hal policy file is still provided in ${sourcecode}/config/50-x11-input-joystick.fdi to be placed in /etc/hal/fdi/policy.

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

## AUTHORS
Sascha Hlusiak (2007-2012),

Frederic Lepied (1995-1999)