Cinematic Mode - Reset and Screen size

[mungewell]

Can't find where the 'Recenter()' command is actually actioned: https://github.com/gusmanb/PSVRFramework/search?utf8=%E2%9C%93&q=Recenter

But it seems to cause the HMD to off/on, resulting in the 'circle of dots' displayed for a few seconds, this is not the behaviour seen on the PS4. Recenter happens quickly, there must be a 'command' for this...

Also support for different Cinematic mode screen sizes would be nice. :-)

[mungewell]

I think this may handled by '0x21' command, messing with that I managed to get Large Cinematic mode but without the tracking (ie. stuck to face) ep.write('\x21\x00\xaa\x10\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')

Which was 'sticky' through on/off/power cycle... use with care I guess. Seems that you need to use the 'Shutdown' command, to completely reboot the Processing Box, to recover.

[mungewell]

# Large Cinematic, Stuck
ep.write('\x21\x00\xaa\x10\x80\x32\x19\x14\x00\x00\x00\x00\x00\x00\x20\x00\x00\x00\x00\x00')
# Large Cinematic, Moves
ep.write('\x21\x00\xaa\x10\xC0\x32\x19\x14\x00\x00\x00\x00\x00\x00\x20\x00\x00\x00\x00\x00')
# Medium Cinematic, Moves
ep.write('\x21\x00\xaa\x10\xC0\x32\x29\x14\x00\x00\x00\x00\x00\x00\x20\x00\x00\x00\x00\x00')

The '0x19' appear to be zoom. 0x14 (close/huge) through to 0x32 (far away/smaller) That '0x20' appears to be screen brightness. 0x20 through to 0x00 are decreasing brightness.

Screen rotation/center is reset every time it is changed (but need to flip between two settings).

[gusmanb]

Wow man, that's really a huge advance!!!

Yes, the recenter is just a trick as I still did not found the correct command, when you leave/enter cinematic mode the view is recentered so I used it, it just leaves cinematic and enters again cinematic.

Hmmm, for what I see, the next logical value should be ep.write('\x21\x00\xaa\x10\xC0\x32\x39\x14\x00\x00\x00\x00\x00\x00\x20\x00\x00\x00\x00\x00') which would lead to small screen size, but just a guess.

I will try these commands and when I get them working will add it to the toolbox, tonight or tomorrow maybe.

[mungewell]

The '0x19' is a zoom value. It can be between 0x14 and 0x32 (ie. 30 levels of zoom). If you write outside these values the write is ignored. Same with brightness, values between 0x00 and 0x20.

[gusmanb]

I've been playing with it, and I've found good things, that 0x80/0xC0 does nothing for me, I pass 0 and it keeps working, 0x80 does not lock, but, that 0x32 is the one which stucked you the view, if you have changed the screen size on the ps4, when you select "small" it gets stucked like what happened to you, that 0x32 controls the distance of the virtual screen, it ranges from 0x1A to 0x50 and the range between 0x1A and 0x1D locks the view as its designed, very far, all fits :).

So, we have now distance, screen size and brightness.

Well, to be 11100% honest, not sure if "distance" is distance and "size" is size of viceversa as the sensation is really similar as we don't have a reference point on the virtual space :)

I'm going to toy a bit with the rest of the bits on the packet to see if I find something else.

UPDATE: Finally it seems it's reversed to what I thought, 0x32 is size and 0x19 is distance.

[gusmanb]

More news, byte nº 11 (the one next to the brightness) is mic volume (or may be mic feedback volume) , it ranges from 0 to 5.

[gusmanb]

Got another one but no idea what is its purpose. If you enter to VR mode and alternate byte 14 between 1 and 0 the headset resets, but I can't find a difference at all, so not sure for what this is..

[gusmanb]

@mungewell I've added you as collaborator to the project. I'm going to add to the wiki all the protocol pieces we know to keep all the info in one place after I update the toolbox with the new controls, modify it as you please ;)

[mungewell]

Thanks for the invite, have accepted.

wrt 'VR mode byte 14' - my first guess would be that this is the trigger for the 90fps mode. I did not see more that 60Hz in the EDID, so maybe 'we' should check whether this byte make extra modes appear in the EDID.

It might also be something to do with social screen, maybe whether it crops/zoom left eye output or plays the H263/4 content sent via USB.

[gusmanb]

@mungewell Nice you accepted, glad to see you aboard :).

I got to do 90Hz, if you have an nVidia card with nVidia control panel, just go to the resolution configuration, create a new mode and set it to 90Hz, that did the trick for me (and of course, also remove your primary screen or it will lock the refresh to 60). I think the device does report EDID with only 60Hz modes to be compatible with any output device and if you set the 90Hz manually it changes it's descriptor, but that's just a guess.

I think you're right about H263, that can perfectly be the quality selector.

I have nearly finished the VR player, I think tonight I will have a running alpha, when I finish it I will change the USB code, a lot of people has problems with libusb and an user has posted some code which works without drivers, just native raw com, so if it really works will ease a lot the installation process.

[mungewell]

Confirmed on the mic level, seems to be local feeback (for comfort if you have really closed headphones I guess:

ep.write('\x21\x00\xaa\x10\xC0\x32\x23\x20\x00\x00\x00\x00\x00\x00\x20\x05\x00\x00\x01\x00')>

Could re-create the 'restart video' bit, but didn't find any obvious differences going on.

ep.write('\x21\x00\xaa\x10\xC0\x32\x23\x20\x00\x00\x00\x00\x00\x00\x20\x00\x00\x00\x00\x00') time.sleep(10) ep.write('\x21\x00\xaa\x10\xC0\x32\x23\x20\x00\x00\x00\x00\x00\x00\x20\x00\x00\x00\x01\x00') time.sleep(10)

Side note: Social screen will de-distort any input resolution in VR mode, but HDM will only show 1080P.

[mungewell]

Regarding lock, I can not get '0x1a' to consistently lock position. It seems that if I run the following with headset off and after it blanks the screen (due to proximity) then the screen is locked, and will not unlock with writes. If I remove the HMD, let it blank, but wake it before I run script it will unlock (regardless of screen 'distance').... something strange is going on.

   ep.write('\x23\x00\xaa\x04\x00\x00\x00\x00')
   ep.write('\x21\x00\xaa\x10\xc0\x32\x23\x20\x00\x00\x00\x00\x00\x00\x20\x00\x00\x00\x00\x00')
   time.sleep(5)
   ep.write('\x21\x00\xaa\x10\xc0\x1a\x23\x20\x00\x00\x00\x00\x00\x00\x20\x00\x00\x00\x00\x00')

EDIT: this may be something to do with having the HMD stationary (ie on the desk) before the screen position is set. Seems like there may be some time to self calibrate required.

   time.sleep(5)
   ep.write('\x21\x00\xaa\x10\xC0\x32\x23\x20\x00\x00\x00\x00\x00\x00\x20\x00\x00\x00\x00\x00')

[gusmanb]

@mungewell Yes, what you say makes sense. The device "locks" the screen position at the center when the helmet hasn't been worn and after some seconds wearing it "releases" the view. That makes perfect sense for a sensor fusion algorithm, until the device has been worn it locks the screen position to avoid drifts, when you wear it starts feeding a Kalman filter (or similar) with all the sensor inputs and when it has learnt enough releases the locing as the tracking starts to be reliable.

Precisely I'm looking at the tracking system, usually these fusionalgorithms use an acceleromter, a gyroscope and a megnetometer, we already know where the device sends gyro and motion data, but we're missing the magnetometer data, maybe it doesn't has a magnetometer, but there are a lot of bytes "unused" on the sensor report so i'm very confident some of these must be the magnetometer data.

About the 0x21 report, I've been thinking, that report has too many bytes unused for what we know at the moment, so I belive those fields must be used with the devices we still can't acces, the 3D audio system, h264 decoder and bulk interface, so I'm starting to think this report is just the "settings" report.

[mungewell]

Closing out this bug as the original request has been fulfilled.

Opening others to question screen lock and mystery byte 14.