USB IR device

[nbd]

Yes, I got it working now. The Iguana IR device is fully functional, running on the TV. Also Lirc works just fine, didn't even need any kernel modules (nor did the Iguana IR device). This is just awesome! Lirc support without any kernel modifications whatsoever..

Imagine the possibilities, you can execute whatever scripts/programs you wish just using any remote control supported by lirc. Perhaps this is the key to PVR, since there is no need to inject the REC/STOP button codes to exeDSP, we can just launch our own PVR soft from those keys. Also if we find a way to display those on-screen thingies, we will be able to create menu based programs, controlled by the TV's remote (the up/down/right/left/enter comes to mind, those are not doing anything special while TV is in the "default" mode).

Soon my telnet enabling is going to be just one button. The hardest part is to decide whether I should use the red or the blue button?

PS. I did some minor modifications to the iguana driver and some of the needed libraries (popt,libusb-1.0,lirc) in order to get them to compile/work. If you are planning to get one of those Iguana IR devices, I can share the details. Or maybe the libraries/binaries could be added to the SamyGO FW patch.

My next step is to do the "External speaker volume control with TV's remote" thing I was planning.

[erdem_ua]

I am watching you

[nbd]

Initial 'proof of concept' test was successfull.

I used the irexec to 'listen' Vol+/- commands from Samsung remote and to send amplifier's Vol+/- by executing irsend.

It works, but it's slow and does not react to keeping the button down. I'll have to write my own client, which combines the irexec/irsend functionality to one executable.

[nbd]

Some update on this, the device is not truly full duplex, sending is in higher priority than receiving, and while it sends it cannot receive signals. This introduces some minor issues, like not reacting very rapidly to holding button down, since I'm sending the commands out as they arrive and this interrupts the receiving. Of course I could get another device and use the other for receiving and the other for sending.

But I'm thinking of another approach; using the TV's IR receiver for receiving and the usb device for sending.

I was looking at the PVR code, and there was injection code for keypress. Isn't it then possible to come up with a way to pass those keypresses to some external program? Don't know yet what would be the best way, using sockets maybe, or system(3) or something else. But it seems possible.

If I modify the PVR code a bit, throw away the Stream_Record stuff and use only the SendKeyPressInput. At first I was thinking just dumping the received key codes to /mtd_ram to see what keys correspond to what code (or is this info already available?)

[nbd]

Ok, now I managed to write Vol+ to a file, by adding this to the pvr.c:

Code: Select all

if(key==0x07) //Vol+
{
	char* filename = "/dtv/usb/sda/volup";
	FILE *file = fopen(filename,"a");
	fputs("Vol+\n",file);
	fclose(file);
}

and it works and does not crash and the volume changes also on TV, so it is returning to the original function.

First of course I did a KeyDump program that dumps the pressed key to a file under /dtv/usb/sda (it coredumped after first keypress, but it wrote the keypress to the file and I got it out). I'm suspecting that fprintf does not work, but fputs does. Mainly the only difference between my KeyDump and this Vol+ code was the fprintf vs fputs

[nbd]

Hello, where could I find more information about how to deal with these injections? I tried to add more code (more ifs for detecting key codes), but it halted the TV. Is there some size limit, or what?

Also I couldn't get this to work either (this code was between the asm volatile instructions in pvr.c):

Code: Select all

        char *filename = "/dtv/usb/sda/keycodes";
        FILE *file = fopen(filename,"a");
        //FILE *file = fopen("/dev/kmsg","a");
        if( file )
          {
            fprintf(file,"%d\n",key);
            //fputc(key,file);
            //fputs("\n",file);
            fclose(file);
          }

I tried all the combinations with kmsg and fputc that are in comments, but no success. I have to admit I don't know much about the magic the loader.c does. Is there something that affects how this code behaves?

[erdem_ua]

Hi,
I write the non working PVR thing.
I don't add support for calling external libs. If you change code than there is initialization commands are changing by gcc. So you needed to tune code by hand.
For example calling a function from program requires global symbol table, that loads at R4 generally, so that corrupts registers. I think this kills the your program.
Please use IDA for inspect generated .so files.
You can locate the changes and add/remove some ASM lines at file.
If you send your source and so file here, I can also debug it. Thanks.

[nbd]

Hello. Here is one attempt to create a KeyDump program. Thanks for helping out!

[nbd]

Actually the best way to handle keypresses, is to use system(3) call to execute a script and pass the key as argument. Then it could be easily customized without rebuilding.

Something like:

Code: Select all

char command[40];
sprintf(command,"/mtd_ram/keypress.sh %d &",key);
system(command);

I'm not sure is the & needed, the system(3) already does a fork to execute the command. So system(command) should return immediately.

[erdem_ua]

Not the best one. Might be useful for executing external application (like your one ) but does not help other extensions that relays addition as dynamic library way.
Anyway, I don't inspect code or dump. Needed to re-compile toolchain and trunk looks like broken.
Also have a some homework needed to completed until Monday. Sill look this progie later. Thanks.