Hi - Newbie here.
I purchased a cheap Ebay MCE knockoff USB remote and connected it to my Ubuntu box and it magically worked. The computer sees the device as a keyboard and receives keys as though they were typed on a regular QWERTY keyboard.
Of course, the remote only sends a set of about 20 key combinations. From what I gather, I will be able to use JP1 to reproduce these keystrokes, but does anybody know if I can add to these existing keystrokes? That is, could I program the JP1 remote to send any keys from a QWERTY keyboard, and will the IR receiver receive them (I assume that the receiver is dumb and will send anything through to the computer).
Thanks.
Can MCE Codes be Extended?
Moderator: Moderators
Whether the receiver is "smart" (picky about the type of signal you send it) or simple (able to receive almost anything), it is certainly able to receive a lot more than 20 different signals.
In Linux, you can easily increase the number of signals the computer understands and you can define what each signal should mean to the OS.
In Linux, you can easily increase the number of signals the computer understands and you can define what each signal should mean to the OS.
Thanks, I'll jump into JP1 and give it a try.
The reason I ask is that there are a few keys on the existing remote that I don't want to remap in Linux, because they also get remapped on the real keyboard as well.
That is, most of the buttons on the remote generate keystrokes like ctrl-g or ctrl-f. It's fine fine remap those key-strokes as I never use those keystrokes on the real keyboard. But there are a couple of buttons that produce keystrokes like RETURN or DEL, which I do not want to remap in Linux.
With the JP1 remote, I'll be able to generate all kinds of crazy keystrokes that are never used on the real keyboard.
Should be fun.
The reason I ask is that there are a few keys on the existing remote that I don't want to remap in Linux, because they also get remapped on the real keyboard as well.
That is, most of the buttons on the remote generate keystrokes like ctrl-g or ctrl-f. It's fine fine remap those key-strokes as I never use those keystrokes on the real keyboard. But there are a couple of buttons that produce keystrokes like RETURN or DEL, which I do not want to remap in Linux.
With the JP1 remote, I'll be able to generate all kinds of crazy keystrokes that are never used on the real keyboard.
Should be fun.
Do you know what software is first in line receiving those signals in Linux? (It sounds like you have something different from the usual LIRC configuration). There is probably some way to configure the signals closer to where they are received to control which key each IR signal is translated to, or even to translate to more generic events.
You're right, it is not using LIRC. I actually wanted to stay away from LIRC as it seems a little too obscure, especially when it comes to finding hardware.
I thought I'd try the MCE remote route, by purchasing a cheap knockoff MCE remote from China. When the dongle is plugged into the USB port, linux recognizes it as an HID (human interface) keyboard. Actually, linux recognizes 2 devices, a keyboard and a mouse.
So when you push buttons on the remote, it is just like typing characters on a keyboard. Aside from this IR remote, I have also connected a wireless RF USB keyboard, and a wired PS2 keyboard to the machine. When you type on any one of those devices, the keys all go to the same place (ie - through the kernel and eventually to X windows). There's no way (of which I am aware) to distinguish where the keystrokes originated. In this case though, it is not really a problem as the keystrokes coming from the IR remote are unique enough that I can trap them. So, for example, the MUSIC button generates ctrl-m, which I trap and run the Rhythmbox music player.
I'm hoping that the JP1 remote will allow me to generate more unique key combinations so that I can do even more things from the remote.
Incidentally, I started out making a MythTV box, but I found the RF keyboard and IR remote so flexible, that I don't bother using Myth and just use the desktop. I now have no reason to ever leave the easy chair.
I thought I'd try the MCE remote route, by purchasing a cheap knockoff MCE remote from China. When the dongle is plugged into the USB port, linux recognizes it as an HID (human interface) keyboard. Actually, linux recognizes 2 devices, a keyboard and a mouse.
So when you push buttons on the remote, it is just like typing characters on a keyboard. Aside from this IR remote, I have also connected a wireless RF USB keyboard, and a wired PS2 keyboard to the machine. When you type on any one of those devices, the keys all go to the same place (ie - through the kernel and eventually to X windows). There's no way (of which I am aware) to distinguish where the keystrokes originated. In this case though, it is not really a problem as the keystrokes coming from the IR remote are unique enough that I can trap them. So, for example, the MUSIC button generates ctrl-m, which I trap and run the Rhythmbox music player.
I'm hoping that the JP1 remote will allow me to generate more unique key combinations so that I can do even more things from the remote.
Incidentally, I started out making a MythTV box, but I found the RF keyboard and IR remote so flexible, that I don't bother using Myth and just use the desktop. I now have no reason to ever leave the easy chair.
For my own new Linux system, I was starting to learn about keyboard input processing last night.
An actual keyboard sends "scancodes". IIUC, one bit is taken by press/release and one bit is given back by an optional prefix scancode. Nulls are reserved, so there are 254 possible scan codes, well more than enough for a real keyboard, but somewnat restricting for pumping IR signals through there as well.
Then there is a translation from scancode to keycode. Some scancodes don't translate and are lost unless you tell Linux to add new translations. The instructions for adding new translations all say to stay in the range 1 to 127 for keycodes. I tried, and outside that range new translations don't work. The predefined translations use most of 1 to 127 and a scattered few of 129 to 255. Those scattered few predefined translations work, but new ones in 129 to 255 don't.
IIUC, there is a different translation from scancode to X keycode (anyway X keycode is different from keycode) but all info I've seen about the translation to X keycode says it is automatic, but only occurs if a translation to keycode would have, and nothing tells you how to manage it, so you define a translation to keycode then discover the X keycode.
Then there is a (confusingly) documented translation to key symbols (things like your ctrl-g example). That translation combines a set of modes (things like whether ctrl is pressed) with the X keycodes to select from a vast number of key symbols. (Some of those key symbols then feed back to change the modes).
I don't know how your device fits in that scheme. The USB device probably sends scancodes to the Linux system. To get a key symbol such as ctrl-g, the USB device could send in an unusual scancode that translates to an unusual keycode that translates directly to the key symbol for ctrl-g. But more likely it sends in four separate scancodes with the standard values for:
ctrl press
g press
g release
ctrl release.
That USB device translates the IR signals into whatever it sends to Linux. I don't know how complex that translation is. Maybe it gets one signal from the remote that it translates in that sequence of four scan codes. But maybe it is a simpler translation, such as one IR signal per scancode, and the remote creates the complexity by sending four signals for one button press.
JP1 protocols that send compound signals like that are possible, and sometimes we've done then for simulation of IR keyboards, but that is a lot harder to set up than sending a single signal per button press. Hopefully you can understand the translation stages on the Linux side enough to get maximum control there and use simpler signals on the IR side. Simpler signals are also more responsive. A compound signal probably takes a tenth of a second per scancode. A complex translation of a single scancode in Linux may be just microseconds, while getting the same effect with multiple parts in an IR signal may take a big fraction of a second.
IIUC, LIRC goes through a very different and much more flexible path, so it has no need for compound IR signals. It never narrows the data flow down to something as limiting as scancodes, so it doesn't need to multiply a button press into a sequence to get it through a narrow interface (to translate it later back to a single wide symbol).
An actual keyboard sends "scancodes". IIUC, one bit is taken by press/release and one bit is given back by an optional prefix scancode. Nulls are reserved, so there are 254 possible scan codes, well more than enough for a real keyboard, but somewnat restricting for pumping IR signals through there as well.
Then there is a translation from scancode to keycode. Some scancodes don't translate and are lost unless you tell Linux to add new translations. The instructions for adding new translations all say to stay in the range 1 to 127 for keycodes. I tried, and outside that range new translations don't work. The predefined translations use most of 1 to 127 and a scattered few of 129 to 255. Those scattered few predefined translations work, but new ones in 129 to 255 don't.
IIUC, there is a different translation from scancode to X keycode (anyway X keycode is different from keycode) but all info I've seen about the translation to X keycode says it is automatic, but only occurs if a translation to keycode would have, and nothing tells you how to manage it, so you define a translation to keycode then discover the X keycode.
Then there is a (confusingly) documented translation to key symbols (things like your ctrl-g example). That translation combines a set of modes (things like whether ctrl is pressed) with the X keycodes to select from a vast number of key symbols. (Some of those key symbols then feed back to change the modes).
I don't know how your device fits in that scheme. The USB device probably sends scancodes to the Linux system. To get a key symbol such as ctrl-g, the USB device could send in an unusual scancode that translates to an unusual keycode that translates directly to the key symbol for ctrl-g. But more likely it sends in four separate scancodes with the standard values for:
ctrl press
g press
g release
ctrl release.
That USB device translates the IR signals into whatever it sends to Linux. I don't know how complex that translation is. Maybe it gets one signal from the remote that it translates in that sequence of four scan codes. But maybe it is a simpler translation, such as one IR signal per scancode, and the remote creates the complexity by sending four signals for one button press.
JP1 protocols that send compound signals like that are possible, and sometimes we've done then for simulation of IR keyboards, but that is a lot harder to set up than sending a single signal per button press. Hopefully you can understand the translation stages on the Linux side enough to get maximum control there and use simpler signals on the IR side. Simpler signals are also more responsive. A compound signal probably takes a tenth of a second per scancode. A complex translation of a single scancode in Linux may be just microseconds, while getting the same effect with multiple parts in an IR signal may take a big fraction of a second.
IIUC, LIRC goes through a very different and much more flexible path, so it has no need for compound IR signals. It never narrows the data flow down to something as limiting as scancodes, so it doesn't need to multiply a button press into a sequence to get it through a narrow interface (to translate it later back to a single wide symbol).
When I got the remote, I played around to see what it was sending.
I checked the events that it was sending to X, and it was as you described. For example, ctrl-g was produced just as if you typed it on a keyboard:
ctrl press
g press
ctrl release
g release
I even checked the scancodes and it was sending the same scancodes as the ps2 keyboard and the RF keyboard. They were indistinguishable.
BTW - after studying how linux handles the keyboard, I found it to be quite complicated for just a keyboard. Mind you, even with the complexity I was surprised how well linux handled the rf keyboard and ir remote right-out-of-the-box. All of the multimedia keys on the rf keyboard worked right away. Several of the ir remote controls worked right way such as volume, mute, the arrow keys and mouse controls. I was able to remap the rest of the buttons in X except for Enter and DEL. When I say remap, I really mean bind-them to a command.
I'm thinking that this IR remote and dongle are acting just like a typical wireless IR keyboard. If I were to, instead, purchase an IR keyboard, I know that the keyboard can send any key combination to the dongle. I could then throw away the keyboard and replace it with a JP1 remote. Hopefully, the dongle that comes with this IR is not limited to the keystrokes generated by this remote, but will rather accept a plethora of commands similar to those generated by a full keyboard.
Actually, right now it does everything I wanted it to do. I will try to see if it can do more though (plus I need to consolidate my remotes, so I might as well go with JP1).
If this dongle does not accept more commands, the other options for expanding IR commands would be:
-get a full IR wireless keyboard and throw away the keyboard
-go with LIRC
Yes, LIRC does offer more flexibility on the software end. I didn't dig too much into LIRC as I was scared off by the uniqueness of the hardware. I'm sure if I went down that path, I would soon be comfortable with it. The MCE route has one advantage where you can easily test your command/keystroke bindings from your keyboard. If you're happy with some of your bindings, you can use them as keyboard shortcuts as well. Of course my other motivations for the MCE route are that it is quick-n-dirty, and I'm cheap.
I checked the events that it was sending to X, and it was as you described. For example, ctrl-g was produced just as if you typed it on a keyboard:
ctrl press
g press
ctrl release
g release
I even checked the scancodes and it was sending the same scancodes as the ps2 keyboard and the RF keyboard. They were indistinguishable.
BTW - after studying how linux handles the keyboard, I found it to be quite complicated for just a keyboard. Mind you, even with the complexity I was surprised how well linux handled the rf keyboard and ir remote right-out-of-the-box. All of the multimedia keys on the rf keyboard worked right away. Several of the ir remote controls worked right way such as volume, mute, the arrow keys and mouse controls. I was able to remap the rest of the buttons in X except for Enter and DEL. When I say remap, I really mean bind-them to a command.
I'm thinking that this IR remote and dongle are acting just like a typical wireless IR keyboard. If I were to, instead, purchase an IR keyboard, I know that the keyboard can send any key combination to the dongle. I could then throw away the keyboard and replace it with a JP1 remote. Hopefully, the dongle that comes with this IR is not limited to the keystrokes generated by this remote, but will rather accept a plethora of commands similar to those generated by a full keyboard.
Actually, right now it does everything I wanted it to do. I will try to see if it can do more though (plus I need to consolidate my remotes, so I might as well go with JP1).
If this dongle does not accept more commands, the other options for expanding IR commands would be:
-get a full IR wireless keyboard and throw away the keyboard
-go with LIRC
Yes, LIRC does offer more flexibility on the software end. I didn't dig too much into LIRC as I was scared off by the uniqueness of the hardware. I'm sure if I went down that path, I would soon be comfortable with it. The MCE route has one advantage where you can easily test your command/keystroke bindings from your keyboard. If you're happy with some of your bindings, you can use them as keyboard shortcuts as well. Of course my other motivations for the MCE route are that it is quick-n-dirty, and I'm cheap.
Just an update...
I got the JP1 remote working and then tried sending all of the OBC codes to the dongle, and the dongle does indeed only recognize the codes that are on the original remote.
I have enough keys to do everything I need for now (media playing etc). For future expansion of functions, I'll try and present an on-screen menu where you can navigate to various functions. Probably the simplest way to do this is to present a file manager where you can use the arrow keys to navigate around and select files (icons) to perform various functions.
I got the JP1 remote working and then tried sending all of the OBC codes to the dongle, and the dongle does indeed only recognize the codes that are on the original remote.
I have enough keys to do everything I need for now (media playing etc). For future expansion of functions, I'll try and present an on-screen menu where you can navigate to various functions. Probably the simplest way to do this is to present a file manager where you can use the arrow keys to navigate around and select files (icons) to perform various functions.