Zeta-Puppis.com

October will be a month full of events:

• On 17th, October, I’ll be (hopefully) in Pisa attending the nss06 conference;
• On 24-25-26th October I’ll attend a VoIP & Networking conference in Bari, at the Sheraton Hotel;
• On 28th October I’ll hold a talk in the italian linux day, probably about vectorial graphic using inkscape.

If you’ll be in one of these events please let me know!

WARN­ING: long post
I bought my first laptop: an IBM ThinkPad R50e (I found only an ital­ian page for this model, sorry me, but I guess there’s a trans­la­tion some­where over the IBM’s site). It has all the things I need with­outh any esotic com­po­nent. So I started hack­ing it…
The debian’s instal­la­tion worked well (with test­ing netinstaller) and I hadn’t any prob­lem. The only think you should keep in mind when con­fig­ur­ing xorg is to use this in the video section:

Section "Device"
        Identifier      "Intel Corporation 82852/855GM Integrated Graphics Device"
        Driver          "i810"
        Option          "VBERestore" "yes"
        Option          "Clone" "true"
        Option          "MonitorLayout" "CRT,LFP"
        Option          "DevicePresence" "yes"
EndSection

In this way you’ll have the mon­i­tor port work­ing (for exam­ple if you want to con­nect the laptop to a video projector).

The first thing I wanted to make work has been the soft­ware sus­pend fea­ture (I’m not talk­ing about the ACPI sleep state, or as it is com­monly named “stand by”, but a real suspend-to-disk fea­ture).
This can be accom­plished in sev­eral ways, but usu­ally with swsusp (that’s kernel inte­grated since 2.6.12 if I recall cor­rectly) or suspend2. With a default setup it doesn’t always work; the shut­down process works well, but the resume hangs when restor­ing ACPI inter­rupts. I tried both ways, with suspend2 it never worked: when resum­ing it hangs at “copy­ing orig­i­nal kernel back”. With swsusp you have to exclude some dri­vers in order to don’t always hang. First of all, remove rtc (real time clock) sup­port. With it enabled I get crash­ing more often than I need. Then don’t use intelfb: although it should be sup­ported, the swsusp with this module loaded works one out three times. I had some crashes with­outh 3D accel­er­a­tion enabled too (but just load i915 and every­thing goes ok).

Then I tried to make some­thing cool with the thin­k­light. There’s already some­thing really cool out there (rock­light over every­thing). But I did some­thing cooler: every key I press makes the thin­k­light blink. That’s not useful, nor mind­sane, but def­i­nitely geek. That’s done through a kernel patch over the key­board driver. As soon as I finish to do some checks I’ll pub­lish the patch here.

About the wire­less card: I can’t get it in mon­i­tor mode by using vanilla kernel sources. If you want mon­i­tor mode, use ipw2200 and ieee80211 from sf.net (http://​www.​ieee80211.sf.net and http://​www.​ipw2200.sf.net) but they’re not so stable. I keep losing 10-15% of wire­less pack­ets with them. There’s not mon­i­tor mode, but since I never done wardriv­ing (and I don’t plan to make it), I think it’s good for me.

And if you want to make some­thing cool to show to the friends, then install fluxbox and 3ddesktop and bind /usr/bin/3ddesk to some key: that’s what will bring your friends to linux.

If we talk about gcc exten­sions then prob­a­bly we shouldn’t talk about likely/unlikely func­tions. But since they are widely used into the GNU/Linux kernel, they are much more than strictly related.
In the truth, they are not func­tions, but macros. Let see how they’re defined:

#define likely(x)       __builtin_expect(!!(x), 1)
#define unlikely(x)     __builtin_expect(!!(x), 0)

You can see these lines in include/linux/compiler.h into your kernel sources. As you can see, likely and unlikely are just macros, the real gcc exten­sion is __builtin_expect.

Prat­i­cally talk­ing, __builtin_expect is a way to say to gcc that such con­di­tion is easier to happen then another (this is usu­ally called branch pre­dic­tion) and is needed to opti­mize the code (a jump, or better, an IP change­ment, takes a lot of cpu cycles, so if you can, opti­mize it).
With 1 we say that the if branch is more prob­a­ble than the else one. While, on the other side, with 0 we say that the else branch is more prob­a­ble than the if one.
That said, this means that if we know that an if (or an else) is much more prob­a­ble to happen, we should use such macro.

Please note that we’re talk­ing about kernel code that needs to be extremely opti­mized. If you’re writ­ing your own appli­ca­tion you prob­a­bly won’t need to use such exten­sions since rarely you’ll have to do branch pre­dic­tion (better, the com­piler should do this for you).

If you bought a Sound­Blaster Live! 24 bit and you wanted to use its AUX input under linux then you prob­a­bly noticed that alsa’s driver (ca0106) doesn’t pro­vide such func­tion­al­ity.
Adding it is not a real issue, prat­i­cally the card has three inputs:

1. microphone
2. line in
3. input

Those inputs are mutu­ally exclu­sive since they uses the same chan­nel. Prat­i­cally talk­ing this mean that they cannot oper­ate simul­ta­ne­ously, and making the AUX work­ing is just a matter of enabling/disabling the pipe against its controller.

Here there is a patch against linux kernel vanilla 2.6.16-rc1. The only issue I found is that if anyone uses the AUX, there’s some back­ground noise but I’m still trying to fig­ur­ing out if this issue comes from the TV card that’s attached to or from the patch itself.

Please note that this patch needs test­ing: if you can test it let me know both if every­thing goes ok and if some­thing goes wrong.