Thank you for the review.
* loader/sx280/check_compat.c looks like it shouldn't be sx280 specific. It would be good to enable the bin compat checks for other cameras in 1.4 if we can.
That would be my plan too, but
- the camera database inside (pid_leds) was made by hand and may miss a few entries. Eventually, I'd like to make this part auto-generated from a central database, such as an expanded camera_list.csv. That would avoid having to hand-edit yet another file when adding a new port.
- I'm still undecided about the action we should take when the compat check fails. We could, for example, switch off the camera, if we know how (I was experimenting with finding the equivalent of the "TurnOffE1" eventproc, but could not reach 100% detection rate and subcpu cameras need a working OS for that call).
- We have quite a few ports where the direct LED control method or the LED address is not known (because no-one has tested it). Some LEDs need to be controlled specially (for example, some old cameras need 2 GPIOs for the print LED), so choosing a known LED address does not guarantee 100% success.
* benchmark module change is unrelated to d6/sx280. It seems fine, no reason not to have it in trunk.
I'm not completely satisfied with this one either, due to the unfinished UI. The hidden options should probably be made visible somehow - I got stuck on this (there's not much screen space left and translations may need to be considered).
* is the d6 longjump code tested? errors in lua should exercise it, in something like chdkptp =return pcall(function() error('test') end=return pcall(function() error('test') end)
returns the same on sx280 and a3200, so I guess it does work. Note that lib/lua/setjmp.S comes from newlib 2.1, as is.
* update_screen_dimensions in mode_get seems like it leaves a window where CHDK could try to draw after the dimensions have changed, but before it has noticed the change. Could be OK, but maybe a risk of writing over things you shouldn't. Not clear how you'd avoid this completely if it were really a problem.
This is not a problem, because the overlay buffers are static (address and size) and not shared with anything else. DIGIC 4+ cameras may need this too (if someone wishes readable CHDK display on an output device other than the LCD).
I have noted the sx280 "cleanup" list.