Jump to content
Flirc Forums

digitalb0y

Moderators
  • Posts

    143
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by digitalb0y

  1. 1) On my to-do list is to research the various solutions and factors that affect scrolling so we can come up with solutions for each platform (as it is more of a platform thing than a Flirc thing). It would be the cherry on top of the very delicious Flirc cake.

    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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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:

    1. Log on to Windows 8 computer on which installation of unsigned drivers is to be managed.
    2. 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.
    3. From the context menu click Run as administrator and on the appeared User Account Control confirmation box click Yes to allow.
    4. On the opened elevated command prompt type
      BCDEDIT –Set LoadOptions DDISABLE_INTEGRITY_CHECKS
      and press enter key.
    5. Once the command successfully completes type
      BCDEDIT –Set TESTSIGNING ON
      Manage-Driver-Signing-300x150.jpg
    6. 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.

    7. Restart the computer to allow the changes to take effect.

    taken from here: http://www.advicehow...soft-windows-8/

  7. 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.

  8. 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.

  9. First we need to enable wakeup on the USB bus to which your Flirc is connected.

    1. 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    
      
      	
    2. You'll need to be root for the next part, so:
      sudo su
    3. 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.
    4. Suspend the system, and see if you can wake it up with your remote.
    5. 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:
    1. leave root:
      exit
    2. edit the file:
      sudo nano /etc/rc.local
    3. 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	
      
      
      	
    4. Save the file (Ctrl+X to save and exit, Y for yes, Enter to confirm the file name is the same).
    5. 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:

  10. I'm eager to try out XBMCbuntu to see if I can get the smoothest experience possible.

    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.

    Is it possible to suspend/wake XBMCbuntu right now with flirc, or is it best to wait until the firmware supports it?

    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.

  11. 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.

  12. 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.

  13. 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.

  14. 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.

  15. 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.

  16. 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.

×
×
  • Create New...