digitalb0y

I do think a press of the select button being mapped to one thing (like say the enter key) and a press-and-hold being mapped to a different key (like say the C key for an XBMC context menu) is a fantastic idea. Very intuitive if you're used to touchscreen interfaces, and a good way to cram more functionality onto a remote with only 7 buttons. Obviously I have no idea what it would take to implement. Similar functionality on the direction buttons might be tricky, because as Chris! points out, the intended effect of the press-and-hold in a lot of situations involving mapping of arrow keys is specifically intended to keep sending the same key. Maybe if there were an option to record a secondary key for each button? One key for press, one key for hold. If the second one isn't set, it could default to keep pressing the key mapped to the first button press. If it stayed like that, people wouldn't even have to reconfigure their Flirc when the feature is introduced. Then there could be a single button added to the GUI for 'hold', and you click hold first and then second key you're trying to map, then press your remote button, and flirc gives that button the secondary function of pressing the second key instead of the first one? Form the command line, something life 'flirc record_hold C' and press select on the remote? Then you could do the same with the arrow buttons if you ant something like wbrinkman describes, and if you elect not to, flirc recognizes that there's no second function of your arrow button and only continues to send the original key when you hold the button? Again, I don't have any clue how hard this would be to implement or if my own comments are even helpful, but I agree it's a great idea.

Well, I'm just starting to learn Python, and I think this will make a great first project. Since there's an API and commands that can easily be scripted I think it's worth trying. I have negative free time so I don't promise any kind of timeline, or even that I'll be successful at all, but if I wind up with anything useful I'll absolutely share it.

Well, using Flirc fully configured on my Mac tonight, I can't reproduce the problem at all. It only seems to happen when I'm programming it, so perhaps it's some kind of UI bug related to my specific remote or something? I opened a text editor and every remote button sends the correct key press and never sticks. I think this is good news, as I actually prefer configuring the device from the command line anyway, and I'm pretty confident it's not doing something it's not supposed to on the Linux box as well. I'm sure my wake issues are just with Linux and my Zotac box. I have no idea why the Mac app sends it into a panic, but I don't think my Flirc itself is defective. Thanks for brainstorming with me!

Based on other forum posts, I was originally guessing my Macs aren't responding to the null message that is sent after a keypress but Linux is just handling that part better. The problem with that logic is that I can't figure out why it works for anyone with a Mac if it doesn't work on any of mine. Also, if I disconnect it when a button causes a stuck key, it's still stuck when I plug it back in. If it were an issue with the null message, I'd expect it not to start up with the stuck key again until I press another button. Two tests for tonight: I don't know for sure whether I have tested the problem after programming the device on the Linux system and then trying to use it on the Mac without ever needing to open the editor (i.e - is it only an issue while it's being programmed or does a properly programmed Flirc still send stuck keys on my Mac?) I haven't begun looking at the interkey_delay setting at all yet. I will play with that a bit as well.

My wife and I each have a MacBook Pro (one 2006 and one 2009) running Snow Leopard and I tested on 2011 MBP running Lion as well. I have the same "stuck key" results on all three, with no other peripheral hardware connected to them and a pretty standard setup. The Linux box is a Zotac Zbox running XBMCbuntu RC2. I haven't tried it with Linux on the Mac itself to see if it's hardware or software responding to whatever the Flirc is sending it, but either way it seems to follow the Flirc from one system to another. I'll bring it to work and try on a fresh OS X installation. I don't have anything set up to dual-boot currently, and even if I set up a VM on one of the Macs to run Linux, it's gonna be a Flirc, an Apple USB bus, and the VM host translating whatever the OS sees and sending it to Linux, so I'd expect it to be broken that way too. I wish I knew someone with another Flirc so I could see If that does it too. Honestly I may be able to live without ever connecting the Flirc to a Mac (although the GUI would be nice to use), but I'd really like to be able to figure out whether the wake from sleep problem on my Zbox is an Ubuntu or Flirc issue. I should have time to dig into some more troubleshooting tonight or tomorrow.

Flirc is such an awesome idea I'm personally glad you came up with it and that you entertain good ideas like the ones in this thread. It would be great if it became successful enough to become your only responsibility. FWIW, I completely second the desire for both a human readable/editable config file, and a tool that shows when a button is pressed, but clearly you see the value in this and probably don't need a bunch of extra clamoring for them in order to be convinced to try! :D

How tough would it be to write something similar to the Flirc GUI that could be run cross platform in a browser over an http port, the way you might control things like Sickbeard, SABnzbd+ or CouchPotato? Then even OSes without their own GUI could make use of a more graphical means of configuring Flirc. This would be great for people like me, who have a Flirc that decided it hates Mac and only wants to function properly from a Linux command line.

Thanks! So, assuming I'm happy to use just the left control key, to modify each of the three keys mentioned above, I'd do: flirc record_api 1 8 flirc record_api 1 16 flirc record_api 1 12 Is that right? EDIT: YES!!! Those three did the trick. Thanks for the HID list. The ones I was finding were not giving me the correct numbers.

Also, I'm sorry I've only posted about problems. I forgot to say what a fantastic idea Flirc is, and how well I think you present it. Even if it turns out that there is something wrong with my unit and we have to work something out, I think the work you're doing is fantastic and I'm really glad someone on the XBMC forums pointed it out to me.

Hi Jason, thanks for the response, I can try that. The problem is that I don't know what key would be a problem. There's no specific stuck key, it's alway just the last one I tried to map using the GUI. I only see this issue on my Macs, and it happens in the dark as well. I was able to program the entire remote using the command line Linux utility via ssh (in the same room with the same ambient lighting). It waited for me to press my remote buttons, and they all mapped accordingly. On the Macs, usually it doesn't wait for me to press a remote button at all, it just says that a key was already mapped. If I clear it and start over, I typically only get a couple of buttons in before one starts sticking again. On the XBMCbuntu box, the only thing not working is wake (which may be a problem with Ubuntu and not the Flirc) and the ctrl+i and ctrl+e mapping (which you addressed in another thread, and I will attempt to troubleshoot). Is there anything else you'd like me to try? And do you have a suggestion for which button to delete if all of them work on Linux and the one that sticks on Mac is not consistent?

This seems like the same issue I posted about in this thread: I got CTRL-E to map, but can't get CTRL+M working, and I don't even know what I'd do to map CTRL+I to work since the HID value for the i key contains a letter, which the Flirc command seems seems to ignore. Perhaps some keys just don't map correctly yet and a new firmware version could address it?

Hello, I waited a while to post this because I wanted to make sure it wasn't just an issue with one computer. My Flirc works as expected on my XBMCbuntu box, but on three different MacBook Pros, it sends stuck key presses, as if I'm holding down the last key I mapped. If I unplug it and plug it back in, or plug it in to a different USB port, the stuck presses continue right away, as soon as the Flirc is rcognized. It only stops when I clear the configuration or flash new firmware. I can sometimes map two or three keys before one gets stuck again, but that's it. I've tried the newest stable firmware and the newest beta firmware for long key presses, and the issue is the same on both. Not sure if this is related or not, but ever since I configured the XBMCbuntu box to wake up to keypresses from the Flirc, the box wakes up immediately every time I suspend it. Perhaps something is stuck on Linux too? It would be harder to tell if things are sticking during programming it using Linux, since I'm only doing that via SSH on one of my Macs, and would never see a key stick in my terminal window that way. XBMC doesn't seem to behave as if a key is stuck though. Is there something else I can try, or is there a chance my Flirc is defective? Thanks!

Okay, this is strange. I figured I could use 1, 16 or 17 for arg1 since my key commands should work with either the left (1) or right (16) control key, and the keys I'm trying to map are: ctrl+e ctrl+m ctrl+i Those shortcuts go to videos, music, and picture libraries, respectively, in XBMC. So I tried the following commands: flirc record_api 1 8 and flirc record_api 1 10 ...and I couldn't find a numerical HID value for i (the guide I was reading to find the other two values listed i as 0C which flirc didn't seem to like). The weird part is that the first command worked perfectly and the button I mapped now takes me to my video library, but when I press the button I mapped with the second command, it acts like I'm pressing m and not ctrl+m. I also tried putting in 16 and 17 for arg1 in both commands, and the results are the same. The ctrl+e command maps fine, but the ctrl+m just acts like I'm pressing m without the ctrl key. Any ideas what I'm doing wrong? And any tips on what value I should use for the i key?

Sorry, I think I just figured out the record_api stuff. As usual, reading more carefully before posting would have been good. :unsure: So if I wanted to map Ctrl+M I'd just do this? flirc record_api 1 10

Is there a way to program shift and control key commands from the linux command line utility? My Flirc always sends stuck keys to my Mac when I try to run the graphical Flirc.app to program it, but it works great on my XBMC box running XBMCbuntu, so I'd rather use that.

If you're just trying to skip to the next playlist item, use comma (,) and period (.)