digitalb0y

I've seen this response a lot on these forums, but I can tell you that rapid button presses on the newer Flirc betas does not perform the same way that holding a key on a physical keyboard does. With a keyboard, no matter how rapidly I repeat a key, XBMC moves to highlight the item that many steps away. If I press and hold a keyboard key, it stops moving as soon as I release the key. In contrast, pressing the same button on my remote two or three times, or holding a button down both result in the menu speeding by way to too quickly to use, for a seemingly random number of list steps.

Yes, if everything you're trying to do is within XBMC, it's actually not difficult to edit keyboard.xml to make the same buttons do different things depending on what you're doing in XBMC. There's also a remote section of that file, and people have posted some great mods for that section so that a remote with few buttons (like say an Apple remote) can have more utility on various XBMC screens.

First, go to Settings > System > Power Saving (I think, I'm going from memory here) and make your shutdown action 'Suspend.' Then on most skins you can add shutdown to your home menu (if it's not already there) or press 'S' for the shutdown menu, as Chris! mentioned. If you have wake on device setup properly, any button should wake your Zbox, though it sometimes takes a while.

Yeah, I use S on my power button. With most skins that makes it necessary to press a couple more buttons to actually shut down, but it also gives you a quick path to your settings or whatever else your skin has built into the shutdown menu.

That's an awesome idea!

Modifying keyboard.xml also keeps you from being able to enter a numeric passcode, although that probably isn't much of an issue to those without kids and/or lots of users. For me the best combination is to set as many of the things I enter frequently to numbers as possible, and keep a bluetooth keyboard handy for the rare times I'm doing things that require a bunch of typing. I really like the JumpSMS idea but in practice I don't know if it's much more convenient than navigating an onscreen keyboard with the arrow keys from time to time. If something I need to type is really so long that I don't want to do it that way, I think using the number keys with multiple presses (SMS style) is still a bigger pain than just picking up a qwerty keyboard. Don't get me wrong, I'm totally for flexibility and for being able to set your box up the way YOU want it. I'm just saying that for me, the only way I could make things more convenient would be with a qwerty keyboard on the back of my remote, like the Boxee remote has. I don't find myself reaching for the bluetooth keyboard often enough to spend a lot of time making something like JumpSMS work. That's totally just me though.

Glad you got the drivers installed! Weird that XBMC would have issues with it though, can you put an XBMC crash log on pastebin?

Give this a shot: How to Enable or Disable Installation of Unsigned Drivers? Administrators must follow the steps below in order to enable or disable installation of unsigned drivers: Log on to Windows 8 computer on which installation of unsigned drivers is to be managed. Assuming that classic start menu has been enabled, go to Start > All Programs > Accessories and from the available list of applications right click Command Prompt. From the context menu click Run as administrator and on the appeared User Account Control confirmation box click Yes to allow. On the opened elevated command prompt type BCDEDIT –Set LoadOptions DDISABLE_INTEGRITY_CHECKS and press enter key. Once the command successfully completes type BCDEDIT –Set TESTSIGNING ON In order to revert the changes back to their normal state repeat steps 4 and 5 but with the commands: BCDEDIT –Set LoadOptions DDISABLE_INTEGRITY_CHECKS and BCDEDIT –Set TESTSIGNING ON respectively. Restart the computer to allow the changes to take effect. taken from here: http://www.advicehow...soft-windows-8/

Sure thing, thanks for your patience. Here's what I've put together so far:

Also, what do you see when you try the following command? cat /proc/acpi/wakeup I finally got a little bit of a guide started: See if it's enough to get you started. If not, post the output of that command here and we can start troubleshooting from there.

One more quick note: even following the extra steps in the XBMC wiki to modify the grub file, I was getting immediate wakeups using Flirc firmware fw_wake_v6. Going back to Firmware 1.0 fixes this. It takes away the ability to use a mapped 'wake' button, but firmware 1.0 using the steps above *should* yield an Ubuntu system that wakes from suspend using any remote button that's programmed in your Flirc config.

First we need to enable wakeup on the USB bus to which your Flirc is connected. Determine which USB buses (if any) already have wakeup enabled: cat /proc/acpi/wakeup On my system, here's the result: $ cat /proc/acpi/wakeup Device S-state Status Sysfs node P0P1 S4 *disabled pci:0000:00:1e.0 P0P4 S4 *disabled pci:0000:00:1c.0 P0P5 S4 *disabled pci:0000:00:1c.1 P0P6 S4 *disabled pci:0000:00:1c.2 P0P7 S4 *disabled P0P8 S4 *disabled P0P9 S4 *disabled USB0 S3 *disabled pci:0000:00:1d.0 USB1 S3 *disabled pci:0000:00:1d.1 USB2 S3 *disabled pci:0000:00:1d.2 USB3 S3 *disabled pci:0000:00:1d.3 EUSB S3 *disabled pci:0000:00:1d.7 You'll need to be root for the next part, so: sudo su You need to determine which of those USB buses (the ones with USBX in the first column) is the one your Flirc is plugged into. Starting with the first bus in the list above, run: echo USB0 > /proc/acpi/wakeup If you run the command from step 1 again, the USB0 line should say enabled instead of disabled. Suspend the system, and see if you can wake it up with your remote. If the machine won't wake with your remote, wake it with the power button or over LAN and repeat step three using USB1 in place of USB0, then repeat step 4. Keep going until you find the bus to which your Flirc is attached. Once you've found the bus the Flirc is on, it will keep working until you reboot the machine, unless you add the command to enable it to rc.local. To do so:leave root: exit edit the file: sudo nano /etc/rc.local Add this to the file below the comments and above the exit line: sh -c 'echo "USB0"' > /proc/acpi/wakeup echo "rc.local has completed sucessfully." >> /tmp/resume.log Note: this assumes USB0 is the bus that worked in the top section. If yours worked on a different bus, change the number in this step accordingly. Here's an example of what the file might look like: #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. sh -c 'echo "USB0"' > /proc/acpi/wakeup echo "rc.local has completed sucessfully." >> /tmp/resume.log exit 0 Save the file (Ctrl+X to save and exit, Y for yes, Enter to confirm the file name is the same). Reboot. If all went well, you should be able to wake your machine from sleep using your Flirc. Note: if you want to eliminate the guess work in the top section and don't have a lot of USB devices that might interfere, you can just enable them all in rc.local. I've seen an Ubuntu forum poster say his rc.local file looks like this: sh -c 'echo "USB4" > /proc/acpi/wakeup' sh -c 'echo "USB3" > /proc/acpi/wakeup' sh -c 'echo "USB2" > /proc/acpi/wakeup' sh -c 'echo "USB1" > /proc/acpi/wakeup' sh -c 'echo "USB0" > /proc/acpi/wakeup' exit 0 There's also some steps you can take specifically if you're running XBMC and the machine wakes immediately when you put it to sleep. There's lots of good troubleshooting info and more to read at: http://wiki.xbmc.org/index.php?title=Enable_Wake-On-Device http://wiki.xbmc.org/index.php?title=HOW-TO:Suspend_and_wake_in_Ubuntu#Remote_Suspend_.2F_Wake

I'm not going to lie, it took me some time to set some things with XBMCbuntu as well. For example, 5.1 sound over HDMI was a bit of a challenge. Then I had to manually configure Wake on LAN (in BIOS), wake on device (instrux coming shortly), bluetooth pairing for my keyboard and trackpad so I can use a web browser when I want to launch one, etc. You can really get sucked into tweaking a system like this for a long time. But in general, there's a lot more Ubuntu left in XBMCbuntu than there is in OpenELEC, so as long as your system is decent I think your logic here is sound. My system is extremely flexible and is still nice and quick. The only advantage I can see for OpenELEC is that it is probably faster on older hardware, but XBMCbuntu really is a great balance of Ubuntu goodies and streamlined, minimal approach. On Linux I have trouble with the beta Flirc firmwares that include support for the wake command, but I don't really need them either. Firmware 1.0 doesn't interfere with the suspend command, so I configure the wake on device using a handful of commands on the Linux box, and then ANY mapped button on my remote will wake the XBMCbuntu box, as it's basically setup as if I want to be able to press any keyboard key to wake it up. The upside of firmware 1.0 is that it's nice and stable. The downsides are that I can't make it so that only a single button mapped to 'wake' will wake it up, and it takes a little longer to respond to the other buttons with firmware 1.0 than it did using the wake command and one of the beta fw_wake firmware versions. Jason's working on better implementations of wake for Linux, but you don't have to wait for newer firmware to start playing.

Welcome to the Flirc forums! See my response to your post on the XBMC forums. Basically if you want to use IR to wake a motherboard that doesn't powering up on USB, use suspend or hibernate. If you're okay with using an Android app or another computer wake your XBMC box over LAN, you can use complete shutdowns. You don't need a delay like you have with EventGhost because XBMCbuntu/OpenELEC will start XBMC after everything it depends on has already started for the most part, and it's okay to just suspend instead of full shutdown because there are tools for automatically updating the library and Linux suspends/wakes on USB very cleanly. I promised a crash course on setting up wake-on-device on Ubuntu a while back but was waiting on a replacement unit from Jason and some additional tests. Now that it's working consistently I'll try and put that together tonight or tomorrow. There are good guides on the topic in the XBMC wiki as well.

http://www.ebay.com/itm/2-USB-3-0-A-Female-Ports-to-MotherBoard-20-Pin-Head-Adapter-Convert-Cable-20cm-/110798108946?pt=LH_DefaultDomain_0&hash=item19cc14f912#ht_2892wt_1180 http://www.frozencpu.com/products/7318/cpa-239/Lian_Li_525_Mesh_Bay_Cover_w_Filter_-_Silver.html?tl=g1c143&id=46Sexgmv http://www.ebay.com/itm/Any-Color-Electrical-Tape-choose-your-color-/130553061942?pt=LH_DefaultDomain_0&var=&hash=item1e6591a236#ht_500wt_1180 :D

I hate to recommend additional hardware too, as part of the Flirc allure is that it works with any remote that sends a standard IR signal, and any computer that works with standard USB keyboards, but in this case I have to agree with SirDrexl. I have a Samsung TV and remote, but the remote is far too limiting to suit me as I need a lot more control than the remote itself allows. If you do decide to replace it, I've seen decent multi-unit universal remotes starting below $20. I think I spent about $45 on mine (URC-RF20). One feature I like most is that it gives me an indicator on its lcd screen when it's sending IR signal, so when I choose a hardware profile that has inactive buttons, it's obvious the second I press one of them. Something like that or a Logitech Harmony are ideal for multi-device control, and they can be programmed as generically as the Flirc can, so you can wind up with complete control and flexibility for a relatively small additional investment.

I don't know what thread I was reading that made me think there was an API when I posted this originally. I patiently await the arrival of such a thing. :-D

Perhaps this will help for size perspective. The unit is resting on the lip of the can: And this one is the best I could do to show you what the raised logo looks like:

Well, I was all set to write such a thing, but I'm still having trouble with wake using Flirc with XBMCbuntu. I got suspend working correctly from the command line and I can wake it by enabling wakeup on the proper USB bus, but whenever I plug a Flirc into a port on that bus, the machine wakes immediately after I suspend it. Jason is working on another approach for sleep/wake on Linux machines, so as soon as a version of Flirc firware is available that behaves as expected, I'll document everything I've tried so far.

That's an interesting idea. The Flirc (not counting the metal part that goes into the USB port) is about 1" x 3/4". One side is completely smooth, the other side has a raised Flirc logo that takes up about half the surface. Each side is slightly convex, so that's something to consider. Double sided tape should stick to it just fine, and I think it's big enough for what you're describing, but the outside sticky surface won't be completely flat.

The Flirc is going to show up as a generic USB keyboard, so hardware compatibility won't be an issue. That means that once you have a Flirc that's programmed to interpret your remote's buttons, your remote will send keystrokes to your computer (regardless of the platform). But like Chris!, I don't know if the software for programming the device is compatible with Win8. I think the only person who can answer that is probably Jason, unless another user has already tried it and can report their findings here.

Just saw that in the RSS feed on the home page of my XBMC box! So cool! That's gonna be at the top of tons of screens for many months! Congrats! Nice writeup, too, Chris!

I could put together a similar guide for Linux users if there's demand for such a thing...

Yeah, now that Jason got me all schooled on how to record modifier keys properly from the CLI, I'm quite sure this is not the same issue. Especially since rgm probably used the GUI to record the button and wouldn't have introduced the dumb user error factor that I did. The more I play with the Flirc, the more I realize the quirks are not due to a mistake in what the Flirc receives or outputs, but most likely an issue with the software receiving the keystrokes. As rgm noted, his is correctly sending ctrl+F, as it executes the find function in Wordpad. In my case what was baffling me was the strange coincidence that I was trying to map ctrl+M, but erroneously used a command that probably mapped it to ctrl+G, and XBMC reacted to the button same way it would to an M, so it made me think it had mapped incorrectly or was not receiving/sending correct signals. I know I'm not a dev or moderator, but FWIW I second Chris!'s suggestion to see if WMC responds properly to ctrl+F from a standard USB keyboard. The other thing I thought it might make sense to try is testing more alternative Harmony profiles, but it sounds like you were already on that path. Since some Harmony profiles seem to result in different results regarding the way that press-and-hold is interpreted and translated by Flirc, it seems plausible to me that a slight difference is possible in this case too, and maybe WMC just doesn't like the slight difference in the way the keystroke is received.

That's also very cool, I hadn't read that part of the site I guess! I have to say, I'm really happy to have found you guys.