Hello, so I wanted to try and use my Xbox 360 Rock Band guitars on my PS3 with ps3xpad but I do know that it's not a HEN plugin and I would have to resign it. But my question is will it work on Hen version 3.0.3 and Firmware 4.87? Asking just to make sure if the versions won't be an issue so I don't accidentaly F%$# something up with my console.
You don't have to resign any binary made for CFW with HEN, all binaries that can run on CFW can also run on HEN.
HEN is basically a slim Cobra payload for CFW, when it comes to custom self/sprx support, it provides the exact same features.
The only difference between HEN & CFW is that HEN's jailbreak is partial (lv2, ie the kernel or supervisor, is jailbroken but not lv1, the hypervisor) so any function in a custom homebrew that relies on lv1 peek/poke access in its code cannot run properly on HEN, of course the rest of the homebrew code that's not using lv1 calls will run just fine.
Think about the ps3 system this way, you install something like wmware or virtualbox on your PC & create a virtual machine with Linux running on it.
Now imagine that running this Linux in the VM you wish to access the hardware directly, well you cannot because everything is virtualised. Let me explain.
To keep things simple let us say that you try to run a command in the Linux user terminal to communicate with your PC graphics card, it will not be Linux that speaks to the graphics card, it will be vmware or virtualbox that will communicate with the hardware & then forward the data to Linux's kernel which will in turn forward it to the terminal that displays it on your screen.
If you wish to access the hardware directly from a Linux user terminal console, you would need to first hack the Linux kernel in the virtual machine then hack the vmware/virtualbox virtual layer (for simplicity sake, I purposefully omit the Windows layers).
It's the same thing on the PS3, using the analogy, you can roughly speaking consider that lv2 is the equivalent of the "Linux kernel" & lv1 is the equivalent of "vmware/virtualbox".
Again I am oversimplifying intentionally but we can push the analogy further, while vmware/virtualbox runs Linux in a virtual machine, it can also concurrently run another virtual machine with MacOS for instance etc..
Similarly the ps3 hypervisor (lv1) can run in a separate "virtual environment" the ps2 emulator or the OtherOS environment for PS3 Linux.
In a CFW, lv1 & lv2 are both exploited, custom homebrew apps have full access to the ps3 system.
In HEN, only lv2 is exploited, custom homebrews have partial access to the ps3 system, it is still sufficient to run 90% of homebrews out there without issues.
Note that in theory there is no danger in running code requiring lv1 access on HEN, the calls will fail, so will the routines using them but that won't break the system, the homebrew function will just fail.
The potential danger the most important on HEN is when using homebrew binaries originally made for CFW that apply customisations to signed system files.
When the modded system files are located in /dev_flash, it usually leads to a partial brick but reinstalling the firmware from the recovery environment recovers the system.
However when the mod is done on CoreOS files it can brick the console to the point of needing a hardware flasher to recover.
Very few homebrews for CFW have one or more features patching CoreOS files but still there are some & their use should of course be avoided on HEN at all cost.
I have never tried to run ps3xpad with HEN, I cannot guarantee without checking the source code but I don't think that plugin uses lv1 peek/poke, if it doesn't it should work fine on HEN as is.
You can safely add the full path to the sprx file in /dev_hdd0/boot_plugins.txt, there is no risk involved if ever it doesn't work.
If I were you, I would first test with the sprx file located on a usb stick rather than hdd0, that way if you experience problems & a crash, you can unplug the usb stick, reboot the console & start HEN without ps3xpad loading automatically then you can safely edit boot_plugins.txt & remove the sprx path if necessary.
And if your tests are conclusive, the plugin works as you wished & you wish to have ps3xpad loaded automatically everytime you use HEN you can copy the sprx to /dev_hdd0 & edit the boot_plugins.txt accordingly.
Note that generally speaking given the memory/perf constraints, the less custom plugins are running concurrently the better, when a plugin is used only occasionally it may be better to use the USB stick method, plugging in the stick only as needed.
Note also that if I am not not mistaken (it had been a while since I used that feature) you may be able to use wMM's PS3MAPI page to launch a vsh plugin at runtime from the browser without editing boot_plugins.txt. You may also be able to use a wMM web command to load/launch ps3xpad from your PC or smartphone browser. Check the webMAN-MOD web commands list thread for details.
