..:: PCSX2 Forums ::..

(03-04-2014, 11:41 AM)roberto30 Wrote: [ -> ]it's not this problem i have got.

DS4's functionnally is perfect.

Except a little problem when i launch a program with UAC, mouse of DS4 don't reply, it's freeze (at moment to select no or yes into windows) i must use my true mouse, and then, i can use again my mouse of DS4.

Is it possible to correct this ?

This is not something that should ever be 'corrected'. I find it reassuring to hear that you cannot use it for UAC as then if your system is ever compromised it will not be through our application that the attacker gets through UAC.

If you want to do system sensitive actions (that need UAC) with an emulated device (the wrapper's mouse) then you will need to turn UAC off. I do not encourage you to do this, as UAC is a security feature, but if you really want to I suppose it is up to you what is worth more.

I personally do not use UAC, but like a 'burner phone' my PC does not hold any sensitive information about me - I don't bank online or store passwords in my browser. If it ever gets compromised I can reinstall Windows without really being bothered by it.

I am going to try to add this feature eventually, BUT: you will have to run the program as Administrator, most likely. It may not have full functionality anymore, like disabling distribution of light bar events or not allowing you to change configuration in the GUI at all without restarting it. There is no panacea. You can't fudge security, you MUST do it right, which means in-depth. As long as we are implementing only functionality equivalent to another HID device, we are good. But when we start letting outside programs manipulate the HID subsystem by manipulating the DS4 GUI, or configuration, or network status protocols, whatever... that's not okay. It is tantamount to disabling UAC/UIPI, your first-line defenses in Windows against attack.

That said, we can also increase the strength one more way, by running it as a separate user entirely so that it is generally not possible to manipulate the program without gaining Administrator rights already (and you've already won the game there.) Aspects of security like this and not allowing too fine read-out of the gyro/accel sensors are very important to me. We do not want to be responsible for anyone else suffering security breaches.

(03-04-2014, 02:16 PM)electrobrains Wrote: [ -> ]Aspects of security like this and not allowing too fine read-out of the gyro/accel sensors are very important to me. We do not want to be responsible for anyone else suffering security breaches.

Definitely not. Though from that post earlier about the gyro/accel keyboard issue, it was noted that certain distance and sensitivity requirements needed to be met for the 80% accuracy to be reached.

What surprises me is that there needed to be a certain frequency of input at least for it to be viable, which based on the average person's typing speed didn't seem necessary. Perhaps they really do need more than just one detection per keystroke for their 'side side distance' to be accurate.

In which case the uncorrected/raw input from just the values I used earlier from ~235 to 255 and 0 to ~35 at a 60Hz refresh rate cannot be enough to still achieve any reasonable amount of accuracy I would think.

(03-04-2014, 03:28 PM)HecticSeptic Wrote: [ -> ]Definitely not. Though from that post earlier about the gyro/accel keyboard issue, it was noted that certain distance and sensitivity requirements needed to be met for the 80% accuracy to be reached.

What surprises me is that there needed to be a certain frequency of input at least for it to be viable, which based on the average person's typing speed didn't seem necessary. Perhaps they really do need more than just one detection per keystroke for their 'side side distance' to be accurate.

In which case the uncorrected/raw input from just the values I used earlier from ~235 to 255 and 0 to ~35 at a 60Hz refresh rate cannot be enough to still achieve any reasonable amount of accuracy I would think.

Well, the more intrinsic thing to consider is that raw input is not even desirable. We want to use the MEMS sensors to correct each other and reduce the noise and jitter, and export that 'adjusted' data. I intend to implement this sort of algorithm and make absolutely certain that espionage is unlikely before exporting any of the MEMS data. Also, this sort of algorithm could be used to make touchpad support feel smoother, too.

http://en.wikipedia.org/wiki/Kalman_filter

One other thing to keep in mind is that a research paper that theorizes a way to perform some attack, and manages to perform it, is just the start. The state of the art of mathematics is always advancing and you can expect that accuracy will only increase over time, given the same data sets. Also bear in mind that this is such a trivial amount of data that a malicious organization could easily keep record of every controller movement you make for the entire time you're playing a game, and go back and analyze it again with better algorithms.

Don't forget that exposing gyro/accel sensors may make them available all over the place, including from JavaScript in the web browser. Also note that protocols used by software are generally proprietary and you can use steganography to hide data by sticking it where people are simply theorizing "entropy" is being input into the system.

Sorry if I'm asking something that has been answered (this thread is huge).

This works perfect for me when connected via USB, but I can't get bluetooth working. The controller connects to my computer fine using the bluesoleil software (tried in devices and printers, add device, but it doesn't find it), but when I start DS4 to XInput Wrapper It gives me the following.



Any idea?

Thanks.

** Nevermind, I managed to get my onboard bluetooth working. My only issue now is how do I turn the controller off?

BT
windows 7
InhexSTER 1.3 RC1

After restarting the computer

- Open DS4Tool 1.3 RC1, then immediately
- Close DS4Tool. (Freezes) every time.

If I open the DS4Tool 1.3, then turn on the controller, everthing works fine. DS4 connects and everthing works. I can turn it off, then Close the DS4Tool fine.

It's just whenever I restart the computer, then Open DS4tool, then immediately Close DS4tool, it FREEZES every time. have to force close.

I tried this twice. both with same result. could just be my computer...

On another note, I was wondering if you could have the option of touchpad's middle button to be 'Unbound'. My mouse's middle button is set to Alt-F4 and whenever I press 'Options' button on the controller to pause a game, I sometimes press the touchpad, and it's where the middle button is..........and boom! Close the game. I never had a need to use the touchpad's middle button in a game....it would be great if you could add 'Unbound' for the middle button.

First off, I'd like to thank you for making this tool. It's just so good in all the ways and I've never had any issues with it.

The reason I registered was to make a feature request. I'd like to suggest a "tablet" mode for the touch pad, or whatever one might call it. The idea is that a point on the touch pad corresponds to a point on the screen so if I touch, say, the upper left corner of the touch pad, it moves the mouse to the upper left corner of the screen. It would be nice if you could limit the cursor to specific windows and even parts of them (specifying which areas in either pixels or %, perhaps). I'd like to see this added primarily for usage in Nintendo DS emulation but I'm sure there'd be a lot of other uses for it as well.

(03-04-2014, 04:29 PM)Jakob Wrote: [ -> ]First off, I'd like to thank you for making this tool. It's just so good in all the ways and I've never had any issues with it.

The reason I registered was to make a feature request. I'd like to suggest a "tablet" mode for the touch pad, or whatever one might call it. The idea is that a point on the touch pad corresponds to a point on the screen so if I touch, say, the upper left corner of the touch pad, it moves the mouse to the upper left corner of the screen. It would be nice if you could limit the cursor to specific windows and even parts of them (specifying which areas in either pixels or %, perhaps). I'd like to see this added primarily for usage in Nintendo DS emulation but I'm sure there'd be a lot of other uses for it as well.

Already a planned feature; thank you, though!

(03-04-2014, 05:13 PM)electrobrains Wrote: [ -> ]Already a planned feature; thank you, though!

Have a cat .gif. You deserved it.

I'm having a problem with the way the DS4 is detected, even before using the ds4tool just as a regular wireless controller the L2/R2 triggers show up as being both axis' and buttons, and the axis acts as always being fully negative, halfway pressed acts as neutral and fully pressed acts as positive, pressing it at all acts as the button.
Not being pressed:
http://i.imgur.com/NptJnUr.png
Being pressed:
http://i.imgur.com/anNcoDA.png

So if I try to map anything in a game/program it'll always go to the axis of the triggers, with DS4tool open it remaps everything except those axis as xinput, and they still prevent me from mapping things in games.
I used to have the motioninjoy drivers installed but I'm pretty sure I got rid of them, when I plug the DS4 in the two drivers it use are 'HID Compliant Game Controller' and 'USB Input Device' the default drivers from Microsoft.