2008-06-30, 15:59
Ok I already mentioned the problem with using translator for kemapping it's only other option is windows messaging which might be doable but would probably be more work that using the Remote Events code already built into XBMC linux and child ports.
My understanding of Remote Events however is quite limited from what i've gathered it seems that (please forgive my usage of the terms server and client as the method used for Remote Events seems a little unclear) XBMC acts as a client that allows a connection from a Remote Events server via a specified port over UDP at localhost or remotely from a seperate network location and accepts messages relayed form the Remote Events server, I don't know the structure of theses messages but they must be fairly simple looking at the config for Remote Events in XBMC as it allows for Repeat Press timings to be configured for buttons that remain held down. Therefore I'm assuming it probably contains nothing more than a notification the code X was recieved and if that continues at a high enough rate it's interpreted by XBMC as a held press. I don't know however if it's designed to accept any remote code or only the range used by the Xbox original remote ideally it can accept any remote code or easily be expanded on to do so.
Now my understanding of Input Service is that it functions as a Remote Code server which you connect to over TCP/IP on a specified port at local host or some other network location. Once connected to the server it sends remote codes as they are pressed to the remote client. In much the way I was guessing the Remote Events servers above work.
It seems to me that there are three possible solutions for a clean connection between the two either expand Remote Events to include the ability to connect to Input Service and utilise it's messages or create a bridge application that connects to both Input Service and Remote Events and relay the messages converting them from the Input Service format to the Remote Events format. Or lastly expand on the Translator code to send messages to Remote Events in a format that it accepts.
The first seems by far the cleanest but would result in a fair amount of specific code for the windows branch which you guys might be trying to avoid (I'm not sure), but would allow people to have only XBMC and Input Service installed an running. The second Requires writing and running a whole seperate app but would allow for people to run only Input Service and that specific app if they didn't want any unnecesary software running on the machine. The last is good as most People would probably already use Translator on the system if they had Input Service on it it requires no extra XBMC code, the code to recieve messages from Input Service is alread in place along with a good cofiguration front end, however you'd have to check and-81's license and possibly negotiate with him over whether it would be built into his releases or how distribution should/could be handled and all that other software politics.
That just about covers my knowledge and oppions on the matter. After the little bit of research I've done. Hope this helps.
My understanding of Remote Events however is quite limited from what i've gathered it seems that (please forgive my usage of the terms server and client as the method used for Remote Events seems a little unclear) XBMC acts as a client that allows a connection from a Remote Events server via a specified port over UDP at localhost or remotely from a seperate network location and accepts messages relayed form the Remote Events server, I don't know the structure of theses messages but they must be fairly simple looking at the config for Remote Events in XBMC as it allows for Repeat Press timings to be configured for buttons that remain held down. Therefore I'm assuming it probably contains nothing more than a notification the code X was recieved and if that continues at a high enough rate it's interpreted by XBMC as a held press. I don't know however if it's designed to accept any remote code or only the range used by the Xbox original remote ideally it can accept any remote code or easily be expanded on to do so.
Now my understanding of Input Service is that it functions as a Remote Code server which you connect to over TCP/IP on a specified port at local host or some other network location. Once connected to the server it sends remote codes as they are pressed to the remote client. In much the way I was guessing the Remote Events servers above work.
It seems to me that there are three possible solutions for a clean connection between the two either expand Remote Events to include the ability to connect to Input Service and utilise it's messages or create a bridge application that connects to both Input Service and Remote Events and relay the messages converting them from the Input Service format to the Remote Events format. Or lastly expand on the Translator code to send messages to Remote Events in a format that it accepts.
The first seems by far the cleanest but would result in a fair amount of specific code for the windows branch which you guys might be trying to avoid (I'm not sure), but would allow people to have only XBMC and Input Service installed an running. The second Requires writing and running a whole seperate app but would allow for people to run only Input Service and that specific app if they didn't want any unnecesary software running on the machine. The last is good as most People would probably already use Translator on the system if they had Input Service on it it requires no extra XBMC code, the code to recieve messages from Input Service is alread in place along with a good cofiguration front end, however you'd have to check and-81's license and possibly negotiate with him over whether it would be built into his releases or how distribution should/could be handled and all that other software politics.
That just about covers my knowledge and oppions on the matter. After the little bit of research I've done. Hope this helps.
