dihu

I would support such an emitter for a different reason. Most equipment in the home media area (like amplifier, TV, etc.) offer no control interface other than IR. So there is no way to switch an amplifier on or select the input channel for audio other than by IR. Having such an emitter at hand multimedia software like XBMC could control also the hardware.

sorry for the delay in responding, I was busy the last days. You cannot press left-alt + s on this remote because left-alt is a key like any other key and produces a signal by itself! So pressing left alt + s is as useful as pressing, say a + s. Because you cannot press buttons in parallel, you are left with 28 + 17 + "modifier keys" buttons. The only solution to that is to simulate modifier keys on the receiver site, i.e. keeping in the receiver an internal state which modifier keys have been previously pressed on the remote. The remote operates similar to pocket calculators where you have to press a yelllow button first to enable the functions printed in yellow on the keyboard. The same happens here. In the original application you press left-alt first and s second and the application decodes this sequence to left-alt + s.

sure, I can map ctrl+shift+a to a button. The simple point is that adding a modifier key like shift I obtain 2*n different codes (if n was the number of previously available codes). Using your approach I'm stuck with n+1 different codes. That makes a slight diffference if you want to restrict the number of buttons on your remote ;-) Anyway, I can cope with this deficiency by writing a small program catching all the events from Flirc and implementing the required finite automaton.

let's make an example: the actual behaviour is: Remote --> Flirc ---> OS 1. CTRL some key 2. SHIFT some other key 3. A A the desired behaviour of Flirc should be: Remote --> Flirc ---> OS 1. CTRL 2. SHIFT 3. A CTRL-SHIFT-A you see the difference? Wether pressing "A" on the remote causes Flirc to send an "A", "SHIFT-A", "CTRL-SHIFT-A", etc. depends on the history of previous keystrokes on the remote. The modifier keys sent from the remote to Flirc should determine which of the various alternatives for the next "regular" keystroke is chosen. PS. it is this remote.

Hi Chris, thanks for the response. Just to make sure: my remote will send three signals (one after the other) CRTL, SHIFT and A. Flirc would have to use the modiifier keys to change it's internal state. Seeing the "regular" key "A" would cause Flirc to send the combined key CRTL-SHIFT-A and presumably reset its internal state. Actually, I don't have a particular application in mind but I like the alphanumeric remote e.g. to navigate in my MP3 collection. Cheers dihu

Hi, I like to use an alphanumeric remote control (shipped with an old Archos 605) with Flirc but run into problems with keys like shift or alt. Flirc assumes that, for instance, CTRL-SHIFT-A is a single keystroke on the remote but this remote has separate keys for CTRL, SHIFT, ALT-L, ALT-R. In contrast to a standard keyboard pushing one of these keys sends a signal by its one. So CTRL-SHIFT-A becomes a sequence (!) of three keystrokes rather than a single one. In order to process this sequence correctly, Flirc would have to store the keystrokes of these buttons internally to change the coding of the next "regular" keystroke (i.e. the "A"). Is that possible?