Thursday, October 16, 2014

Building the Forking X server

Building the Forking X server

I work on Debian (Sid), so the Git repositories contain debian/ and  packages are built by git-buildpackage as documented in another post.

You can also install by using my debian repository:
deb sid main

I did not implement a new Extension - I extended the protocol of XKB.
So, first build the x11proto-kb-dev package
Now it's possible to build both libX11 and the server:
Since the ABI between the server and "input device" driver, it's necessary to recompile them. I use only evdev & synaptics. But, evdev is used for the keyboard, and I need precise timestamps, so there are changes, hence build from this repo:
At this point the Xserver could be restarted. After building the X11 from:

    one can start asking the X server about the active plugins. There is a tool for that:
At this point it is possible to:
$ xinput list
....Virtual core keyboard                       id=3    [master keyboard (2)]
$  xplugin -l -d 3  
3 plugins in the pipeline
1: never-freeze-queue
2: xkb-auto-repeat
0: core

The function of each plugin:  

never-freeze-queue collects events while waiting for following plugins to proceed (& accept the events).  xkb-auto-repeat generates the auto-repeat events, core is the interface with dix/events.c.

Now we can finaly build the interesting feature: the "fork" plugin to be inserted before the auto-repeat plugin. It is implemented in C++ which explains some effort in the X server and x11proto-kb sources to make them C++ compatible.
so after building (& installing) you can insert that plugin:
xplugin -d 3 fork       # 3 is still the id of keyboard.
or also remove it:
$ xplugin -d 3 -fork

Now to activate some of the forks we need to communicate with that plugin, 
and build up a language to express the configuration.
For the configuration language, I chose to use Scheme, in the Gauche implementation. So, one needs to install Gauche-dev, and build this binding module:
building that one is more involved (see my blog about building Gauche modules).

That packages contains my configuration to be used this way:
$ fork-config-mmc.scm 3

When trying to configure, keep in mind, that allocation of the "fork" keycodes
is possible only if the XKB Geometry allows it. I.e. keycodes not found on the Geometry will be used.

See in how key "f" is used as Hyper modifier, or how Meta key acts as Escape key.

Monday, August 18, 2014

Forking -- multitouch on keyboard

Multitouch on keyboard is about ... interpreting simultaneous key presses
in a way that is different from sequential.

That is pressing 2 keys A+B should be something different from A, followed by B.
Years ago, I was told focus on the problem of converting one of the
letters into a modifier, and keep B as is. This has been enough of challenge to implement (properly), and I can share the software now.

The implementation includes patches to several components of the X-Windows system, and configuration tools.

Here's a diagram of involved parts:

The most complex part is extension of the Xorg server, to somehow postpone processing key events while maintaining the semantics of Un/Grab requests.

Since we use the timing of key events, we want to get best precision timestamps on them. Xorg server has to get the monotonic timestamp from the kernel/evdev.
That implies a bit of patches to input driver(xorg-evdev), and the DDX code to accepts events and put them into the event queue.

From there we want to plug this new functionality in the heap of machinery which implements auto-repeat, other XKB functionality, and then the Grab/Ungrab ops.

I have tried to separate, serialize the implementation of these functionalities, using this simple architecture: a linked list of  blocks with this API:
 (image missing)

These blocks pass Events  to the next one (in one direction), and in the other direction the information about Grab/Ungrab state is passed.

Indeed, if no event comes in, time can still be "pushed" through all these plugins,
so a plugin can also tell how early it is significant to push time to it.


Wednesday, October 9, 2013

Hooks to adapt a notebook to different conditions

So, I use Ubuntu 12.04 on my notebook.

Here a list of (shell) hooks I implemented to make the system adapt to "the environment". Only the minimum relevant code

  • Open/close lid -> internal screen on/off
  • grep -q closed /proc/acpi/button/lid/*/state
    xrandr -display $DISPLAY --output $internal --off

  • When (un)docked -> external monitor on/off.  un/docking detected by AC online. No other way found (with Dell latitude e*)


    if [ $(cat /sys/class/power_supply/AC/online) = "1" ]; then
    DISPLAY=:0 xrandr --output DP-1 --auto --rotate left 
  • Turn audio off/on  when on office network/at home:
    /etc/dhcp/dhclient-enter-hooks.d/  does not work with NM (see )
    So /etc/network/if-up.d/mute-in-office

     if [ ${DHCP4_DOMAIN_NAME-} = '' ];
       amixer set Master mute
     elif [ ${CONNECTION_ID-} = "home-ssid" ];
            amixer set Master unmute
            amixer set Front unmute
            amixer set Headphone unmute

  • prevent Skype from animating (in gnome-panel) when offline
    skype without any dbus  access?

    sleep 10s
    killall -STOP skype

    killall -CONT skype
  • keep cpu at minimum
    case "$1" in
            resume | thaw)
    sudo cpufreq-set --governor powersave
    foreach dir (/sys/devices/system/cpu/cpu*/cpufreq/) {
       echo powersave | sudo tee $dir/scaling_governor
       echo 1199000 | sudo tee $dir/scaling_min_freq
    #sudo hdparm -Y /dev/sdb

Friday, May 17, 2013

Shell skeletons

Shell skeletons --- a tool to start using a sequence of commands

When I started to build debian packages from Git, I adopted git-buildpackage.
The steps I used were (at least) 7:

  • git-dch  --release "--debian-tag=michal/%(version)s"
  • git add debian/changelog; 
  • git commit -m release
  • git-buildpackage --git-tag "--git-debian-tag=michal/%(version)s" 
  • debi --debs-dir ../build-area/
  • git-buildpackage -S
  • debrelease -S  --debs-dir=../build-area --dput

I had this recipe in a file/editor, and pasted line by line into shell, possibly adapting the text, and then invoked.
In case of error I could reinvoke the command, with some modification.

Then I learned that with Zsh, I can programmatically use that feature which implements C-q (push-line):  there is a stack which I can pre-populate, and then
ZLE will  prefill the command line by popping the strings from the stack.

So I came up with this function:

zload-file () {
        setopt nomonitor
        coproc tac $file &|
        while read line
                builtin print -z $line
        done <&p
        setopt monitor

Sure, I have to put the lines in reverser order -- the last one to be pushed as first, so that it ends at the bottom.

PS: After a while I learned/realized all the arguments of those commands, and made scripts (release & snapshot) which hide all the details, and expose different set of options-- those which I care about.

Sunday, November 25, 2012

Git-hierarchy --- how to use

Documentation on git-hierarchy.


Note: when I say branch, I mean the named head.

A "feature branch", or a segment, is a triple:
1/ branch
2/ start commit reference. (points to a real commit - sha1-hash)
3/ base symbolic reference -- name of branch to re-base it on.

A sum is a branch name and a list of summands -- symbolic references
of branches, which should be (re-)merged to form the "unique commit" of the branch.

Sums are handy for:
- the final release commit
- as the "base" reference for segments.

poset: the partial ordering of (relevant) heads, induced by:
 segment-head > the head referenced by the base symref.
 sum-head > each of the heads referenced by the list of summands.


git-segment  list, describe, create segments
git-sum    list, describe, create, modify  sums

git-rebase-poset the main tool -- rebase/remerge all the sums & segments.
so that for each segment  start is (again) equal to base, and sum-heads commits are joins of the summands.

git-rename  .. when renaming branches, rename the whole segment/sum, or
               update the other symbolic references to reference the changed  name.

git-delete  .. check if possible to delete the sum/segment, or if anything is
               referencing it -> abort.


start ... could have used tags. not now.
bases ... symbolic references; ex.  ref/base/antiflicker points at "ref: refs/heads/master".

summands ... symbolic refs. ex.  ref/sum/all/1  points at "ref: refs/heads/antiflicker",        ref/sum/all/2 points at "ref: refs/heads/auto-raise ...

Transferring to other repos

For now it's only a tool for individual use. There are some limitations in Git, which I had to work around:

  • "git push" resolves symbolic refs before sending them.
  • "git fetch" from GitHub does not fetch refs other than tags & branches.

So, if I want to at least transfer the structure, I need to patch git, or use this trick:

I can for example make a tag whose message -- as string -- is a table - dump of the symrefs:
sym-ref-name      ref: .....

git tag "hierarchy-refs" -m "$(git-dump-refs)"
and on fetching:
git cat-file tag hierarchy-refs |tail -n +6 |  git-recover-symbolic-refs

Thursday, October 11, 2012

System to keep a hierarchy of modifications for public software.

System to keep a hierarchy of modifications for public software.

I have developed a few extensions to free/open software, over past years.

Doing so in spare time, my priority was to get the features done,
at the cost of code quality, sharing(?).

During years, naturally, a need arose to re-apply those big patches to
evolving upstream sources.

So, inspired by Debian, I started to experiment with Quilt, and
represented my modifications as progressions of patches.

But there were certain projects, where my changes were so big,
that I was not able to extract such a linear sequence without
additional tools.

With the help of Git and especially Magit, I started to
classify separate diff hunks, then group those classified as related
and regroup etc.

  (I did this for my changes to Sawfish WM).

The whole set of changes grew to be  layers of changes, some dependent
on previous ones;  not a previous one, but more of them.

So I wanted to understand this partial ordering, and somehow represent it in Git.

The benefit for this would be easier future rebasing upon new upstream,
since rebasing smaller parts requires  less knowledge (decisions) at a time. And
some of my features can be also implemented upstream -- so I can just drop that
part of my changes, and  adapt/rework the rest.

Single "features" are thus represented as a linear sequence of commits,
and the dependency between them is represented by "basing" one  "feature"
on  a merge (commit) of  prerequisite features.

So, in my current version, I have merges - "sums", which are just lists
of features - "segments". And "segments" are "branches"  with
a Start commit (a hash id), and a symbolic "base", which is a "sum".
That base-sum can also be a trivial sum -- a simple  segment.

Rebasing such a hierarchy is a matter of walking in the topological order of
the dependency (between features -- segments) and sums,
rebasing them --onto the updated "bases"  or  redoing merges.

Code is here