Notices

Actually, my original design included two different collections to choose from -- you could either choose a keyset or a device. But the device list I came up with was so pitifully small, I just gave up on it. I am indeed hoping that the Compatible Devices List grows rapidly! (And in fact I'm adding the compatible devices into Pierogi bit by bit, even though I don't yet have an interface to access them yet...)

The biggest problem for Pierogi right now is that all of the keyset information I've got, every last bit of it, was derived from folks "reverse-engineering" their remote controls by pointing them at an IR receiver hooked up to a PC and pressing each button one by one. That's how the LIRC folks do it, how the Pronto folks do it, and how the JP1 guys do it. So I'm sure there are times when people wrote down the wrong timing value, or missed a button, or swapped two different buttons, or made an error naming the button, etc. (Let alone the errors I make importing the config files.) The data is not going to be perfect. What I would most like to know is this -- when people find a keyset that works with their device, do all the buttons work? Are there missing buttons? Are there buttons swapped around?

This is time consuming work, and I don't really expect people to just sit in front of their device and hit every single button in Pierogi. But I'd love to hear about it if and when a keyset does not perform as expected...

I would love to incorporate the full LIRC database, and perhaps, in the fullness of time, I will accomplish that goal. Until then, though, some folks may not want to wait for their favorite device to get supported.

Good question! In fact, a couple months back, I started the project planning to use the same scheme QtIrreco does -- reading individual LIRC config files provided by the user. Even as I started creating my own internal database of keysets, I still intended to keep the ability to import LIRC config files.

But there are problems with using the LIRC system. LIRC was created for the purpose of allowing a PC to read data from any random remote control pointed at it. Receiving IR is its bread and butter, transmitting IR back out again is just a side-project. The LIRC config files are very poorly designed, if what you want is to create a universal remote control, not a universal IR receiver -- they don't provide much (if any) information about the original target device of the remote, they have no coordinated method for naming individual commands (most LIRC users don't even care what their remote buttons are labelled as, since they end up remapping them for their own purposes anyway), and they mostly just describe the raw IR pulse sequence, which is inefficient as many protocols use redundancy and checksums to improve reliability. So, as time has passed, Pierogi's internal system for managing keyset data has moved further and further away from the LIRC format; so much so that I no longer have an easy way for people to just import LIRC files.

There's no reason I couldn't come up with an alternative standard. Indeed, the file formats that the JP1 folks are using are much closer to what Pierogi would need (which only makes sense, as they are more interested in the transmission side of the equation than in the reception side). But yeah, this is all going to take more time to implement.

Absolutely! (And in fact, if you take a look at the Pierogi keyset code, you'll see that I've actually started to put device data into each keyset, where I have it. I just haven't set up an interface to access it yet...) My problem has always been that I just don't have enough data. The Wiki page with the Compatible Devices List should hopefully make this more useful...

Sony is quite nice in that they set up one protocol for all their TVs from way way back when, and they've stuck to it (for the most part) all the way up to today. So almost all Sony TVs should be supported directly from the Sony TV Keyset 1. I've checked, and the RM-887 keys fall into that keyset as well. If it doesn't work for you, please let me know!

I have no knowledge of Pierogi's inner workings but I think of each keyset being something in the form of a config file (similar to LIRC) with a human readable format in a keysets directory would be a super easy way for each user to import/write/test keysets, after that it is a matter of uploading that config to the public/proposing it to be included in the next release.

Unfortunately it does not. Neither it does with any of the other Sony TV keysets. I will give it another try tomorrow just to be sure.

Thanks for the great work

Oh, well, let me give you a little intro! Don't worry, it isn't too painful. Here's a bit of the current sony.cpp file:

So yes, I'm just dropping the data directly into the constructor for each keyset object. Each object has a set of associated devices, a "threadableProtocol" object that is used to actually interact with the IR hardware, and finally a set of key assignments, each containing three pieces of data: the human-readable string (taken from the LIRC file), a mapping to a Pierogi button, and the actual code to be sent out in infrared. In this case, the Sony 12-bit code is composed of two pieces of data, a 5-bit address and a 7-bit command. (There are also 15-bit and 20-bit Sony codes.)

If you wanted to code this up yourself from an LIRC file, there are two problems -- one, LIRC doesn't know anything about Pierogi buttons, so you'd have to do that mapping yourself (not so hard), and two, LIRC doesn't know anything about Sony codes, so you'd have to convert their pulse counts into Sony format yourself (which might be harder for folks to do, if they're not handy with thinking in hexadecimal.) Originally, I was using the LIRC pulse counts directly, but it is just far easier (and more efficient) to calculate the pulses using the manufacturer's protocol instead.

But yeah, I do agree that there needs to be a better way to do this, other than just writing it all down directly in the code.

Well, drat. I'm not sure what to say about that... One thing I should ask: does your TV support "pairing"? I haven't added pairing support for Sony yet, so if you don't have the TV set up on the default pairing setting, this keyset won't work...

Hey, another keyset update working its way into extras_devel. This time, we have new keysets for Huawei, Onida, Vestel, Virgin Media, and Vizio. Also added a Sharp air conditioner keyset.

On that Pioneer Amp: I've got a file that purports to be the keys associated with the VSXD510, but they come out being the keys already associated with Pioneer Audio Keyset 3. I don't know why that keyset isn't working. It may be that my protocol code is just messed up somewhere. I'll have to keep digging on that one...

thank you, I am very pleased with the application

I think initializing every keyset as an object (that initializes several more in itself) might be the source of the memory hogging. If you place the keysets in separate files and let the app collect the filename list on startup, initializing only one generic keyset object and replacing it's routines and commands each time you choose another one, you are going to get rid of the memory problem and migrate to a config file architecture. Heck, if you load all the files in the memory as a binary data and initialize only one at a time, you are going to save more memory

About pairing, I have no idea what that is... It is an old CRT TV that I doubt is smarter than - receive IR commands, execute them...

Yes, you are absolutely right! That is exactly what is causing the memory issues.

Well, I was hoping to avoid putting so many files into the N900's file system. I thought it would be a pain to manage. But, as you say:

That is my current plan. I'm going to take all the keyset data out of the constructors and either (a) create a "factory class" that constructs keysets dynamically as required, or (b) set up a database to read in keyset info as needed. I had looked into sqlite when I started all this, but it seemed like overkill for my needs then; but it might make accessing the keyset data easier for users.

In any case, yes, that should ease the memory problems significantly.

Ah, I wouldn't put anything past Sony. They can create some amazing products. But yeah, I just looked up the RM-887 in Google, and it doesn't appear to support pairing... I'm not sure what is going wrong.

Why not use QSettings?

Great and well thought-through application Thanks for creating this!