I don’t know anything about the 4K, and I don’t think anyone has used it with PimaxXR before.
Does it not have 10 deg canting on each eye like the 5K & 8K?
Why is it that Parallel Projection always seems to be enabled with that headset?
2 Likes
Ok so I just Googled the 4K, and it doesn’t look like it has canted displays. Meanwhile, Pitool seems to advertise steamvr_use_native_fov = 0, which is what Pitool uses to enable Parallel Projection on the 5K / 8K.
So it looks like PimaxXR removes 20 deg of canting which is what is killing your FOV. I can make PimaxXR ignore steamvr_use_native_fov when it detects a 4K to solve this.
That bit does not however explain the resolution issue from earlier. Looks completely unrelated, but really seeing Pitool giving us strange values for pvr_getHmdInfo() and now steamvr_use_native_fov, I wonder what will be next 
I am also curious if you can use pimax_cli · mbucchia/Pimax-OpenXR Wiki · GitHub to force the value of steamvr_use_native_fov to 1 (which IMO should be what Pitool needs to always returns for a non-canted headset).
I do agree however it is possibly an issue with the p4k being eol for so long.
Maybe @PimaxQuorra @PimaxUSA & @hammerhead_gal can check with the Pitool/Client team after CNY. Perhaps they can either fix this long term for p1:Series hmds or Release a legacy version driver?
1 Like
No canting on the p4k. It is a single 3840×2160p Sharp panel rainbow rgb @ 60hz. It accepts 1080p & 1440p signals and upscales to 2160p. Also features Aspheric 53mm lenses. No mechanical ipd adjustment; only software ipd.
PP should not be on. @XuCrUtZ if you can turn off PP that option should not be present/available.
1 Like
@Heliosurge On the PiTools that option doesn’t even exists for me to check or uncheck (parallel reprojection)…
@mbucchia I`ve never used this cli before, I could test it later today, but the fix you did worked to render exactly the image I was having before, thanks!
The fix made by mbucchia is a workaround the PiTools that is sending false information about the HMD. Still we need help to make it right to the next release build. Or it could be the OpenXR dll from OpenComposite that is doing that?
1 Like
Very much agreed. As for OpenComposite; I can’t see that being the issue.
What firmware version are you using on the p4k?
My Pimax 4k is running the 1.0.0.265 firmware.
1 Like
I am not sure if this will fix your issue but pimax did release 1 final new firmware that is newer than 265 in the linked post below.
The @Playa link there is a direct link for the final p4k firmware.
That is definitely not involved in the issue.
The resolution values were sent directly from pi_server.
You did say that you turned off Vive compatability, I wonder if that was the reason.
2 Likes
No need to test. The fix I gave you completely ignore that steamvr_use_native_fov value anyway.
1 Like
@Heliosurge thanks for the firmware suggestion, but it isn’t working for my HMD.
The firmware is installed and detected by the DFU.exe window, but not by the PiTool 1.0.1.284.
It remains on error 10510 and the diagnosis fail to do anything…
On thing that I’ve noticed: after the 999 firmaware, the DFU.exe does not detect the name of the HMD anymore, not even after going back to the 265 firmware, it should be Pimax 4K in there:
Even with this problem, using the 265 firmware the PiTools starts to recognize my Pimax 4K again and I can use it normally…
EDIT: for anyone with trouble to update the firmware, on Windows 11 you have to temporally disable the Core Isolation → Memory Integrity check, after the flash operation you can activate it again.
EDIT 2: the DFU.exe does not update after the HMD reboot, after restarting the DFU.exe with the 265 firmware, it shows back the Pimax 4K name!
2 Likes
Hmm okay thank you. Maybe @PimaxQuorra can pass that along to the team and see if they can maybe look into releasing maybe a revision to correct that firmware?
1 Like
@PimaxQuorra if you need me to test anything, just ask, I volunteer myself to help you to maintain Pimax 4K support. I can code C++ too, if needed.
2 Likes
Checking with the tech specialist and software devs.
Roll back to previous Pitool version is inconvenient, but this might be the solution to address this issue.
2 Likes
Can you also check with them if there is a way to programmatically query the pitool version from PVR SDK.
Supporting multiple versions of pitool is honestly beyond inconvenient to developers, because there are workarounds specific to bugs in certain versions of pitool.
Best example is the issue with world-locked quad layers that was introduced in pitool 283 and that I reported in October to @hammerhead_gal. A workaround to make it work with 283 and above breaks compatibility with 281 and below. No workaround makes it not work with 283 and above. Telling users to use 281 and below exposes another bug that was thankfully patched in 283.
I have had to answer questions about these two bugs in 281 and 283 maybe 20-40 times on my GitHub/Discord in the past year.
Only other way I can think of to deal with this is to now ship 2 versions of my program, one for pitool 283 and above, and the other version for older pitool. This isn’t something I really have time to do.
Thanks.
4 Likes
I just wanted to +1 here. world-locked quad is unpleasant issue in UI. I am going to try downgrading to v281 for now, but this needs to be fixed.
3 Likes
Agreed! Please pimax fix the quad layer issue!
1 Like
Ping on that as well. I would love to make some of these workarounds conditional on Pitool version so that i don’t have to ship 2 versions of PimaxXR.
I was hoping there is a pvr_get*Config() I could use.
2 Likes
I just reverted to 280 and it works like a dream. I do not understand exactly what is going on but not only layer tracking was weird with 284. It also looks like PVR handles resubmission of layers if game does not submit ones. This is critical for loading screens etc when game freezes. I was about to write multithreaded submission in mhy code but it looks like it is not necessary! It is just that in 284 something is broken (when no frames are submitted, tracking freezes).
Another thing is that 280 does not need PiTool to be running, which is much more convinient for complex sim setups. EDIT: I was wrong, starting pitool is still required with 280 
EDIT2: 281 also works correctly with quad layers, but 284 definitely not, it’s broken.
2 Likes
I’d also like to mention that workaround @mbucchia has for world locked quads in post 283 does not provide the correct experience, it improves it but it is still wrong. The real fix in PVR is needed.
1 Like