Take in framebuffer resolution, not output res

[tannewt]

Fixes #7911

[RetiredWizard]

I ran this on the Adafruit Feather RP2040 dvi and it seemed to work fine. I displayed a gif from desktop flash and an example turtle script without issue.

I was hoping I might stumble on a clue as to why the DVI+PicoW build is giving me trouble but other than learning that a color depth of 1 requires a widthxheight of 640x480 and a color depth of 8 requires 320x240 when creating a picodvi.framebuffer (either in C or python) I don't think I'm any closer.

[dglaude]

I tested all the combo I had in mind with the artifact for the Feather RP2040 DVI from this PR, and I get the result in the code comment.

I am not super fan of the error "# ValueError: Invalid width" but at least those 3 give the same value:
print("input: ", w, h, cd)
print("board: ", board.DISPLAY.width, board.DISPLAY.height)
print("disp: ", display.width, display.height)

Regards

import displayio
displayio.release_displays()

import time
import board
import picodvi
import framebufferio
from bitmaptools import draw_line

for i in range(10):
    print("Sleep out of 10: ", i)
    time.sleep(1)

w=320; h=240; cd=8 # OK 320 240 8
w=320; h=240; cd=2 # ValueError: Invalid width
w=320; h=240; cd=1 # ValueError: Invalid width
w=640; h=480; cd=1 # OK 640 480 1
w=640; h=480; cd=2 # OK 640 480 2
w=800; h=480; cd=1 # OK 800 480 1
w=800; h=480; cd=2 # OK 800 480 2
w=400; h=240; cd=8 # MemoryError: memory allocation failed, allocating 110412 bytes
w=400; h=240; cd=2 # ValueError: Invalid width
w=400; h=240; cd=1 # ValueError: Invalid width

fb = picodvi.Framebuffer(
    width=w, height=h, color_depth=cd,
    clk_dp=board.CKP, clk_dn=board.CKN,
    red_dp=board.D0P, red_dn=board.D0N,
    green_dp=board.D1P, green_dn=board.D1N,
    blue_dp=board.D2P, blue_dn=board.D2N)

display = framebufferio.FramebufferDisplay(fb)

print("")
print("input: ", w, h, cd)
print("board: ", board.DISPLAY.width, board.DISPLAY.height)
print("disp:  ", display.width, display.height)

for i in range(3):
    time.sleep(i)

[tannewt]

@dglaude Would Invalid color_depth make more sense?

[tannewt]

Ok, this should be ready for review. Thanks for the testing! It'll raise Invalid color_depth if the resolution is correct but the color_depth doesn't match.

[dhalbert]

I tested with more or less @dglaude's code above, and got what I expected

It's a bit weird to me that 320x240 with a color depth of 1 or 2 doesn't work, but I guess that's the way it is.

[tannewt]

We could implement it but PicoDVI doesn't by default.

[RetiredWizard]

I also tested with the above code and it worked as expected. I did notice one peculiarity, If you set the framebuffer to any of the sizes greater than 320x240, pressing ctrl-D and then attempting to run the code with another framebuffer size greater than 320x240 but different than the one you just used caused a memory error. Pressing ctrl-D again, after getting the memory error and pasting in the same code that just gave you the error then succeeds.

[dhalbert]

I saw the memory errors too, but I thought it was because the buffer was deliberately persistent across VM's.

[RetiredWizard]

There did seem to be some correlation with the persistence of the DVI output across Ctrl-D restarts but I didn't do it enough times to figure out the relationship. I was changing framebuffer sizes most times and it didn't seem like the DVI output survived most ctrl-D restarts but it did sometimes.....

[dglaude]

I am fine with "Invalid color_depth" or anything, really.

I had the same memory issue (I guess)... this is why I have that count-down.
For each test I started from power on, that is the time I needed to get to the console in time to see the message.

I did not try to understand the random memory allocation issue... could it be that the REPL use the DVI output and block reuse? I don't know much how ^D interact with memory management.

I was thinking the allocation error were due to some fragmentation, assuming some stuff stay allocated and block big allocation?

Is this memory thing a blocker for this PR?

My guess is that it was the same behavior as before the PR and unrelated to making x and y more easy to understand.

[tannewt]

I think the memory issue does have to do with the buffer outside the VM heap vs inside. I don't know of a good way to fix it.