DIY 31 Megapixel Enlarger

[keesbran]

Also for posterity here's the display working on my desktop pc which is thankfully still operable. Now I just need to replicate this on the pi!

Nice! I am experimenting with rpi5 now and with the standard config.txt and after adding video=HDMI-A-1:2560x4320@23 in cmdline.txt the screen resolution is recognised! This did not work on the rpi4 though.

HDMI-A-1 "Chimei Innolux Corporation 0x6301 (HDMI-A-1)"
Physical size: 330x180 mm
Enabled: yes
Modes:
640x480 px, 59.939999 Hz
640x480 px, 60.000000 Hz
720x480 px, 59.939999 Hz
720x480 px, 59.939999 Hz
720x480 px, 60.000000 Hz
720x480 px, 60.000000 Hz
2560x4320 px, 23.010000 Hz (current)
Position: 0,0
Transform: normal
Scale: 1.000000

So the 2560x4320 is now recognised as current screen size.
With VNC Viewer I actually can see it. The screen itself is still dark. Now I will add the config elements from the sumaopai config.txt for the hdmi timing. Looking more carefully to this config.txt one sees some copy paste mistakes. Like a double entry for dtparam=i2c_arm=on and two entries for gpu memory: gpu_mem=128 and gpu_mem=192. Both won't harm much I guess.

 

[keesbran]

But when adding the 8k config.txt setting the screen resolution is back to 720x480@60:

HDMI-A-1 "Chimei Innolux Corporation 0x6301 (HDMI-A-1)"
Physical size: 330x180 mm
Enabled: yes
Modes:
640x480 px, 59.939999 Hz
640x480 px, 60.000000 Hz
720x480 px, 59.939999 Hz
720x480 px, 59.939999 Hz
720x480 px, 60.000000 Hz
720x480 px, 60.000000 Hz (current)
2560x4320 px, 23.010000 Hz
Position: 0,0
Transform: normal
Scale: 1.000000

To have the screen recognized op the pi5 I had to add this line from the original config:
# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d

 

[Graham06]

I also tested for the framerate that should be 23Hz. Is that correct?

When I was looking at my settings this evening, I noticed that my framerate was 22Hz

 

[Graham06]

I can't log in using safe mode or even completely wipe the machine and reinstall windows.

I suspect that won't work. I bet the bad info is written to the lcd firware which will persist through a os reinstall.

I think recovery might be possible. I think bitlocker prevents someone reading the drive data when the drive is installed in another computer:

1:
- plug in an external monitor to the hdmi port
- you can use your tv or your now working mono lcd
- switch the login screen to the lcd. this might be via windows-P or F8. can't test myself

2:
- turn on your laptop, and old pc in the same lan
- on the old pc see if you can see the laptop in the "Network" section of "My Computer"
- alternatively log into your router/dhcp provider and find the IP of the laptop
- this to be able to run "ping laptopname" or "ping laptopip" from start->run->cmd on the old pc
- in a cmd window on old pc run "net use x: \\laptopname\c$ /u:userwithadminrights *" (is the final * needed?)
- place a batch file in x:\Users\UserName\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
- you'll have to log in as Username on the laptop, which might be a bit tricky
- alternatively edit something under x:\window\system32\ I've done this before but can't remember what and the internet seems useless these days. I edited a batch file or temporarily replaced an unimportant .exe with an .exe that did what I wanted.

 

[keesbran]

This is what I know until now. When using the sumaopai config.txt I can see the screen showing some activity on the rpi4 but it blacks out after some time. The screen does not show up when passing the wlr-randr command. When adding:

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d

to config.txt and a reboot I don't see the screen activity anymore but the screen shows up in with wlr-randr although with the wrong resolution and I found no way to force it to the right one it got from cmdline.txt.

Also with this 'forced' kms an edid file is created at

/sys/class/drm/card1-HDMI-A-1/edid

With:

edid-decode /sys/class/drm/card1-HDMI-A-1/edid

I was able to decode and see it. See attached file for the screen connected to the rpi4. At this level things seem to go wrong. Force kms or not? How to get cmdline.txt settings respected? The edid that seems to reflect that. Conclusion: hardly any progress. I could replicate this also on the rpi5 where the edid was identical. But without the kms line it did not show any screen activity. Maybe kms is loaded by default on the rpi5 though.

Enough for today

 

[AndrewBurns]

Success! I managed to get the 10.1" 8k display working on a Raspberry pi 4.

What I had to do ultimately was 'downgrade' the OS from the latest Pi OS version (Bookworm) to the previous version (Bullseye), because the latest OS only supports the 'KMS' display driver mode which ignores all of the HDMI timing info in the config.txt file and always tries to read an EDID from the display (which doesn't work in this case). The older OS allows you to use the 'FKMS' display driver, which does respect the settings in config.txt, and when I did that and used the settings supplied by Sumopai it worked instantly.

So basically the only things you need to do to make the display work on a Pi 4 are as follows:

- Install the latest Bullseye OS, NOT Bookworm

And in config.txt:

- Change the display driver from KMS to FKMS using:

dtoverlay=vc4-fkms-v3d

- Add the following HDMI timing info:

[HDMI:0]
hdmi_ignore_edid=0xa5000080
display_hdmi_rotate=0
hdmi_drive=1
hdmi_force_hotplug=1
hdmi_force_hotplug=1
hdmi_timings=2560 0 56 32 44 4320 0 25 3 6 0 0 0  25 0 221184000 0
hdmi_group=2
hdmi_mode=87
hdmi_pixel_freq_limit=500000000
hvs_priority=0x32ff
max_framebuffer_width=2560
max_framebuffer_height=4320
framebuffer_width=2560
framebuffer_height=4320
framebuffer_depth=32
framebuffer_ignore_alpha=1
config_hdmi_boost=4
gpu_mem=192
framebuffer_ignore_alpha=1
hdmi_pixel_encoding=2

 

[AndrewBurns]

Oh and it's worth noting that the pi is -extremely- slow when driving this screen, not sure if that's just because of the high resolution or because of having to use an older and presumably less efficient display driver. My other pi driving my 7k resolution screen is significantly faster (still pretty slow though) and that one was able to use the latest Pi OS because that screen had a correct EDID on the HDMI converter, unlike the Sumopai one.

It should still work for what I want to use it for, but connecting to it using VNC was just painful to do anything, expect to do all of your code development remotely or via command line.

 

[keesbran]

Oh and it's worth noting that the pi is -extremely- slow when driving this screen, not sure if that's just because of the high resolution or because of having to use an older and presumably less efficient display driver. My other pi driving my 7k resolution screen is significantly faster (still pretty slow though) and that one was able to use the latest Pi OS because that screen had a correct EDID on the HDMI converter, unlike the Sumopai one.

It should still work for what I want to use it for, but connecting to it using VNC was just painful to do anything, expect to do all of your code development remotely or via command line.

Fantastic that you got this screen working with the pi 4. Do you think this OS downgrade might also work with the pi 5?

 

[AndrewBurns]

Fantastic that you got this screen working with the pi 4. Do you think this OS downgrade might also work with the pi 5?

Unfortunately it looks like the legacy OS (Bullseye) isn't listed as being compatible with the Pi 5, only up to the 4B.

If you want to keep trying with Bookworm though I did find this document today that includes a lot of info about how to migrate the legacy config.txt commands to work with the new KMS display driver:

Edit: Sorry wrong link, I'll try to find the right one again...

I found this just before I 'fixed' the problem with my downgrade, so never got a chance to test it, but there does seem to be some promising info in there.

 

[AndrewBurns]

Update: Here's the link I was actually thinking of: https://pip.raspberrypi.com/categor...-WP/Transitioning-from-Buster-to-Bullseye.pdf

 

[Graham06]

Oh and it's worth noting that the pi is -extremely- slow when driving this screen, not sure if that's just because of the high resolution or because of having to use an older and presumably less efficient display driver. My other pi driving my 7k resolution screen is significantly faster (still pretty slow though) and that one was able to use the latest Pi OS because that screen had a correct EDID on the HDMI converter, unlike the Sumopai one.

It should still work for what I want to use it for, but connecting to it using VNC was just painful to do anything, expect to do all of your code development remotely or via command line.

Ugh. I wonder if you can get accelerated display if you write correct EDID data to the display. I found the troubleshooting guide below while looking up what the acronyms meant. I am glad I went with the cheap PC + nvidia 3050 route.

Once you have the best config for your hardware, please post a walkthrough to save others from the setup hassle.

I haven't made much progress on mine. I have Chartthrob modifications, and a cmdline curve modification tool I should post. I still don't have a perfect correction curve, and haven't even started on my own display software (Still using the binary @avandesande posted) I want to make the tools output AMP (pencil curve) files instead of the 18 point spline CRV. The light field of my enlarger is not completely flat which complicates making fine curve corrections.

Slightly boring story: I have a Canon Pro 10 printer which I hate. It costs $100 every few months. If I turn it off, it will spitefully dump half its ink when I turn it back on, so of course it had run out of black when I wanted to print a tax return filing extension, so I went downstairs and printed it on my digital enlarger using Kodak Ektamatic SC A which is a gorgeous lightweight fibre paper. Worked first time and was quicker than driving to Best Buy to give Canon another $100.

Troubleshooting KMS HDMI
( I am thankful that I haven't had to learn any of this ) Did you manage to repair the EDID data on your laptop display?

EDID: Extended Display Identification Data. A metadata format for display devices to describe their capabilities to a video source. The EDID data structure includes the manufacturer name and serial number, product type, physical display size, and the timings supported by the display, along with some less useful data. Some displays can have defective EDID blocks, which can cause problems if those defects are not handled by the display system.

FKMS (vc4-fkms-v3d): Fake Kernel Mode Setting. While the firmware still controls the low-level hardware (for example, the High-Definition Multimedia Interface (HDMI) ports, the Display Serial Interface (DSI), etc), standard Linux libraries are used in the kernel itself. FKMS is used by default in Buster, but is now deprecated in favour of KMS in Bullseye. Bookworm does not support Legacy or FKMS graphics stacks.

KMS: Kernel Mode Setting; see https://www.kernel.org/doc/html/latest/gpu/drm-kms.html for more details. On
Raspberry Pi, vc4-kms-v3d is a driver that implements KMS, and is often referred to as "the KMS driver".

 

[AndrewBurns]

Ugh. I wonder if you can get accelerated display if you write correct EDID data to the display. I found the troubleshooting guide below while looking up what the acronyms meant. I am glad I went with the cheap PC + nvidia 3050 route.

Once you have the best config for your hardware, please post a walkthrough to save others from the setup hassle.

I haven't made much progress on mine. I have Chartthrob modifications, and a cmdline curve modification tool I should post. I still don't have a perfect correction curve, and haven't even started on my own display software (Still using the binary @avandesande posted) I want to make the tools output AMP (pencil curve) files instead of the 18 point spline CRV. The light field of my enlarger is not completely flat which complicates making fine curve corrections.

Slightly boring story: I have a Canon Pro 10 printer which I hate. It costs $100 every few months. If I turn it off, it will spitefully dump half its ink when I turn it back on, so of course it had run out of black when I wanted to print a tax return filing extension, so I went downstairs and printed it on my digital enlarger using Kodak Ektamatic SC A which is a gorgeous lightweight fibre paper. Worked first time and was quicker than driving to Best Buy to give Canon another $100.

Troubleshooting KMS HDMI
( I am thankful that I haven't had to learn any of this ) Did you manage to repair the EDID data on your laptop display?

EDID: Extended Display Identification Data. A metadata format for display devices to describe their capabilities to a video source. The EDID data structure includes the manufacturer name and serial number, product type, physical display size, and the timings supported by the display, along with some less useful data. Some displays can have defective EDID blocks, which can cause problems if those defects are not handled by the display system.

FKMS (vc4-fkms-v3d): Fake Kernel Mode Setting. While the firmware still controls the low-level hardware (for example, the High-Definition Multimedia Interface (HDMI) ports, the Display Serial Interface (DSI), etc), standard Linux libraries are used in the kernel itself. FKMS is used by default in Buster, but is now deprecated in favour of KMS in Bullseye. Bookworm does not support Legacy or FKMS graphics stacks.

KMS: Kernel Mode Setting; see https://www.kernel.org/doc/html/latest/gpu/drm-kms.html for more details. On
Raspberry Pi, vc4-kms-v3d is a driver that implements KMS, and is often referred to as "the KMS driver".

For my laptop I simply wiped and reinstalled windows, luckily I have a NAS (network drive) that I store all my info on, and so wiping the laptop doesn't really lose anything of value.

I don't plan to try to get the display working with the latest version of Pi OS myself as what I have is working well enough for me now. The slowness only seems to be when connecting to the Pi with VNC (like remote desktop), I now have Visual Studio Code set up so that I can develop my python scripts and run them on the Pi remotely from my laptop, which is how I drive my current contract-printing setup, and that works just fine. So for now I'm considering the LCD side of my UV projector done and I need to get back to working on the rest of the optical path and cooling.

Speaking of which, does anybody know if there's a difference in image quality depending on which side of the LCD you pass light through? On my contact printing system I have the LCD around the 'correct' way, so that when you view the LCD with the light source behind it the image is displayed normally. However in my projector it would be convenient to have the LCD mounted the other way around, with light shining through it in the opposite direction such that when you viewed the image it would be horizontally flipped. As far as I know there's nothing about the LCD that means light should only go through it one way and not the other, but I don't know for sure either...