All Blogs

See src/view-reflection.c in your local gallery git clone. Suboptimal code, no slideshow (only displays the first picture for a given tag), but well.

Maybe I should try to load images (using GdkPixbuf or something alike), use GEGL to do some transforms on them (more optimized than my hackish filters :-P), then use these transformed images on a Clutter texture...

I wonder how hard it would be to play a movie using clutter-gst and add reflections of it.

Today I looked at Clutter, a nifty "rich UI" creation library using OpenGL and the like. After playing around with some of the samples, reading some API docs and writing one dumb simple text-rotating application (think Windows' text-message screensaver, you know), I wanted to make something more advanced (hum-hum).

I decided writing some photo slideshow application would be cool. We already have several of those, obviously, remember this is just a playground.
Having some sort of F-Spot (a great photo management application) integration would be nifty too, so I started with that: loading taglists and picture-paths for one tag. In the end it turned out writing that took more time than writing the simple view I created.

Next I wrote the Clutter driver code and some system to be able to easily switch view functions. I only implemented one so far, which just fades between images (in, out, next image in, out etc) and stores the GdkPixbuf's in a ringbuffer. Not optimal, no cleanup code yet, jadajadajada.

No screenshots as a static screenshot would not be very impressive (the current application neither but hey ;-)).

Anyway, it might be useful as a sample/basic Clutter application for some people. You can find the source code, clone URL and compilation instructions here. If you implement some nifty view, share it!

Enjoy.

For quite a while on several systems where ACPI is used to deliver key press events to the operating system (mostly laptops, that's why we got the asus_acpi, thinkpad, toshiba, sony,... drivers in the kernel). In userspace acpid was used then to fetch these commands, a callout script was used which used some application to inject the corresponding keycode (based on the ACPI event ID, which is just "randomly chosen" by the hardware manufacturers) on some input device, so applications (eg your X server) were able to see the key press events. Especially the acpid -> callout -> map scancode to keycode -> inject in input device isn't such a "nice" solution, but it worked, most of the time.

Recently people (one of them Richard Hughes of GPM fame, you know, that power-eating applet ;-)) started to rework these in-kernel drivers to use the kernel input subsystem directly, so no more round-trip to userspace would be necessary.
There are 2 possibilities here: you can store a scancode to keycode mapping table in the driver itself, or you can remap scancodes to a keycode from userspace on some device using ioctl's.

This last method is made easy by HAL (0.5.10 or git), which includes a callout which allows you to store the mappings in an FDI file, and then performs the remapping when a matched device is found on the system. More information about this can be found here.

IMHO this method is the cleanest, as it doesn't force us to store big device-specific mapping tables in the kernel driver. It's userspace so much easier to make changes, add new device information,...

ASUS laptop owners couldn't make use of this yet as nor the in-kernel driver, asus_laptop, or it's -cvs version provide relaying to a kernel input device. Yesterday I decided to implement this, and today it got somewhat finished, after some minor issues. You can find the resulting patch here, it's against current acpi4asus CVS, but I think it should apply cleanly against a vanilla kernel too. I'll submit it to the acpi4asus list tomorrow. Git repository is here, you want the "acpi_keys_to_input_layer_no_internal_mapping" branch.

After compiling the driver and insmoding it (or modprobe if you install it too, make sure you don't load the old version by accident) you should see some information in dmesg: a message the driver is loaded, the name of your laptop model, and the fact a new input device called "Asus Extra Buttons" was created. Now when you press some multimedia buttons and check dmesg again, it should tell you some keys were pressed it can't map to a known keycode, also providing the scancode. You can use this information to generate an FDI file as described in the pages I linked to before.

If you're using an "old" HAL version, you can download a small utility here to emulate HAL's behaviour using hard-coded information. You need to make a list of scancodes and their meaning using KEY_* values. You can find these constants in /usr/include/linux/input.h, or in include/linux/input.h of your local kernel source tree.
Once you know which scancodes map to which KEY_* value, you can add them to the "mappings" variable defined at the top of the C file. The format is simple: scancode1, keycode1, scancode2, keycode2,...,-1. Make sure you always add pairs of scancode/keycode values, and end the array with a -1.

Once you entered the values, compile the program (gcc -o set-asus-keymap set-asus-keymap.c), figure out the event device node for the Asus Extra Buttons device (check /proc/bus/input/devices, where Name is Asus Extra Buttons, see which eventX is after Handlers), and run the program (as root) using ./set-asus-keymap /dev/event/eventX (now I don't want *any* comments on this entry regarding "I have no eventX node").

When you're done with this, create a nice FDI file too, and send it to the HAL mailing list so others can enjoy your research too :-)

That's about it, your special keys should "just work" and acpid is no longer necessary to handle them.

Some time ago my ACPI-driven laptop keyboard buttons (volume control, music player controls,...) stopped working. I'm using the acpi-support package (although not running a Debian derivate) driven by acpid.
Today I decided I wanted my buttons back, so I started to find out what was going wrong.

The issue: acpi_fakekey checks all /dev/input/eventX devices whether or not it's a keyboard device, and if it finds one, it writes the necessary scancode to this device. Since some recent kernel, /dev/input/event0 is no longer my AT keyboard, but one of these ACPI buttons, so writing scancodes to the device won't work: my X server keyboard driver won't see them.

/proc/bus/input/devices told me I need event4 (or use this command: hal-get-property --udi `hal-find-by-capability --capability input | grep KBD` --key input.device | sed "s:/dev/input/event::g"
). Patching acpi_fakekey.c is pretty trivial:

--- acpi-support-0.94/acpi_fakekey.c.orig       2007-04-28 18:09:37.078953488 +0200
+++ acpi-support-0.94/acpi_fakekey.c    2007-04-28 18:09:49.578470914 +0200
@@ -13,7 +13,7 @@
         char filename[32];
         char key_bitmask[(KEY_MAX + 7) / 8];
 
-        for (i=0; i<32; i++) {
+        for (i=4; i<32; i++) {
                 snprintf(filename,sizeof(filename), "/dev/input/event%d", i);
 
                 fd = open(filename, O_RDWR);

Replace the 4 with the correct number on your system.

Now my buttons "work" again. Patching acpi_fakekey so it uses HAL to figure out the correct device to write to might be somewhat more reasonable though :-)

Just read this interesting post. Had to change the read command somewhat to match my dmesg format (timestamps, you know).

Anyway, here's the result:
$ su -
# /etc/init.d/syslog-ng stop
# echo 1 > /proc/sys/vm/block_dump
# echo "Wait some time here, just use your desktop as usual"
# dmesg | gawk '/(READ|WRITE|dirtied)/ {activity[$3]++} END {for (x in activity) print activity[x],x}'| sort -nr | head -n 10 | gawk '{print $2 " " $1}'
pdflush(215): 160
evolution(7736): 149
pdflush(7670): 126
firefox-bin(7748): 26
gaim(7146): 12
jfsCommit(221): 5
gconfd-2(7114): 5
mono(7200): 4
mono(7199): 4
jfsIO(220): 4
# echo 0 > /proc/sys/vm/block_dump
# /etc/init.d/syslog-ng start
# exit