PSVRFramework icon indicating copy to clipboard operation
PSVRFramework copied to clipboard

Config change - 0xF0 report

Open mungewell opened this issue 8 years ago • 8 comments

It has been suggested that a response '0xF0' indicates a configuration change. This can be seen in the attached log, and also sees related to command '0x21' in that the 5th byte changes between '0x80' and '0xC0'. config_change

mungewell avatar Nov 04 '16 14:11 mungewell

I think F0 means OK instead of change, the answers to what it's supposed to be the calibration also have a 0xF0 unless it really is not calibration but other command.

gusmanb avatar Nov 04 '16 17:11 gusmanb

Got this, F0 is an status change, not config.

b0 is a mask with the general status,

  • b7 unknown but used, on the example report it's always 1, on mine is always 0
  • b6 always 0?
  • bit 5 is mute.
  • bit 4 is headphones connected/disconnected
  • bit 3, always 0?
  • bit 2 is cinematic on/off? (see b7)
  • bit 1 is worn/not worn
  • bit 0 is headset on

b1 is mic volume from 0x00 to 0x32 b2, b3, b4 always 0? maybe volume is an integer? b5 always ff? b6 always 00? b7 social output processed? bridge output ID?

  • Explanation: this byte goes to 0 when in cinematic mode and mask b2 goes to 1, what seems to make the social screen output to be just a bridge to the HDMI input. When changed to VR mode it changes to 1 and at the same time social screen output is reset and I assume if we could see instantly the changes on the screen (it takes some milliseconds, half a sec aprox. for the TV to get the signal) we would see the output processed by the black box with the distortion correction applied, after that headset resets mode, shows HDMI input unprocessed and b2 goes to 0.

b8 always 02? Rest of bytes always 00?

That's what I got for now. I will try to find why the user who posted the pictures had b7 on the mask to 1.

EDIT: byte index is after report info: report id, status, data start, and data size.

gusmanb avatar Nov 08 '16 19:11 gusmanb

Byte 0/bit 6 for me is 1 when Blueray is playing, 0 when PC is playing.

Your byte counting is off... Byte 7 (one before the 0x02 in picture) for me switches to 0x01 when in VR mode, and I also have seen 0x03 but don't have/understand a trigger at the moment. Byte 8 stayed at 0x12 for me (with 1080p60 output to social screen)

mungewell avatar Nov 08 '16 20:11 mungewell

Yes, b7 was displaced by one :)

Ok, so bit 6 must be something related to signal input, any idea in what difference can be this? maybe audio format?

And byte 8 for me is 02 too, no idea why you have 0x12, something different on our set up?

gusmanb avatar Nov 08 '16 20:11 gusmanb

byte 0/bit6 did not change when I was/wasn't playing HDMI audio via PC, but yes it could be format(pcm/ac3) or frequency related (PSVR advertises 44.1 or 48, but USB audio is fixed at 48KHz).

mungewell avatar Nov 08 '16 20:11 mungewell

Looks like 0xf0 report has a minute counter, for how long the display is on. Resets if display turns off after HMD is removed from head.

Wed Nov  9 00:27:29 2016
f000aa10
573000000eff00001200000000000000 W0=00=00=0E=FF=00=00=12=00=00=00=00=00=00=00
-
Wed Nov  9 00:28:18 2016
f000aa10
573000000fff00001200000000000000 W0=00=00=0F=FF=00=00=12=00=00=00=00=00=00=00
-
Wed Nov  9 00:29:18 2016
f000aa10
5730000010ff00001200000000000000 W0=00=00=10=FF=00=00=12=00=00=00=00=00=00=00
-
Wed Nov  9 00:30:18 2016
f000aa10
5730000011ff00001200000000000000 W0=00=00=11=FF=00=00=12=00=00=00=00=00=00=00

Also the '03 before the 12' I mentioned earlier is triggered by using the '0x11' command to turn on the LEDs (not followed by another command).

And there's more, byte0/bit6 is set when I use a RaspberryPi to supply HDMI (and HDMI audio) - don't think it does HDCP so might just be HDMI@48K marker... still think the USB audio only works when there is HDMI audio connected.

mungewell avatar Nov 09 '16 07:11 mungewell

Hey, I think I know what bit 6 is, CEC! That makes a lot of sense, raspberry and your blu-ray player have it, computers don't. I will update the info report with the byte with the counter (may be that's a short or it will roll over?).

And for that 03, we need to check it with the new findings on the 0x11 report to see if we can make some sense of that.

gusmanb avatar Nov 09 '16 08:11 gusmanb

Looks like the byte before the 0x12 is affected by command 0x23. This was thought to indicate VR mode, but I haven't figured out what these other values mean...

ep.write('\x23\x00\xaa\x04\xc0\x00\x00\x00')
f000aa10
172a000082ff00181200000000000000

ep.write('\x23\x00\xaa\x04\x80\x00\x00\x00')
f000aa10
1726000086ff00101200000000000000

ep.write('\x23\x00\xaa\x04\x40\x00\x00\x00')
f000aa10
1726000088ff00081200000000000000

mungewell avatar Nov 15 '16 06:11 mungewell