Quite a while ago, I bought some device with a laser pointer. I did lost it over time and eventually ran into it just a couple days ago. In the meantime, I bought an Arduino and started experiencing with it, especially with photo-sensitive resistors (photoresistors).
So I wondered what kind of fun could come out of a laser + a photoresistor + an Arduino. Actually, it didn't take long to figure out what to do. Remember all the Mission: Impossible-like movies and shows, where people are to move into laser-secured rooms, without interrupting any of the laser beams? Well, that's pretty-much the idea I came up with: "securing" my room door with such things.
The setup is pretty easy: the Arduino is on one side of the door, with the photoresistor and another 10k resistor that we need to have a changing voltage. The laser is on the other side of the door, directed right to the photoresistor and connected to the Arduino via a couple wires. So the general idea here is to make the Arduino power the laser and get the tension from the photoresistor (or the 10k resistor) a couple times every second. Here is a scheme:
Here is a demo video of the Arduindoor system running (first time making an alarm ring, second time playing/pausing music) :
If you're interested in the idea, you can setup your own with the additional help of:
During this summer period, temperatures are starting to get really high, and often higher than what my computer can handle, apparently.
Since a couple of weeks, I noticed a nasty white flickering taking over the screen after hours of use, with my integrated Intel HD Graphics 2000 on SandyBridge Intel i3 2120.
I tried to search for a solution but couldn't find anything that helps, except turning the computer off for some hours, thus letting it cool down.
So this happens more and more often as uptime increases and at some point, it gets so frustrating that my only solution is to turn the computer down and do some other business. It happens more when running 3D games and also continues on tty sessions (even with X not running at all).
So I made a video to explain the situation to Intel GFX people on IRC, who sadly couldn't bring me much more help.
As I am porting Replicant, our fully free Android derivate, to the new Goldelico GTA04, I had to deal with ALSA user-space integration in Gingerbread. So let's take a quick look about it: On Gingebread (and previous versions), user-space audio is done via the libaudio library. The Android framework will basically interact with AudioFlinger that is the component in charge of loading that libaudio library and dealing with it (that's frameworks/base/services/audioflinger/AudioFlinger.cpp). So libaudio is basically the place where PCM read/write and mixer stuff happens. As we started looking into the various existing ALSA libaudio, my fellow Replicant developer GNUtoo told me about TinyHAL, a clean and flexible audio module that does ALSA and routing from XML configuration files. Too bad, TinyHAL was designed for Ice Cream Sandwich, and the Audio API changed in ICS (basically, it is now a module, like the ones for gps, sensors, lights, etc). So I couldn't use it as-is, but there were various concepts I hoped I would be able to reuse, like the XML routing config or the use of the TinyALSA lib, that is very clean, simple to use and handles ioctl-level ALSA stuff.
In the end, I decided to write my own libaudio, using both TinyALSA and XML config files, that I called TinyALSA-Audio. Audio output and Mixer was quite straightforward and worked quickly. AudioFlinger basically opens the AudioStreamOut at 44100Hz, 2 chans, S16_LE format (signed 16bits, little endian), which works fine with the audio hardware, a TWL4030 Codec here, that didn't complain at all.
Next step was about audio input and recording. At first sight, I thought it would be as easy as audio output, that is just setting the controls, opening the device via TinyALSA, sending the config following what AudioFlinger asks and just read the data. So I basically wrote code that was that simple, but it failed while setting the config: cannot set hw params: Invalid argument was the error. As I didn't see what could possibly be wrong about the params, I decided to take a look at how tinycap, the capture utility that comes with TinyALSA handles things. It actually sets the params at 44100Hz, 2 chans, S16_LE, and recording works then. When I tried to force the params to what AudioFlinger asks, that is 8000Hz, 1 chan, S16_LE, I got the very same error as on my libaudio: cannot set hw params: Invalid argument.
So what was it all about? Does the CODEC only records at 44100Hz, 2 chans? I tried with zygote stopped, and then 8000Hz mono worked. I also checked in the kernel code: the TWL4030 CODEC is supposed to work at 8000Hz mono as well. So I deducted that when the output device is opened, the input device will only work at the same config (rate, chans). What a bummer! AudioFlinger asks for 8000Hz mono, not 44100hz stereo, though that's all I can get when output is opened (which is always the case when zygote is running).
Thanks to the AOSP, there are various others libaudio that I could use to learn things. First thing to know was if that "issue" was specific to TWL4030 or common to all ALSA CODECS. So I did the same test (with tinycap) on the Nexus S and Galaxy S, and the result was that both couldn't record at any other rate/chans that the ones set when opening output. Galaxy Nexus audio module confirmed that too. So what is the solution here? Obviously, it consists in finding a way to return 8000Hz mono data to AudioFlinger while reading 44100Hz stereo data: that's resampling.
Galaxy S and Nexus S libaudio all handled resampling by internal algorithms, which seemed a pain to use and adapt on my libaudio. The solution finally came from the Galaxy Nexus audio module. And I really want to send a big Thank-You to the people who wrote it. First of all, it uses the very same TinyALSA as my libaudio uses. Second thing is that it doesn't embed complicated algorithms for resampling but uses the new Android 4 framework for resampling, that wasn't so hard to understand. behind that engine is the libspeexresampler lib, that is part of speex code. So all I had to do was to backport that Android 4 resampling code, enable to build of libspeexresampler in gingerbread and make use of all that in my lib.
Though, wait a second, when reading AudioFlinger code, it all seemed to indicate that AudioFlinger embeds its own resampling engine, so that when the lbiaudio reports different parameters, it handles resampling to what it wants (mostly 8000hz mono). So I tried to make use of that, in vain. I couldn't figure out why it didn't work, it just didn't. I read the AudioFlinger code several times, made sure the resampler was enabled and all, but in the end, the produced audio was just garbage, so I just gave up on using AudioFlinfer's resampler. After all, if all the AOSP libaudio do not make use of it, there might be a reason. So the thing appears to be totally messed-up and nobody cares enough to fix it but rather implement resampling in the libaudio itself. Not a very good thing for me, I would have preferred to leave resampling to the upper layer, but anyway, I had Galaxy Nexus code that could be adapted to my lib. So that's basically what I did: backporting the Android 4 resampler code to my libaudio, making use of it and using ICS external/speex repo. In the end of this misadventure and with some fine tuning, it all worked.
That's pretty much the end of the story, now I have my TinyALSA-Audio lib that handles input/output routing via mixer audio output and audio input as well, to various rates. Here are some links:
As I am doing software development that sometimes requires a lot of resources (mainly when building Android/Replicant), I recently decided to get myself some new hardware. I was previously running with a dual-core Pentium 4 running at 3.00Ghz, along with 4G RAM (the motherboard chipset is limited to 4G), two Hard Drive Disks and an nVidia graphical card. All was running under Trisquel 5.0, with the nouveau driver for nvidia cards, that didn't permit outstanding hardware acceleration (though it was fairly good enough to play 720p videos).
Finally I decided to get an Intel i3 CPU, dual core at 3.30Ghz and an adequate motherboard, both coming with SandyBridge support. I ended up buying 8G of DDR3 RAM, which is fairly enough for Android/Replicant build to stay on RAM (it finished on SWAP with my old hardware). I'm particularly amazed of SandyBridge, that technology that permits the CPU to hold an Intel GPU that can be used with an appropriate motherboard. It is very-well supported by Linux (and by Linux-libre as well), Xorg and Mesa (compared to all of what I've tested with Linux-libre). I was able to play Nexuiz at 1280x800 with nice effects, 0 A.D. with shades and water reflection disabled and a few other ones (Mania Drive, OpenArea, etc).
All that came with a 60GB SSD used as rootfs. It really speeds up the boot process alot! (The BIOS is actually taking longer than grub up to gdm)
On the software side, I stick to distributions promoting and distributing only free software. I thought about getting to Debian as I mostly agree with their decision to distribute a kernel free of firmwares, but that will load them when present (which is what we do in Replicant too). Though, I'm using Trisquel since a year now, and I kinda got used to it. As usual, it is very usable, ready and nice-looking! As I have no hardware requiring non-free software to be loaded, I'm totally fine with Linux-libre, even though I agree more with the Debian way of things regarding the kernel.
Let's cut-off the long and boring text and get to serious matters. Trisquel decided to stick with gnome-panel while Gnome 3 features the new gnome-shell interface. I'm very pleased with that decision, as I already tried gnome-shell and find it less usable than good-old gnome-panel, mainly because there is no really quick way to have the windows listed, to switch from one to another and to reduce them. When I first ran into Gnome "fallback" experience (that is what gnome-panel is called now), I got very disappointed by the unavailability of right click on bars to customize them (move stuff, add widgets, etc). I though it was the end of the gnome-panel era and sincerely thought that this fallback experience was just a quick hack, with no possible customization. Thankfully, I was wrong. You can actually do the very same changed in that GTK3 gnome-panel by holding the Alt key while doing right-click on a panel. After discovering that, I quickly got back into my old setup, with some adjustments.
The main bummer I faced is that Trisquel theme was apparently not designed to be used with the "menu bar" applet, that holds Apps and Places. It was really ugly-looking, so I strongly recommend you to use this css layout (in /usr/share/themes/Trisquel/gtk-3.0/apps/): gnome-panel.css
As you can see on the screenshot up there, I am using conky to display time, date and various infos about the system. Here is the conkyrc, designed (with absolute values) for a 1680x1050 screen: conkyrc, draw_bg.lua.
Also, if it turns out conky won't stop flickering, even if you're using double buffer and all, make sure that maximum_width is greater than the actual width conky uses. If you didn't define maximum_width anywhere and conky won't stop flickering, that may very well be the reason. Define it with an appropriate size and it may help to sort things out. That's one problem I had while doing that conkyrc.
As for an icon theme, I'm using elementary, with the Trisquel logo on top. It has a huge benefit: the icon that shows up when changing the volume will no longer be ugly as it's obviously resized from a non-vectorial image. It'll show a nice and clean white speaker icon. When I was doing that conkyrc, I also turned on metacity compositing, that is a very unknown feature but permits some nice stuff while remaining simple (no outrageous effect that will slow you down). For instance, it gives that volume popup clean round edges, instead of the sharp ones, as well as some nice transparency. If your GPU can handle it, I strongly advise to turn metacity compositing on. That's just one gconf key to set: gconftool-2 -s '/apps/metacity/general/compositing_manager' --type bool true
So, I decided to start out a new dev blog, focused on software (and sometime hardware) development I'm doing. Currently, it mostly takes place in the Replicant project, a fully free Android derivate. I'm hoping I'll get to Coreboot development soon, even though it seems quite hard at first sight.
I used to write on http://blog.paulk.fr, but that was in french and so did limit a lot the scope of people able to read my posts. I'll probably keep writing there sometimes, but probably for non-technical stuff (there is a wide range of subjects that I'd be interested to talk about).
For this blog, I decided, for a change, to use a non-mysql blog engine. I would gladely have used heavy engines as Dotclear or Wordpress, if any of these supported sqlite (which is way easier to handle for personal-use blogs as mine). Anyway, I got to PluXml and gave it a try. It's apparently written by a bunch of frenchies (the comments on the code are in french). I had to do a couple of personal modifications to make it fit my expectations.
First thing is about the theme: the default one is IMO kinda ugly. As I didn't want to spend the crazy amount of time that creating a theme from scratch requires, I just picked a good-looking one and did a few changes. The theme is called Mystique. I think it was designed for Wordpress (as it's used on coreboot blog) but then got ported to PluXml. After small changes (that I won't list there, because I already forgot about half of them), I came up with something good enough for my daily use on this blog. The result is available for download at: http://download.paulk.fr/pluxml/mystique.tar.gz and should be GPLv2-licensed.
About PluXml code changes, I made a diff from someone's code that I found on a forum (the author is given in the source code). It permits to have a tags cloud. It's available there: http://download.paulk.fr/pluxml/tagArtsList.diff. Last change I did is a new function to list the articles taged with a particular tag. The code is used to show selected posts on the top bar of the blog. It's available as well: http://download.paulk.fr/pluxml/artTagsCloud.diff under the GPLv2+ license.