Depois de tantos problemas no desktop, como fontes queimando, cabos de energia derretendo e nobreaks indo pro saco, resolvi comprar um notebook pra funcionar como ferramenta backup. Veio com Windows Seven (eu estava fugindo do Vista), Geforce with CUDA e um Intel Core i3. Já fui instalar Python e Java. A "problemática" de se usar Python no Windows é que não é tão "automágico" como no Linux. Sei

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.

No en todas las distribuciones gnu/linux están disponibles parches para mejorar la visualización de tipografías en monitores LCD (creo que por un problema de patentes), Fedora es una de las distribuciones que no incluye esos parches. En el blog Infinality.net encontré unos paquetes, una guía y recomendaciones para mejorar nuestras fuentes. Resumiendo un poco los…Más

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).