@Philips_Support_P, or perhaps @wernerj or anyone who knows more about this:
Why doesn’t the PPX use all the available resolution available on the light engine? When the Rockchip logo displays you can see there’s more pixels available, and this picture also shows this (see the edge of light versus the edge of the image):
Would this extra capacity be available for a FullHD+ mode in the future, running perhaps at a QHD resolution of 2560 x 1440?
What is the maximum resolution of the light engine anyways?
2 Likes
Interesting question @IvoGrijt.
I was able to find this:
The black level of a single-chip DLP depends on how unused light is being disposed. If the unused light is scattered to reflect and dissipate on the rough interior walls of the DMD / lens chamber, this scattered light will be visible as a dim gray on the projection screen, when the image is fully dark. Deeper blacks and higher contrast ratios are possible by directing unused HID light away from the DMD / lens chamber into a separate area for dissipation, and shielding the light path from unwanted internal secondary reflections (Link)
Also, I found this in the DMD’s tech specs on the Texas Instruments site:
BenQ suggests some fixes for this in their products: There are reports of a white border affecting all TI 0.47" DMD projectors. Any word on fixing for this? | BenQ
I’ve been curious about this myself for the longest time but haven’t been able to find a definitive answer. Perhaps those pixels are inactive to create sharper, darker, borders for the projected image or to create a more focused, central beam of light that can be shaped by the optical array/lenses. But then, that does not explain how the whole area is used when the projector boots up with the Philips logo displayed. Perhaps @Philips_Support_P or @wernerj can shed some ‘light’ on this. 
1 Like
This image is wider, as wide as the white border in my previous picture, indicating that the unit is capable of projecting past the image border:
But this is also wider than the Philips logo at startup. This image only appears in the event of a cold boot or crash.
1 Like
I’ve gotten the RK kernel boot splash (most likely early boot stage splash) even from cold boot once (brief sub-second flash), that’s what made me realize that the built-in splash of the dlpc itself isn’t used for the philips white splash. All of that is HDMI output from the RK SoC into the V56 chip, then parallel video to the fpga/dlpc. That means that if you’ve got 960x2 pixels width while booting but it’s reduced after android has booted then some underscan is configured within Android. No keystone correction active at all? If you run HDMI or usb-c video you’re getting an image the same size as the boot splash? What about that nasty no signal image (internally generated in the V56), how large is that in comparison?
It’s possible that the V56 chip is reconfigured after boot as well which may affect scaling, I haven’t had time to dig through that yet. The Mstar source I have is old and definitely not a perfect match for what’s inside the PPM but the Melody hardware in the V56RB configuration (the one with the 3 port hdmi switch built in) IS supported. This scaler thing is what I believe can give a limited zoom (reduction) functionality even for hdmi/usb-c video), but the lack of documentation really makes it very difficult to figure out the limits.
We can always tap the HDMI output directly from the RK SoC output to verify image integrity, but it’s quite a bit of work getting an interposer in between the V56 and the PCB.
2 Likes
On my copy the border around the image is compatible with the given POM dimensions. but even in the latest release I had spotty issues with keystone correction doing weird things like reducing the image size much more than needed and not returning to full size when placing the pico horizontal.
1 Like
