Making calibration values permanent

Using the calibrator to get new calibration values is one thing, but making the calibration values permanent is another.
This page gives an overview of possible approaches, together with their advantages and disadvantages.

(default) printing instructions on standard output

Currently the calibrator prints instructions on creating a script with xinput commands and example xorg.conf, HAL policy and UDEV rule files on stdout.

Advantages:

• simple, no dependencies
• no special permissions (eg root) needed to run the calibrator

Disadvantages:

• does not automatically save the calibration
• need to run the application from a terminal
• need to read all the output, choose one method and act upon

a pointercal file (default on SHR)

For SHR, a distribution for smartphones, Martin Jansa invented the following smart hack:

1. add a script xinput_calibrator_pointercal.sh to Xsession.d such that it is called automatically when X starts
2. if there is no pointercal file yet (eg /etc/pointercal.xinput) then run the calibrator and save the ‘xinput’ commands printed on stdout in the pointercal file.
3. if there is a pointercal file, execute it (it will run the necessary xinput commands)

Advantages:

• Calibration is automatically, and only once, started on first use
• Calibration values are automatically saved and set when starting X

Disadvantages:

• Assumes there is always a touchscreen (that needs calibration), only valid for phones
• Running the calibrator manually will not change the default values in the pointercal

adding global udev rule

Write out a complete udev rule file.d
To make it multiple screen tolerant, the filename would be something like xinput-calibrator-%device-name%.rules, the program would need the right permissions to be able to put it in /etc/udev/rules.d/

TODO: need the kernel-device-name, the sysfs name (how?)
p(. When using evdev, the sysfs name is the same as the evdev name. When not using evdev (eg evtouch) this is not the case. I just noticed there is also ‘input.product’, next the general ‘info.product’. Need to check if this is the Xorg name, if it is, we have a way to map Xorg names to kernel names !

Advantages:

• Works across X restarts
• Works with input hotplugging (eg unplug and plug in)

Disadvantages:

• Need writing capabilities (eg root) in /etc/udev/rules.d/

adding xorg.conf.d file

Write out a valid xorg (sub)config
To make it multiple screen tolerant, the filename would be something like xinput-calibrator-%device-name%.conf, the program would need the right permissions to be able to put it in /etc/X11/xorg.conf.d/ or wherever the Xorg config dir is.

TODO: need sysfs name (how? see adding global udev rule)
TODO: can we have partial confs ? eg. do not specify the specific device, but do specify the calibration vals…

Advantages:

• Works across X restarts
• Should work with input hotplugging (eg unplug and plug in)

Disadvantages:

• Need writing capabilities (eg root) in /etc/X11/xorg.conf.d/
• Need very recent xserver (currently not in an X Release yet?)

adding xinput commands to $HOME/.xsession

In the default configuration, the X server of a user calls the ~/.xsession file when it starts. We could put xinput calls in that file, though it has to be before any ‘exec’ call, and it should not corrupt the users existing config.

Advantages:

• No root needed, user-specific

Disadvantages:

• Only for one user
• If there is a ‘greeter’ (gdm/xdm/…) then the screen is not calibrated until the user logged in.
• Have to parse and carefully write out a new .xsession file

start-up scripts, global config

We could make it a full blown app: a /etc/default/xinput_calibrator file would contain a configurations dir, in the config dir (eg /etc/xinput_calibrator/) there would be config files per configured touch screen, contain $NAME, $CALIBRATION, $SWAPXY and whatnot.
These files would be read and xinput would be called when the system starts (/etc/rc2.d/xinput_calibrator or upstart variant) and/or when the X server starts (in /etc/X11/Xsession.d/xinput_calibrator)

Advantages:

• Clear configuration place
• Allow to configure ‘extras’ like force autostart of calibration if no calib file present (useful on phones)

Disadvantages:

• No device hotplugging ?
• if only Xsession.d script, then no calibration during greeter ?
• more packaging effort, no stand-alone application

integrate with a settings daemon

The calibrator could be integrated with a settings daemon, it would be responsible for saving and restoring calibration values.

Advantages:

• Integrated in existing configuration tool
• Let the settings daemon save/restore the config
• No root

Disadvantages

• Needs GUI integration
• No support for non-DE users (phones, fluxbox etc)
• Redo all the work for kde/xfce/lxde variants ?