seife's assorted rants

LIRC IRMP remote control code “sharing”

seife — Sat, 28 Apr 2012 10:05:56 +0000

While investigating inferior LIRC performance today, I checked the timings used by IRMP and found that using those instead of the “measured” ones of LIRC in the config file made LIRC perform much better. See the patch for details.

Looking at the lircd.conf more thoroughly for the first time, I finally found the similarities between the lircd remote control codes and the IRMP codes (at least for the NEC protocol used with this handset):

IRMP “address”: 0xBA45
IRMP “command”: 0x1A
lircd “pre_data”: 0xA25D
lircd “code”: 0x58A7

The IRMP Documentation (sorry, german only) describes the NEC protocol as follows:

32 bits of data: 8 address bits + 8 inverted address bits + 8 command bits + 8 inverted command bits

The IRMP “address” is really 8 bit only: 0xBA inverted is 0x45, leading to an “effective address” of 0x45.
The IRMP “command” is already 8 bit only.

Now double-check with the lirc codes: address 0xA2 inverted = 0x5D, command 0x58 inverted = 0xA7, so the scheme seems to apply to both.

Using only the relevant 8 bits:

IRMP address: 0x45
IRMP command: 0x1A
lircd address: 0xA2
lircd command: 0x58

Looking closely, I found that the difference is actually the LSB / MSB order: IRMP is shifting the bits in reverse order compared to lircd.

So if needed, it should now be pretty easy to extract codes for IRMP from lircd.conf files using a simple perl script or the other way round, at least for NEC codes. Lircd has the advantage that you can easily “learn” your new remote control handset with an interactive program (if you disregard the suboptimal timing data it creates).

Kdump Vortrag / Paper

seife — Sun, 18 Mar 2012 07:47:03 +0000

(German only, the paper is also only available in german right now).

Zur Zeit halte ich Vorträge über kdump, unter anderem auf dem GUUG Frühjahrsfachgespräch 2012 und den Chemnitzer Linuxtagen 2012.

Da die Dauer der Vorträge meist auf ca. 45 Minuten begrenzt ist, enthalten die Vortragsfolien nur wenig technische Details. Für den Tagungsband des FFG 2012 habe ich jedoch einen Artikel geschrieben, der als Einstieg in das Thema besser geeignet ist. Diesen Artikel gibt es hier.

Viel Erfolg!

What to do about a trademark trolls?

seife — Thu, 09 Feb 2012 08:27:50 +0000

Imagine there is a GPL’d open source project, going strong for more than 10 years, with more than 50 contributors. Now a company comes along and registers the name of the project as a trademark with the clear intention of suing people using this name to sell equipment with the software preloaded.

They are not contributing to the project.

Is there anything the project can do about that?
The opposition deadline (german: “Widerspruchsfrist”) is not over yet.

Oh - and of course they are blatant GPL violators, linking the project’s GPL’d software against closed source libraries which in turn use closed source kernel drivers, ship a U-Boot version of which nobody has ever seen the sources and so on, but that’s a different story.

Using IRMP with Arduino

seife — Sat, 28 Jan 2012 12:10:24 +0000

I needed to implement an infrared remote control decoder, so certainly I took out my Arduino and hooked up an IR sensor chip to pin 2. Then the interesting thing started. Looking around, I found ladyada’s tutorial on IR sensors. However, the method used there is pretty limited (you basically record a sample of each key signal and then compare the received signal to your samples) and unreliable for many protocols.
Then I found IRMP (german only link, sorry) which is a very versatile IR decoder for many protocols. However, IRMP is made to be used with plain avr-gcc, not from within Arduino’s IDE.
But fixing that was really not very hard.
The results are available on gitorious, project arduino-addons/irmp-arduino, including a simple example sketch to test the decoder.

Note that I’ll probably rebase the git tree whenever something happens in the IRMP SVN repository, so be aware of that in case you make local changes to the code and want to update from my tree.

Have fun!

Decrappify GNOME3 Powermanagement

seife — Thu, 29 Dec 2011 11:01:27 +0000

GNOME3 has actually become quite usable, but I was really annoiyed by the inability to disable actions on “critical low battery” (Additionally, there is no way to define what “critical low battery” is and with a big battery I assume this might well mean that you cannot use the machine anymore even though there is half an hour of juice left). Add to that bnc#738782 which leaves my screen unlocked after suspend and I decided it was time to use someting sane — like xfce4-power-manager — instead.

However, it’s not that easy, as everything power related is hard-coded into the gnome-settings-daemon — and even in different places.

So here is a package with a patch that simply disables the handling of all the power-related keys in the media-keys (!) plugin and additionally prevents the build of the power plugin completely.

Now just start xfce4-power-manager (and maybe use the Evil Status Icon Forever shell extension to make it show up in a visible place).

The patch is here, it is clearly not upstreamable but I’d rather have an ugly hack than an unusable “good solution”

If you don’t want to fight package maintainers…

seife — Fri, 23 Dec 2011 08:51:06 +0000

…then work around the bug.

One example is bug 699400: hwclock is never set correctly when NTP is used (unless it was almost correct before…).

I reported the bug, I argued with the maintainer, it did lead to nothing, the bug was “RESOLVED INVALID” (interesting notion: either it is resolved or it is invalid, then there is nothing to resolve…)

What’s my workaround? I exploit the fact that old SysV init uses bash scripts. The init script which sets the clock does source /etc/sysconfig/clock. Internally, it uses a variable ELEVENMIN_MODE.
So what did I do? Simply add

readonly ELEVENMIN_MODE=no

at the end of /etc/sysconfig/clock.
The script will throw some errors on boot and shutdown due to its inability to change a readonly shell variable, but I can live much better with a harmless warning than with a totally wrong system time at each reboot

Update: Werner has pointed out in the bug that this is totally wrong and will make a mess of your time settings, so use this at your own risk. OTOH I have more than 2000 productive systems here running with this. We had lots of problems before and have no problems anymore after doing it like described here. So at least for me the wrong solution works good.

A trivial systemd unit script: vboxservice.service

seife — Tue, 22 Nov 2011 08:25:42 +0000

In a VirtualBox guest, VBoxService (which is for example responsible for setting the time after a host suspend/resume) is not started on boot. I thought about writing a simple init script to doit (editing the vboxadd init script seemed like a bad idea, since it might get overwritten on updates).
Then I decided to try the “native systemd” way.
Executive summary: it is much easier than with old style SysV init:

# cat /etc/systemd/system/vboxservice.service
[Unit]
Description=VirtualBox guest services

[Service]
ExecStart=/usr/bin/VBoxService -f

[Install]
WantedBy=default.target

Activate with systemctl enable vboxservice.service.

12.1 update - no problems and systemd rocks

seife — Fri, 18 Nov 2011 18:44:32 +0000

Two days ago I updated my home server to 12.1, basically by doing

# cd /etc/zypp/repos.d
# sed -i 's/11.4/12.1/' *
# zypper ref
# zypper -v dup --no-recommends

The only small glitch I had was systemd apparently taking a nap during boot, which made the machine take very long to boot (about 2 minutes).
After filing bug 730776, I found out (with the helpful hint from Frederic), that I still had an invalid swap partition in my fstab. After fixing that, the bootup now really is blazingly fast:
server:~ # systemd-analyze Startup finished in 4116ms (kernel) + 33827ms (userspace) = 37944ms

new avr-gcc packages

seife — Wed, 16 Nov 2011 18:24:18 +0000

Thanks to Volker Kuhlmann, there are now 3 brand new avr-gcc packages in the CrossToolchain:avr repository: avr-gcc-436, avr-gcc-462 and avr-gcc-47-20111105.
The “original” cross-avr-gcc package is still at 4.3.3, as that’s the most tested revision and also it has additional patches that are dropped from the new versions. Those patches add, amongst others, XMEGA support which is not present in the avr-gcc packages. That’s something to improve in the future.

The packages contain a run-avr-gcc-XXX wrapper script (substitute XXX with the 436, 462,…) to make testing the respective compiler very easy.

Have fun testing!

Cool. Censored Mailinglists.

seife — Thu, 10 Nov 2011 15:56:55 +0000

Funny. As soon as someone brings up an unwanted topic, the openSUSE Factory Mailinglist Dictator^WModerator shows up and the rest of the discussion never reaches the list. Without a notice of course.

So that’s what I had to say on the topic, and the Factory list will now probably do without me. This post is just that people have a chance to know why their bugreports will be handled the way they are.

Date: Thu, 10 Nov 2011 07:50:03 +0100
From: Stefan Seyfried
To: opensuse-factory@opensuse.org
Subject: Re: Decision making (Was Re: [opensuse-factory] Kmail 4.7 is not
 shippable in 12.1)
In-Reply-To: <201111091248.27668.markus.s@kdemail.net>

On 09.11.2011 12:48, Markus Slopianka wrote:

> On Mittwoch 09 November 2011 11:45:27 Stefan Seyfried wrote:
>
>> We should simply revert the mistake of making KDE the default desktop.
>
> https://features.opensuse.org/306967
> https://features.opensuse.org/307495
>
> Live with it, vocal minority!

Well, some time ago it was said that openSUSE is a meritrocracy. Those
who do the work get to decide.

It is very easy for people to first vote "make $BROKEN_DESKTOP default"
and later complain that it does not work.

Obviously, all the people wanting to have a certain desktop as a default
need to make it work. If it doesn't, it does not deserve to be the default.

There is even FATE for that: https://features.opensuse.org/312959
Right now, people vote for not having a working desktop.

That's fine with me. Makes bugfixing much easier: either "RESOLVED -
WORKSFORME", or "Component: KDE4-Workspace", "[x] reassign to default
component owner".
I doubt it improves the user experience, but hey, the users voted for
it, so who am I to complain.