Some more investigative work done.
Architecturally, the remote is actually three devices in one, a mouse, and two keyboard devices.
For reasons not really important, Gyration split the remote into a keyboard and mouse, both of which have event devices which emit HID packets.
The good news is, that ALL of these packets are completely decoded by the kernel in 0810. However, this is made less easy by the fact that I have to decode button presses from two different devices, and act upon them.
It's made even more interesting by the fact that X does not decode the resulting event Key messages. Why? is anyone's quess. So this means that the input device must be accessed directly, and the resulting Key messages need to be decoded.
So for this remote, we need two threads created which listen to the input device file, read from it, and queue up a key event inside orbiter for further processing.
This brings us to the second bit of this whole thing, now that we know we have to decode these event messages, can't we just make and ship a DCE device that sends DCE commands to the right places?
Not exactly, and that would be reinventing part of the wheel...
Because there isn't a direct correlation between all keys and DCE commands, or PK_Button symbols, there is no way to just make a DCE device that sends Simulate Keypress messages to the orbiter.
Why?
Well, the answer is a bit more complicated.
LinuxMCE deals with anything that has buttons that you use as a remote to an on-screen device, as an Infra Red remote. This is done so that the RemoteMapping table can be used to determine what commands to send depending on the screen that is currently visible.
There are rows for each screen type, and in each, a set of new line delimited lines, containing:
keysym1;keysym2|message to send
i.e.
tv;live_tv;LiveTV;|0 -106 1 43 29 1
you can refer to this mapping by tv, live_tv, or LiveTV, and when evoked, will send a message from device 0 to -106 (the media plugin), message type 1 which is command, 43 which is MH Start Media, 29 which is the command parameter for media type, and 1 which means media type 1, which is TV.
Basically, this is the same format as the last set of parameters as MessageSend.
why is this important?
When Orbiter starts, it looks for all children of the Orbiter that are of category Remote Controls. It will then grab two very important pieces of device data, Configuration, and Mapping.
Mapping, is basically just a simple way to re-map scan codes (which are normally X scan codes, but can contain synthetic scan codes injected into the event system too. we'll use this to deal with buttons that X doesn't deal with.), the Gyration Go Mouse template uses this to map the three grey buttons to key codes for F6, F7, and F8, and can be used for SIMPLE remapping of completely decodable buttons to other keys. I use this to map the green windows button to menu. Each entry is:
event type, event keycode=new event type, new event keycode
event types:
2 = key pressed
3 = key repeat
Configuration, is the more interesting one, and can be used to emit commands to the system based on key codes that are recognized.
It is organized as so, one per line:
RemoteMapping_Entry,x scancode,UDH,Y
the last parameter is optional.
The first bit is of course, the remote mapping entry to match, remember earlier?, the second bit is the scan code to match, the third bit corresponds to Up, Down, or Held-down states, and Y is an optional parameter, that if present, means that this mapping ONLY makes sense for screens that have yielded all input, such as when a DVD menu is displayed, or when MythTV is visible. These correspond to screen types that are labeled as "osd" in the description.
These two device data will be used to map our remote buttons, but this still begs the question, if X doesn't decode our buttons, how will they reach this point?
This is where our injecting synthetic events comes into play.
There is a method in Orbiter that injects events into Orbiter's event queue. One of those events registers key presses, along with up, down, hold states.
What we do, is take the HID codes emitted, and add 10000 to them, so we can distinguish them from the other scan codes.. so HID packet 401 becomes 10401.
We can then reference the button like so in Configuration:
Music,10401,U,Y
and we now have a mapping for the music button to go to the music screen.
I hope this is shedding a light for others as to the internals of supporting other types of remote controls.
-Thom
