Up to this day, programming for the Xorg window system is not opened to everyone.

A typical student must demand hard work and follow many computer classes enough to
acquire specific knowledge programming in C that would give her/him the chance to
code for the Xorg.

Lately the Xorg grew in maturity and has gained significant popularity. One
important advancement is the method of keeping the source code in more than one
repository, so that different people can develop on particular branches in
parallel, that may then be merged and updated in turn by others.

The input layer in Xorg offers driver support for various input devices, such as
mice, tablets, pens, touchscreens... Even there are good programmers and great
companies producing such hardware, still, new ideas will emerge and new drivers
will so need be written faster and better.

The task for the diploma would be to transfer all Xorg input layer maintenance --
from the initial driver projection, through implementation hardened by
verification and correction, to automated derivation and further synchronization
with software changes in Xorg and modifications of the hardware -- to an automated
co-integrated development framework for specifying, reasoning, correlating and
generating Xorg driver code.

The main feature of this newer approach to Xorg development is the maximum
expected from computer and the minimum from the human, and this is understood in
the sense that the large amount of currently existing Xorg code is just enough to
be relied upon for a systematic manner of updating and adding input drivers to it,
and it is quite fitted at this point to lent itself neatly to a formal software
specification, generation and maintenance tool.

The focus of the thesis work should be centered around advancing development via
co-integration of specifications together with reasoning under uncertainty.

The scenario of this approach has several aspects (1-4), parameters (5-6) and
coordinates (7-8).

1. The driver exists but it is incomplete; the minimal behavior is there, but it
lacks important optimizations and/or enhancements; the human efforts to complete
its functionality must be relayed to the computers.

2. A determined group of people finds there are ways to substantially transform or

visibly improve the driver with respect to the device and its environment, so they
create their own driver repository; for many such groups, drivers share many
aspects in common, and only the implementations differ with the devices.

3.1. Existing input drivers need have specifications, that combined with
specifications of the input subsystem and of further other parts of Xorg make into
a robust and useful unit of reference for other drivers to have them co-integrated
in their own development tree.

3.2. However, not few existing input drivers exhibit bugs, mistakes or flaws,
either at one stage or along stepping between stages; if they are to be referenced
as "trusted" drivers, these shortcomings must be found means to be coped with, so
that errors do not get injected further on.

4. As Xorg evolves, its design encounters shifts in perspectives of its logical

parts or replacements of its actual modules; these lead to the necessity or
possibility of altering also the driver design and implementations; it is hence
imperative that Xorg partial specifications also exist that can essentially and
relevantly capture their perspectives and that can easily and properly support
their changes.

5.1. A lot of work that must be done is writing specifications for various Xorg
modules, the input subsystem and the input drivers: they must only conceptually
make a whole, but must not be entirely complete, and more important, not mutually
consistent.

5.2. Once we get our hands on the specifications, they form the input to an
automated reasoner such as Isar: with a proper training, not only programs can be
derived from correctness proofs, but also specifications themselves can be
adjusted or synthesized; for the first, we extract the computational content of
proofs structured in a constructive logic; for the second, we detect the
contradictory models of programs in a Paraconsistent Logic (see also a book).

6.1. Before committing an actual module written in C to a repository, the

intermediate language SWIG for testing and prototyping C should be used, and so
the programs are derived with output in this language first.

6.2. The actual C code would be the last step; at this lowest level, human
assistance should be at its highest intensity.

7. The requirements described before concern mainly methodological issues of a

more or less organizatorical trait; this only scratches the surface, as in fact
the hardest work is the conceptual model of the physical functioning of the
device, which is in need of choosing mathematical models and devising logical
behaviors.

8. Initial specifications are created from existing code by parsers.

Application Domain: The Xorg Window System

Programming Languages: Standard ML, SWIG, C

Specification Languages & Tools: Common Algebraic Specification Language, The

Heterogeneous Tool Set

Proof Assistants & Tools: Isabelle, Proof General