Categories

• Help and Support

  Get help and support from other RetroPie users

  19713
  Topics
  138542
  Posts

  

  I found a workaround that appears to be working. Since I don't think this is an uncommon combo with nespi 4 case and BT controllers I can maybe help someone else out. The issue with slow performance both with the SSD itself and interference with BT controllers disappeared when moving the USB controller for the SSD to from the USB 3.0 port to the USB 2.0 port instead and the connector for the front USB ports to USB 3.0 from USB 2.0. Even the long ES loading time is gone.
• General Discussion and Gaming

  General discussion relating to using RetroPie and gaming. Please do not use for help/support requests.

  MAME Random Of the Week
  2514
  Topics
  33625
  Posts

  

  I notice that when I connect to pi via web browser These get created $cat /proc/bus/input/devices I: Bus=0006 Vendor=046d Product=c31c Version=0001 N: Name="virtual-keyboard" P: Phys= S: Sysfs=/devices/virtual/input/input2 U: Uniq= H: Handlers=sysrq kbd event0 B: PROP=0 B: EV=3 B: KEY=1ffffff ffefffff ffffffff fffffffe I: Bus=0014 Vendor=0079 Product=0006 Version=0001 N: Name="virtual-joystick" P: Phys= S: Sysfs=/devices/virtual/input/input3 U: Uniq= H: Handlers=event1 js0 B: PROP=0 B: EV=b B: KEY=f 0 0 0 0 0 0 0 7fff0000 0 0 0 0 0 0 0 0 0 B: ABS=1b This leads me to think that connecting two gamepad to laptop and playing with them simultaneously (games like contra) may not be possible.
• Projects and Themes

  Show off your custom builds, themes, and splashscreens

  1597
  Topics
  31356
  Posts

  

  @Clyde you sure sent me down a rabbit hole here! :) It appears that when using latest stable mainline kernel 5.8.10 (as of 2020/09) it no longer gives out initramfs unpacking failed: Decoding failed error. So finding working kernel may be the path of least resistance here. Or spending ~1s longer booting when using gzip compression. That said, based on info in that Ubuntu bug report it looks like 'initramfs unpacking...' error is sent as KERN_CRIT (loglevel=2), so I thought I'll be done with it by simply dropping kernel loglevel to KERN_EMERG (loglevel=0). And sure enough, it's hidden, but after boot I thought I'll check that the error is still in kernel logs and that it got hidden and that loglevel got properly set: $ pi@retropie ~ $ dmesg | grep -i 'initramfs unpacking' [ 0.834312] Initramfs unpacking failed: Decoding failed pi@retropie ~ $ uname -a Linux retropie 5.7.19-050719-generic #202008270830 SMP Thu Aug 27 08:35:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux pi@retropie ~ $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.7.19-050719-generic root=UUID=639b8c73-24be-4c14-858b-4e4c017dcc8e ro loglevel=0 splash vt.global_cursor_default=0 vt.handoff=7 $ cat /proc/sys/kernel/printk 4 4 1 7 All as expected, except that kernel is now back to KERN_WARNING (loglevel=4). It turns out that modern Linux distributions set kernel log level during boot to distro specific defaults. In Ubuntu this is controlled by /etc/sysctl.d/10-console-messages.conf where kernel.printk = 4 4 1 7is set (on Raspberry OS / Raspbian these are /etc/sysctl.d/98-rpi.conf, kernel.printk = 3 4 1 3). In 'old' days, with pre-systemd Linuxes, which is when I looked at this direction last time, when you set loglevel boot parameter, that's what you had when the OS was up. So this was a bit confusing at first. This also lead me to look into boot parameters. As it turns out, quiet is actually a shorthand for loglevel=4 (KERN_WARNING). Both Ubuntu (source code) and Raspberry Pi documentation state this. Thus quiet and loglevel= should never be used at the same time to boot the kernel since one or the other will override the other. Also note that while Ubuntu defaults to 'quiet' (loglevel=4) log level after boot, Raspberry OS switches to loglevel=3 after boot (e.g. lower than quiet). So it looks like most documentation online is plain wrong or at least misleading regarding silently booting Linux and recommends mixed use of 'quiet' and 'loglevel' or does not account for the fact that quiet really means loglevel=4. Or mention that Linuxes will during boot switch to distro specific loglevels, which for example in case of Raspbian OS is more silent than 'quiet' boot parameter. Based on this, a couple of recommendations: Update RetroPie documentation to not recommend using quiet (loglevel=4), and only recommend to use loglevel=3 (which is also where RaspberryOS will switch after boot). And maybe link to RaspberryPi docs about 'quiet' as a reminder to avoid future confusion about the matter. Update Ubuntu setup script to use 'loglevel=0' instead of 'quiet' @MisterB to actually be silent Consider if for truly silent system, also /etc/sysctl.d/{10-console-messages|98-rpi}.conf' should be changed to set lower loglevels? Consider if loglevel=0 (or some other loglevel < 4) is a way to go all around? After all this is console loglevel, and everything will still get written to kernel logs if needed for debugging (regardless of the fact that messages to console would get suppressed). Personally for my RetroPie installation I am going with loglevel=0 for both boot and post-boot (I set /etc/sysctl.d/{10-console-messages|98-rpi}.conf to kernel.printk = 0 4 0 7). That said, I don't think I've fully thought out what negative impacts this might have so I have some hesitation to yet recommend this as a go-to tactic to silence the system. Or if the kernel.printk should be set to e.g. '0 4 8 7' instead - especially I am not confident about 3rd parameter (minimum_console_loglevel) and what it really does, or even if loglevel=0 is really valid, and I'm not ready to read the kernel source yet. Food for thought though. Fun times. edit: added link to /proc/sys/kernel/printk documentation.
• Ideas and Development

  Share your ideas and suggestions for RetroPie. You can also use this area for development discussion.

  1325
  Topics
  27402
  Posts

  

  true but some people don't know how to create a .sh as I've said I don't know how this should be in implemented but it would be nice to be able to see your achievements when you're hovering over the game in ES
• ControlBlock, PowerBlock & Co.

  Get help and support for PetRockBlock's hardware

  312
  Topics
  2031
  Posts

  

  Can you show an image of your hardware setup? Instead of using a switch you could try and only short-circuit the switch pins on the PowerBlock with, e.g., a jumper. That should turn in the Pi. Does that change anything?
• Announcements

  Announcements regarding our community
  29
  Topics
  37
  Posts

  

  Hey all, We started our documentation using the Retropie-Setup GitHub Wiki. Once it got large enough we used the wiki as a source for generating a prettier mkdocs based documentation with the material theme it worked well in that the community could still contribute to the wiki but the docs also looked better, unfortunately there were also some issues, one major issue being that if any of the page names were changed it would break all the documentation. We also had some spam. As a result we have deprecated the GitHub wiki in favour of a standalone documentation repository found here: https://github.com/RetroPie/RetroPie-Docs The community can still contribute but will need to submit pull requests to the repository. This allows for contributions to be vetted and makes the docs more stable. I know it will probably break some links on multiple sites but it makes sense to have the docs consolidated in one place rather than having duplication, and the SEO will update itself soon enough. Thanks for all the contributions thus far, I am pretty pleased with our project's documentation and it is a big reason why it's the most popular pi based gaming project. As this is mostly a backend change the public facing documentation will still show up here: https://retropie.org.uk/docs/