Posts made by betlog-betlog

I get the feeling most questions would be more likely to get answered if we asked them in the relevant core's forum, or emulationstation forum, etc.

To be clear: The stick IS operating as analog. But the zone of movement where it is analog is very small, kicks in at a relatively high value (presumably at least 4096,4096), and reached 100% input almost immediately with only a very small movement. There is a large area towards the outside of the movement circle, seems like more than half of it, where all movement is at 100% despite not being anywhere near the physical limit of the stick movement. black=no effect grey= effect, engages suddenly at high value, and quickly reaches 100% with very little movement. white=100% effect, reaches 100% well before stick physically reaches edge of range. ^^^ bad ^^^ Modern controller sticks self-centre, so a huge analog deadzone is redundant, and suddenly outputting 100% effect when it's nowhere near 100% of it's physical movement range.. is very tedious.

Got up this morning and turned Pi on. No bluetooth connection. Tried unplugging/replugging dongle(s). Total failure. So I set max_usb_current=0 and rebooted. Immediately it worked. Very strange, considering it worked fine the night before and now suddenly didnt work at all after a night powered down. Is it possible that the Pi is drawing current from the HDMI cable even when the Pi itself is off? The only difference between working (last night) and not working (today) was that overnight I physically remove power from my tv via a switch on a powerboard...that the Pi is also powered from. However while testing I generally only unplug the Pi, and do not kill power to the TV as well. Weird. In any case it's back to the usual: working on one dongle just fine across reboots, but not after powerdown/power disconnections. Re-plugging the dongle is still the 'easy' fix.

Like this? Yes?

Anything that uses the analog joystick. It's most annoying in flight sims like Ace Combat (PSX) There is such a huge dead spot that by the time the joystick takes effect it's already a strong response... so it almost may as well be digital on/off. It defeats the purpose of having analog.

I got the impression that mupen64 was for N64 games only....yes? In any case, the variables that I want to alter never actually stays changed after I set it, so I'm finding it difficult to even learn by trial and error. ie: input_axis_threshold in retroarch and AnalogDeadzone in mupen64 But I only made the original post in case it was a bug.

Not lag. Joystick deadzone.

I assumed it would be useful. I'm a noob with the whole emulation thing, and was attempting to come to grips with adjusting controller settings.

re: input_axis_threshold = "0.500000" Does setting this variable have any relevance if the stick is in analog mode? Is it possible to change this value and have it STAY set? Despite changing it in every config I can find, it still resets to 0.5 I am attempting to make my analog sticks more sensitive, and because there appears to be no way to reduce/remove the massive deadzone (which would be ideal) I was experimenting with input_axis_threshold. Presumably by setting it to 1.000000 I will enable the full range of the stick. Right now, between the deadzone which seems to eat the first 20% of movement, and the stick feeling like it achieves maximum signal at about 50% of it's movement... it is extremely difficult to control games like 'Ace Combat 3 - Electrosphere' with any degree of finesse. TL;DR: Reduce PS3controller analog stick deadzone, and increase range of stick movement before 100% signal.

re: CRT only. Right. So then faux-lightguns.... Is the use of mouse and wii controller likely to be included soon?

Minor update: Increased current to USB seems to make no difference. So far. Powering off just now with two dongles attached failed to reconnect on reboot. One dongle was clearly attempting connection, and (as usual) looked to have succeeded and be actively communicating, but ps3 controller didnt rumble or stop blinking. Rather it eventually timed out and powered off. I removed the dongle that appeared to be connecting, and pressed the ps3 button again. Immediate successful connection to the other dongle that was still plugged in. There's something strange going on with the edge condition of physically plugging and unplugging dongles.

light guns.... A few roms look like they would be ideal for a light gun. But are there any that are useful with a pi/recalbox setup?

Also of note, and I think very handy: When using two dongles, a successful pi poweroff state causes the ps3 controller to rumble briefly. Possibly because it's being actually signaled to turn off... but I didn't check it's lights so I'm not sure of that last part.

Received 4 of these today http://www.ebay.com/itm/401090361856?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT I then systematically inserted them one at a time, and using a USB cable sync'd them all to a single shanwan PS3 controller CECHZC2U BLUETOOTH DUALSHOCH III (yes, actually spelled with the typo) All dongles immediately worked with the new pairing. I did some other tinkering for a while, including numerous shutdown -r now But notably did not have a problem until I decided to test them and tried an actual power off. shutdown -h now The results of some fairly extensive testing were strange, and at first led me to think it was partially faulty dongles. However the more tests i did the more this became false. If a dongle is plugged in while the PI : 1) is powered: it will always work - assuming it has been previously paired with a controller. 2) is not powered: the ps3 controller will usually, if not always refuse to reconnect when the pi is later powered up. In all cases the dongle lights up at one second intervals until the ps3controller hotkey is pressed, then it flashes (presumably) in accordance with power output as it connects to the controller. However I noted that in all cases where the dongle/ps3controller failed to connect... the dongle was lit up and rapidly blinking exactly the same as if it were successfully connected/paired to the ps3controller. OF NOTE: If I left two dongles plugged in I had almost total success in subsequently reconnecting the ps3controller after a poweroff state, without getting up to physically re-plug the dongle. The simplest 'fix' is to re-plug the dongle while the pi is in a powered-up state, and then hit the controller hotkey as per usual (no USB cable required). After these tests I set: max_usb_current=1 So I'll continue running with two dongles for a while, but intend to eventually re-test similar with one dongle and poweroff states...and the higher current.

Normally I'd just create a symlink to fix this, but I have no idea what to do about it on a read-only root system. # /usr/bin/mupen64plus __  __                         __   _  _   ____  _ |  /  |_   _ _ __   ___ _ __  / /_ | || | |  _ | |_   _ ___ | |/| | | | | '_ \ / _ \ '_ | '_ | || || |) | | | | / | | |  | | || | |) |  / | | | (_) |   |  __/| | || _ \ ||  ||_,| ./ _|| ||_/   || ||   ||_,|/ ||         http://code.google.com/p/mupen64plus/ Mupen64Plus Console User-Interface Version 2.5.0 UI-Console Error: dlopen('./libmupen64plus.so.2') failed: ./libmupen64plus.so.2: cannot open shared object file: No such file or directory UI-Console Error: AttachCoreLib() Error: failed to find Mupen64Plus Core library # find / -name libmupen64plus.so.2 # find / -name libmupen64plus* /usr/lib/libmupen64plus.so.2.0.0

For example, I think I know what I'm doing, yet sti still requires a password after I get what looks like a positive insertion of an authorized_key... user@betlognuc:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub root@recalbox /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@recalbox's password: Number of key(s) added: 1 Now try logging into the machine, with:   "ssh 'root@recalbox'" and check to make sure that only the key(s) you wanted were added. user@betlognuc:~$ ssh root@recalbox root@recalbox's password: # cd .ssh # ls -al total 12 drwx------    2 root     root          4096 Jul 13 06:07 . drwxr-xr-x   15 avahi    avahi         4096 Jul 13 06:07 .. -rw-------    1 root     root          2809 Jul 13 06:07 authorized_keys # cat authorized_keys ssh-rsa **** yep, it's there*** buuuut.... # shutdown -r now Broadcast message from root@RECALBOX (pts/0) (Wed Jul 13 06:09:31 2016): The system is going down for reboot NOW! # Write failed: Broken pipe user@betlognuc:~$ user@betlognuc:~$ ssh root@pilan root@pilan's password: ...it still asks for the password... and the whole idea of adding the pubkey is so it doesn't. What am I missing here?

The unstable, auto-updated, most recent version. Naturally I did try adding them to //recalbox/share/system. But evidently I'm too familiar with debian and not with .... what IS recalbox's distro called? Would you mind throwing some relevant command lines at me please? The way recalbox's flavor of linux works in not familiar to me at all.

I have a shanwan controller and previously it worked fine (after initializing one time by plugging it in via USB and holding the P3 button). It would then automatically reconnect every time i started the recalbox and hit the p3 button (without cable connected) - just like it should. However for the last few days it has stayed in seek mode when I turn the controller on. I discovered that to fix it I need to pull the BT dongle out and reinsert it. The controller will then reconnect normally after P3 is pressed. This may be an issue with my particular BT dongle, as I have had one other identical unit die previously. I will be receiving several more newer dongles  in the next few weeks, so will test.

I would like to access root@recalbox via ssh keypair instead of a passphrase But: /root/ is apparently read only ~ ( /recalbox/share/system/ ) contains a ~/ssh/ directory (I was expecting it to be the more traditionally named: ~/.ssh/) but doing:

scp /home/user/.ssh/id_rsa.pub root@recalbox:/recalbox/share/system/

cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

or even (into ~/ssh instead of ~/.ssh)

cat ~/id_rsa.pub >> ~/ssh/authorized_keys

does not allow me to log in without entering the passphrase. The linux used by recalbox is increasingly unusual to me. Can someone please explain how to enable passwordless keypair SSH logins?

Sorry, my bad. I'll be using that menu a lot now.   ...no offense intended, but if old topics are b*mped it's usually because the online documentation isn't complete. Or perhaps the various languages and forums are detracting from search engine results?