Rock 5C - capable of unusual resolution spec?

#1

Hi All,

I am considering using the Rock 5C for an unusual projection device using a specialised monochrome 16K screen.

This device uses a custom technique to drive a 15120x6230 LCD panel but from a ‘bit packed’ 5040 x 6230 signal at 20Hz - it extracts 3x monochrome 8bit signals from the 3 colour channels in a 24 bit RGB signal. ie. 1 RGB pixels === 3 MONO pixels

Does anyone know if this device would be capable of driving such a screen from a hardware perspective?
NB. The image to be displayed is STATIC - so there is no issue with refresh or frame rate.

Thanks in advance :slight_smile:

B

#2

FYI - of course not verified https://github.com/copilot/share/485a13b2-0284-88c4-a912-364a449921da

1 Like
#3

i dont think this is possible without modifying the kernel

#4

Would you be in a position to offer guidance on how that could be done? :pray:t2:

#5

tbh, i am also not sure 100% but what i know is blow.

when a buffer is sent over the display interface (lets say hdmi or mipi or what ever), it goes through the vop2 hardware. thats a silicon part in the SOC composed of several internal sub components. If i am not wrong encoding the buffer in a given image format to a given output interface is done in the hardware. So you custom RGB format will not be supported by the hardware. You might fool it to send as normal RGB but i am still not sure it will be accepted interms of maximum width height pov.

I would suggest to look at https://github.com/FanX-Tek/rk3588-TRM-and-Datasheet TRM in chapters vop2 and https://github.com/rockchip-linux/kernel/blob/develop-6.1/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c vop2 code.

As mentioned before, i have no clue if i am right or wrong, i only patched trivial stuff in vop2 kernel before so dont know myself as well how it works inside out.

#6

I think the unpacking is done on the little HDMI / MIPI interface board that drives the LCD. So I can just pack the bits in software, then send it as normal RGB data over to the device.
The issue is the unusual resolution required.
While the volume of pixels is within the capabilities of the chip, the arrangement of them puts them outside the hard coded bounds of the driver.
I’ve modified the ‘rockchip_vop2_reg.c’ file where the maximums are defined and I’m recompiling the kernel as we speak.
Hopefully this will do the trick!

#7

How did you go? I’m interested in this kind of patch to know the limits of the hardware!

Many thanks in advance.