EPUBs are getting more and more important thesedays. If you believe the essays from well-informed magazines, they will develop into a standard for book and text consumption as MP3 did for audio.

Today, lots of e-book readers are available and more will be ready in the future. Apart from the problem, if an e-book reader supports EPUB, the EPUB file itself has to adhere to certain specifications. This is the task for epubcheck, a commandline utility which validates an EPUB file.

The RPM package can be found in my OBS repository home:thomas-schraitle as usual. To use it, just run epubcheck with your EPUB file and see what it finds.

Have fun!

Over the past couple of days, I’ve been trying to figure out how input in Linux works on modern systems. There are lots of small pieces at various levels, and it’s hard to understand how they all interact. Things are not helped by the fact that things have changed quite a bit over the past couple of years as HAL – which I helped write – has been giving way to udev, and existing literature is largely out of date. This is my attempt at understanding how things work today, in the Ubuntu Lucid release.

Kernel

In the Linux kernel’s input system, there are two pieces: the device driver and the event driver. The device driver talks to the hardware, obviously. Today, for most USB devices this is handled by the usbhid driver. The event drivers handle how to expose the events generated by the device driver to userspace. Today this is primarily done through evdev, which creates character devices (typically named /dev/input/eventN) and communicates with them through struct input_event messages. See include/linux/input.h for its definition.

A great tool to use for getting information about evdev devices and events is evtest.

A somewhat outdated but still relevant description of the kernel input system can be found in the kernel’s Documentation/input/input.txt file.

udev

When a device is connected, the kernel creates an entry in sysfs for it and generates a hotplug event. That hotplug event is processed by udev, which applies some policy, attaches additional properties to the device, and ultimately creates a device node for you somewhere in /dev.

For input devices, the rules in /lib/udev/rules.d/60-persistent-input.rules are executed. Among the things it does is run a /lib/udev/input_id tool which queries the capabilities of the device from its sysfs node and sets environment variables like ID_INPUT_KEYBOARD, ID_INPUT_TOUCHPAD, etc. in the udev database.

For more information on input_id see the original announcement email to the hotplug list.

X

X has a udev config backend which queries udev for the various input devices. It does this at startup and also watches for hotplugged devices. X looks at the different ID_INPUT_* properties to determine whether it’s a keyboard, a mouse, a touchpad, a joystick, or some other device. This information can be used in /usr/lib/X11/xorg.conf.d files in the form of MatchIsPointer, MatchIsTouchpad, MatchIsJoystick, etc. in InputClass sections to see whether to apply configuration to a given device.

Xorg has a handful of its own drivers to handle input devices, including evdev, synaptics, and joystick. And here is where things start to get confusing.

Linux has this great generic event interface in evdev, which means that very few drivers are needed to interact with hardware, since they’re not speaking device-specific protocols. Of the few needed on Linux nearly all of them speak evdev, including the three I listed above.

The evdev driver provides basic keyboard and mouse functionality, speaking – obviously – evdev through the /dev/input/eventN devices. It also handles things like the lid and power switches. This is the basic, generic input driver for Xorg on Linux.

The synaptics driver is the most confusing of all. It also speaks evdev to the kernel. On Linux it does not talk to the hardware directly, and is in no way Synaptics(tm) hardware-specific. The synaptics driver is simply a separate driver from evdev which adds a lot of features expected of touchpad hardware, for example two-finger scrolling. It should probably be renamed the “touchpad” module, except that on non-Linux OSes it can still speak the Synaptics protocol.

The joystick driver similarly handles joysticky things, but speaks evdev to the kernel rather than some device-specific protocol.

X only has concepts of keyboards and pointers, the latter of which includes mice, touchpads, joysticks, wacom tablets, etc. X also has the concept of the core keyboard and pointer, which is how events are most often delivered to applications. By default all devices send core events, but certain setups might want to make devices non-core.

If you want to receive events for non-core devices, you need to use the XInput or XInput2 extensions for that. XInput exposes core-like events (like DeviceMotionNotify and DeviceButtonPress), so it is not a major difficulty to use, although its setup is annoyingly different than most other X extensions. I have not used XInput2.

Peter Hutterer’s blog is an excellent resource for all things input related in X.

Just a short note: Today I announced that the company I am working for is switching from MS Office to OpenOffice.org. :-)
Most of the people never heard from OpenOffice.org before and have no idea about Free / Open Source Software. The majority of the minds is open and they are curious about that new software. Others kindly asked for guidance. All in all I have a good feeling about that change. Wish me luck!

openSUSE strategy is evolving. The strategy team is working very hard to integrate all the input they get. We got some great ideas from our contributors as well as from users and even non-users.
I would be interested in further input from the upstream projects.

• What do you expect from the openSUSE community? In which direction should out strategy point to improve our collaboration?

Please let us know your hopes and expectations in the comments or via mail (firstname.lastname  at gmail com).

P.S.: I would be great if you could spread that page to other upstream projects.

Yesterday I wrote up a new feature request for openSUSE and the OBS on openFATE. The general idea is to make the Build Service more useful to users by giving them more information about the repositories available.

The major complaint that people using the OBS have is simple. If you search on openSUSE Software Search or webpin you may find five different packages of the software you want; What's the difference between them? Which one is stable? Which one will still be working in a week's time? On the opensuse-kde mailing list, we constantly get asked to explain the difference between KDE:Distro:Stable, KDE:Distro:Factory, and KDE:Unstable:SC - even after pointing them to the wiki pages here and here.

There is even disagreement on what "Stable", "Unstable" etc. means - people ask is it KDE that is Factory - or openSUSE? And then whenever a repository rename occurs, users are left surprised when their zypper refreshes suddenly return errors. And how do you tell users about important changes in repositories like the upcoming shift from KDE SC 4.5 to 4.6 that is about to happen in KDE:Distro:Factory?

So having thought about all this, I wrote up my suggestions on openFATE:310604. Basically I propose a NEWS file, or similar, that gets pushed to users and updated with the metadata, along with a repository stability flag where each state is very clearly defined and visible in software search results. Please vote and comment, and lets get this done for openSUSE 11.4!

Hudson X11 Automated Testing - To run GUI automated test in Hudson environment. Ara Pulido, demonstrated me, how to setup Hudson and to run some Mago test. The tests were failing, as the ldtp daemon failed to load. When I started poking, I found, the tests can run only in console mode. We need to start a X session, then need to start the test. Even, after this, the tests were failing. Setting DISPLAY doesn't help ! Accessing accessibility service from terminal failed, as AT_SPI_IOR not set from the terminal.

To overcome, this issue, implemented a service and a client, the service runs during the gnome-session startup.

The service (UNIX socket) listens for commands from client, once received execute them in the shell and returns back both stdout and stderr. Just one command per request, not to make things complicated ;-)

During the test, X session will be started with Xvfb, need to evaluate X dummy driver instead. Accessibility, should be enabled and gnome screen saver, should be disabled, before starting the test. Requirement for LDTP tests.

More about this, available here (documented by Ara) and here, also FAQ

Note: Currently tested with GNOME Desktop on Ubuntu Linux using Mago and LDTP from GIT head

Special thanks to Ara Pulido (Ubuntu), Brian Nitz (Sun / Oracle) and Tyller Ballance (Hudson team)

Following on from my previous posts [1], [2], here is are the release announcements for the OpenSync plugins I've been working on.

opensync-plugin-kdepim
This is an OpenSync 0.22 plugin to sync with KDEPIM (pre-akonadi, so < 4.5). Using this and the OpenSync framework you can sync your KDE PIM data with mobile devices and other applications. This is ONLY compatible with OpenSync 0.22; not OpenSync 0.3x or above. This code is not guaranteed bug-free; always have a backup of your data. This plugin can sync contacts with KAddressBook, events and todos with KOrganizer, and notes with KNotes (over DBus). If you have akonadi configured this plugin will refuse to sync (you can override this in the config, see the README). IMPORTANT: Note syncing depends on you having a KDE installation where bko#251914 is fixed. This means knotes >= 4.4.7, or use the patch there to recompile.
If you can't get that to work, or if you don't need note syncing, in the patches directory of the source there is a patch that can turn off note syncing and allow it to compile.

opensync-plugin-kdepim on kde-apps.org
libopensync-plugin-kdepim-0.22.tar.bz2 source tarball on the OBS

opensync-plugin-akonadi
This is an OpenSync 0.22 plugin to sync with KDEPIM with akonadi, so > 4.4).
Using this and the OpenSync framework you can sync your KDE PIM data with mobile devices and other applications.
This is ONLY compatible with OpenSync 0.22; not OpenSync 0.3x or above.
This code is not guaranteed bug-free; always have a backup of your data.

This plugin can sync contacts, events, todos, and notes with Akonadi. (There is currently no easy way to view Akonadi notes). Make sure you have at least one akonadi collection of each type before syncing.

opensync-plugin-akonadi on kde-apps.org
libopensync-plugin-akonadi-0.22.tar.bz2 source tarball on the OBS

For both, prerequisites are libopensync-devel and libkdepimlibs4-devel. Compilation is standard

mkdir build; cd build
cmake ..
make
make install

Usage is add plugin to an OpenSync sync group; sync.

Both are available on the OBS in KDE:Unstable:Playground

As explained in my previous post, something is finally happening with regards to KDEPIM and syncing with mobile devices.

As step 1, I have resurrected KitchenSync - the KDE OpenSync frontend. This application allows for creating, configuring, and syncing OpenSync sync groups among any of the OpenSync plugins (check your distro for opensync-plugin-* or similar).

Basic use should be straightforward - add a sync group, add the members you want to sync between, configure if necessary, sync.

The underlying OpenSync 0.22 framework is showings its age a bit though, and does have some bugs, so if you see a problem in KitchenSync, first make sure that the syncing works with the command-line tool msynctool before reporting a bug in KitchenSync (which, for this version, you can do by directly contacting me here on this blog or via email). Msynctool will also show a bit more debugging output so if something is going wrong, definitely check there first.

I've made binary and source RPMs available for openSUSE 11.1 and newer on the OBS in KDE:Unstable:Playground, which I'll try and keep updated whenever I can.
The source tarball is also available thanks to the OBS. I'll see about getting some publicly accessible source repository soon.

Prerequisites are libopensync-devel, libkde4-devel, and kdepimlibs4-devel or whatever similar name your distro calls them. Compilation instructions are standard KDE SC 4 / cmake stuff.

mkdir build; cd build
cmake ..
make
make install

The release is available on KDE-Apps.org.

In an entirely coincidental event, Quentin Denis has revived the KDE4 + OpenSync 0.40 version of KitchenSync on KDE SVN too. This does not overlap with his work; OpenSync 0.40 is not compatible with OpenSync 0.22. However, I'll be keeping track of his development and backporting any useful fixes (and lending any help I can).

Those of you who have used KDE software for a while may remember way, way back when it was announced that KDE would be cooperating with a project called OpenSync to provide PIM data synchronisation to a wide range of devices. The program KitchenSync was brought in as an OpenSync frontend and for a while everything was good - you could sync contacts, events, todos, and notes from KDE 3.5 with your mobile phones and PDAs.

Then the OpenSync project moved away from the stable version 0.22 and started work on a grand new 0.3x branch. They said when they reached 0.40, the project would be stable for end users again. Three years later they are still not ready, with the last release, 0.39, one year ago now. The project still has not been abandoned but things are moving extremely slowly.

Meanwhile KDE moved on as well, to our beloved 4.x series. It was decided to wait for OpenSync 0.40, and then put some effort into porting over the KDE-OpenSync integration - but as KDE release after release went by without OpenSync 0.40 being ready, people got bored of waiting for OpenSync and so KitchenSync was dropped, leaving KDE 4.x users no way of syncing PIM data with mobile devices. Further complicating this is the recent move to akonadi, which adds another layer between your PIM data and where you want it to be - on your mobile device. Compounding this is that all distributions, on the instructions of the OpenSync project, still ship the now-unmaintained and uncared-for OpenSync 0.22 version.

A few technically successful KDE Google SoC projects were undertaken to provide an alternative syncing framework (for example based on SyncML) but they never gained enough polish, or enough device support, to catch anyone's attention.

Now one of my introductions to the F/OSS world was helping a project called SynCE, a framework to talk to Windows Mobile devices from Linux. SynCE had always used OpenSync as the syncing framework and a common question on the SynCE mailing lists was "How can I get my data into KDE?" - and there was no answer. So finally given some free time this summer I decided to do something about it.

In total, I backported the half-finished KitchenSync KDE4 + OpenSync 0.40 port back to OpenSync 0.22 so that it is usable right now. Then I did the same for the KDEPIM plugin - but this only works with KDE SC releases before akonadi was introduced (i.e. < 4.4). Then I wrote a brand-new Akonadi Sync plugin for OpenSync 0.22 - not to be confused with the still-in-development Akonadi / OpenSync 0.40 plugin still available in KDE trunk. I'll do separate release announcements for them all.

UPDATE 26/09/10: Switch the repositories back to X11:Drivers:Video; thanks to Stefan's work it is updated. Also, a post on the list says that ati-fglrxG01 legacy driver won't work on openSUSE 11.3 even if it builds, due to Xserver incompatibilities :(
UPDATE 24/09/10: I've branched and submitreq'ed the changes back to X11:Drivers:Video. Therefore I've changes the instructions below to checkout my branch instead and avoid the patching.
UPDATE 24/09/10: If you need the ATI legacy driver, for example for Radeon X1400 chipsets, checkout X11:Drivers:Video/ati-fglrxG01 instead. I've patched that to build on openSUSE 11.3 but don't have the hardware to test if it actually works.

In part 1 of this topic, I discussed the current (sad) state of ATI/AMD fglrx video driver RPMs on openSUSE Linux, and suggested that the best, cleanest way to build them was actually via the OBS. Here I cover step-by-step instructions on how to do so.

(Note: I use sudo on my machine, if you don't have it configured, use su)
The first step is to install the OBS command-line frontend, osc.

sudo zypper in osc

This will also pull in the famous SUSE 'build' script that allows cleanly building rpms.

Then, in a clean working directory (e.g. ~/src):

osc co X11:Drivers:Video ati-fglrxG02

Voila! The necessary spec files and patches will be made available in X11:Drivers:Video/ati-fglrxG02.

If you use sudo, make sure to edit the osc configuration file ~/.oscrc to tell it that. Uncomment the line starting with su-wrapper and change the value to suit you.

Now time to build! (Fix distro version/arch as necessary)

mkdir ~/src/packages
cd X11\:Drivers\:Video/ati-fglrxG02
sh ./fetch.sh
osc build -k ~/src/packages -j 4 openSUSE_11.3 x86_64 ati-fglrxG02.spec

fetch.sh downloads the ATI driver release you wanted. The osc build will download necessary pacakges, create an entirely separate build system running in a chroot at /var/tmp/build-root - where it cannot affect your main system - and safely build the kernel module rpms, and once built save them in ~/src/packages. You will be asked for the root (or yours, if using sudo) password to create the chroot.
Similarly build the X11 drivers.

osc build -k ~/src/packages -j 4 openSUSE_11.3 x86_64 x11-video-fglrxG02.spec

Now go to your brand new rpms and install them!

cd ~/src/packages
sudo zypper in -f ati-fglrxG02-kmp-desktop-8.771_*.x86_64.rpm \
                    x11-video-fglrxG02-8.771-*.x86_64.rpm

This does take a bit of bandwidth (~150 binary packages to download into /var/tmp/osbuild-packagecache), and is slightly slower than compiling the driver yourself, but it's much cleaner and you end up with a better constructed package. The package will automatically change your display driver to fglrx on installing, and when uninstalling will not leave any cruft about your system. This method is also completely applicable to openSUSE 11.2 and previous.

Incidentally, if you add something useful in these RPMs (spec file, code patch), feel free to submit the changes back to the OBS so everyone can benefit - see OBS Collaboration.