Hi folks,

this post is just request for all obs-packagers. Please, don’t forget write some documentation about your projects (which you maintain or develop). I mean, documentation for developers. This make more easy to understand logic of program, connection between some modules inside or interfaces between widget/applet and “system/hardware part”. For sure, comments in source code (or in changelog) help, but some times they give not so much clarity.

This is not so complicated to write one-two pages about project, which you hack. This also can save time of new developers. They will not ask you about architecture of project, and that will save your time too

I don’t know how will be better to do it: use wiki (create a new page) or add just text-file in source project. Anyway it’s not so important where will be this documentation, main things that this documentation will be exist

I unfortunately received an e-mail just now from the Linux Foundation with regards to our precious Smeegol, and it appears on the face of it that they’re not that impressed with our efforts. Somewhat bizarrely as they have had plenty of opportunity to respond. Now I’m not going to start ranting and raving about injustice etc, what I will say is this and it is a bit of a rant ;-) :

Since Lucas passed Zenity to me and Arx Cruz we worked to fix some issues/bugs and add new features.
You can see some of the action on bugzilla or on git. Here we carefully select and thought about bugs and enhancements so we won't break Zenity compatibility with older versions delivering users the same usability and don't break scripts.


For GNOME 2.32 we set a new dialog to give the user the possibility to insert a Password...



or a Username and Password dialog.



So now the goals for GNOME 3.0 is to include a few more features contributed by some Zenity users and port some of the parts to GNOME 3.0 and GTK+- 3.0.

Enjoy and join the fun...

As many of you know and have generously donated, Bryen was robbed while traveling through Spain recently. We have now closed the pledge as we exceeded our goal. I have now transfered all of the funds to Bryen and he is planning on donating the rest to the GNOME A11y cause. Something that is close to him.

So, a huge thanks to all.

A picture says more than 1000 words

I was just having fun with that..

Those changes are in git only repo, not tarball has been released yet, so if you want to test it you’ll not find it on the usual X11:lxde repo.

But don’t worry, i packaged it.. add X11:lxde:Test repo and upgrade libfm and pcmanfm from there..

As the openSUSE tradition:

Have a lot of fun…

So after many months of hard work, Smeegol is out the door. Now contrary to what some folk may think, this was *NOT* a one man show – far from it! I may have spearheaded the whole affair, but I in no way can take credit for it all – that doesn’t mean I wouldn’t accept any of your fine donations ;-) I’d like to take this opportunity to thank many of the people that helped get this labour of love out the door.

Many of you that follow my blog probably know Bryen, also known by suseROCKS.  He is someone that has dedicated a significant amount of his time and effort throughout his life to spread awareness about accessibility.  This month he is traveling in Europe to help further this effort.  Unfortunately, while he was in Spain he was robbed.  There are several of us that have thought about trying to raise some money to replace these items.

So, if you’d like to join us and show your appreciation for all that Bryen has done we ask that you donate what you can at this link: http://pledgie.com/campaigns/13645

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!