SamyGO

Here are the libraries that I have used. I did some modifications to the irexec and irsend (the other didn't have option to set the socket path, so I added). All default paths point under /mtd_ram/... I didn't make them very consistent, better would have been to place them all directly under /mtd_ram instead of all kinds of subdirectories. You'll have to create the subdirs, or specify the socket, pid & logfile path on the command line.

Here is what I have used: (I have the iguanaIR device, so you can skip that part if you have some other device)
Also the modifications for irexec _might_ contain some extra quirks, like not calling system(), but send_packet directly, thus the lircrc should look like:
But there is also _irexec which does the other way, but I don't really remember now which does what. The errors will tell you

Is there any progress in subject? Can be mentioned solution "marked" as working?

Hello, yes I'm about to proceed, since there is now a way to call system commands from remote control button events (thanks to sbav1). The idea is to call volup.sh and voldown.sh, which do the actual sending. There might also be possibility to detect key down/hold/up events, so that the down event would produce send_start event, hold wouldn't do anything, and up would produce send_stop event (or what were the terms in lirc). This would hopefully speed things up a little bit.

Don't know when I have the opportunity to test this, but definitely I'm still actively working on this. Thanks for listening

Ok, glad to hear.
I was about to start writing some simple TCP server and try to send received input as RC keys but maybe I will save my time (ok ok, i'll give it today ).
I hope there will be simpler method than patching the SendKeyPress and changing keys when it is called (if I understand you correctly).. also be aware, that such application could disable another application (ie PVR) by "overpatching" SendKeyPress function..

If I understand correctly, you (nbd & doodlecz) have two different things in mind:

1. (nbd): extend fuctionality of existsing Samsung RC: be able to associate custom system commands / actions with particular keys, e.g. for controling external equipement (say HTPC or sound receiver) remotely with keypresses from samsung RC, or to remap functions/keys on Samsung remote.
2. (doodlecz): be able to control the TV from the network or from the shell (eg. to change channels or sources on TV, by sending commands over the network from some external program or device).

1) is now relativelly easy to do and allready more-or-less researched thanks to erdem, 2) may be not that easy.
Unless I'm very much mistaken, doodlecz is working on 2). I hope he will be able do this; such fuctionality, if possible, will be very much appreciated.

I did some preliminary attempts on 2) but with rather mixed luck so far.
The idea is to call KeyCommon::SendKeyPressInput() directly from additional thread (thread spawned from pvr_injection(), to get hold of 1st and 3rd argument). This thread is waiting/listening for keycodes on named pipe (I think TCP/IP socket will be much better for this purpose). It kinda works (eg. "echo 0x20 > /dtv/dtv/fifo-rc-receive.0" from command line does the job), but there is a problem (unexpected side effects). Orignal RC input gets blocked after sending keycode from command line. It's not blocked permanently (any further keypress seems to unblock remote input), but it looks like samsung procedures for handling RC commands are actually a little more bit complicated than I thought...

Sources attached, in hope they may be somehow usefull for doodlecz, as I'm out of ideas how to resolve this problem.

I have to admit, my idea is only theory right now. However I hope, it can work.
To my knowledge, KeyCommon::SendKeyPressInput is not the only function which should be called and in fact, my first try will be to call another function. I think the behaviour you explained is in fact visible within IDA..
Btw, in your source, I don't know if before calling KeyCommon::SendKeyPressInput, the R0 is set to instance of KeyCommon instance - it is not static method and IMO should be set. Is it somehow set by GCC or is it the 1st arg you mention? Sorry, don't know - learning ARM asm on the fly

Hello, actually the 2) should be doable if you have one of these IguanaIR devices that I have, with an IR emitter cable attached to it. Then you could set up a daemon to listen network socket (or something like that, no an expert on these) and then just use the Iguana device to send actual IR commands to the TV through the IR emitter. Not very elegant, but it is a working solution (until software solution is released).

And yes, I'm really pursuing the 1) which has its own thread.

If you like, you can try to check the first test version - it seems working for me (LE*B650T2W / T-CHL7DEUC 2005.0).
After execution of "remote" app, you should be able to connect via telnet to port 2345. Then you can write your favourite keycode in decimal and press enter. After this, the connection will be closed by server and keycode should be processed. Also you can close the server by entering "Q" char..
App does not use any injection. Feel free to modify anything.

doodlecz wrote:If you like, you can try to check the first test version - it seems working for me (LE*B650T2W / T-CHL7DEUC 2005.0).

Great work, thank you very much! It works flawlessly on my TV.
Now its' really elegant solution; also I think your nice clever object method call technique may have many more uses in the future

Thanks, I think this could be just a start and other features could be added to the server later..
- "plugins" or Game content execution on the TV
- remote recording (would be easy to input additional info like scheduling information or filename..)
etc.

However I'm sure, this would work and therefore it is not challenging very much - there is a lot of other "unfinished business" Also client app would be needed.