add brightness argument to virtualdisplay and xdisplay_mirror

[FoamyGuy]

@jedgarpark mentioned this would be helpful for photographing the the panels.

It can make some content a bit easier on the eyes as well.

[jepler]

I'd like to figure out whether this is actually a brightness problem, a gamma problem, or something else.

My code converts all RGB565 and RGB888 framebuffers to 10 bits using a modified gamma curve with a 2.2 exponent.

I'm curious if (without modifying brightness) changing the exponent = 2.2 argument in src/include/piomatter/render.h to 1.0 gives better appearance for the case where you wan to reduce overall brightness. If a video source is "pre-corrected for gamma" then applying gamma a 2nd time would exaggerate bright colors.

second, I'm curious if adding a "fixed off time" as an alternate way to reduce brightness is better or worse. In the relevant pinout in src/include/piomatter/pins.h try setting a post_oe_delay = of some larger number than 0. I'm not sure what a good number would be, you could try 500 maybe? This should reduce global brightness but I'm not sure by how much.

[FoamyGuy]

@jepler I tried exponent=1.0 and I cannot perceive any difference in brightness with that value in place vs. 2.2

However I don't really know if I building / installing the right way or what, because I also tried changing post_oe_delay to larger values and I am not perceiving any difference with those either.

After each change that I made I ran these

pip uninstall Adafruit-Blinka-Raspberry-Pi5-Piomatter
pip install ./

I tried a handful of values for post_oe_delay and never could see a difference between them personally. I was running the virtualdisplay.py example launching mednafen with donkey kong contry rom and watching until the full green forresty scene which fills the whole screen. Eventually I started just adding more digits, the highest value I tried was 5555500.

[FoamyGuy]

I was modifying the post_oe_delay value inside of adafruit_matrix_bonnet_pinout_bgr and using the --pinout AdafruitMatrixBonnetBGR argument, I also tried --pinout AdafruitMatrixHatBGR a few times before changing to Bonnet to match the c struct exactly even though I think they are mirrored or aliased between the Hat and Bonnet.

[FoamyGuy]

Trying briefly to trace the code using post_oe_delay I found this

Adafruit_Blinka_Raspberry_Pi5_Piomatter/src/include/piomatter/render.h

Lines 229 to 230 in 0a9e578

	do_data_delay(addr_bits | pinout::oe_inactive,
	pinout::post_oe_delay);

and

Adafruit_Blinka_Raspberry_Pi5_Piomatter/src/include/piomatter/render.h

Lines 141 to 143 in 0a9e578

	auto do_data_delay = [&](uint32_t data, int32_t delay) {
	delay = std::max((delay / CLOCKS_PER_DELAY) - DELAY_OVERHEAD, 1);
	assert(delay < 1000000);

which seems like where it gets used most directly. It seems to me that some of the values I tried should trip this assert but don't seem to, I added two more 9s at the beginning of the value to be sure but still don't see any difference in behavior or assert error print out, maybe it's not expected to print or interrupt?

[jepler]

that's odd, I guess we'll have to consider your results inconclusive. well, we can put this in if it helps you, that's fine. It's just that it feels like there's a different explanation for "the brightest pixels are TOO bright" and I'd hoped we could figure it out.

[jepler]

approved with grumbles that I feel like there might still be some underlying problem here that a brightness modification of pixel values is concealing.

[FoamyGuy]

the brightest pixels are TOO bright

Your other PR seems to have resolved that issue, the bright lines of pixels were what I was seeing originally that got me interested in this.

They seemed to be helped by overall brightness lowering like this at the time, although I have gone back and forth some and seen that it didn't help in all cases either. Sometimes I would still see those even with the brightness lowered.

This brightness control also helps by lowering the overall brightness of all the pixels (at the cost of color depth, especially at lower values) which makes them easier to look at (for my eyes at least), and a bit easier to get favorable lighting to film and photograph them.