CHDK Forum
CHDK Development => General Discussion and Assistance => Topic started by: srsa_4c on 13 / March / 2016, 20:03:42
-
My aim with this topic is to start a discussion on improvement possibilities of the CHDK display routines, focusing on DIGIC 6.
I only have some ideas, but no complete plan.
Difficulties on D6:
- framebuffers are larger, resolutions and aspect ratios are different
- the "final" overlay consists of 2 separate buffers (bitmap is YUV (2 pixels share chroma), alpha channel is in a separate buffer)
- these are used by current CHDK routines
- shared chroma makes drawing difficult - the source buffer is also available (RGBA), but it's unknown how to transfer its content to the "final" overlay
- buffer dimensions change when switching to a different output device (LCD, video out, HDMI)
- this one does not seem to make problems - reading bytes from uncached RAM seems very slow
- not currently a problem, but good to know when searching for solutions - no known simple way to erase the whole overlay
- the current workaround is to display and remove a known and almost empty Canon dialog box - D6 has a dedicated core for drawing overlay
- there is some sort of communication between ARM and that core
- finding out more about those communication routines would likely improve our display possibilities
CHDK:
- all drawing ends up using a single pixel drawing routine
- not optimal for performance, but easy to manage and overview
- current D6 routine is ugly and slow - some CHDK features do read (and store) parts of the overlay
- on D6, this would require huge amounts of memory
The sx280 has the lowest frame buffer resolution: 640x480 in LCD mode. An easy way to handle this would be using half resolutions is one or both directions. I chose not to do that, because 320x240 is just too low for my taste. On the other hand, the g7x's lowest resolution is 720x480, drawing with half (quarter) resolution would yield a familiar 360x240 dots.
What I'm considering
- adding the possibility of different "default" fonts, more suitable for higher resolutions
- using faster routines for drawing text
I have an RBF font utility in the works. Also managed to export the default CHDK font to RBF (to my surprise, it appears to be a subset of unicode characters). If it's really unicode, it will likely be possible to make higher resolution variants (does somebody know where the CHDK font comes from?).
Sorry about the lengthy and messy post.
edit: this post looks worse than I anticipated. Repeated newlines don't get displayed, there's huge space between paragraphs...
-
Thanks for starting this. I haven't really dug into the display code much yet, I hope to get into that a bit more now that I have most of the basic functionality working.
- D6 has a dedicated core for drawing overlay
- there is some sort of communication between ARM and that core
finding out more about those communication routines would likely improve our display possibilities
In the 3rd dryos ROM in both the sx280h and g7x dumps, I found
"TAKUMI Corporation"
"GV550"
Which looks like an IP core GPU http://www.gshark.com/en/products/gv550/index.html (http://www.gshark.com/en/products/gv550/index.html)
This is the same ROM with references to OpenGL ES. Since this is an IP core people license to integrate in their own chips, it seems unlikely we'll find much in the way of documentation.
The binary gk.log generated along with the romlog appears to be related to the GPU.
The main ROM display code on G3X and G5X seems to be quite different from other D6 cams, although it still has the GV550 string mentioned above. Other r57 cams code seems to be similar to g7x / sx280.
-
In the 3rd dryos ROM in both the sx280h and g7x dumps, I found
"TAKUMI Corporation"
"GV550"
Which looks like an IP core GPU http://www.gshark.com/en/products/gv550/index.html (http://www.gshark.com/en/products/gv550/index.html)
This is the same ROM with references to OpenGL ES. Since this is an IP core people license to integrate in their own chips, it seems unlikely we'll find much in the way of documentation.
The binary gk.log generated along with the romlog appears to be related to the GPU.
I'm somewhat confused about this D6 display stuff. I'm assuming the 3rd core is not _the_ GPU, because it runs DryOS. If this is true, then I would expect the 3rd core to interface the GPU and the (ARM<->graph) message routines I mentioned should then be a the interface to Canon's display routines running on the 3rd core...?
-
I'm somewhat confused about this D6 display stuff.
Me too.
I'm assuming the 3rd core is not _the_ GPU, because it runs DryOS. If this is true, then I would expect the 3rd core to interface the GPU and the (ARM<->graph) message routines I mentioned should then be a the interface to Canon's display routines running on the 3rd core...?
That's pretty much what I've been guessing, but it's just a guess at this point.
-
I have an RBF font utility in the works. Also managed to export the default CHDK font to RBF (to my surprise, it appears to be a subset of unicode characters).
Almost unicode, some non-alphabet characters differ though.
I still don't know what the source of CHDK default font is, but I have noticed similarity to some (PC) text mode bitmap fonts.
I'm now able to create and use different fonts (https://chdk.setepontos.com/index.php?topic=12813.msg127604#msg127604)* as CHDK built-in font. Two examples attached, one is "PxPlus IBM VGA8" from this site (http://int10h.org/oldschool-pc-fonts/), the other is unifont (http://czyborra.com/unifont/). Both were converted from their truetype versions.
edit:
*limited to the current 8x16 pixels. Extending built-in font support to larger fonts is still todo.
edit2:
link added
-
I still don't know what the source of CHDK default font is, but I have noticed similarity to some (PC) text mode bitmap fonts.
Finally found the source. It's called Terminus (http://terminus-font.sourceforge.net/). It also has higher resolution variants, so it will be possible to keep it as default font.
-
I'm not sure if this should go in this thread, or the digic 6 thread (https://chdk.setepontos.com/index.php?topic=11316.80)
@Ant me asked (in PM)
When do you plan to add into CHDK support for Digic6 pixel format?
We realy need it:
https://chdk.setepontos.com/index.php?topic=12532.msg129205#msg129205
Short answer:
I'm supposed to have plans?! :haha
Longer answer:
There are a number of interrelated issues, which will require someone to spend a significant amount of time. At the moment, my time for CHDK is limited and tends to be in short chunks. I will continue working on bits and pieces as I have time, but I don't have a specific plan.
srsa_4c's OP in this thread, and reply in the thread Ant linked (quoted below) cover some of the main issues
One of the difficulties is that parts of the CHDK code still expect a one byte/pixel overlay. Some routines (maybe zebra, edge overlay) save and restore parts of the overlay during their activity - that is currently impossible on D6 (the overlay data not only has a different pixel format, it also has opacity information in a separate buffer). And of course, the drawing routines need to be optimized for greater speed. All this would have to be solved before "fixing" zebra and edge overlay.
IMO, the stuff that needs to be done falls in a few general categories
1) Do the reverse engineering to find what we need digic 6
We have most of the buffers of interest, but we still need to figure out how to refresh the display without the busy hack. We also don't know how to get the current buffer for the viewports.
It's possible that further investigation would let us use the RGBA buffer rather than split alpha/YUV. Further work on the Zico/Mzrm/GPU (see https://chdk.setepontos.com/index.php?topic=11316.80) may open up alternative approaches.
2) Resolve how to handle different display types in CHDK code, especially in modules
We could use the THUMB_FW ifdef in modules, but this will break if different D6 cameras have different requirements.
We could build separate modules for different display types, either with ifdefs in the same source, or entirely separate files.
We could (maybe) implement generic methods in the core so modules don't need anything display specific, but this would likely impact performance and code size.
This is a "boring" code organization issue, but as the person who ends up trying to keep several hundred CHDK ports usable and maintainable, it matters to me.
3) Implement the actual code to do what we need on d6
E.g. getting the right values out of the different YUV formats, drawing the zebra/histogram/edge, saving/restoring buffers or changing the code to not need it.
-
Looking at @62ndidiot 's motion detection code (https://chdk.setepontos.com/index.php?topic=12918.0) I realized the current digic 6 ports (including my g7x port) define vid_get_viewport_width and vid_get_viewport_height as the actual sizes (counting by Y values, as returned by GetVRAMHPixelsSize etc)
In older ports, _width is half the real width, and height is half if the real height is more than 240 (and yscale is set to 2). The _proper functions return the real width/height, primarily for PTP live view. The history is complicated, but it stems from the original cameras had a 720x240 viewport and a 360x240 bitmap. Using half width for the viewport allows a 1:1 correspondence, and results in roughly square pixels. Canon added different permutations of viewport and bitmap later and we added workarounds to mostly keep the same "logical" screen layout.
We haven't run into problems with this yet for the D6 ports, because the functions that depend on it being that way don't work for other reasons.
I'm not sure if it makes sense to keep the difference between the CHDK and _proper dimensions for D6, but we should make a specific decision. (we can always make a different specific decision later if the first turns out to be bad ;))
For the moment, I'm inclined to leave _width and _height the real values, and see how it goes.
In any case, the _proper values should always be the real values, not 2x the real value as some currently are. yscale should also be 1 if the height is the real height.
Thread on viewport / bitmap functions in general https://chdk.setepontos.com/index.php?topic=12709.0
-
An observation from working on live view: The "focus peaking" display does not appear in either the viewport or bitmap, unless it's encoded in a way that goes away in the YUV conversion.
The same is true for the playback mode zebra, for both d6 and older cam.
-
On EOS cameras, digic 4 and 5, playback zebras are implemented with 0xC0F140CC (http://magiclantern.wikia.com/wiki/Register_Map/60D), and there is some sharpening done on the entire screen with 0xC0F14140 (https://chdk.setepontos.com/index.php?topic=12086.msg118373#msg118373) (EnableFilter string). The effect of these changes is only visible on the display, not in the image buffers - they appear to be computed by the display device (the one that combines the BMP and YUV buffers, probably some FPGA). Zebras are applied on the YUV buffer only, while the sharpening is applied on the BMP image as well.
Note: on 5D3, playback zebras are implemented with 0xC0F14140 in firmware 1.1.3 and 0xC0F14394 on 1.2.3. This is why I guess the display device is probably not a hardcoded ASIC, but something reconfigurable.
Do you have "hardware" focus peaking on any compacts before digic 6?
-
Thanks for the zebra info.
Do you have "hardware" focus peaking on any compacts before digic 6?
AFAIK no. I could be wrong, but I don't see any mention in the G15 or G1x manuals.
-
There is variable on EOS M3 that can turn on/off focus peaking (0x0000F9D8 for fw.v1.0.1)
-
The current drawing code uses active_bitmap_buffer as an index into opacity_buffer (without the &1 vid_get_active_bitmap_buffer uses :-[).
:-[
This is - partly - my fault (the original draw_pixel_std() also does that). It should probably be fixed as it can cause unpleasant surprises, especially for in-progress ports.
Doing the &1 operation may introduce some overhead in the pixel drawing routine - we could perhaps introduce a variable for (active_bitmap_buffer&1) and only update it in the spytask loop?
-
:-[
This is - partly - my fault (the original draw_pixel_std() also does that). It should probably be fixed as it can cause unpleasant surprises, especially for in-progress ports.
FWIW, on G7X at least it seams active_bitmap_buffer is only 0 or 1. But yes, results could be catastrophic if it ever had other values.
Doing the &1 operation may introduce some overhead in the pixel drawing routine -
Hmm, 1 register->register instruction only, but for every single pixel... still, it's should be much faster than the cams that write on both buffers. So I'm OK just having the &1 in gui_draw.c.
For d6 draw_pixel_std I'd probably calculate the current buffer once at the start.
we could perhaps introduce a variable for (active_bitmap_buffer&1) and only update it in the spytask loop?
Some drawing is also done in kbd_task. We could update in both, or just be OK with it being out of date some times.
If we do this, I'd suggest storing actual buffer addresses (bitmap for all, also opacity for d6), not just the index. Then they could just do something like
gui_draw_bitmap_buffer=vid_get_bitmap_active_buffer();
gui_draw_opacity_buffer=vid_get_opacity_active_buffer();
and the low level firmware variables would never have to be exposed.
I lean a little to the second option, but I don't have strong preference.
-
FWIW, on G7X at least it seams active_bitmap_buffer is only 0 or 1. But yes, results could be catastrophic if it ever had other values.
active_bitmap_buffer is declared as int (which is a good choice for speed reasons). If someone doing a port chooses a fw var that is not an int ... - something like this may have caused the never ending failures of the sx700 port.
Hmm, 1 register->register instruction only, but for every single pixel... still, it's should be much faster than the cams that write on both buffers. So I'm OK just having the &1 in gui_draw.c.
For d6 draw_pixel_std I'd probably calculate the current buffer once at the start.
we could perhaps introduce a variable for (active_bitmap_buffer&1) and only update it in the spytask loop?
Some drawing is also done in kbd_task. We could update in both, or just be OK with it being out of date some times.
If we do this, I'd suggest storing actual buffer addresses (bitmap for all, also opacity for d6), not just the index. Then they could just do something like
gui_draw_bitmap_buffer=vid_get_bitmap_active_buffer();
gui_draw_opacity_buffer=vid_get_opacity_active_buffer();
and the low level firmware variables would never have to be exposed.
I guess your suggestion could further reduce the instruction count of draw_pixel_std() - I'd check the disassembly of the possible code variants and the benchmark too.
... and hope that it doesn't break the sx230. One of my theories is that some DIGIC 4 revisions have problems with accessing the same memory area via uncached CPU accesses and DMA (EDMAC) at the same time. I think one of the ML ports (500d?) suffers from something similar. edit: yes, src/zebra.c waveform_draw_image()
-
Doing the &1 operation may introduce some overhead in the pixel drawing routine -
Hmm, 1 register->register instruction only, but for every single pixel... still, it's should be much faster than the cams that write on both buffers. So I'm OK just having the &1 in gui_draw.c.
I have experimented with this a bit, and ended up with the following:
Index: core/gui_draw.c
===================================================================
--- core/gui_draw.c (revision 4702)
+++ core/gui_draw.c (working copy)
@@ -40,7 +40,7 @@
register int cli = cl ^ 0xffffffff;
extern volatile char *opacity_buffer[];
- //extern int active_bitmap_buffer;
+ int active_buffer_index = active_bitmap_buffer & 1;
static unsigned int prev_offs = 0xffffffff;
register unsigned int offs2 = (offset>>1)<<2;
if (cli != 0xffffffff)
@@ -47,39 +47,39 @@
{
if (prev_offs != offs2)
{
- bitmap_buffer[active_bitmap_buffer][offs2+2] = 0x80-((((int)cli)<<5)&0xe0); // U?
- bitmap_buffer[active_bitmap_buffer][offs2+0] = 0x80-((((int)cli)<<2)&0xe0); // V?
+ bitmap_buffer[active_buffer_index][offs2+2] = 0x80-((((int)cli)<<5)&0xe0); // U?
+ bitmap_buffer[active_buffer_index][offs2+0] = 0x80-((((int)cli)<<2)&0xe0); // V?
prev_offs = offs2;
}
if (offset&1) // x is odd
{
- bitmap_buffer[active_bitmap_buffer][offs2+3] = (cli&0xc0); // Y
+ bitmap_buffer[active_buffer_index][offs2+3] = (cli&0xc0); // Y
}
else // x is even
{
- bitmap_buffer[active_bitmap_buffer][offs2+1] = (cli&0xc0); // Y
+ bitmap_buffer[active_buffer_index][offs2+1] = (cli&0xc0); // Y
}
// simple transparency
- opacity_buffer[active_bitmap_buffer][offset] = (cli&16)?0x60:0xff;
+ opacity_buffer[active_buffer_index][offset] = (cli&16)?0x60:0xff;
}
else // color==0, black, fully transparent
{
if (prev_offs != offs2)
{
- bitmap_buffer[active_bitmap_buffer][offs2+2] = 0x80; // U?
- bitmap_buffer[active_bitmap_buffer][offs2+0] = 0x80; // V?
+ bitmap_buffer[active_buffer_index][offs2+2] = 0x80; // U?
+ bitmap_buffer[active_buffer_index][offs2+0] = 0x80; // V?
prev_offs = offs2;
}
if (offset&1) // x is odd
{
- bitmap_buffer[active_bitmap_buffer][offs2+3] = 0; // Y
+ bitmap_buffer[active_buffer_index][offs2+3] = 0; // Y
}
else // x is even
{
- bitmap_buffer[active_bitmap_buffer][offs2+1] = 0; // Y
+ bitmap_buffer[active_buffer_index][offs2+1] = 0; // Y
}
// fully transparent
- opacity_buffer[active_bitmap_buffer][offset] = 0;
+ opacity_buffer[active_buffer_index][offset] = 0;
}
#endif
}
Introducing a local variable for the buffer index seems to speed up drawing a little, even with the added AND operation. Approx. +2.7 %, according to benchmark runs.
-
I have experimented with this a bit, and ended up with the following:
...
Introducing a local variable for the buffer index seems to speed up drawing a little, even with the added AND operation. Approx. +2.7 %, according to benchmark runs.
Thanks. Seems fine to me.
Faster is nice, but I wouldn't be much worried about performance unless it was a lot slower.
FWIW, it didn't affect the G7X MD crash.
-
Thanks. Seems fine to me.
Committed (https://app.assembla.com/spaces/chdk/subversion/commits/4704). Good news for people trying to port a D6 camera.
-
Found a full-screen Canon "dialog" that's just black and displays no text or graphical stuff. It's similar to DisplayBusyOnScreen - that means only one instance of it can exist, further attempts to display it again are ignored.
Seems like it doesn't exist on older DryOS (and VxWorks) cameras.
It's in the same library as DisplayBusyOnScreen (assert indicates the same source file). Can be found almost right after DisplayBusyOnScreen, UndisplayBusyOnScreen.
Examples (display_blank_screen, undisplay_blank_screen):
a3200 100d: 0xff8a1974 (seems unreferenced), 0xff8a1a14
sx280 102b: 0xfc14a2af, 0xfc14a327
m10 110d: 0xfc3274a1, 0xfc327541
Stuff I tried (sx280):
- display_blank_screen
- fill opacity buffers with 0 (just once)
- overlay disappears, viewport buffers (play or rec mode) become visible (and stay so)
...
- undisplay_blank_screen
- Canon overlay comes back
Above doesn't work from scripts (because CHDK issues several screen redraws while running scripts).
From memory, certain Canon graphical elements (e.g. low battery symbol) are positioned on top of any other screen elements, so those can disrupt the experience.
What could we do with the extra full screen dialog?
- fire it up in ALT mode and enjoy flickerless display
When a full screen dialog is visible, it's possible that changes to the source bitmap overlay (likely RGBA on DIGIC 6) are automatically copied onto the YUV and opacity buffers (this is just theory, may not actually work)*.
- display it when other full screen CHDK activity is going on (zebra, edge overlay, etc)
Update.
Turns out, DisplayBusyOnScreen and display_blank_screen use the same dialog resource and event callback. The resource contains (reference to) a hand icon and the "Busy" text, display_blank_screen hides both before displaying the dialog. No luck finding a background color property yet.
edit:
* Indeed, that's not working (tried on a DIGIC 4 cam).
edit2:
Pretty much everything written above can be disregarded. The firmware always redraws the whole overlay when it moves the focus rectangle around, even when the black dialog is on top and covers everything.
-
I'm trying a different approach to enlarge the font size on DIGIC 6 ports.
Cams with 3:2 or wider display will simply (not so simply, actually) use the current built-in font, at 200% magnification (16x32).
For the few models that have unfortunate 640x480 overlay, I'm planning to magnify the 8x16 font to 14x32. The horizontal part seems to be working (see image), hopefully it won't screw up non-Latin glyphs.
edit:
First implementation is working, draws ~5500 char/s with the default pixel drawing routine (to be improved).
Turns out, all D6 ports will have to use the same font size due to the way CHDK source is organized and built.
First try to implement a lookup-table based draw_pixel_std() routine was an utter failure (turned out to be slower than the current one that computes the colors).
-
On EOS M3 I use modified argnor32.rbf from Magic Lantern.
But it doesn't contain non latin glyphs.
(https://chdk.setepontos.com/index.php?action=dlattach;topic=12788.0;attach=13690)
Why CHDK doesn't use Canon fonts?
-
On EOS M3 I use modified argnor32.rbf from Magic Lantern.
But it doesn't contain non latin glyphs.
You could convert just about any font you'd like (there are 2 rbf converter utilities). Why are you using a partial font that even has ML-specific chars in place of accented chars?
Why CHDK doesn't use Canon fonts?
1) Because "we" don't know how.
2) They are too large and may lack some characters we're using.
I only see one potential use - if someone made a non-ASCII version of CHDK (Chinese, Japanese, Arabic, etc.).
-
Why are you using a partial font that even has ML-specific chars in place of accented chars?
Because it was "found" on my SD card in ML directory. :)
Because "we" don't know how.
https://chdk.setepontos.com/index.php?topic=6204.0
https://bitbucket.org/hudson/magic-lantern/src/8e0d34d81dc1ebfb08176de6bb3ee3715c4f5c10/src/bmp.c?at=unified&fileviewer=file-view-default#bmp.c-942
-
https://chdk.setepontos.com/index.php?topic=6204.0
https://bitbucket.org/hudson/magic-lantern/src/8e0d34d81dc1ebfb08176de6bb3ee3715c4f5c10/src/bmp.c?at=unified&fileviewer=file-view-default#bmp.c-942
Okay, it now only needs CHDK integration then (plus implementing font detection in finsig's, ...).
Meanwhile, I'm now wasting the second day in a row trying to improve draw_pixel_std(). Should I ever finish, next item to look at will be the draw_pixel_proc() and draw_pixel_proc_norm() replaceable functions, and their impact on my plans to introduce optimized multi-pixel drawing routines...
In case someone knows a faster method to draw on uyvy framebuffers, don't hesitate to tell.
edit:
What I currently have is this (only tested it on my sx280 with 14x32 font size), gets me ~5900 chars/sec (was ~5560 chars/sec prior to optimization).
static void draw_pixel_std(unsigned int offset, color cl)
{
#ifndef THUMB_FW
// drawing on 8bpp paletted overlay
#ifdef DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY
bitmap_buffer[active_bitmap_buffer][offset] = cl;
#else
frame_buffer[0][offset] = frame_buffer[1][offset] = cl;
#endif
#else
// DIGIC 6, drawing on 16bpp YUV overlay
#ifndef DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY
#error DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY is required for DIGIC 6 ports
#endif
register int cli = cl ^ 0xffffffff;
extern volatile char *opacity_buffer[];
int active_buffer_index = active_bitmap_buffer & 1;
unsigned char *obu = (unsigned char *)(&opacity_buffer[active_buffer_index][0]);
unsigned char *bbu = (unsigned char *)(&bitmap_buffer[active_buffer_index][0]);
if (cl)
{
// this gets one transparent gray
obu[offset] = ((cl)&0xf0)==0xb0?0xc0:0xff;
register unsigned int offs2 = (offset>>1)<<2;
if (offset&1) // x is odd
{
bbu[offs2+3] = (cli&0xc0); // Y
}
else // x is even
{
bbu[offs2+2] = 0x80-((((int)cli)<<5)&0xe0); // V?
bbu[offs2+0] = 0x80-((((int)cli)<<2)&0xe0); // U?
bbu[offs2+1] = (cli&0xc0); // Y
}
}
else // color==0, black, fully transparent
{
// fully transparent
obu[offset] = 0;
register unsigned int offs2 = (offset>>1)<<2;
if (offset&1) // x is odd
{
bbu[offs2+3] = 0; // Y
}
else // x is even
{
bbu[offs2+1] = 0; // Y
}
{
bbu[offs2+2] = 0x80; // U?
bbu[offs2+0] = 0x80; // V?
}
}
#endif
}
Odd pixels only get intensity and opacity. Reading from uncached RAM, manipulating it then writing it back would be a significant performance hit (I tried that too).
-
What would be the effect if you treated all pixels equally, writing one byte Y , one byte chroma, one byte opacity? Surely this is no worse than writing two bytes chroma for even pixels and no bytes chroma for odd? Would it cause flickering?
The act of writing a single pixel of a certain color just isnt well defined, it will affect the color of its sibling pixel.
Really you are always affecting pairs of pixels.
-
What would be the effect if you treated all pixels equally, writing one byte Y , one byte chroma, one byte opacity? Surely this is no worse than writing two bytes chroma for even pixels and no bytes chroma for odd?
I tried, could not make it work faster (per benchmark) than the version that writes unequal amount of bytes. Also, anything using lookup tables turned out to be slower - the reason behind this could be that the lookup table was placed far from the function and the compiler used indirect references to it (would have been more efficient with ADR instructions and nearby table).
If you're bored, you can experiment with it - it's always possible that I'm overseeing something.
The act of writing a single pixel of a certain color just isnt well defined, it will affect the color of its sibling pixel. Really you are always affecting pairs of pixels.
True, but only seems to matter when drawing thin vertical lines.
Latest version - finally a usable palette and 5976 chars/sec @ 14x32 font on the sx280. The version decoded by chdkptp (attached) just doesn't look like it does on the LCD.
static void draw_pixel_std(unsigned int offset, color cl)
{
#ifndef THUMB_FW
// drawing on 8bpp paletted overlay
#ifdef DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY
bitmap_buffer[active_bitmap_buffer][offset] = cl;
#else
frame_buffer[0][offset] = frame_buffer[1][offset] = cl;
#endif
#else
// DIGIC 6, drawing on 16bpp YUV overlay
#ifndef DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY
#error DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY is required for DIGIC 6 ports
#endif
extern volatile char *opacity_buffer[];
int active_buffer_index = active_bitmap_buffer & 1;
unsigned char *obu = (unsigned char *)(&opacity_buffer[active_buffer_index][0]);
unsigned char *bbu = (unsigned char *)(&bitmap_buffer[active_buffer_index][0]);
unsigned int cli = (cl+1);
unsigned int clm = (cl-1)^0xffffffff;
unsigned int clu = (clm)&0xf0;
obu[offset] = (cl&0xf)?255:cl;
register unsigned int offs2 = (offset>>1)<<2;
if (offset&1) // x is odd
{
bbu[offs2+3] = clu; // Y
}
else // x is even
{
if (!(cli&2))
{
cli = 128;
clm = 128;
}
else
{
cli *= 5;
clm <<= 2;
}
bbu[offs2+1] = clu; // Y
bbu[offs2+0] = cli; // U?
bbu[offs2+2] = clm; // V?
}
#endif
}
Here's the matching palette (platform/sx280/platform_palette.c). May need adjustment on other models.
// Playback mode colors
unsigned char ply_colors[] =
{
COLOR_TRANSPARENT, // Placeholder for script colors
COLOR_BLACK, // Placeholder for script colors
0x0f, // White
0xce, // Red
0xd1, // Dark Red
0x81, // Light Red
0x71, // Green
0xae, // Dark Green
0x3e, // Light Green
0xfe, // Blue
0xf1, // Dark Blue
0x2e, // Light Blue / Cyan
0x74, // Grey
0xb4, // Dark Grey
0x34, // Light Grey
0x01, // Yellow
0x41, // Dark Yellow
0x0e, // Light Yellow
0xb0, // Transparent Dark Grey
0x8e, // Magenta
};
// Record mode colors
unsigned char rec_colors[] =
{
COLOR_TRANSPARENT, // Placeholder for script colors
COLOR_BLACK, // Placeholder for script colors
0x0f, // White
0xce, // Red
0xd1, // Dark Red
0x81, // Light Red
0x71, // Green
0xae, // Dark Green
0x3e, // Light Green
0xfe, // Blue
0xf1, // Dark Blue
0x2e, // Light Blue / Cyan
0x74, // Grey
0xb4, // Dark Grey
0x34, // Light Grey
0x01, // Yellow
0x41, // Dark Yellow
0x0e, // Light Yellow
0xb0, // Transparent Dark Grey
0x8e, // Magenta
};
I saw the zebra+everything patch, I'll get to that later - still working on pixel + font drawing stuff.
-
As far as "blinking" the bitmap buffer goes, is it necessary to write 0x80 0x00 0x80 0x00 (uYvY) everywhere as well as to zero the opacity buffer, or would zeroing the opacity buffer be sufficient?
This might help with the problem of thin vertical lines if you can disappear a pixel by using opacity.
-
As far as "blinking" the bitmap buffer goes, is it necessary to write 0x80 0x00 0x80 0x00 (uYvY) everywhere as well as to zero the opacity buffer, or would zeroing the opacity buffer be sufficient?
You could find out by modifying one of the drawing functions. IIRC, when I was first attempting to display something on the sx280, I was able to see a faint overlay without even modifying the opacity buffer. Visibility may depend on the content of the viewport and/or the overlay's luminance.
This might help with the problem of thin vertical lines if you can disappear a pixel by using opacity.
I'm not too concerned about thin standalone vertical lines - I don't think they're very common on the CHDK UI.
-
I tried modifying the blink function in zebra to only zero the opacity buffer (and not write a transparent color to the bitmap). It doesn't work. Can't say I understand why though. So we still rely on the nice functionality of bzero4 :)
-
Attached is an experimental patch that - for simplicity - treats the DIGIC 6 overlay as if it were quarter resolution (half horizontally and half vertically). Only used my sx280 to test. As a said repeatedly, I find the resulting look rather unpleasant. Not only does this make the CHDK overlay visibly pixelated, but fonts are also wider than they were on pre-DIGIC 6 cams.
On cameras with 640x480 overlay, 40 characters fit in a row. Again, that's barely sufficient - file browser columns don't fit, various extensions display clipped lines, menu entries get cut short.
On the plus side, it can be done simply and most drawing routines can be left unchanged. It's also quick, ~11850 chars/sec on the sx280, according to the benchmark, without any optimization.
The other way (keeping full resolution) is still not done completely - many drawing operations need to be optimized to keep drawing speed acceptable. It also changes drawing infrastructure considerably - optimized drawing requires separate drawing functions instead of a single draw_pixel_std().
-
Attached is an experimental patch that - for simplicity - treats the DIGIC 6 overlay as if it were quarter resolution (half horizontally and half vertically). Only used my sx280 to test.
I'm far enough in the G16 port that I could probably test this. The text is very small on the G16 screen - it's the first port where I've selected a larger RBF font for the menus.
But any time I feel like complaining, I fire up my really old A560. Now that was a painful display to read!
-
Attached is the first (in progress) hi-res version of the DIGIC 6 drawing routines. platform_palette.c has to be modified on every D6 port, and it's recommended to reset the CHDK OSD related config. The bult-in 8x16 font is upscaled to 14x32. It doesn't look too pretty, but I think it's usable. Added bonus is that scalable OSD elements can be set to use the unscaled 8x16 font.
Drawing of the built-in font is accelerated for 8x16 and 14x32 sizes.
Zebra, etc. is not integrated yet.
-
Attached patch integrates 62ndidiot's zebra, histogram and motion detection developments into the hi-res DIGIC 6 display patch (platform_palette.c and the two stubs have to be added to other ports). I have only made changes to the zebra code, did not change the other two. Also renamed bzero4 to memset32 and changed the exported gui_draw routines.
I suspect that the routines I'm currently using for zebra may not be the final ones - I'm not sure if they are optimal.
-
Attached patch integrates 62ndidiot's zebra, histogram and motion detection developments into the hi-res DIGIC 6 display patch (platform_palette.c and the two stubs have to be added to other ports). I have only made changes to the zebra code, did not change the other two. Also renamed bzero4 to memset32 and changed the exported gui_draw routines.
Downloaded and built for sx60hs. Seems to work fine. The menu fonts and ALT screen stuff is easier to read.
Some compiler warnings in gui_draw.c, that I don't recall seeing before:
./../../../core/gui_draw.c: In function 'set_transparent':
../../../../core/gui_draw.c:108:5: warning: passing argument 1 of '_bzero' discards 'volatile' qualifier from pointer target type [enabled by default]
_bzero(&opacity_buffer[active_buffer_index][offset], n_pixel);
^
../../../../core/gui_draw.c:99:17: note: expected 'char *' but argument is of type 'volatile char *'
extern void _bzero(char *s, int n);
^
../../../../core/gui_draw.c: In function 'draw_2pixels_simple':
../../../../core/gui_draw.c:267:27: warning: initialization from incompatible pointer type [enabled by default]
unsigned short *obu = current_opacity_buf;
^
../../../../core/gui_draw.c:268:25: warning: initialization from incompatible pointer type [enabled by default]
unsigned int *bbu = current_bitmap_buf;
^
../../../../core/gui_draw.c: In function 'draw_hline_simple':
../../../../core/gui_draw.c:306:28: warning: initialization from incompatible pointer type [enabled by default]
unsigned short *obud = current_opacity_buf;
^
../../../../core/gui_draw.c:307:26: warning: initialization from incompatible pointer type [enabled by default]
unsigned int *bbud = current_bitmap_buf;
-
Downloaded and built for sx60hs. Seems to work fine. The menu fonts and ALT screen stuff is easier to read.
Some compiler warnings in gui_draw.c, that I don't recall seeing before:
Thanks for trying. The warnings are due to some missing casts.
-
An explanation of this DIGIC 6 display "rework".
What it provides:
Display a big default font that is approximately same size as on previous DIGIC cams.
This is achieved by upscaling the original 8x16 font to 14x32. The 8 -> 14 conversion allows keeping the aspect ratio and provides 45 characters in a row (which is what cameras with 4:3 LCD used to have).
The font remains stored in its original 8x16 format.
The real display resolution is used.
Historically, supported Powershots started with an overlay of 360x240 pixels. Horizontal resolution was doubled in later camera generations, for which CHDK was adapted by writing double pixels. That has not changed further until the appearance of DIGIC 6.
I felt that halving the CHDK overlay resolution yet again is not the way to go, even if it's simpler to do.
Unfortunately, the CHDK drawing architecture relies heavily on paletted display where one pixel corresponds to one byte.
This patch therefore has to translate one byte colors to yuv chroma and luma values (plus opacity).
Pros:
- Default font is "normal" size again, should be more readable.
- Drawing is accelerated for the default font. Over 19000 (14000) chars/second according to benchmark - lower value is for drawing with unaligned (odd) starting position.
- OSD icons (battery, USB symbol, etc) are doubled (in each direction).
- CHDK menu and other UI elements fit on screen like they used to on previous camera generations.
- Palette is still computed, but almost all required CHDK colors are available.
- OSD elements can be set to use the unscaled "mini" 8x16 font, using the OSD editor.
- ...?
Cons:
- The 8 -> 14 translation introduces a distortion that changes the font's look somewhat.
- Accelerated drawing bypasses the old drawing infrastructure. Pixels of the default font are no longer drawn by a single pixel drawer routine. This is a very unfortunate loss, but I found no better way to improve the sluggish drawing speed.
- Drawing function replacement is ineffective for font drawing. It was only used by the zebra module. The new zebra code (made by 62ndidiot) does not use it.
- Accelerated routines (those with "simple" in their name) rely on global variables for current buffer addresses and foreground and background colors. This makes drawing even less thread safe (but I can't imagine it causing memory corruption).
- The new routines used by the new D6 zebra code "stand out", as they draw yuv colors directly, rather than CHDK ones. This is actually a change introduced by me.
- One of the D6 zebra specific new routine uses two stubs directly in core. This would be unsafe on ARM firmware, but doing so provides lower overhead and is safe on D6.
- The three D6 zebra specific functions are exported and require dummies on pre-D6 ports. This is an unfortunate overhead - the module specific tools would need to be changed to allow skipping nonexistent exports.
- The current D6 zebra can't display the histogram (those menu options are ignored).
- The new histogram (62ndidiot's work) has an inappropriate default position (not completely visible). Should be fixable.
- The CHDK boot logo doesn't display correctly, the bitmap part is unscaled and misplaced. Should be fixable.
- Some games use direct coordinates expecting 8x16 fonts - they look mostly unusable.
- ...?
The patch also contains a fix for a bug introduced with the (relatively recent) rotated OSD functionality. Just check what the file reader does when OSD is rotated.
62ndidiot's zebra, histogram and motion detection fixes are included, as noted above.
The patch does not support D6 ports other than my two, but the changes made to the M10 port should tell what to do (palette and two stubs).
BTW, I did not do this work to let it become buried here and forgotten. I'd like to hear others' opinions: should this go official, and if so, should parts of it change or not.
The alternative patch can be found earlier in this thread (the lo-res one).
edit:
I have doubts about the attachment download counter. It jumped to one right after posting (in a few seconds). A google-bot maybe?
-
The new histogram (62ndidiot's work) has an inappropriate default position (not completely visible). Should be fixable.
Feel free to adjust the default position as you see fit in order to make a complete patch.
I'll retry this patch in a few days on the sx60hs.
Is there any generic way we can make this patch work for all digic 6 cams without by hand changes for updates in the platform specific directory?
I think it works very well and is a real improvement over the existing graphics. thanks so much!!
-
BTW, I did not do this work to let it become buried here and forgotten. I'd like to hear others' opinions: should this go official, and if so, should parts of it change or not.
I'll take a look at both patches on the G16 and weigh in with my opinion. Won't be until next weekend though. I have been using an alternative menu font so I'm looking forward to trying a better solution.
-
An explanation of this DIGIC 6 display "rework".
Thanks so much for doing this, as well as the detailed write up :)
I probably won't be able to dig into it much before next weekend, I have few initial comments that don't depend on getting into the code. It does build and run on G7 X (following the M10 example)
If we feel like this is the right direction, I'm fine with it going into the trunk with some unresolved issues.
I felt that halving the CHDK overlay resolution yet again is not the way to go, even if it's simpler to do.
That's my feeling too.
- The 8 -> 14 translation introduces a distortion that changes the font's look somewhat.
I think this is OK. I did notice the font looked a bit ugly compared to the large one I was using for the menu before, but it's readable and certainly better than the tiny font in the old version.
- The new routines used by the new D6 zebra code "stand out", as they draw yuv colors directly, rather than CHDK ones. This is actually a change introduced by me.
I think this is fine (conceptually at least, I haven't looked at the specific code) I would rather have separate code that makes sense for each platform than a tangle of stuff that tries to maximize re-use.
- One of the D6 zebra specific new routine uses two stubs directly in core. This would be unsafe on ARM firmware, but doing so provides lower overhead and is safe on D6.
_bzero / _memset32 are quite simple functions, we could have our own versions in CHDK, or even inline them in the drawing function if it helps.
Anyway, no immediate worry. Would be nice to be able to generate build errors if someone did the same thing in a pre-digic 6 build.
- The three D6 zebra specific functions are exported and require dummies on pre-D6 ports. This is an unfortunate overhead - the module specific tools would need to be changed to allow skipping nonexistent exports.
We may want to deal with this in the future, especially if we end up with more functions like this, but with only 3 I don't think it needs to be addressed right away.
- The current D6 zebra can't display the histogram (those menu options are ignored).
It's better than having neither ;)
One thing I did notice about the zebra on g7x is that I had to set the thresholds quite high (25+ for both over and under) to see the zebra, even when pointing at a light in a dark room.
-
- The current D6 zebra can't display the histogram (those menu options are ignored).
It's better than having neither ;)
Does the CHDK histogram do anything that the Canon one does not? I've been under the impression that histogram was added in the early days of CHDK when it was not common for Canon firmware to provide one. But I'm guessing every D6 camera will include a Canon histogram so maybe it could be dropped from the D6 CHDK builds?
-
Does the CHDK histogram do anything that the Canon one does not?
I wondered the same thing.
-
Does the CHDK histogram do anything that the Canon one does not?
Yes: Various RGB modes, log scale, auto-scaling, over/under indicators ...
How useful these things are is a different question.
I've been under the impression that histogram was added in the early days of CHDK when it was not common for Canon firmware to provide one.
Yes.
But I'm guessing every D6 camera will include a Canon histogram so maybe it could be dropped from the D6 CHDK builds?
I'm not sure if this is true of the lower end D6 cameras. The SX280 manual only mentions the playback histogram.
-
I'm not sure if this is true of the lower end D6 cameras. The SX280 manual only mentions the playback histogram.
Correct, there's no live histogram in the sx280 (and, according to the manual, the followup models don't have it either).
Feel free to adjust the default position as you see fit in order to make a complete patch.
Items with "should be fixable" note will eventually get fixed sooner or later.
Is there any generic way we can make this patch work for all digic 6 cams without by hand changes for updates in the platform specific directory?
That would require a generic palette header for D6, probably in include/. The two stubs could go in stubs_entry.S (but I don't know the thumb2 sigfinder enough to do it).
One thing I did notice about the zebra on g7x is that I had to set the thresholds quite high (25+ for both over and under) to see the zebra, even when pointing at a light in a dark room.
This seems camera model dependent. The sx280 also needs high thresholds, but the sx60 and m10 do not.
-
That would require a generic palette header for D6, probably in include/.
Since (as far as I understand) the palette code should be the same for all, that seems like it would be a good idea anyway.
The two stubs could go in stubs_entry.S (but I don't know the thumb2 sigfinder enough to do it).
I can add these quickly, but just for information:
Ones that already appear in the CSV, you should be able to just remove the UNUSED in sig_names. The OPTIONAL should also be removed if it's expected to be needed in every port. memset32 probably needs a new match type in sig_rules.
-
It might be safe to say memset32 equals bzero +4 since the sigfinder will find bzero matches anyway.
-
I added both to the sig finder.
-
Here's the latest version of the patch, adapted to current trunk.
The only change is that I've removed the useless camera specific platform_palette.c and platform_palette.h files and placed a generic d6 palette in platform/generic/palette.c (which is referenced in makefile_platform.inc).
No other platform changes are needed.
-
Here's the latest version of the patch, adapted to current trunk.
Nice - I'm a fan ! New vs old on my G16.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FjBx7WYm.jpg&hash=08f8c870e98f211f06a8c6699e166165)
Colors are better on this one - have not played with a custom palette for the G16.
Also, I wasn't able to get the d6_display_lores_on_sx280_v1.diff version to work well - looked like buffer sizes were wrong - so I gave up on that one.
-
I spent a bit more time looking at this.
The only think I think is a must-have before checking in is to ensure MD for pre-digic 6 cameras is not broken. I've attached an updated patch that uses two completely separate implementations of md_detect_motion. Tested OK on G7X and SX160.
The updated patch also cleans up some trailing whitespace that caused extra noise in the histogram diff, removes the unneeded vid_get_bitmap_active_palette from G7X.
I tested the histogram R G B displays using the same test page I used for MD, seems OK.
I would prefer the unrelated OSD rotate fix be checked in separately.
Other thoughts (nothing that needs to be addressed before checking in)
direct access to things like bitmap_buffer[active_buffer_index] in gui_draw.c concern me a bit, because the logic required to get the current buffer could easily change in future cameras. Wrapping in a lib.c function lets ports handle that, at the cost of function call overhead.
An alternate approach would be to have a CHDK variable that is only updated at defined points: e.g. before every gui redraw, and/or every kbd_task iteration. The canon firmware swapping buffers in the middle of a gui_redraw could cause some parts to be drawn on the "wrong" buffer, but I'm not sure how bad it would be in practice. A better solution would be to find a way to hooked into something that gets called when the canon firmware actually swaps buffers. Being able to use the current buffer directly without any index etc could provide a slight performance benefit.
platform dependent #defines in module code are proliferating, specifically the font size stuff. This technically OK if it only depends on THUMB_FW, but it's going to be easy to forget and accidentally make a change that makes the modules no longer platform independent.
register is almost certainly ignored by the compiler, and if it's not, is very likely to do more harm than good (I know existing code uses it too).
Using THUMB_FW to represent both the instruction set and display architecture also seems likely to bite us in the future. I have ideas about this, but it's probably a topic for another post.
- The CHDK boot logo doesn't display correctly, the bitmap part is unscaled and misplaced. Should be fixable.
A simple workaround would be to just disable the logo and have the text only splash screen.
jog dial control in the OSD editor is added, should be documented.
-
Thanks for the comments.
Also, I wasn't able to get the d6_display_lores_on_sx280_v1.diff version to work well - looked like buffer sizes were wrong - so I gave up on that one.
I agree that setting up the required display dimensions for the lo-res "rework" is a bit frustrating - the sx280 parts of that patch were meant to give hints on what to do.
The only think I think is a must-have before checking in is to ensure MD for pre-digic 6 cameras is not broken. I've attached an updated patch that uses two completely separate implementations of md_detect_motion. Tested OK on G7X and SX160.
Did the CHDKPTP based test on the sx280 and checked that motion is still detected on the ixus115. It was not a very thorough test though.
An alternate approach would be to have a CHDK variable that is only updated at defined points: e.g. before every gui redraw, and/or every kbd_task iteration.
I actually tried something similar to this earlier, on the sx280.
First attempt was to read and store the current buffer in a spytask hook (the get_mode one). It did not work at all - hook was called before vid_bitmap_refresh() request in spytask, which flipped buffers and most of drawing went into the wrong buffer.
Second attempt was reading current buffer in vid_bitmap_refresh(), after the busyonscreen procedures. This one worked better, but was not 100% reliable.
Did not try doing it from a different task (or a timer).
platform dependent #defines in module code are proliferating, specifically the font size stuff.
Unfortunately, font size is hardcoded (using macros) rather than being part of some camera_info structure. I did not feel like changing that at this moment - it could easily affect some calculations and compile time optimizations.
This technically OK if it only depends on THUMB_FW, but it's going to be easy to forget and accidentally make a change that makes the modules no longer platform independent.
That happened already - some games look now quite broken due to unexpected font size.
Using THUMB_FW to represent both the instruction set and display architecture also seems likely to bite us in the future. I have ideas about this, but it's probably a topic for another post.
I was using a separate #define for yuv overlay before the D6 support was integrated in trunk. I chose to remove it at one point (the sx280 was the only D6 port at that time).
jog dial control in the OSD editor is added, should be documented.
I only put that in because I wanted to use something that could replace the missing zoom buttons on my M10. Could probably stay because it can be operated faster than the zoom/halfshoot buttons.
-
Thanks for the comments.
Also, I wasn't able to get the d6_display_lores_on_sx280_v1.diff version to work well - looked like buffer sizes were wrong - so I gave up on that one.
I agree that setting up the required display dimensions for the lo-res "rework" is a bit frustrating - the sx280 parts of that patch were meant to give hints on what to do.
Yes - thanks for the hints. We both know the value of those when exploring new territory. I gave up on spending any time at all on the low-res version once you posted the newer hires versions.
-
An alternate approach would be to have a CHDK variable that is only updated at defined points: e.g. before every gui redraw, and/or every kbd_task iteration.
I actually tried something similar to this earlier, on the sx280.
Understood. I'm fine with the current code being added, it's just something I worry about biting us later.
That happened already - some games look now quite broken due to unexpected font size.
I think this is a different issue. It would be good to fix the games, but I'm not to worried about them.
What I meant was modules for a given instruction set are currently identical, no matter what camera they were built for. Having a hard rule of "no ifdefs in module code" made it easier to recognize mistakes that would break this. Again, I'm not asking for any change right now, just worrying out loud about about how to keep it maintainable ;)
Using THUMB_FW to represent both the instruction set and display architecture also seems likely to bite us in the future. I have ideas about this, but it's probably a topic for another post.
I was using a separate #define for yuv overlay before the D6 support was integrated in trunk. I chose to remove it at one point (the sx280 was the only D6 port at that time).
Yeah, without a solution to the module issue (how we define modules for a specific display type, rather than instruction set), it's probably not worth it.
jog dial control in the OSD editor is added, should be documented.
I only put that in because I wanted to use something that could replace the missing zoom buttons on my M10. Could probably stay because it can be operated faster than the zoom/halfshoot buttons.
Makes sense, I have no objection to it being added.
-
I somehow doubt low res on a hires display is much faster. Still got the same number of pixels to manage. Hi res is the right choice, it looks nicer.
I'm very happy with the progress everyone has made and I'm looking forward to when we can solve the flickering and correct bitmap buffer "timing" issues. Recall we do have a directly accessible memory pointer to the current buffer.
-
I'm looking forward to when we can solve the flickering
Well, this has been an issue as long as there has been CHDK. I think it's worse now as recent processors update the display buffers more often.
But the fact that we have not been able to find calls that let us add stuff to the display buffer such that it does not get erased on refresh is a big limitation. For the most part, we have been bypassing the Canon code and writing directly to the display buffers. And getting erased after each Canon update to the display.
FWIW, there is of course an option to simply write to the display buffer a lot more often. But that option has been "shot down in flames" in the past as taking too much CPU time. But IIRC, there has never been a measurement of how much it takes, or how much is "too much". It's been more an intellectual good code practice argument IMHO.
At some point, I've intended to go back through a couple of my ports and see what vid_bitmap_refresh() , vid_turn_off_updates() , and vid_turn_on_updates() really do if they are nulsub'd out.
-
One bit of display related code I'd forgotten about is autoiso.c live_histogram_read_y, used by custom auto ISO and lua get_live_histo
I checked in code for this in r4777, it shouldn't interact with srsa_4c's patch at all.
I tested get_live_histo to verify that it returns expected results on new and old cameras.
-
I somehow doubt low res on a hires display is much faster.
The aim of the lo-res patch was to show an alternative that does not screw up the existing drawing architecture. It has a satisfactory drawing speed. But, as I mentioned, I don't like it because of the resulting pixelated look and short text lines.
But IIRC, there has never been a measurement of how much it takes, or how much is "too much".
You can have an idea by using the benchmark (text output, especially "FPS").
-
But IIRC, there has never been a measurement of how much it takes, or how much is "too much".
You can have an idea by using the benchmark (text output, especially "FPS").
I could do that. But I gave up.
Frankly, I don't care if CHDK sucks down almost 100% of the CPU if it fixes flicker - other than when the shutter key is pressed or a script is running. Both easily detected and dealt with. If continuous AF runs slow as a result, so be it.
But I don't expect to win that argument.
-
Would it be possible to run a watchdog task that cycles more frequently than 30 msec? A very simple task to monitor changes in the active buffer address say every 10 msec and trigger an update from chdk.
-
Would it be possible to run a watchdog task that cycles more frequently than 30 msec? A very simple task to monitor changes in the active buffer address say every 10 msec and trigger an update from chdk.
Sure, physw should theoretically run every 10ms (but might not in some case), or you could create your own task just for this purpose. How "trigger an update" would actually be implemented would need some thought though.
The digic 6 code has more problems than the usual flickering though.
-
How "trigger an update" would actually be implemented would need some thought though.
Isn't that essentially what philmoz's draw_test_guard() & draw_set_guard() code in core/gui_draw.c tries to do?
-
I must misunderstand something here. If the primary update task executes every 30ms, that's about 30fps. We should not be able to see flickering at that rate. Worst case 30ms pass before the chdk stuff is redrawn. Or is the average/worst case actually much worse, like 80/250ms?
-
I must misunderstand something here. If the primary update task executes every 30ms, that's about 30fps. We should not be able to see flickering at that rate. Worst case 30ms pass before the chdk stuff is redrawn. Or is the average/worst case actually much worse, like 80/250ms?
The update task does not redraw the screen each time it runs. The code I referenced in my previous post can detect some limited situations where a redraw is needed. But for the most part the display info is only written once and not refreshed.
-
I must misunderstand something here. If the primary update task executes every 30ms, that's about 30fps. We should not be able to see flickering at that rate. Worst case 30ms pass before the chdk stuff is redrawn. Or is the average/worst case actually much worse, like 80/250ms?
Drawing is done in spytask. It cycles approx. 50 times a second because of this
msleep(20);in its main loop. GUI is refreshed in every fourth cycle:
if (((cnt++) & 3) == 0)
gui_redraw();
edit:
The guard pixel based forced redraw is only used in a few CHDK GUI modes (don't remember the proper terminology), such as the CHDK menu. It can only detect when the top left pixel of the overlay is erased.
edit2:
And of course, spytask is in core/main.c
-
I must misunderstand something here. If the primary update task executes every 30ms, that's about 30fps.
No. See the main loop in core/main.c
Spytask tries to run at 20 ms intervals (but of course, it might not if the system is busy), and gui_redraw runs once every 4 spytask iterations. So yes, 80 ms.
We should not be able to see flickering at that rate.
This is not really true. Around 30 FPS is about where animation of similar images appears smooth, but that's not what's happening here.
Isn't that essentially what philmoz's draw_test_guard() & draw_set_guard() code in core/gui_draw.c tries to do?
That tries to detect when an update is needed, but it doesn't make the update happen sooner than it otherwise would in the 80ms cycle. You could set a flag skip the "every 4th iteration" logic. You could also trigger a redraw with some kind of synchronization object, or directly from whatever task was detecting the need for updates, but spytask does more than drawing, so this might take some work.
Frankly, I don't care if CHDK sucks down almost 100% of the CPU if it fixes flicker
I don't think simply upping the frame rate would help that much, but you could try making gui_redraw run every iteration and see what happens.
- other than when the shutter key is pressed or a script is running. Both easily detected and dealt with. If continuous AF runs slow as a result, so be it.
I don't really agree with this: The Canon UI getting laggy is really annoying, and this already happens on G7X when the Canon and CHDK UIs are fighting. Also, I don't think it's safe assume that the Canon firmware will degrade gracefully (i.e. continuous AF just runs a bit slower) if CHDK hogs the CPU.
Making the UI smooth is a worthy goal, but aside from the D6 specific issues, it's a bit OT for this thread. IMO, to make it really look good, we'd have to actually integrate with the Canon drawing system (probably involving the "controller" system, or maybe something with the GPU code on D6), but if there are other changes that offer a significant improvement without negative side effects, I'd certainly consider them.
-
Watching my sx60hs display flicker under conditions of maximum Canon Ui activity, I think I see some periodicity: about 3 flickers than a pause then 3 more every 2-3 seconds, indicating the Canon Ui and chdk differ in frequency by an approximately constant number of hertz.
-
Getting back to srsa_4c's patch: I don't see any reason it shouldn't be checked in. I seems like the right direction and it will be easier to continue development with it in the main source. With the MD update I think the risk of breaking pre digic 6 cameras is low.
-
Getting back to srsa_4c's patch: I don't see any reason it shouldn't be checked in. I seems like the right direction and it will be easier to continue development with it in the main source. With the MD update I think the risk of breaking pre digic 6 cameras is low.
I think I should have said "check it in if it seems good enough".
Anyway, some new concerns, not on my previous list:
- the draw_hline() rotated OSD fix causes approx. 0.5% drop in character drawing performance on pre-D6 cameras, due to the added check
- decisions based on font size are inconsistent
Examples:
core/gui_draw.c draw_icon_cmds()
modules/gui_osd_edit.c
I checked in (https://app.assembla.com/spaces/chdk/subversion/commits/4779) the draw_hline() fix regardless, because I have no immediate idea on improving performance.
I would prefer the unrelated OSD rotate fix be checked in separately.
You can proceed with the rest, changed or unchanged.
-
You can proceed with the rest, changed or unchanged.
OK, I checked it in as-is in 4780. Thanks again for putting this together.
- the draw_hline() rotated OSD fix causes approx. 0.5% drop in character drawing performance on pre-D6 cameras, due to the added check
I checked in the draw_hline() fix regardless, because I have no immediate idea on improving performance.
I'm wouldn't worry about a fraction of a % performance difference to fix a bug.
- decisions based on font size are inconsistent
core/gui_draw.c draw_icon_cmds()
modules/gui_osd_edit.c
I'm not sure I follow. Do you mean using #ifs vs runtime, or something else?
-
So now we need to verify histogram and zebra. Fix histogram default position?
-
So now we need to verify histogram and zebra. Fix histogram default position?
It's not bad unless you the R G B mode, but it would be good to match the other cams I guess.
The other display related item left is edge overlay. I know you and ant had code for this. The last one I tried didn't erase properly when updating live (on the initial half press) but otherwise seemed OK.
-
I think @ant s version of edge overlay and mine were equivalent. In hindsight, ant's is easier to maintain and verify since it cleanly separates digic 6 code form pre digic 6 with little intermingling.
As for erasing, that needs to be worked on I guess. I confess to not really understanding how edge overlay is used. It may be as simple as adding a call to the new gui_draw routine "set_transparent" at the appropriate point.
-
I think @ant s version of edge overlay and mine were equivalent.
Attached is the one I tried. It still applies and builds cleanly with the current code.
As for erasing, that needs to be worked on I guess. I confess to not really understanding how edge overlay is used.
It's confusing, I had to go back to the manual (http://chdk.wikia.com/wiki/CHDK_User_Manual#Edge_Overlay_.28panorama_tool.29). But it definitely shouldn't fill up the screen with old edges when you have half-press held for the first shot. This may not be obvious if the canon firmware OSD is updating frequently too, since it would blow away the stale edges.
-
- decisions based on font size are inconsistent
core/gui_draw.c draw_icon_cmds()
modules/gui_osd_edit.c
I'm not sure I follow. Do you mean using #ifs vs runtime, or something else?
Unfortunate wording.
In draw_icon_cmds() I used this:
if (FONT_HEIGHT > 16)to choose between doubled or unchanged coordinates. Perhaps a separate #define would be more appropriate.
In modules/gui_osd_edit.c, I put in a bunch of #if's like this
#if (FONT_HEIGHT <= FONT_REAL_HEIGHT)which will need to be fixed if the default font is changed to a native resolution one (if that ever happens).
-
The edge overlay drawing issue happens because draw_get_pixel_unrotated is noop in digic, and the edge code uses this to erase pixels that don't correspond to edges.
I checked in Ant's code, since I don't see an obvious quick fix and it works reasonably well if you don't move the camera around when edge is live.
-
I've noticed occasional crashes on G7x that appear to be related to drawbusyonscreen
These seem to happen switching between play and rec over ptp. Haven't had time to look into it yet.
Example romlog attached.
edit:
Added a second romlog I annotated previously
-
I've noticed occasional crashes on G7x that appear to be related to drawbusyonscreen These seem to happen switching between play and rec over ptp. Haven't had time to look into it yet.
I think that I've finally tracked down some pseudo-random G16 crashes (usually when entering ALT) to vid_bitmap_refresh(). It uses _displaybusyonscreen() and _undisplaybusyonscreen().
If I comment out those routine things seem to be much more stable but the screen gets messy.
edit : take this with a "grain of salt" - early port with lots of other stuff broken
-
I've noticed occasional crashes on G7x that appear to be related to drawbusyonscreen
These seem to happen switching between play and rec over ptp. Haven't had time to look into it yet.
Example romlog attached.
Looks like a failed sanity check on a pointer to a dialog item, bit0 is set -> corrupted or invalid pointer.
The busy dialog does have a few dialog items: an icon and the "busy" text (there might be other components that qualify as dialog items).
I realize that getting rid of the busy screen hack would be a major step forward, but I, unfortunately, still have no idea about a good replacement.
-
I (re?) discovered another feature of the drawbusyonscreen hack. The Canon firmware ignores key presses generated when the busy dialog is shown.
This means that if CHDK does something that generates a key press and also refreshes the screen (like sending a click in chdkptp), it is likely to be ignored. Worse, in some cases only the release is missed, making the Canon firmware think the button is held down.
Initially I thought g7x just needed CAM_KEY_PRESS_DELAY, but increasing it up to 140 didn't make the problem go away. It does help a bit.
With displaybusyonscreen/undisplaybusyonscreen commented out of lib.c, key presses work fine using the standard delay, but of course screen refresh is totally hosed.
-
Some research on DIGIC 6 overlay (sx280).
I have managed to log all messages sent to the 'graphic core'. Also logged the messages' content.
Unfortunately, none of this did uncover anything usable.
Sending messages consists of two phases:
- creating the message (uses a message ID (3rd argument in the sx280 version), message length, a handle (or pointer) and a message type(?) ).
I named the function that is used to do this 'mzrm_createmsg'. It can be recognized by the "[Mzrm]CreateWait" debug string.
The function allocates the requested message area and returns a pointer to it.
The returned area starts with a mandatory header, 3 words: ID, type(?), length, which adds to the requested size.
- sending the message (uses the same handle as 'mzrm_createmsg' plus the pointer returned by 'mzrm_createmsg')
Can be identified by looking for "[Mzrm]SendWait". I named it 'mzrm_sendmsg'.
It also returns a value (I'm not sure yet how longer responses are retrieved).
All messaging functions call the above 2 functions.
The message ID - message name translation requires the message name table from the Xtensa blob - related post is https://chdk.setepontos.com/index.php?topic=11316.msg129104#msg129104 .
sx280 version is attached here: https://chdk.setepontos.com/index.php?topic=11316.msg129051#msg129051
g7x version is here: https://chdk.setepontos.com/index.php?topic=11316.msg129344#msg129344
Both mzrm_createmsg and mzrm_sendmsg start with a call to TakeSemaphore, which is located in RAM - can be hacked.
My current guess on the MZRM acronym is: [M]arius (main ARM core), [Z]ico (graphic core), [R]?, [M]essaging
Captures are attached, showing the sx280 booting up to playback mode with a photo displayed, plus CHDK activity caused by its (Un)DisplayBusyOnScreen calls.
Both captures include a USB cable insertion which erases the screen without showing "ScreenLock" and its friends in the camera log.
Line structure of the basic (shorter) capture is: system tick, message, LR (return address), task name
The longer capture adds more info (call stack, message content).
Messages have more and less obvious parts.
Framebuffer addresses and dimensions (640, 480) are recognizable. ROM addresses are also present, which may indicate that the Xtensa also sees the ROM.
A stream of messages usually ends with these 3 messages:
GraphicSystemCoreFinish, JediFinish, XimrExe
Unless I missed something, the addresses of 'our' overlay buffers (YUV+opacity) only show up in XimrExe messages. That X might mean 'transfer'.
Camera log during the detailed capture:
00000320: UI:LogicalEvent:0x5006:adr:0,Para:0
00000400: UI:Initialized WindowSystem.
00000400: UI:ScreenLock
00000400: UI:ScreenUnLock
00000410: UI:LogicalEvent:0x300a:adr:0,Para:0
00000410: UI:DispSwCon_TurnOnBackLight
00000410: UI:TurnOnBackLight
00000420: UI:CECConnectCnt
00000420: UI:HDMIConnectCnt
00000420: UI:MuteOffPhysicalScreen
00000420: UI:LogicalEvent:0x3139:adr:0,Para:0
00000460: UI:PB.Create
00000640: UI:LogicalEvent:0x301c:adr:0,Para:0
00000650: UI:PB.CreateE
00000650: UI:AC:StartPB
00000650: UI:DispSwCon_TurnOnDisplayDevice
00000650: UI:AC:EBtn
00000650: UI:PB.Start
00000650: UI:ScreenLock
00000650: UI:DSIC:47,0
00000650: UI:CC_CompFlhJpg
00000650: UI:_CompFlhJpg
00000650: UI:PB.Flash
00000650: UI:PB.S_Meta
00000650: UI:DSIC:47,0
00000650: UI:LogicalEvent:0x3201:adr:0,Para:0
00000650: UI:ScreenUnLock
00000660: UI:LogicalEvent:0x320b:adr:0,Para:0
00000660: UI:PB.StartE
00000660: UI:DisplayPhysicalScreenCBR
00000660: UI:DispSw: Unlock
00000660: UI:DispSwCon:Unlock
00000660: UI:DispSwCon_TurnOnBackLight
00000660: UI:DispSwCon_MuteOffPhysicalScreen
00000660: UI:Window MuteOff
00000660: UI:MuteOffPhysicalScreen
00000660: UI:DSIC:ed,0
00000660: UI:AC:EnryPB
00000660: UI:AP:ChkCnctUSB
00000660: UI:PB.DPOF
00000660: UI:DisplayPhysicalScreenCBR
00000670: UI:LogicalEvent:0x3221:adr:0x194b080,Para:26521728
00000670: UI:PB.MAX_ID
00000670: UI:PB.RefPB
00000670: UI:ScreenLock
00000670: UI:DSIC:47,0
00001060: UI:PB.DrawI
00001120: UI:LogicalEvent:0x3220:adr:0,Para:0
00001120: UI:PB.CTG
00001190: UI:LogicalEvent:0x666f:adr:0,Para:0
00001250: UI:LogicalEvent:0x3204:adr:0,Para:0
00001250: UI:PB.Check
00001260: UI:PB.DcdCBR
00001260: UI:DSIC:48,0
00001260: UI:PB.RfrsI
00001260: UI:PB.F_Dec
00001260: UI:LogicalEvent:0x3202:adr:0,Para:0
00001260: UI:ScreenUnLock
00001330: UI:DSIC:48,0
00001330: UI:DispSw: Unlock
00001330: UI:DispSwCon_TurnOnBackLight
00001330: UI:DispSwCon_MuteOffPhysicalScreen
00001330: UI:Window MuteOff
00001330: UI:MuteOffPhysicalScreen
00001330: UI:DisplayPhysicalScreenCBR
00002300: UI:ScreenLock
00002320: UI:ScreenUnLock
00002370: UI:DisplayPhysicalScreenCBR
00004140: UI:Button:0x000010B3:ConnectUSBCable
00004140: UI:IsWirelessConnect?:0
00004140: UI:ChkStoreLens
00004140: UI:IntPcCnct
00004140: UI:DlvrUSBCnct
00004140: UI:_CnctUSBCBR
00004190: UI:LogicalEvent:0x3138:adr:0,Para:0
00004200: UI:LogicalEvent:0x5005:adr:0,Para:0
00004200: PTPRspnd.StartUpPTPFrameworkClient
00007570: UI:ScreenLock
00007590: UI:ScreenUnLock
00007650: UI:DisplayPhysicalScreenCBR
00008220: UI:ScreenLock
00008240: UI:ScreenUnLock
00008300: UI:DisplayPhysicalScreenCBR
00009210: System.Create
00009210: StartRedirectUART
00009230: Printf
00009230: ShowCameraLog
-
I think I found it.
Attached patch replaces the old DisplayBusyOnScreen-based vid_bitmap_refresh() on the sx280. It works by copying the "source" RGBA overlay over the active overlay buffers. The fw function I found sends out the GraphicSystemCoreFinish, JediFinish, XimrExe messages, and it only takes a single argument.
I'm currently test-driving this method, but have not found any glitches so far.
I'd like to note that the functions involved are heavy stack users, but so were the busy dialog functions.
I think this might enable us to use the RGBA buffer directly, but I'm not sure yet.
edit:
g16 101a: 0xFC15A05B
m3 101a: 0xFC37ECA3 (looks a bit different, but the m3 is newer codebase)
sx60 100f: 0xFC337089 (also looks newer)
g7x 100d: 0xFC36168B (also newer)
Confirm address by using disasm before using, though.
-
I'm currently test-driving this method, but have not found any glitches so far.
Sorry - have not been following this thread closely. I can test on the G16 but I'm not really sure what I should expect. What does this do?
-
Sorry - have not been following this thread closely. I can test on the G16 but I'm not really sure what I should expect. What does this do?
In short: no more busyonscreen (see the patch for details).
-
Sorry - have not been following this thread closely. I can test on the G16 but I'm not really sure what I should expect. What does this do?
In short: no more busyonscreen (see the patch for details).
So I guess I need ask what "busyonscreen" looks like? Now that I look for it, I assume it's the open hand icon with a line through it and the word Busy that appears briefly when I go in & out of <ALT> mode? Is it a problem or just annoying (disappears in fractions of a second on the G16)?
-
So I guess I need ask what "busyonscreen" looks like? Now that I look for it, I assume it's the open hand icon with a line through it and the word Busy that appears briefly when I go in & out of <ALT> mode? Is it a problem or just annoying (disappears in fractions of a second on the G16)?
It's both annoying and a problem too. If I recall correctly, you may have been one of the persons who reported crashes that seemed to be related to the busy dialog.
edit:
Yep. https://chdk.setepontos.com/index.php?topic=12788.msg132369#msg132369
-
It works on M3 but still conflicting with canon's histogram and electronic level.
There need a synchronization with canon's GUI...
-
It's both annoying and a problem too. If I recall correctly, you may have been one of the persons who reported crashes that seemed to be related to the busy dialog.
Good enough for me - I wasn't questioning the need, just trying to understand the scope.
edit: Yep. https://chdk.setepontos.com/index.php?topic=12788.msg132369#msg132369
edit : take this with a "grain of salt" - early port with lots of other stuff broken
i.e. unconfirmed :)
In any case, your patch works seamlessly on my G16 1.01c (routine at 0xfc15a093 - thanks for pointing the way in your original post. The 1.00h uses the same address as the 1.01a). No more "busyonscreen" popping in & out. Nice!
-
edit: Yep. https://chdk.setepontos.com/index.php?topic=12788.msg132369#msg132369
edit : take this with a "grain of salt" - early port with lots of other stuff broken
i.e. unconfirmed :)
Crashes in the displaybusyonscreen function are confirmed on other cameras. It also messes up key handling: https://chdk.setepontos.com/index.php?topic=12788.msg133780#msg133780
-
reyalp
If you'll decide to apply new patches, here is the one for M3.
-
I think this might enable us to use the RGBA buffer directly, but I'm not sure yet.
Well, yes and no.
It looks like the firmware only updates parts of this overlay that actually change. That means, the old (single) guard pixel based detection (which parts of CHDK currently use) would not be usable on the RGBA buffer.
It works on M3 but still conflicting with canon's histogram and electronic level.
That is caused by the firmware continuously updating the overlay. It has no relation to our screen erase method.
There need a synchronization with canon's GUI...
That would not help much as we can't write our OSD fast enough.
Some completely new method might work. Such as
- creating a valid Canon full screen "dialog" that has its own content (say, a bitmap that we provide) and is always visible
- creating a similar layer, but using the Xtensa side API
Sadly, the difficulty to research/accomplish these is pretty high.
-
It looks like the firmware only updates parts of this overlay that actually change.
But your voltmeter script (that uses _LCDMsg_SetStr) causes flickering of all CHDK OSD elements and menu.
-
I think I found it.
Attached patch replaces the old DisplayBusyOnScreen-based vid_bitmap_refresh() on the sx280. It works by copying the "source" RGBA overlay over the active overlay buffers. The fw function I found sends out the GraphicSystemCoreFinish, JediFinish, XimrExe messages, and it only takes a single argument.
Nice job :D
On g7x, this works, and resolves the key press issue I mentioned earlier.
I noticed in Auto mode (where the canon firmware updates the focus box all the time) leaving alt mode with the CHDK menu open sometimes results in a flashing copy of the menu. Similarly, sometimes the <alt> indicator will flash for a long time after leaving alt mode.
I don't see this with the displaybusy code. Both flash while the menu is open, but only the new function shows a stale copy of the menu flashing after leaving alt. It looks like the focus box updates swap buffers without clearing the rest of the screen.
Doing something something that updates more of the Canon UI (like pressing SET) makes it go away.
-
I spent some time unsuccessfully trying to draw directly with Zico
The various Zico messages (https://chdk.setepontos.com/index.php?topic=11316.80) have wrappers call mzrm_createmsg, package up the parameters, and call mzrm_sendmsg.
A bunch of these call seemingly simple drawing functions (GrypDrawDot, GrypDrawHLine) which I hoped to call directly. However, I wasn't able to get GrypDrawHLine to do anything with various guessed arguments and sequences of Flush/Finish calls, in a loop of 50 calls with a 10ms sleep. Little surprise this didn't work since I couldn't find examples in the firmware of a correct sequence.
-
works on SX60HS. Nice! :D
It would be interesting to catalog messages for various video modes (and other modes as well), just to see if we can make sense of the arguments and syntax. I'm assuming I can find your message logging code somewhere up this thread?
Will this function be in the sigfinder soon? I already modified my stubs_entry_2.S for each firmware, but it'll probably be redundant.
-
Will this function be in the sigfinder soon?
I'm working on it.
I'm curious if anyone else sees what I'm seeing on g7x, with the menu flashing after leaving alt mode.
-
I'm curious if anyone else sees what I'm seeing on g7x, with the menu flashing after leaving alt mode.
On M3 it's ok excepting movie mode(when AF is on) and canon's histogram.
-
I'm curious if anyone else sees what I'm seeing on g7x, with the menu flashing after leaving alt mode.
I tried a few times an SX60 to reproduce this in Auto mode (shoot) with ALT and menu. The screen is flickering quite a bit, but leaving Alt mode seems to just behave normally. No ghosts.
-
It looks like the firmware only updates parts of this overlay that actually change.
But your voltmeter script (that uses _LCDMsg_SetStr) causes flickering of all CHDK OSD elements and menu.
I filled a part of the RGBA overlay(s) using memset. The Canon OSD did not erase parts that fell outside the playback mode overlay, while browsing images. It only got overwritten when I entered the Canon menu.
I noticed in Auto mode (where the canon firmware updates the focus box all the time) leaving alt mode with the CHDK menu open sometimes results in a flashing copy of the menu. Similarly, sometimes the <alt> indicator will flash for a long time after leaving alt mode.
I managed to reproduce something similar on the M10. "Scene intelligent auto" and "hybrid auto" modes seem to be affected, but it's not easy to reproduce.
What's likely happening (IMHO) is that we are refreshing the wrong buffer (because the firmware happens to flip them while we're trying).
I could think of 2 possible workarounds:
1) try using a different active_bitmap_buffer (for example, the M10 has another very similarly acting fw variable at offset +4)
2) refresh both buffers
I tried 2) on M10 and now I don't seem to get visible glitches.
The sx280 seems to act differently, the only problem I encountered (once) so far was when I exited ALT while the Canon menu was active: upon exiting the Canon menu, the CHDK menu appeared on the fading remains of the Canon one.
A bunch of these call seemingly simple drawing functions (GrypDrawDot, GrypDrawHLine) which I hoped to call directly. However, I wasn't able to get GrypDrawHLine to do anything with various guessed arguments and sequences of Flush/Finish calls, in a loop of 50 calls with a 10ms sleep. Little surprise this didn't work since I couldn't find examples in the firmware of a correct sequence.
Yeah, that's hard. On the sx280, a very large part of these functions is unreferenced, a small subset is actually used. I also managed to crash Zico by sending two XimrExe messages in a row (the second one caused the crash).
Since D6 DSLRs use the same Xtensa firmware (I found a 750d dump somewhere), it might be possible to get some more information from their fw.
I'm assuming I can find your message logging code somewhere up this thread?
Not yet, just the hint (the point where it can be hacked). You also might need to find and disassemble the Xtensa blob(s) to get the message list.
edit:
I attached the research-hack I used on the sx280. Almost every bit of it will need to be adapted if somebody would like to use it on another camera.
-
I'm curious if anyone else sees what I'm seeing on g7x, with the menu flashing after leaving alt mode.
I tried a few times an SX60 to reproduce this in Auto mode (shoot) with ALT and menu. The screen is flickering quite a bit, but leaving Alt mode seems to just behave normally. No ghosts.
Ditto for the G16.
Tried various video and shooting modes - with Set/Func and Menu screens selected as I went in & out of <ALT> or <ALT>+CHDK menu. Nothing unusual or ghosted images.
But maybe I'm not looking for the right thing?
-
But maybe I'm not looking for the right thing?
On G7 X, it happens if I
1) Have the camera is in auto mode, where the AF frame (often) continuously wanders around the screen
2) Enter alt and the CHDK menu
3) Leave alt
The ghost of the CHDK menu then sometimes flash until the canon firmware updates something other than the AF frame.
Strangely, this doesn't happen with face tracking continuous AF in P mode, but it's a bit intermittent in the auto case too, so maybe I just didn't manage to reproduce it.
I believe the AF frame is drawn directly on the YUV bitmap rather than the RGB buffer. I suspect this may explain why other Canon UI elements updating make the problem go away.
-
I believe the AF frame is drawn directly on the YUV bitmap rather than the RGB buffer.
Yes and no. Explained below.
Looks like I was wrong about that double RGBA buffer. I have made several dumps of it (on the M10), and it definitely does not look like the overlay buffers (yuv, opacity) that are actually displayed.
A typical dump is attached.
The main OSD content is in the upper buffer, in all dumps I have seen.
Overlaid items (here, the AF frame) are in the second buffer, with no other content. I don't know whether this topology is fixed, or it can change.
As for screen refresh, following seems to work for me. No active_bitmap_buffer is involved.
_transfer_src_overlay(0);
_transfer_src_overlay(1);
-
The main OSD content is in the upper buffer, in all dumps I have seen.
Overlaid items (here, the AF frame) are in the second buffer, with no other content. I don't know whether this topology is fixed, or it can change.
On M3 items are in the same buffer:
(https://chdk.setepontos.com/index.php?action=dlattach;topic=12788.0;attach=14273)
As for screen refresh, following seems to work for me. No active_bitmap_buffer is involved.
_transfer_src_overlay(0);
_transfer_src_overlay(1);
This works on M3 in auto modes: no CHDK ghosts but CHDK OSD still flikering...
-
On M3 items are in the same buffer
That's one of the YUV overlay buffers and an opacity buffer below. I was talking about the source overlay buffers which have RGBA pixel format (32 bit per pixel) and fixed dimensions: 960x480. There's two of them, hence my 960x960 image.
This works on M3 in auto modes: no CHDK ghosts but CHDK OSD still flikering...
Since we're still drawing to a buffer that's continuously getting overwritten, flickering is absolutely no surprise.
-
I was talking about the source overlay buffers which have RGBA pixel format (32 bit per pixel) and fixed dimensions: 960x480
Understood.
It's interesting that LCDRect_Create draws at the same buffer as AF frame.
-
Additional idea (did not try it).
If it is really Ximrexe that does the framebuffer copy AND the camera survives if it is not sent, we could block the message in ALT mode and enjoy flickerless drawing...
Sounds too good to be true?
Another use: when this message is detected, there's a high probability that something needs to be redrawn.
Drawback: intercepting this message requires a permanent TakeSemaphore patch that causes a (tiny) performance drop.
-
Drawback: intercepting this message requires a permanent TakeSemaphore patch that causes a (tiny) performance drop.
mzrm_createmsg and mzrm_sendmsg functions are using pointers to debug functions(see at 0xFC2FD870 on M3) that actually are NULL. Maybe we can use it?
-
mzrm_createmsg and mzrm_sendmsg functions are using pointers to debug functions(see at 0xFC2FD870 on M3) that actually are NULL. Maybe we can use it?
They are too deep down and too conditional.
TakeSemaphore is right at start. It lets us skip the whole mzrm_createmsg if we chose to do so. The mzrm message functions usually check the return value of mzrm_createmsg for NULL and skip sending the message if it is indeed NULL (well, not much else could they do).
I did this on the sx280 102b:
Index: boot.c
===================================================================
--- boot.c (revision 4883)
+++ boot.c (working copy)
@@ -74,6 +74,16 @@
"cmp r0,r2\n"
"blo task_hook_loop\n"
+ "adr r0, patch_TakeSemaphore\n" // src: Patch data
+ "ldr r1, =0x010c59f8\n" // dest: Address to patch (hook_ has thumb bit off)
+ "add r2, r0, #8\n" // two words
+"ts_hook_loop:\n"
+ "ldrh r3, [r0],#2\n"
+ "strh r3, [r1],#2\n"
+ "cmp r0,r2\n"
+ "blo ts_hook_loop\n"
+
+
" ldr r0, =0x010c1000\n"
" ldr r1, =0x0001f3c4\n"
" BL sub_fc12dd3a\n" // clean data cache (on the kernel area)
@@ -99,6 +109,10 @@
"patch_CreateTask:\n"
"ldr.w pc, [pc,#0]\n" // Do jump to absolute address CreateTask_my
".long CreateTask_my + 1\n" // has to be a thumb address
+
+ "patch_TakeSemaphore:\n"
+ "ldr.w pc, [pc,#0]\n" // Do jump to absolute address
+ ".long TakeSemaphore_my + 1\n" // has to be a thumb address
);
}
@@ -590,3 +604,44 @@
}
+//*****************************************************************
+
+void __attribute__((naked,noinline)) TakeSemaphore_my() {
+asm volatile (
+ "ldr r3, =0xfc2546a7\n"
+ "cmp r3, lr\n"
+ "bne nomod\n"
+"mod1:\n"
+ "push {r0,lr}\n"
+ "mov r0, r11\n" // r2 of mzrm_create
+ "cmp r0, #0x1d\n" // ximrexe, @ FC2DC5D6
+ "bne mod1out\n" // only touch ximrexe
+ "bl mzrmmod1\n"
+ "pop {r0,lr}\n"
+ "mov r0, #0\n" // make mzrm_create return null pointer
+ "ldr pc, =0xFC254725\n" // leave mzrm_create, without doing anything
+"mod1out:\n"
+ "pop {r0,lr}\n"
+ //"b nomod\n"
+"nomod:\n"
+ "push {r2, r3, r4, r5, r6, lr}\n"
+ "mov r4, r0\n"
+ "ldr r0, =0x8154\n"
+ "mov r5, r1\n"
+ "ldr pc, =0x10c5a01\n"
+".ltorg\n"
+);
+}
+
+
+static unsigned int taskinf[20];
+static int msgsize;
+
+extern int _get_self_task_id();
+extern void _get_tcb(int tid, void* buf);
+
+void mzrmmod1() {
+}
+
+The patch contains unnecessary parts and the asm isn't optimal.
This is just POC, it just suppresses all Ximrexe messages. Screenshot attached (shows both framebuffers from the same session, as you can see the previous diskboot's splash has survived the few seconds while the cam was off).
Using this, framebuffers are still flipped back and forth as usual while using the camera.
Newer cameras contain more Ximr messages (for example, g7x has XimrExeGain, no idea what it does).
I only tried this on the sx280.
-
Thanks for that - works on G5X :D
That was the magic function I could not find - might be able to make some progress now (time permitting).
Phil.
-
Will this function be in the sigfinder soon?
I'm working on it.
I added a match for transfer_src_overlay, it finds the same values srsa_4c listed earlier.
I also added a match for active_bitmap_buffer. The match is the value the canon firmware passes to transfer_src_overlay, which is 4 bytes off from the the value we used on most ports before. Based on testing with chdkptp live view, it appears work correctly on g7x, and (almost always?) contains the same value as the old variable.
Using the new active_bitmap_buffer value did not affect the ghosting in after leaving alt in auto mode. However transfer_src_overlay the function with 0 and 1 does. I'm going to check this code in for g7x, as it seems substantially better than the displaybusy code.
-
I updated finsig_thumb2 to identify mzrm_createmsg and mzrm_sendmsg (along GraphicSystemCoreFinish which is used to find them)
-
Does this work for M10 110d and 110f and if so what are the addresses for 'transfer_src_overlay' ?
-
what are the addresses for 'transfer_src_overlay' ?
https://app.assembla.com/spaces/chdk/subversion/source/4888/trunk/platform/m10/sub/110d/stubs_entry.S#ln224
https://app.assembla.com/spaces/chdk/subversion/source/4888/trunk/platform/m10/sub/110f/stubs_entry.S#ln224
-
Thought I'd drop a quick placeholder here based in a conversation with reyalp on IRC today.
[14:56] <reyalp> we totally forgot about grids and script drawing
[15:02] <waterwingz> understandable
[15:05] <reyalp> my feeling is script should be able to draw at "native" resolution, but maybe something could be added to drawings.lua (or another library) to make screen size relative stuff easier
[15:10] <waterwingz> thinking about that - it will make all scripts that draw now not able to work with newer cameras - and the code gets bigger as they try to play with scaling everything correctly relative to all the other screen drawings
[15:10] <waterwingz> all it buys you is the ability to draw more finely on larger pixel x-y displays
[15:11] <waterwingz> vs just assuming drawings work in a 360x240 sandbox
[15:11] <waterwingz> and letting CHDK figure out how to map that
[15:12] <reyalp> aspect ratios kinda mess that up though
[15:14] <reyalp> and my thought was giving you the option of sandbox drawing in lua
I played with the G16 (digic6) port today with CHDK grids and script drawing (CHDKplus.lua) The results were "interesting" in the case of grids and awful in the case of script drawing.
-
I have ported the experiments to the M10 and have some findings to share.
- The XimrExeGain mzrm message is used by firmware when the overlay "fades in" (upon exiting the shooting menu or the rec menu). It does everything the regular XimrExe does (copies an RGBA buffer's content to one of the YUV overlay/opacity buffer pairs) plus it handles the fade effect.
- I tried modifying the source and destination buffer addresses that can be found in the big structure that is passed through with the XimrExe message. It can be done, the Xtensa side does not check their validity.
An example XimrExe message from the M10 (1st column is decimal byte offset, 2nd column hexadecimal word, 3rd column interpretation):
header
25
13
304
message
0 bff00510
4 2d00000 720
8 50001e0 480
12 1000000
16 0
...
40 0
44 5652414d 'VRAM'
48 5fe05c00 dest. yuv buf
52 5fd08a00 dest. opacity buf
56 1000102
60 2e0 736, dest full width
64 1e0 480, dest full height
68 2c60164
72 0
76 3000000
80 1
84 3000000
88 10500
92 0
96 1e00000 480
100 2d0 720
104 10000
108 5652414d 'VRAM'
112 41e7eb00 RGBA buffer (2nd one)
116 0
120 5000004
124 3c0 960, src buf width
128 1e0 480, src buf height
132 0
136 3000000
140 1
144 3000000
148 10500
152 0
156 1e00000 480, src used height within buffer
160 2d0 720, src used width within buffer (the rest is ignored/not copied)
164 10000
168 5652414d 'VRAM'
172 41cbcb00 RGBA buffer (1st one)
176 0
180 5000004
184 3c0 src buf width
188 1e0 src buf height
192 0
...
616 0
620 808000
624 1
628 0
632 1
636 1000000
640 1
644 0
648 0
652 1010101
656 0
660 1e002d0 480, 720
664 0
668 0
672 0
676 0
680 0
684 1000
688 0
692 0
696 0
700 0
704 0
708 4000000
712 0
716 0
720 0
724 0
728 0
732 0
736 3ff51000
740 3fc0001e
744 3f1c007e
748 3ce40199
752 a16
756 0
760 4000000
764 340ff4
768 2760f62
The only changing parts of this message I've seen so far are the destination yuv and opacity buffer addresses. Those most likely depend on the parameter passed to transfer_src_overlay().
This is still not enough to make a new D6 CHDK display implementation, but it might give ideas.
-
What is known about D6 display so far.
- The DIGIC display device is configured to use YUV+opacity buffers (double buffering).
It also supports legacy, paletted mode(s), but that is only used on DSLRs in their bootloader.
- The Xtensa side draws to 2 big RGBA buffers. The first buffer is used usually.
If there's content in the second buffer, it will appear as top(?) layer.
Menus tend to use exclusively the second buffer.
In the cams I know, these RGBA buffers are sized 960x480 (max. supported resolution is full HD). G5x might have even larger buffers.
If the current output device has less resolution, surplus pixels on the right are not transferred to the final buffers.
- Transfer between the source RGBA and destination YUV+opacity buffers is done on the Xtensa side.
Two known messages (as mentioned earlier): XimrExe, XimrExeGain (early models don't have the latter).
Transfer is initiated in the ARM side transfer_src_overlay() function. The parameter to this function is
very likely for selecting the destination buffer.
- Currently known possibilities and limitations
- We can't prevent the Xtensa side from drawing to its RGBA buffers.
- It's possible to suppress the XimrExe messages completely. While these are suppressed, we can freely use the YUV+opacity overlays.
Caveat: the firmware will continue to switch those buffers whenever it wants.
- It's possible to modify the XimrExe messages.
- Destination can be modified (possible use: refresh a certain buffer deliberately)
- Source can be modified (possible use: replace the first/second RGBA buffer with our RGBA buffer).
- If we decide to draw on our own RGBA buffer, we face the following problems:
- Need to allocate 960*480*4 bytes (~1.8MB) from somewhere. It _might_ be possible to use a much smaller RGBA buffer and let XimrExe scale it, but I'm not sure. A smaller buffer may not combine very well with a large one.
- Need to detect when the firmware switches to the 2nd RGBA buffer and switch to that in XimrExe.
- Need a method for erasing that huge area (memset is ineffective and hogs the CPU). Some kind of DMA or a clever XimrExe modification, perhaps.
- Unknown weirdness on G5x. Above findings may not apply there.
-
- Unknown weirdness on G5x. Above findings may not apply there.
Thanks for that, good summation. Clarifies what I've seen with the G5X and fills in some gaps.
Main differences on the G5X:
- RGBA buffer is 864 x 480 pixels (x 4 bytes per pixel), total size 1.58MB.
- There is only one RGBA buffer (that I can find).
Phil.
-
DIGIC 6 findings continued.
When JediDraw messages are intercepted, all Canon drawings disappear - except for text (which keeps accumulating on screen as, apparently, JediDraw is needed for erasing text). The JediDraw message does include one RGBA buffer address, so it might be possible to redirect the drawing (with unknown consequences)*. I have not yet been able to find the message responsible for drawing text.
This time, I used an Xtensa side wrapper to replace the original message handler. It can be copied to an arbitrary place in Xtensa program memory (I used the unused part of the 0xbff20000...0xbff27fff area), and the address of 'jdraw_replacement' needs to be written at the appropriate place in the message handler table (related post (https://chdk.setepontos.com/index.php?topic=11316.msg135538#msg135538)).
# xtensa-elf-as try1.s -o try1.o
# xtensa-elf-objcopy -O binary try1.o try1.bin
# to check generated code: xtensa-elf-objdump -d try1.o
.text
.begin
.literal_position
orig_jedidraw:
.word 0x80AD1A2C
jdraw_enabled:
.word 0xbff07ffc
.word 0
.align 4
jdraw_replacement:
entry a1, 32
l32r a3, jdraw_enabled
l32i a3, a3, 0
beqz a3, jd_skip
mov a10, a2
l32r a8, orig_jedidraw
callx8 a8
mov a2, a10
retw
jd_skip:
movi a2, 0
retw
.end
When copying stuff to the 0xbff2xxxx area, following precautions are needed:
- The procedure should happen in or after zicokick_start. There's an unused Canon debug callback that lets hijack this function.
- Whole words need to be written
edit:
*Looking at the Xtensa side code, only the first 4 words of this particular message are used, the rest (including the framebuffer address) is ignored.
Message handlers (the ones I've seen) only have a single argument: a pointer that points to the message body (I managed to dump message content on the Xtensa side to prove this).
The Xtensa core is able to reach near the end of physical RAM (I copied stuff there from the Xtensa side), so I assume it is able to address the whole RAM.
-
I have not yet been able to find the message responsible for drawing text.
SflwWrpDrawStringWithinRect message contains coordinates(220,220) and "Test" string (0x74736554) taken from LCDMsg_Create function:
Message: 0064: SflwWrpDrawStringWithinRect, size:0072 (0072), addr:bff00598
00000040 00000000 00000048 bff005d0 00dc0000 00dc0000 003f0000 002c0000 bff005c8 00000004 00000000 00000000 74736554 aaaaaa00 5652414d 42703000 00000000 05000004 000003c0 000001e0 00000000
Stack:
bff00598 ffffffe8 00000000 00434ce8 00dc0000 006a2680 002c0000 006a25d8 006a2610 00000000 00000000 fc268925 002c0000 005a98b0 00000004 00000000 00000000 00000001 00000000 00020064 bff00064 00000064 bff00064 00640064 00640064 00000000 00000000 00dc0000 00dc0000 003f0000 002c0000 00434ce8 00433228 006a25d8 00000001 006a2610 005a98b0 000000dc 000000dc 00000108 000000dc 00000003 00434ce8 fc268a79 006a2610 005a98b0 00000004 006a2698 006a2680 00000000 00000000 000003c0 006a26a0 005a98b0 00433228 fc3f2cdd 0000011b 4d746e46 632e6e61 37333720 0000000a 000000dc 000000dc 0000003f
-
SflwWrpDrawStringWithinRect message contains coordinates and "Test" string (0x74736554) taken from LCDMsg_Create function:
Yes, that was one of the suspects, but I did not yet go further with those experiments.
Preventing Canon drawings from appearing on the RGBA buffers could potentially enable us to draw on one of them, but there are still unresolved issues in the way:
- the destination buffer is not always known
- we don't know when the firmware switches to the second buffer (when menus are active, mostly)
...
-
It looks like the 5th word in JediDraw message points to the structure containing coordinates of rectangle(100,100,520,280) taken from LCDRect_Create function:
Message: 0108: JediDraw, size:0044 (0044), addr:bff00500
0000006c 00000000 0000002c bff0051c 02341140 00000000 000000c0 5652414d 42703000 00000000 05000004 000003c0 000001e0 00000000
Stack:
bff00500 fffffffc 00000000 00000000 00000000 000000c0 0002868c 00028640 000286a8 02341140 80000002 fc3f04b1 80000002 0003f30c 0019e468 00434d50 fd82d41c 00000000 ffffffff 006a24a8 006a2400 00000000 00434ce8 006a2498 00000000 00000000 42c80000 fc3f0597 00000000 fc268f35 00000000 000001e0 00000000 00000000 04380000 05000064 01000064 00000064 00000064 00640064 00640064 00000000 00000000 00000118 00000208 0003f30c 00000000 00000064 00000064 0000026c 0000017c 00434ce8 00000064 00000064 00000000 006a2400 006a2498 006a24a8 00434ce8 00000064 00000000 00000028 00000064 fc269077
JediDraw content at 0x02341140:
00c00101 02341200 fd82d41c 00000000 023411d8 00000004 00000000 00000000 000000c0 00000001 00000000 00000000 000000ff 00000000 00000000 00000000 42c80000 42c80000 01180208 00640064 00640064 00000000 00000000 023411cc 00000000 00000000 000000ff 00640064 00640064 00000000 00000000 00000000 00640100 00000000 0003f30c 0000000c 00000001 00800080 00000064 00000064 00000208 00000118 ab92caab ab82ba0f a8b1ae70 ea28faa5 a8a2bcf2 a288aef9 00c00101 023412c0 fd82d41c 00000000 02341298 00000004 00000000 00000000 000000c0 00000001 00000000 00000000 000000ff 00000000 00000000 00000000
But I'm not sure about the length of this structure ...
-
But I'm not sure about the length of this structure ...
It's either one of the members of the JediDraw structure (or the other structure it points at), or, it doesn't appear in the structure at all because it's pre-defined.
-
I've shifted text strings rendered by SflwWrpDrawStringWithinRect, but some text stayed on the same positions.
So Canon OSD is rendered by JediDraw unlike menus.
-
I was about to write that
With JediDraw and SflwWrpDrawStringWithinRect messages blocked, all Canon drawings disappear from screen.
when I found out that I still get text on screen when I enter the shooting mode selection menu. So, apparently there are other ways to draw text (and make it move/disappear), still to be found out.
About the length of JediDraw messages: I suspect that it's this word in Ant's example: 000000c0. In some cases, certain bytes of the structure are not initialized, showing the usual uninitialized memory junk.
Some JediDraw messages refer to resources in ROM - my guess is that those are bitmap or vector images - unfortunately, in an unknown format.
edit:
The message used for drawing text on the shooting mode selection menu is OAE_PackerSeaflowDrawWithinRect. Maybe that's all, maybe there's more. This message can also be blocked without consequences.
-
edit:
The message used for drawing text on the shooting mode selection menu is OAE_PackerSeaflowDrawWithinRect.
Older cameras (M3, G7X, SX60, SX280) don't have this message.
-
Parts of CHDK assume that viewport dimensions match the bitmap overlay dimensions. The ones I know of are
- zebra
- edge overlay
When HDMI output is active (and it is fullHD res), viewport and overlay dimensions are different - viewport is fullHD, overlay is quarter of that (960x540 on DIGIC 6).
Under these conditions, edge overlay simply misbehaves (blocks physw, no display), but current zebra code overflows the overlay buffers (which, depending on camera RAM layout, can cause a crash).
The above modules can probably be fixed(*), but until that happens, I'm considering to add checks to skip problematic parts of their code when viewport is larger than overlay.
*That fix is only "easy" when overlay size is quarter of viewport size. There are alternative viewport buffers in rec mode that are sized differently.
-
Question: can HDMI output be active in shoot mode?
-
Question: can HDMI output be active in shoot mode?
AFAIK, you could get HDMI (or at least some sort of live video?) on older Powershots but Canon disabled that feature several (?) years ago.
-
Question: can HDMI output be active in shoot mode?
AFAIK, you could get HDMI (or at least some sort of live video?) on older Powershots but Canon disabled that feature several (?) years ago.
Many cameras, including recent models allow analog video out. Canon dropped this capability on lower end cameras.
The EOS M cameras are the only CHDK supported models which allow HDMI out in rec mode.
-
mzrm_createmsg and mzrm_sendmsg functions are using pointers to debug functions(see at 0xFC2FD870 on M3) that actually are NULL. Maybe we can use it?
They are too deep down and too conditional.
TakeSemaphore is right at start.
Emulating EOS M3 in QEMU (https://www.magiclantern.fm/forum/index.php?topic=2864.msg210762#msg210762) I found better way to intercept MZRM messages.
Function 0xFC3F10D8 (pointer stored at 0xBFF00420) is always called inside mzrm_sendmsg (at 0xFC2FD87E). The number(n[0..31]) of current message to send is stored at 0xBFF00410. The pointer to it's buffer is stored at 0xBFF00468+4*n. The number of message accepted by MZRM is stored at 0xBFF00428.
-
Finally got this drawing using JediDraw and SflwWrpDrawStringWithinRect
(https://i.ibb.co/rFc9JcH/chdkptp-20190205-193112.png) (https://ibb.co/HBxZQxq)
Some info about JediDraw and SflwWrpDrawStringWithinRect:
38310:39331627: PhySw:0x00000000:
Message: 0108: JediDraw, size:0044,addr:bff00500 [29-29]
bff00500[+000]: 0000006c
bff00504[+004]: 00000000
bff00508[+008]: 0000002c
bff0050c[+012]: bff0051c pointer to output buffer
bff00510[+016]: 006a6420 pointer to JediDraw structure
bff00514[+020]: 00000000
bff00518[+024]: 000000c0 size of this JediDraw structure
bff0051c[+028]: 5652414d VRAM signature
bff00520[+032]: 42541000 ARGB buffer address
bff00524[+036]: 00000000
bff00528[+040]: 05000004
bff0052c[+044]: 000003c0 width
bff00530[+048]: 000001e0 height
bff00534[+052]: 00000000
JediDraw structure at 0x006a6420:
006a6420[+000]: 00c00101 object type 0C00 - vector graphic, bits [8-11] - the position
of the object relative to the coordinates (1 - 4th quadrant, 5 - center, 9 - 2nd quadrant)
006a6424[+004]: 006a64e0 pointer to next JediDraw structure
006a6428[+008]: fd82d41c address of vector object (fd82d41c - filled rectangle)
006a642c[+012]: 00000000
006a6430[+016]: 006a64b8 pointer to drawing limits
006a6434[+020]: 00000004
006a6438[+024]: 00000000
006a643c[+028]: 00000000
006a6440[+032]: 000000c0 size of this JediDraw structure
006a6444[+036]: 00000001
006a6448[+040]: 00000000
006a644c[+044]: 00000000
006a6450[+048]: 000000ff
006a6454[+052]: 00000000
006a6458[+056]: 00000000
006a645c[+060]: 00000000
006a6460[+064]: 43480000 x position of object, float32
006a6464[+068]: 42ec0000 y position of object, float32
006a6468[+072]: 002a00b4 bits [16-31] object height, bits [0-15] object width
006a646c[+076]: 00640064
006a6470[+080]: 00640064
006a6474[+084]: 00000000
006a6478[+088]: 00000000
006a647c[+092]: 006a64ac pointer to object color ???
006a6480[+096]: 00000000
006a6484[+100]: 00020001 bits [16-31] border thickness
006a6488[+104]: 000000ff border color RGBA
006a648c[+108]: 00640064 color coefficients ???
006a6490[+112]: 00640064 color coefficients ???
006a6494[+116]: 00000000
006a6498[+120]: 00000000
006a649c[+124]: 00000000
006a64a0[+128]: 00640100
006a64a4[+132]: 00000000
006a64a8[+136]: 0003f30c
006a64ac[+140]: 0000000c
006a64b0[+144]: 00000001
006a64b4[+148]: ff00a000 object color ARGB
006a64b8[+152]: 00000000 x position of drawing limits
006a64bc[+156]: 00000000 y position of drawing limits
006a64c0[+160]: 000002d0 width of drawing limits
006a64c4[+164]: 000001e0 height of drawing limits
006a64c8[+168]: afafafaf unused in 0C00 structure
006a64cc[+172]: afafafaf unused in 0C00 structure
006a64d0[+176]: afafafaf unused in 0C00 structure
006a64d4[+180]: afafafaf unused in 0C00 structure
006a64d8[+184]: afafafaf unused in 0C00 structure
006a64dc[+188]: afafafaf unused in 0C00 structure
38310:JediDraw [180,042] at [000,000-720,480] col:ff00a000 [0200:0118]
38310:39332640: PhySw:0x00000000:
Message: 0064: SflwWrpDrawStringWithinRect, size:0076,addr:bff00550 [30-29]
bff00550[+000]: 00000040
bff00554[+004]: 00000000
bff00558[+008]: 0000004c
bff0055c[+012]: bff0058c pointer to output buffer
bff00560[+016]: 00c80000 bits [16-31] x position of string
bff00564[+020]: 00940000 bits [16-31] y position of string
bff00568[+024]: 00000000 bits [16-31] string width
bff0056c[+028]: 00000000 bits [16-31] string heght
bff00570[+032]: bff00580 pointer to string
bff00574[+036]: 00000009
bff00578[+040]: 00000000
bff0057c[+044]: 00000000
bff00580[+048]: 4b444843 'CHDK'
bff00584[+052]: 31303220 ' 201'
bff00588[+056]: 00000039 '9'
bff0058c[+060]: 5652414d VRAM signature
bff00590[+064]: 42541000 ARGB buffer address
bff00594[+068]: 00000000
bff00598[+072]: 05000004
bff0059c[+076]: 000003c0 width
bff005a0[+080]: 000001e0 height
bff005a4[+084]: 00000000
SflwWrpDrawStringWithinRect [0200,0148]:[0000,0000] CHDK 2019
Probably it could be used for rendering CHDK GUI, but we need to synchronize somehow with Canon GUI drawing...
-
Nice reverse engineering work. My choice (for CHDK display) would be a method that draws a large bitmap, where we could write the bitmap's contents. But the main problem is this:
but we need to synchronize somehow with Canon GUI drawing...
-
JediDraw can also draw UYVY bitmaps:
46530:47561436: CtrlSrv:0x00000000:
Message: 0108: JediDraw, size:0044,addr:bff00500 [00-00]
bff00500: 0000006c 00000000 0000002c bff0051c 02341200 00000000 000000c0 5652414d
bff00520: 42541000 00000000 05000004 000003c0 000001e0 00000000
JediDraw content at 0x02341200:
02341200: 00000103 023412c0 0234128c 00000000 023412a8 00000004 00000000 00000000
02341220: 000000c0 00000001 00000000 00000000 000000ff 00000000 00000000 00000000
02341240: 42600000 42a80000 00f4016e 00640064 00640064 00000000 00000000 00000000
02341260: 00000000 00000000 000000ff 00640064 00640064 00000000 00000000 00000000
02341280: 00640000 00020202 00000000 00000002 00000001 00000000 00f4016e 00f40180
023412a0: 5f8cee00 000001e0 00000038 00000054 0000016e 000000f4 00000000 00000000
46530:JediDraw [366,244] at [15991150,15991168-1603071488,480] col:00000000 [0056:0084]
see "Playback information display" and "Shooting information display" menu
5f8cee00 - address of bitmap
-
Very nice work :D
Probably it could be used for rendering CHDK GUI, but we need to synchronize somehow with Canon GUI drawing...
I would expect there to be some kind of "finish", "flush" or "swapbuffers" command that actually updates the screen. If we could add a hook to draw our stuff just before it executes...
-
IIRC, LCDMsg function creates a controller to redraw itself. So we can try to use the same method.
-
JediDraw can also draw UYVY bitmaps
Turns out I've already done some research into this ~ a year ago but did not finish or publish it. This method can resize the bitmap while copying.
I would expect there to be some kind of "finish", "flush" or "swapbuffers" command that actually updates the screen. If we could add a hook to draw our stuff just before it executes...
The usual message pattern is
GraphicSystemCoreFinish
JediFinish
XimrExe
where ximrexe initiates the overlay transfer.
So, maybe catching GraphicSystemCoreFinish and adding one more jedidraw before that could enable us to overwrite the overlay. Alpha blending our overlay would be even better...
-
Yes it can resize bitmaps as well as vector images:
(https://i.ibb.co/Jd5RcCC/chdkptp-20190206-210729.png) (https://ibb.co/Db5D1LL)
-
Alpha blending our overlay would be even better...
Not sure about mixing two bitmaps. As you can see JediDraw overwrites information in bitmap buffers(this screenshot was made with "Skip D6 Opacity"):
(https://i.ibb.co/pK0QjN5/chdkptp-20190206-212234.png) (https://ibb.co/dpWt4Xx)
It looks like Canon uses scanned certification logo :)
-
@Ant
May I ask how you made your (vector and bitmap) experiments that resulted in the above pictures? Did you build your own jedidraw struct based on an earlier captured example or you used some higher level function? If you built your own, what did you do with pointers inside those structs that are normally set by Canon code?
If we want to make use of jedidraw, we need to be able to find out how to do it on various cameras. I captured (what I believe is) the equivalent of what you posted here (https://chdk.setepontos.com/index.php?topic=12788.msg139367#msg139367), and the M10 version has some significant differences. So, unless a working higher level function is found, that would mean low level research on each model.
-
Drawing bitmap was not successful and I only modified canon's messages.
To draw vector and text I used this code:
int (*Clean_data_cache_line)() = 0xFC1300B3;
int (*SflwWrpDrawStringWithinRect)() = 0xFC3F1C9B;
int (*JediDraw)() = 0xFC4BB8BB;
void draw_rectangle_mzrm(coord x1, coord y1, coord x2, coord y2, int cl, int flags)
{
int JDarr[96] = {
0x00c00101, 0x02341380, 0xfd82d41c, 0x00000000, 0x02341358, 0x00000004, 0x00000000, 0x00000000,
0x000000c0, 0x00000001, 0x00000000, 0x00000000, 0x000000ff, 0x00000000, 0x00000000, 0x00000000,
0x42c80000, 0x42c80000, 0x01180208, 0x00640064, 0x00640064, 0x00000000, 0x00000000, 0x0234134c,
0x00000000, 0x00000000, 0x000000ff, 0x00640064, 0x00640064, 0x00000000, 0x00000000, 0x00000000,
0x00640100, 0x00000000, 0x0003f30c, 0x0000000c, 0x00000001, 0xffa0a0a0, 0x00000000, 0x00000000,
0x000002d0, 0x000001e0, 0xafafafaf, 0xafafafaf, 0xafafafaf, 0xafafafaf, 0xafafafaf, 0xafafafaf
};
int buf[9] = {
0x5652414D, 0x42541000, 0, 0x5000004, 0x3C0, 0x1E0, 0, 0, 0x60
};
JDarr[1] = &JDarr[0];
JDarr[4] = &JDarr[38];
JDarr[23] = &JDarr[35];
*(float*)(&JDarr[16]) = x1;
*(float*)(&JDarr[17]) = y1;
JDarr[18] = x2 + (y2 << 16);
JDarr[37] = cl;
JDarr[25] = 0x20001;
Clean_data_cache_line(JDarr, 0xC0);
JediDraw(buf, JDarr, 0, 0xC0);
}
void draw_string_mzrm(coord x, coord y, const char *s, int cl)
{
int buf[9] = {
0x5652414D, 0x42541000, 0, 0x5000004, 0x3C0, 0x1E0, 0, 0, 0x60
};
SflwWrpDrawStringWithinRect(buf, x << 16, y << 16, 0, 0, s, strlen(s), 0, 0, 0x64, 0);
} transfer_src_overlay need to be called too.
-
Now bitmap drawing is OK:
(https://i.ibb.co/VHQ8z41/bitmap.png) (https://ibb.co/HNxQb8S)
void draw_rectangle_mzrm(coord x1, coord y1, coord x2, coord y2, int cl, int flags)
{
int JDarr[96] = {
0x00000103, 0x02341d40, 0x02341d0c, 0x00000000, 0x02341d28, 0x00000004, 0x00000000, 0x00000000,
0x000000c0, 0x00000001, 0x00000000, 0x00000000, 0x000000ff, 0x00000000, 0x00000000, 0x00000000,
0x42de0000, 0x42e80000, 0x00F00168, 0x00640064, 0x00640064, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x000000ff, 0x00640064, 0x00640064, 0x00000000, 0x00000000, 0x00000000,
0x00640000, 0x00020202, 0x00000000, 0x00000002, 0x00000001, 0x00000000, 0x01E002D0, 0x01E002E0,
0x5f8cee00, 0x000001e0, 0x00000000, 0x00000000, 0x000002d0, 0x000001e0, 0xaaaaaaaa, 0xaaaaaaaa
};
int buf[9] = {
0x5652414D, 0x42541000, 0, 0x5000004, 0x3C0, 0x1E0, 0, 0, 0x60
};
JDarr[1] = &JDarr[0];
JDarr[4] = &JDarr[42];
JDarr[2] = &JDarr[35];
JDarr[40] = *(int*)(0xC154); // bitmap buffer
JDarr[25] = 0x00020001; // border thickness
JDarr[26] = 0x00A000FF; // border color
Clean_data_cache_line(JDarr, 0xC0);
JediDraw(buf, JDarr, 0, 0xC0);
}
-
Now bitmap drawing is OK
That's not bad. I wonder what happens if you're outside the menu (I mean, there are 2 rgba buffers and the menu draws on the second one).
How well is the M3 working in qemu? Does arm side mzrm messaging work, so stuff like this can be debugged? Other alternative (for me) is to port a1ex's mpu exception stuff as I see no easy way to intercept this drawing path.
-
How well is the M3 working in qemu? Does arm side mzrm messaging work, so stuff like this can be debugged?
Menu navigation works only in playback mode, without images on card(probably because of missing the Omar core).
Yes.
https://www.magiclantern.fm/forum/index.php?topic=2864.msg211107#msg211107 (https://www.magiclantern.fm/forum/index.php?topic=2864.msg211107#msg211107)
Other alternative (for me) is to port a1ex's mpu exception stuff as I see no easy way to intercept this drawing path.
Probably there is another way (https://chdk.setepontos.com/index.php?topic=12788.msg139197#msg139197). But it's need to check if canon code updates the pointer at 0xBFF00420 or not.
I wonder what happens if you're outside the menu
(https://i.ibb.co/kX35Kj0/osd-bitmap.png) (https://ibb.co/cQbkJ0t)
-
Menu navigation works only in playback mode, without images on card(probably because of missing the Omar core).
Have you published your qemu changes somewhere?
Other alternative (for me) is to port a1ex's mpu exception stuff as I see no easy way to intercept this drawing path.
Probably there is another way (https://chdk.setepontos.com/index.php?topic=12788.msg139197#msg139197). But it's need to check if canon code updates the pointer at 0xBFF00420 or not.
I meant the higher level ARM side functions, many of those don't call any RAM functions and can only be intercepted with the MPU exception method.
I'm still trying to research what jedidraw is capable of (the yuv bitmap method). I already found that one of the 0x64 (100 decimal) bytes is image brightness. Would be great if it supported different image formats or transparency.
-
On the m10, one of the bytes in the JediDraw struct appears to control mixing the old drawings and the new. It is initially 0x64 (this 0x64 is separate from those words that are set to 0x640064). From Ant's example, it looks like this struct member is either missing or located elsewhere on the m3. On the m10, it's in the second word of the big struct.
I could not find this until I stopped experimenting with changing the fw's JediDraw messages on-the-fly: Canon uses multiple layers for almost everything, so many of the changes have no visible effects because lower and upper layers are concealing them.
Also found a possible hook, called right after GraphicSystemCoreFinish is sent. Did not test it yet.
loc_FC20DA5A: 6 refs ▼
push {r4, lr}
movs r4, #0
bl 0xfc3eb656 ; <GraphicSystemCoreFinish>
ldr r0, =0xC500 @ FC20DA74 ; <ptr_hook_after_gscf>
ldr r0, [r0, #0]
cbz r0, 0xfc20da6c
blx r0
mov r4, r0
loc_FC20DA6C: 1 refs ▲
mov r0, r4
pop {r4, pc}
-
From Ant's example, it looks like this struct member is either missing or located elsewhere on the m3. On the m10, it's in the second word of the big struct.
Do you mean this word 006a64a0[+128]: 00640100 (https://chdk.setepontos.com/index.php?topic=12788.msg139365#msg139365) ?
There need to see your logs. Which GUI elemets use this mixing?
many of the changes have no visible effects
Just in case: did you call Clean_data_cache_line?
P.S. attached my log...
-
Do you mean this word 006a64a0[+128]: 00640100 (https://chdk.setepontos.com/index.php?topic=12788.msg139365#msg139365) ?
I don't know. Here's mine (m10, all words are hex):
17810: [CtrlSrv] JD, abb 0;
*R0: 460560
5652414d,
41e7eb00,
0,
5000004,
3c0,
1e0,
0,
*R1: 1abeb40
2000103, -> drawing type and direction
640202, -> byte2: percentage of new drawing vs old content at the same place (defaults to 100)
4c, -> never changes
1abec20, -> points after this struct
1abebdc, -> points to bitmap descriptor, inside this struct
0,
1abebf8, -> points to some coordinates, inside this struct
4,
0,
0,
e0, -> length of this struct in bytes
1,
0,
0,
ff,
0,
0,
0, -> pointer in some other JD messages
0,
43eb0000, -> destination coordinate in float
438c8000, -> destination coordinate in float
9600c8, -> destination height, width
0,
640064, -> influences pixel data interpretation
640064, -> influences pixel data interpretation
0, -> influences pixel data interpretation
0,
0, -> pointer in some other JD messages
0,
0,
20001, -> border width
3e3e3eff, -> border color
640064, -> 080008 makes grey border dark blue
640064, -> 080008 makes grey border vanish
0,
0,
200, -> crash when byte1 changed
0,
0,
2, -> crash when altered
10107, -> junk word
140000, -> y, x offset in src
7800a0, -> height, width to copy
a000a0, -> full height, width
5823cb00, -> bitmap (yuv) buffer
0, -> junk word
0, -> ? some coords
9, -> ? some coords
2d0, -> ? some coords
1d4, -> ? some coords
c0, -> junk
1, -> junk
0, -> junk
0, -> junk
ff, -> junk
0, -> junkWhich GUI elemets use this mixing?
I only hand-picked some JD structs, none of them has a value different from 0x64. Historically, Canon has been avoiding overlapping graphics as far as I can tell.
Just in case: did you call Clean_data_cache_line?
Yes, I based my function on your example.
A logged session (startup in playback mode and entering thumbnail-view) of JD structs is attached.
edit:
Added some empirical notes to some struct members. byte0: lsb in a word, byte3: msb in a word
-
Just in case: did you call Clean_data_cache_line?
Oops. I was not doing this during that part of research, so that may be it. :-[
But the multiple layer stuff I mentioned still stands (drop shadow, borders, etc).
-
(drop shadow, borders, etc).
If you mean shadow around OSD icons - it's a border that can be modified in JD structure.
Your JD structure is slightly different. Can you specify your mixing word?
Historically, Canon has been avoiding overlapping graphics as far as I can tell.
Found this situation: see histogram and focus frame.
(https://chdk.setepontos.com/index.php?action=dlattach;topic=12788.0;attach=15450)
But this is vector graphic. Not sure this possible for bitmaps...
-
(drop shadow, borders, etc).
If you mean shadow around OSD icons - it's a border that can be modified in JD structure.
Your JD structure is slightly different. Can you specify your mixing word?
Not sure what mixing word is, but I added notes to the example struct above. JD can draw borders by itself, but I think the drop shadow is not specified in the same message as the yuv bitmap.
Found this situation: see histogram and focus frame.
Yeah, and seems like there's more of that. It's very likely though that the histogram and/or grid and/or focus rect is drawn onto the other rgba surface, so only the end result is mixed.
-
It's very likely though that the histogram and/or grid and/or focus rect is drawn onto the other rgba surface, so only the end result is mixed.
Yes. Focus frame is drawn at 42703000 and histogram is drawn at 42541000.
I also found the third type of JD structure used for histogram:
21170:22189900: CtrlSrv:0x00000000:
Message: 0108: JediDraw, size:0044,addr:bff00500 [11-10]
bff00500: 0000006c 00000000 0000002c bff0051c 02341680 00000000 000004a0 5652414d
bff00520: 42541000 00000000 05000004 000003c0 000001e0 00000000
JediDraw content at 0x02341680:
02341680: 00400105 02341b20 00000000 00000000 02341b0c 00000004 00000000 00000000
023416a0: 000004a0 00000001 00000100 00000080 f0f0f0ff 0234170c 00247864 00000000
023416c0: 43b98000 422c0000 00aa0100 00640064 00640064 00000000 00000000 00000000
023416e0: 00000000 00000000 000000ff 00640064 00640064 00000000 00000000 00000000
02341700: 00640000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
02341720: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
02341740: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
02341760: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
02341780: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
023417a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
023417c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
023417e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
02341800: 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000000
02341820: 00000000 00000000 00000000 00000001 00000000 00000001 00000000 00000001
02341840: 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001
02341860: 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000000
02341880: 00000001 00000001 00000001 00000001 00000001 00000001 00000002 00000001
023418a0: 00000001 00000001 00000001 00000001 00000001 00000002 00000002 00000002
023418c0: 00000002 00000002 00000002 00000002 00000002 00000001 00000001 00000002
023418e0: 00000001 00000002 00000002 00000002 00000002 00000002 00000002 00000002
02341900: 00000002 00000003 00000003 00000003 00000003 00000002 00000003 00000003
02341920: 00000002 00000003 00000005 00000006 00000005 00000005 00000005 00000006
02341940: 00000006 00000008 00000008 0000000b 0000000b 00000009 00000007 00000007
02341960: 00000008 00000008 00000007 00000007 00000007 00000009 00000008 00000009
02341980: 00000007 00000007 0000000b 00000009 00000009 0000000b 0000000a 00000009
023419a0: 0000000a 0000000a 0000000c 0000000c 0000000d 0000000d 0000000d 0000000f
023419c0: 0000000d 00000010 00000014 00000014 0000000f 00000010 0000000f 00000014
023419e0: 00000016 00000017 00000015 00000013 00000015 00000017 00000017 00000018
02341a00: 00000018 00000017 00000019 00000016 00000017 00000017 00000018 0000001a
02341a20: 00000019 0000001e 00000020 00000021 00000021 00000022 00000026 00000027
02341a40: 0000002b 00000031 0000002c 0000002b 0000002d 0000002f 00000030 00000032
02341a60: 00000032 00000037 00000037 0000003f 0000003f 00000037 00000034 00000039
02341a80: 00000039 00000043 0000004a 0000004f 0000004b 00000048 0000004c 00000048
02341aa0: 00000050 00000051 0000004e 0000004f 0000004e 00000055 00000053 00000052
02341ac0: 00000056 0000005d 0000005f 00000061 00000068 00000065 0000006b 00000071
02341ae0: 0000007c 0000008e 000000ab 000000b5 0000009a 00000099 000000b6 00000064
02341b00: 0000005f 00000098 00000333 00000173 0000002b 00000100 000000aa 00000000
21170:JediDraw [256,170] at [000,000-000,000] col:00000000 [0371:0043]
-
found a possible hook, called right after GraphicSystemCoreFinish is sent. Did not test it yet.
Calling my jedidraw (drawing yuv bitmap, same size as the one in the playback information display menu) from that hook worked. This method obviously only updates that bitmap when the Canon overlay is being drawn.
From Ant's example, it looks like this struct member is either missing or located elsewhere on the m3. On the m10, it's in the second word of the big struct.
Do you mean this word 006a64a0[+128]: 00640100 (https://chdk.setepontos.com/index.php?topic=12788.msg139365#msg139365) ?
There need to see your logs. Which GUI elemets use this mixing?
In playback mode when multiple thumbnails are shown at once, scrolling through them at max speed (by holding down 'up' or 'down') fires jedidraw messages where that byte is less than 100.
I started collecting bigger logs by using one of the RAM areas that appear to be unused for a longer time. (I filled a large part of RAM with a magic word and used a function to find untouched areas).
For logging format, I currently output each jedidraw (and other) message in one line, csv format. This log can then be loaded in a spreadsheet (LibreOffice Calc in my case) which can help evaluating some of the words in those messages.
-
I started collecting bigger logs by using one of the RAM areas that appear to be unused for a longer time.
Why don't you use _exmem_alloc ?
It gives me at least 16MB.
-
Why don't you use _exmem_alloc ?
It gives me at least 16MB.
That could work too, of course. But knowing those seldom used areas can be useful - logging stuff before the OS starts, for example.
I'm unable to fill more than 0x1a000000 bytes of uncached RAM (done in the very first lines of boot.c) using memset32 - a watchdog shuts down the cam if I attempt more.
-
In playback mode when multiple thumbnails are shown at once, scrolling through them at max speed (by holding down 'up' or 'down') fires jedidraw messages where that byte is less than 100.
These thumbnails don't look transparent.
I assume that MZRM can't render transparent bitmaps.
-
This thumbnails don't look transparent.
No, and it happens too fast to observe. It's also possible that the M3 version is different. Log a session in which you do the thumbnail scroll and look for any changes in those 0x64 bytes.
-
It's also possible that the M3 version is different.
What about SX280?
No, and it happens too fast to observe.
The thumbnails are drawn on a gray background. So I don't see it even on CHDK-PTP screenshots.
Log a session in which you do the thumbnail scroll and look for any changes in those 0x64 bytes.
Have you managed to render transparent bitmaps from your code?
-
What about SX280?
Not yet. I'll probably port the "aborttrick" version to this cam. But it is 1st generation so I don't have high hopes.
Have you managed to render transparent bitmaps from your code?
Yes, but as I said, the byte I found is about mixing new overlay with the old. When used repeatedly, the transparent bitmap will turn opaque sooner or later.
-
But new overlay still contain a black area that should be fully transparent to be used as CHDK layer.
Maybe it's better to replace one of rgba buffers in XimrExe message or add the third buffer(if it possible)?
-
But new overlay still contain a black area that should be fully transparent to be used as CHDK layer.
The source bitmap has no transparency information, so whatever its background is, it will remain visible. I wonder if rgba bitmaps are supported by one of the methods (JD or not). Ximrexe does support rgba as source, but its destination is yuv+opacity, and I can't recall whether it can enlarge images.
Maybe it's better to replace one of rgba buffers in XimrExe message or add the third buffer(if it possible)?
We can't control which of the rgba buffers is used for which kind of content, plus we can't control the active yuv+opacity buffer. The latter can fluctuate quite often in some modes.
Plus, if ximrexe can't upscale images, we'd need a full size rgba buffer. With jedidraw, we could use a 720x240 yuv buffer and draw on it like on classic powershots (360x240).
-
No real progress, just observations.
The sx280 constructs a large (taller than overlay's height) yuv bitmap in playback mode's thumbnail view, rather than drawing the thumbnails one-by-one. I found the larger jedidraw struct to be seemingly always 128 bytes long. Unfortunately, its yuv bitmap mode refers to a (probably previously prepared) external MARV struct that also refers to other structs...
I collected some statistics about the mzrm messages actually used in playback and rec mode (it's possible that some of the other messages are also used under different circumstances). The attachment (.ods file in 7z) lists all messages of sx280 and m10 together with the number of uses in a few minute session. The usage counts are in hex.
-
I accidentally discovered that there is a way to disable most of the Canon overlay drawings on newer cameras. From approx. DryOS r52 on, there is an event procedure named SetWindowSystemDrawSetting. It just sets a global variable which I named canon_drawing_enabled. It is 1 by default, setting it to 0 makes the Canon overlay drawing code skip its main drawing path. Not affected are: mostly animated icons and buffer switches. Still, it makes CHDK menu browsing in rec mode a bit more comfortable. Example implementation for two of my cameras follows.
Index: platform/ixus150_elph140/lib.c
===================================================================
--- platform/ixus150_elph140/lib.c (revision 5233)
+++ platform/ixus150_elph140/lib.c (working copy)
@@ -113,6 +113,18 @@
_ScreenUnlock();
}
+extern int canon_drawing_enabled;
+
+void vid_turn_off_updates()
+{
+ canon_drawing_enabled = 0;
+}
+
+void vid_turn_on_updates()
+{
+ canon_drawing_enabled = 1;
+}
+
int vid_get_palette_type() { return 5; }
int vid_get_palette_size() { return 256 * 4 ; }
Index: platform/ixus150_elph140/sub/100c/stubs_min.S
===================================================================
--- platform/ixus150_elph140/sub/100c/stubs_min.S (revision 5233)
+++ platform/ixus150_elph140/sub/100c/stubs_min.S (working copy)
@@ -29,3 +29,5 @@
DEF(video_target_framesize2, 0xBDB0) // approx. 2*video_target_framesize (for intraframes?), found in sub_FFAB938C
//DEF(video_framesize, 0x70f0) // most recent frame's compressed size, found at 0xFF993D74
//DEF(video_frame_data, 0x70f4) // most recent frame's RAM address
+
+DEF(canon_drawing_enabled, 0x7b60) // 0x7b54 + 0xc, from SetWindowSystemDrawSetting_FW
Index: platform/sx280hs/lib.c
===================================================================
--- platform/sx280hs/lib.c (revision 5233)
+++ platform/sx280hs/lib.c (working copy)
@@ -8,6 +8,18 @@
_transfer_src_overlay(1);
}
+extern int canon_drawing_enabled;
+
+void vid_turn_off_updates()
+{
+ canon_drawing_enabled = 0;
+}
+
+void vid_turn_on_updates()
+{
+ canon_drawing_enabled = 1;
+}
+
void shutdown() {
//***TODO***
/*
Index: platform/sx280hs/sub/102b/stubs_min.S
===================================================================
--- platform/sx280hs/sub/102b/stubs_min.S (revision 5233)
+++ platform/sx280hs/sub/102b/stubs_min.S (working copy)
@@ -51,3 +51,5 @@
//FAKEDEF(enabled_refresh_physical_screen, 1)
DEF(displaytype, 0x8eb8) //0x8ea4 + 0x14, found @ fc135f2a (GetDisplayType)
+
+DEF(canon_drawing_enabled, 0x12ad0) // 0x12ac4 + 0xc, from SetWindowSystemDrawSetting_FW
Index: platform/sx280hs/sub/102c/stubs_min.S
===================================================================
--- platform/sx280hs/sub/102c/stubs_min.S (revision 5233)
+++ platform/sx280hs/sub/102c/stubs_min.S (working copy)
@@ -51,3 +51,5 @@
//FAKEDEF(enabled_refresh_physical_screen, 1)
DEF(displaytype, 0x8eb8) //0x8ea4 + 0x14, found @ fc135f2a (GetDisplayType)
+
+DEF(canon_drawing_enabled, 0x12ad0) // 0x12ac4 + 0xc, from SetWindowSystemDrawSetting_FW
This global variable and its support code is completely missing from earlier cameras, so this method only helps those more recent models.
edit:
There is not a lot of talk about vid_turn_off_updates() and vid_turn_on_updates(). Turns out, using ScreenLock() and ScreenUnlock() in those functions seems to get rid of all Canon overlay updates, but the black screen side effect (https://chdk.setepontos.com/index.php?topic=6341.msg77530#msg77530) is still there when trying on sx280.
-
I think srsa_4c may have explored most of this already, but anyway:
The canon code references displaytype values 11 and 12, with resolutions 1024x768 and 900x600.
On sx710 (101a), these can sometimes actually be set, using the function called by DispCon_SetDisplayType:
=call_func_ptr(0xfc0f0dfb,12)
The canon UI is garbled, but CHDK OSD is OK if the buffer sizes from canon code are used. I think it crashes if the function is called with an image on the camera, but there might be random crashes too. Switching to rec crashes if PTP is connected, but works if not. The live view is garbled in rec. Shooting works.
I don't think there's any real use for these modes.
I also found that if you connect HDMI to a lower res monitor (1280x1024, with an HDMI-DVI adapter in this case) it uses displaytype 8, 720x480 res. This low res HDMI still doesn't allow rec mode. Unlikely other TV out modes, this is 8 regardless of the NTSC/PAL setting.
In regular HD HDMI, the playback live buffer is full 1920x1080, 2x the size of the bitmap. The code I used on G7X and sx710 supports this over PTP, although I have trouble imagining a use case for it.
-
ML forum member kitor has just posted a large amount of DIGIC 7-8-X overlay (https://www.magiclantern.fm/forum/index.php?topic=26024.0) related reversed information. It may not directly apply on PowerShot-based firmware, but looks like a good starting point.
-
Oh hello. It was a bit funny (and disappointing?) to see that most of my research is a duplicate of this thread :D
Anyway, the interesting bit for you is probably Ximr Context structure and layers implementation from Digic 7 (with pure Ximr functions).
From what I understand some CHDK cameras have separate buffer for GUI and for focus box overlay, which is similar to EOS R/RP setup (Digic 8 ), while other have single buffer (like on 200D / Digic 7).
Of course this can still be depending on Zico firmware, but since 200D don't use this feature and it is still available, I guess D6 cameras should have it too.
Additional info, not posted yet: "flags" or "color" field of MARV structure is kind of bitfield, It seems to contain 4 things (starting from MSB): Type (?), bits per pixel, subsampling and flag if VRAM has separate opacity layer (UYVY + Alpha). I experimented with that a bit yesterday and had "input" YUV+Alpha layers working on EOS R for different subsampling modes. Unfortunately I found no traces of potential indexed RGB mode - it would be too easy :(
Now, questions time ;)
@srsa_4c - do you have any idea for accessing drysh on zico core? At least on EOS Zico firmwares there are all the strings there. But we are able to switch UART only between main core and Lime with drysh uart_change command. Turtius traced how this switch works and it just sets 2 bit bitmasks at locations:
- d01202f0 (RX) and d01202f4 (TX) for R/D8
- d20702e4 (RX) and d20702e0 (TX) for 200D/D7
"11" switches to Lime, "00" to ICU, as for 01 and 10 - there's just a silence.
-
Anyway, the interesting bit for you is probably Ximr Context structure and layers implementation from Digic 7 (with pure Ximr functions).
Yes. My guess is that the Zico firmware is the product of a single development team. So, the Zico side of your findings should also apply on our cameras. The ARM side is unfortunately different. Some sort of layers support should be available, since the sx280 (as one of the first D6 cameras) already uses 2 large RGBA buffers.
From what I understand some CHDK cameras have separate buffer for GUI and for focus box overlay
To make things more difficult, the "focus box" layer is also used for other things, for example the menu is drawn there. That has prevented me from trying to repurpose the second buffer as CHDK overlay.
Unfortunately I found no traces of potential indexed RGB mode - it would be too easy :(
I think I could live with a yuv or rgba overlay if a small buffer could be magnified to full screen size.
do you have any idea for accessing drysh on zico core?
No, unfortunately not. I only wired UART on cameras that are more or less broken already, my D6 or newer cams are still fully operational.
At least on EOS Zico firmwares there are all the strings there. But we are able to switch UART only between main core and Lime with drysh uart_change command.
It appears to me that the uart line switching related commands are not consistent. For example, the two ARM firmwares on sx280 appear to have a shell command named sw. The Zico firmware is missing that, but has its own related commands (cpusel for example). Later (D7) versions of Zico no longer have cpusel.
A possibility is that the uart output (and/or the dryos shell) is blocked by default and needs to be activated somehow (either from ARM or from the Zico firmware).
Since everything except the main firmware runs from RAM, the possibility to modify the code is there.
-
If you can dump memory structure that is sent via XimrExe (size is probably less than 0x300 - which is size for D7) I can tell you a bit more from that.
If there's a place for more layers there - even if ARM side is missing other Ximr family functions, it should be possible to setup this manually.
To make things more difficult, the "focus box" layer is also used for other things, for example the menu is drawn there. That has prevented me from trying to repurpose the second buffer as CHDK overlay.
So similar but quite different - R use layer 0 for GUI and LV overlays, layer 1 seems to be utilized just for focus overlay.
-
@srsa_4c - do you have any idea for accessing drysh on zico core? At least on EOS Zico firmwares there are all the strings there.
Since (on our cameras at least) the zico code is all in RAM, it seems like you should be able to do something like the console hook (https://chdk.setepontos.com/index.php?topic=11029.0) relatively easily: That is, override the tty read/write function to read/write from RAM shared with the main core instead. Unfortunately, the relative lack of xtensa tooling and documentation compared to arm makes it annoying to work with.
-
If you can dump memory structure that is sent via XimrExe (size is probably less than 0x300 - which is size for D7) I can tell you a bit more from that.
I made some captures some years ago. I put a few on a spreadsheet (one word per row), with some annotations (I have not worked on them recently). I hooked mzrm_sendmsg to get the "message", so there are some words of message header before the actual struct. The sizes are not uniform, sx280 uses a longer struct than the eos m10. All captured words are in hex.
-
FWIW, you've probably already worked them out, but I added some reverse engineered structures in https://app.assembla.com/spaces/chdk/subversion/commits/5762
-
FWIW, you've probably already worked them out, but I added some reverse engineered structures in https://app.assembla.com/spaces/chdk/subversion/commits/5762
Thanks! I was looking just at Ximr part, without underlying mzrm messages. But Turtius from ML forum/discord was experimenting with OpenVG functions from D7 Zico - it may be helpful for him.
I made some captures some years ago. I put a few on a spreadsheet (one word per row), with some annotations (I have not worked on them recently). I hooked mzrm_sendmsg to get the "message", so there are some words of message header before the actual struct. The sizes are not uniform, sx280 uses a longer struct than the eos m10. All captured words are in hex.
Interesting that those two have different size of Ximr Context structures. M10 uses 15 words per layer, SX280 has 16 words per layer (ends with 7 word VRAM/MARV struct, last struct word is 0 - it is PMEM pointer). 15 words per layer are used in 200D / D7. This apply only to "input layers", output chunk definition structure (first VRAM in Ximr Context) is different than input layers.
But in both cases there's a huge chunk of empty space after last layer structure is the place where D7 and D8 puts next layers. Size would fit 9 input layers total (including existing ones), but both on 200D (8 layers) and R (5 layers) there's some empty space after last layer definition.
I need to dump from from my mum M10 and take look at it. Considering two cameras of the same generation must have slightly different Zico firmware (so Ximr structure is different), I don't think those structures are hardcoded, and I except to find similar setup to 200D.
-
But in both cases there's a huge chunk of empty space after last layer structure is the place where D7 and D8 puts next layers. Size would fit 9 input layers total (including existing ones)
That's my hope too.
Perhaps worth to mention that most or all framebuffers are fixed in PowerShot firmware, whereas (AFAIK) they are allocated at run-time in EOS firmware.
I briefly looked at my sx280 disasm and found that the big ximr structure is allocated on stack just before it is sent. A bunch of functions are used to populate it - next step is to analyze them.
-
I just imported M10 111a into Ghidra, so I'll have some details coming soon ;)
Perhaps worth to mention that most or all framebuffers are fixed in PowerShot firmware, whereas (AFAIK) they are allocated at run-time in EOS firmware.
They are kind of allocated (addresses are passed up from gui_init_event), but they somehow seem to always end up in exactly the same address, on multiple firmware versions and even between cameras (R and RP)
-
I just imported M10 111a into Ghidra, so I'll have some details coming soon ;)
In case you haven't found them, there are some scripts to help with that https://chdk.fandom.com/wiki/Firmware_analysis_with_Ghidra
-
Thank you.
I have some problems with Ghidra auto-analysis, at some moment it stops progressing and then 30 minutes later it will crash (same issue I had with 200D ROM).
Before it crashed I managed to locate XimrExe (size of payload is 0x300, like on 200D), CreateMARV, and what I thought might be the code that is responsible for context setup. But with missing xrefs and crash later... I have to retry tomorrow, this time starting with those scripts. Saving a project may be a good idea too :-X
One thing I noticed, MARV "flags" field is a little bit different than on later models, it seems to hold just color type ID and bytes per pixel. Not that surprising for early implementation.
-
I just imported M10 111a into Ghidra, so I'll have some details coming soon
I forgot to mention that PowerShot-based firmwares provide very few Zico hints on the ARM side. A list of mzrm handlers is useful for identifying the ARM side functions. Attached is a list of the m10 handlers, starting with handler #0 (first valid handler is #2). Look up calls to mzrm_createmsg to use the IDs.
-
Look up calls to mzrm_createmsg to use the IDs.
Added scripts to use lists like this to comment / find calls in ghidra https://app.assembla.com/spaces/chdk/subversion/commits/5827
edit:
And one to name the calling function, if it only appears to create one type of mzrm message (which appears to be all of them on g7x and m10, at least) https://app.assembla.com/spaces/chdk/subversion/commits/5839
-
Function at fc23d2b8 is responsible for redraw and for XimrContext structure population.
XimrContext is the structure passed as the first argument to most functions and then to XimrExe.
Disambiguation - we call VRAM structure "MARV" in Magic Lantern (little endian signature).
"Output Chunk" as well as "Ximr Context" are names directly taken from XCM on EOS R+. (XCMStatus EvShell command)
"Flags" field of MARV is a bit different to what I'm used to - possible values are 0x04000002, 0x05000004 and 0x07000002.
On the left "color type", on the right probably bytes per pixel.
Max 8 layers like on 200D. Layer definition inside Ximr Context has identical offsets to 200D.
Ximr functions are easy to find as they always take Ximr Context as first param.
All layer manipulation functions are easy distinguishable for that as 2nd param is checked to be below MAX_LAYER_COUNT (8 in case od Digic 6/7, 6 for Digic 8,X)
Bad news: The very first call is XimrInitializeContext, which means it is recreated on every redraw. This is different to 200D/M50 which does it once on init.
It is however a bit similar to R+ where this is handled by XCM on every redraw.
Now, some stubs. Declarations fit those from 200D.
Names of those stubs are made up by their function, no strings exists for those in EOS roms too.
I left numbered params where I'm not sure of their meaning, but they are saved into XimrContext structure.
fc3ed850 XimrInitializeContext(pXC)
fc3edac0 XimrSetLayerVisibility(*pXC, layer_id, state)
fc3edcae XimrSetLayerColorParams(*pXC, layer, *pMARV, color_id, p5)
fc3edae0 XimrSetLayerMARV(*pXC, layer_id, *pMARV, p4)
fc3edb26 XimrSetLayerDimensions(*pXC, layer, src_x, src_y, src_w, src_h, dst_x, dst_y)
fc3edc30 XimrSetLayer_related_fc3edc30(pXC, layer_id, p3, p4, p5)
fc3edc68 XimrSetLayer_related_fc3edc68(pXC, layer_id, p3, p4, p5)
fc3ed9ec XimrSetOutputChunkMARV(*pXC, *pMARV)
fc3edaa2 XimrSetOputChunkResolution(*pXC, w, h)
Decomp of those functions is weird to understand, as it has the same caveat as 200D, R and R6:
pLayer = (XimrLayerData_withOffset *)((int)pContext + layerId * 0x3c);There's some compiler optimization going on there, you need to offset actual context inside structure definition.
Undefined fields were not referenced (at least on 200D). Fields with _<offset> name - referenced, but unknown meaning, may have wrong data size.
struct XimrLayerData_withOffset {
//add fake paddng
uint8_t _0x48;
uint8_t _0x49;
undefined field_0x4a;
uint8_t _0x4b;
uint8_t _0x4c;
uint8_t _0x4d;
undefined field_0x4e;
undefined field_0x4f;
undefined field_0x50;
undefined field_0x51;
uint8_t _0x52;
uint8_t _0x53;
uint8_t _0x54;
uint8_t color_type;
uint8_t visibility;
uint8_t _0x57;
undefined field_0x58;
undefined field_0x59;
uint16_t src_y;
uint16_t src_x;
uint16_t src_h;
uint16_t src_w;
uint16_t dst_y;
uint16_t dst_x;
uint16_t enabled;
struct MARV MARV;
First "true" field is at offset 0x48 while looking at decomp. Layer definition inside XimrContext start at the same offsets and seems to have the same structure.
Layers data is located at the same Ximr Context offsets as 200D/Digic 7.
Output Chunk is defined at different offset in Ximr Context (start at 0x28 on M10, 0xC on 200D).
Interesting part - there's a condition on which 3rd layer is referenced:
XimrSetLayerVisibility(XimrContext,2,1);
XimrSetLayer_related_fc3edc68(XimrContext,2,0,2,*param_5);
If you are able to patch this function and inject some instructions, you should be able to add own layer like this:
XimrSetLayer_related_fc3edc30(XimrContext,0,0,3,0);
XimrSetLayerVisibility(XimrContext,0,1);
XimrSetLayerColorParams(XimrContext,0,pNewLayerMARV,colorId,0); //colorId is probably just 1
XimrSetLayerMARV(XimrContext,0,pNewLayerMARV,p4);
XimrSetLayerDimensions(XimrContext,0,0,0,src_x, src_y, src_w, src_h, dst_x, dst_y);
Please remember than on 200D (Digic 7) I had to align display buffer to 0x100, otherwise it was shifted by offset/4. This wasn't the case on R/Digic 8.
Other potential candidates to hook: very end of XimrInitializeContext, very beginning of XimrExe (before mzrm_createmessage).
I would just copy all parameters from layer 0/1, except pNewLayerMARV which you need to create yourself. In my experiments I created the structure myself, but there's a CreateMARV function you may try to use at fc586110:
MARV * CreateMARV (void * p1, uint32_t flags, uint width, uint height, uint p5, uint p6)
I never dug into functions that are not responsible for layers, except naming some of those. Goal was to add own layers, and those XimrSetLayer_* were enough to achieve that on 200D.
-
First of all, thanks for sharing all this information.
I would just copy all parameters from layer 0/1
I did just that, copied the layer 1 descriptor to layer 3, inside the ximr struct. Then, I patched a few members in the layer struct (without calling any of the ximr functions). I intercepted the ximr struct in the function that sends the ximrexe message. I used the protection region trick for the experiment, but for a production version I'd patch the dry_memcpy function instead.
I left the pixel format as is, so the demo layer was rgba. It's looking very pretty, but we'd have to find 1.3MB RAM for a 720x480 buffer. If I see it correctly, upscaling of layers is not possible.
-
So it works, nice :)
Using ximr stubs should be "universal" for different Zico firmwares. As you already found, those differ in two examples you provided - but Ximr* functions may provide universal interface (those from M10 were on par with 200D/R)
On Digic 8 I was able to create 720x480 layer while Canon code used 960x540 layers. So it covered only "visible area". With caveats, but those were directly related to XCM / refreshVrmsSurface implementation specific for EOS R only.
-
Thanks @kitor and @srsa_4c - this is very cool :)
Based on the M10 info I was able to duplicate this on the G5X using an RGBA buffer allocated from EXMEM.
Edit: I patched dry_memcpy as srsa_4c suggested in order to modify the layer structure.
Edit2: On the G5X the RBGA bitmap visible area is always 720 pixels wide for the LCD, EVF and HDMI displays (whereas the YUV output varies from 720 when using the LCD up to 1024 for HDMI). The LCD and HDMI buffers are both 480 rows high, the EVF is 540.
Phil.
-
I've been playing with this on the G5X and G7X2 and found some strangeness when using HDMI output.
The RGBA layers are not full screen when using HDMI, they are smaller and centered (affects Canon UI as well).
This would affect zebra and edge overlay if we used an RGBA layer for the CHDK UI, as the pixels in the two frames are not aligned.
If transfer_src_overlay is called to refresh the RGBA layer while the camera is switching from LCD to HDMI out, it will crash.
Additional RGBA layers are rendered twice when using HDMI. They are rendered once at the RGBA frame size and again at the YUV frame size on the screen. The attached image shows this - only two blue boxes were drawn into the RGBA layer. This may also be happening when using the LCD; but is not visible because the frames are the same size.
Phil.
-
Please forgive me if this post doesn’t link to the topic.
My feedback is that on my M3, the CHDK drawing is always skewed left relative to the image, when I use HDMI out.
-
Additional RGBA layers are rendered twice when using HDMI. They are rendered once at the RGBA frame size and again at the YUV frame size on the screen. The attached image shows this - only two blue boxes were drawn into the RGBA layer.
I just tried, happens on m10 as well.
When I copied the second layer (which uses the first RGBA buffer and is used for most of overlay) ximr struct to a later layer and zeroed out the second layer struct, I seemingly got identical result to normal, no double draw.
I suspect the key is somewhere in the ximr struct.
The RGBA layers are not full screen when using HDMI, they are smaller and centered (affects Canon UI as well).
The ximr struct does have data that looks like border size in that case.
Could you make dumps of the whole struct on your g5x? It has 3 different resolution output devices, seeing one dump for each could be helpful. I only have lcd and hdmi.
-
Attached zip file has ximr context dumps from LCD, EVF and HDMI.
I am copying layer[1] (second layer) from offset 0x48+0x3c in the ximr context data - in HDMI the first layer looks like YUV format.
I can see the centering offsets in the layer struct just before the 'MARV' marker - changing these I can make the RGBA layer full screen; but I still get the double rendering (even if I zero out the second layer).
Edit: I also tried just replacing the RGBA buffer pointer in the 2nd layer and not modifying anything else - I still get the double rendering ???
On a side note - one plus in all this is that patching dry_memcpy and checking if the call is from the function that updates the display gives a very reliable way to detect when the CHDK UI needs to be refreshed. I've tried this on the G5X and G7X2 to replace the current guard pixel logic and it gives a much better CHDK UI with much less flickering.
Phil.
-
Attached zip file has ximr context dumps from LCD, EVF and HDMI.
Thanks. From a quick look, the ximr structure seems to match the m10 struct.
Edit: I also tried just replacing the RGBA buffer pointer in the 2nd layer and not modifying anything else - I still get the double rendering
I had a thought that maybe the zico side needs to know the buffers in advance, so I added an offset (+256) to the 2nd layer's rgba buffer address. Aside from the shifted view, no artifacts are visible on hdmi output (no double drawing).
@kitor: Can you check whether your cameras have such drawing issues on HDMI?
-
Double rendering - no. Magic Lantern menus worked fine on my own layer on HDMI output of EOS R.
Maybe your buffers overlap or something?
Part of layer definition structure in XimrContext contains offsets that are cut off from full buffer (not rendered) and layer offset (move "0,0" somewhere else on screen). See XimrSetLayerDimensions:
src_x, src_y, src_w, src_h is region from buffer that will be rendered. Everything outside this region is just not visible (not rendered / transparent). This will "crop" potential junk that you don't want to be visible.
dst_x, dst_y is offset in output buffer where 0,0 from input layer will be rendered. With that you can move output horizontally and vertically.
Additionally, somewhere in XimrContext structure there is scaling ratio (or really two ratios - horizontal and vertical) set. Those apply to all layers and are used to up/downscale from layers to output buffer. This is set once per XimrContext, so it applies to all layers at once - thus as long as you alter Canon generated XimrContext this should be fine.
All those params change for each output type. They are different for LCD, HDMI, EVF (or in general per output YUV resolution). So when switched to HDMI, you would need to update both crop region and offsets to probably something like (0,0, buf_w, buf_h),(0,0) to both properly start buffer from 0,0 and tell Zico to render whole buffer content.
For horizontal shift there maybe an issue with buffer memory alignment - i touched that topic in my writeup, I had to memory-align buffers on Digic 7 to 256 blocks - see my PoC from chapter 1.2
But if this would be the issue, you would get a random shift on every boot / buffer allocation unless your method of malloc returns the same address every time ;)
-
I had a thought that maybe the zico side needs to know the buffers in advance, so I added an offset (+256) to the 2nd layer's rgba buffer address. Aside from the shifted view, no artifacts are visible on hdmi output (no double drawing).
Try shifting it by a larger negative amount.
In the attached image I have copied layer 2 and just adjusted the RGBA buffer address lower in memory by 40 rows.
I have no explanation for this - it is just weird.
Edit: This also happens if I just change the RGBA buffer address in layer 2 by the same amount without duplicating the layer (2nd screenshot).
Phil.
-
Try shifting it by a larger negative amount.
I'm 99% sure this is your problem. I never tried to shift layer by "negative amount", only positive. And srsa confirms no issues on that.
Can you dump XimrContext struct for me while this weird issue is visible?
-
Try shifting it by a larger negative amount.
I'm 99% sure this is your problem. I never tried to shift layer by "negative amount", only positive. And srsa confirms no issues on that.
Can you dump XimrContext struct for me while this weird issue is visible?
Attached is a zip file with the ximr context dump from the second screen shot in my earlier post.
The only change made to the context is to shift the RGBA buffer address in the second layer as I described. Everything else is unchanged.
In this dump the buffer address is 0x42584800, the normal address is 0x425aa000.
Edit: This is from the G7X2 as were the earlier screen shots. The G5X behaves the same.
Phil.
-
Hi,
According to your dump:
OutputChunk:
Layer config:
- width: 960
- height: 540
VRAM struct:
- width: 1024
- height: 768
- pBitmap @ 0x7FD00000
- pOpacity @ 0x7FB80000
- flags: 0x1040280 (UYVY + Alpha)
Layer 0 (Canon):
Layer config:
- color_type: 1 (UYVY + Alpha ?!?!)
- src_x: 0
- src_y: 0
- src_w: 960
- src_h: 540
- dst_x: 0
- dst_y: 0
VRAM struct:
- width: 1024
- height: 768
- pBitmap @ 0x4196A000
- pOpacity @ 0x41AEA000
- flags: 0x1040280 (UYVY + Alpha ?!?!)
Layer 1 (yours):
Layer config:
- color_type: 5 (RGBA)
- src_x: 0
- src_y: 0
- src_w: 720
- src_h: 480
- dst_x: 120
- dst_y: 30
VRAM struct:
- width: 960
- height: 540
- pBitmap @ 0x42584800
- pOpacity @ 0x0
- flags: 0x5040100 (RGBA)
Please note, I might have swapped src_x/y with dst_x/y. Digic 8 uses slightly different struct in terms of both fields order and data types.
This both answers and raises some questions.
First, looks like Canon switches to YUV GUI rendering ?! It uses 1024x768 YUV buffer and renders 960x540 starting from 0,0.
Since output is also 960x540 - I believe scaling factor is 1:1 (idk where it is located in XimrContext).
With that said, your layer is 960x540 RGBA but you told it to render 720x480 starting from 120,30. This is probably source of most problems.
Change layer config to 960x540 from 0,0 - like Canon layer does.
Layer config:
- color_type: 5 (RGBA)
- src_x: 0
- src_y: 0
- src_w: 960
- src_h: 540
- dst_x: 0
- dst_y: 0
I believe this will solve your layer offset problems.
I attached partial grammar for Hexinator. If you load your dump + this grammar, you can see what different fields mean. This is specific for dump provided, as XimrContext may differ on other cameras.
(https://i.imgur.com/lLOROoi.png)
-
With that said, your layer is 960x540 RGBA but you told it to render 720x480 starting from 120,30. This is probably source of most problems.
Change layer config to 960x540 from 0,0 - like Canon layer does.
Thanks for looking; but in this dump I have NOT added any new layers to the display. Both layers are Canon layer with Canon values for all properties.
The only change I made was to adjust the Canon RGBA buffer address to demonstrate that the weird rendering issue also happens unless the buffer addresses are exactly what the Canon UI uses. You can see the rendering error at the top of the screen shot where content that should have been off the bottom of the screen is being shown.
Phil.
-
Oh, I misunderstood that. This is even funnier if they mix RGBA and YUV layers.
This is Digic 7, am I correct? I'll try to replicate it on 200D.
This happens only on HDMI out?
-
Oh, I misunderstood that. This is even funnier if they mix RGBA and YUV layers.
This is Digic 7, am I correct? I'll try to replicate it on 200D.
This happens only on HDMI out?
Same on G5X which is Digic 6.
It only appears to happen when using HDMI.
-
@philmoz
Have you tried dumping the contents of the yuv layer (layer0) in hdmi mode?
Because I just did that and found my new layer's content in it - that's the full width junk that appears as extra.
Also, that layer seems to visually disappear when I enter the Canon menu. When I compare the ximr structures in those cases, I find a changed byte in layer2 (that layer is supposed to be invalid) and a changed word in the unparsed part of the struct that follows the layer definitions (plus the output buffers can be flipped, but that's normal and doesn't influence anything).
-
I checked, and:
- no such thing happen on EOSR or 200D
- 200D XimrContext mapped directly to grammar I made for you
I think your problem is related to YUV layer itself. It is strange for me that Canon uses one YUV and one RGB layer... I'd look how this YUV layer is created by Canon code.
I attached XimrContext from 200D for reference. May be helpful in future.
This is with my layer setup (Canon has only one layer on 200D), while in HDMI output mode.
[Edit]
Brainfart. I removed most of the post as it was wrong.
MARV buffer size (resolution) is one thing, Layer config is just "put that rectangle from buffer, starting from 120x30 of size 960x540 on screen; start drawing from 0,0".
This was source of that noise in my case, I told it to go outside the buffer myself ;)
-
@philmoz
Have you tried dumping the contents of the yuv layer (layer0) in hdmi mode?
Yes layer 0 is where the extra stuff us being rendered to - setting it's visibility to 0 makes it go away.
Unfortunately this layer is also where the Canon focus rectangle is drawn so disabling it is not really an option.
Phil.
-
Yes layer 0 is where the extra stuff us being rendered to - setting it's visibility to 0 makes it go away.
Unfortunately this layer is also where the Canon focus rectangle is drawn so disabling it is not really an option.
I tried going after that buffer (0x41141000 in multiple models), but did not get very far. The sole display-related reference to it is one level up from the ximr-creating routine, where it is placed in a MARV struct. I also could not find that address in the zico firmware. It's not impossible that it's being mov + add'ed together somewhere else, but, for the time being, I have no idea how that buffer gets its original content.
For another trial, I zeroed out the third layer's descriptor (which does have some bytes other than zero in hdmi mode), but the double render was unaffected.
-
Found it. The firmware uses ximrexe (a separate call, just before the overlay is refreshed) to create the yuv layer in hdmi mode. Recognizing that case is simple: the yuv layer is updated when the output buffer is 0x41141000 (for most cameras I guess).
It looks like that buffer only has secondary use in a few cases (factory exe, developtest and such), so it could potentially be used for display purposes. Inside are 960x540 yuv and opacity buffers in m10.
-
This come through my mind, but I thought it would be stupid to go rgb -> yuv and then yuv + rgb -> yuv once again. Looks that I was wrong.
So with that (if you skip adding your layer to overlay render calls) everything is fine?
-
So with that (if you skip adding your layer to overlay render calls) everything is fine?
The extra full width copy of the new layer disappears, so it's fine.
The source of the yuv layer is the second 960x480 rgba buffer (on m10). I guess they decided to do this in order to resize that layer to correctly show at 16:9 aspect.
-
Found it. The firmware uses ximrexe (a separate call, just before the overlay is refreshed) to create the yuv layer in hdmi mode. Recognizing that case is simple: the yuv layer is updated when the output buffer is 0x41141000 (for most cameras I guess).
It looks like that buffer only has secondary use in a few cases (factory exe, developtest and such), so it could potentially be used for display purposes. Inside are 960x540 yuv and opacity buffers in m10.
Awesome - thanks for that.
Comparing the firmware code to the M10, the corresponding G7X2 buffer address is 0x4196a000.
If I skip adding my layer when the layer 0 buffer is 0x4196a000 then I get my layer scaled up to the YUV layer size and rendered underneath the Canon UI.
However if I only add my layer when the buffer is 0x4196a000 (for HDMI) then I get my layer un-scaled and on top of the Canon UI.
Edit: On the G7X2, when using HDMI out, the new layer I add must have dimensions of 960x540 in the MARV section. Any other size results in random garbage being added to the output YUV layer.
Phil.
-
@srsa_4c
In the current CHDK code the CHDK UI is drawn directly on the output YUV buffer so everything drawn is immediately visible.
This requires some way to notify CHDK that the screen needs to be redrawn which we have various solutions for.
If we move the CHDK UI to a new RGBA layer and insert it into the ximr context then our content won't be visible unless the firmware does a screen refresh.
So we need some way to force the firmware to update the display so our layer gets re-drawn.
Calling transfer_src_overlay seems to work; but I'm concerned their could be timing issues with the firmware and CHDK both calling this.
Have you come across any other way to tell the Canon code that a screen refresh is needed?
Phil.
-
You need [1] to at least match layer resolution (resolution in MARV structure + buffer size for it) to layer size of Canon code.
After that it is all about manipulating coordinates/size of "rectangle to be transfered" (i mean src_x/y, src_w/h and dst_w/h).
You will probably need to adjust coordinates based on active display output. EOSR does this "accidentally" in Canon code for me.
200D does not, and with "default" offsets (120,30) (720x480) (0,0) it will go to 120x30 of layer buffer, fetch 720x480 rectangle starting from that point and draw it from 0,0 of visible output area.
So for HDMI output one need to switch from (120,30) (720,480) (0,0) to (0,0) (960,640) (0,0), and vice versa.
For cameras with EVF (if they are any) you will have similar third case for EVF.
[1]
As I said a few posts before, layers are not upscaled separately to fit the screen, but there's a single "scaling ratio" defined for whole XimrContext.
Canon code is keeping this scaling ratio "right" for their layers (and this is the reason why all of them have one resolution).
Technically you should be fine with any lower resolution as long as you keep Ximr drawn rectangle coordinates in that buffer - but you won't be able to draw over full screen due to how scaling ratio is handled globally.
As for "telling Canon to refresh", we don't.
In EOS roms there's a flag that we call refresh_display_needed. If set to 1 and refreshVrmsSurface() is called (this is the one that does XimrExe call in EOS), it will redraw everything.
If you just set the flag, you will wait forever, so I initially created own redraw() which set the flag, did caches sync (iirc it was necessary) and called refreshVrmsSurface().
Of course this is different for your codebase, but you can just trace how to properly call that function which does XimrExe inside.
Later we switched into another approach.
We just "steal" winsys semaphore, and guard our own XimrExe call with pointer to "old" (existing) XimrContext structure (as the buffer location used by Ximr in advance). That's it, done.
Winsys semaphore is used in EOS by refreshVrmsSurface() to guard XimrExe too. Not sure if you have any equivalent, and maybe it is not really needed.
The worst it can happen is short visual glitch when switching outputs (as your code might race Canon one, and try to render before Canon updated (in your case regenerated) structure to match HDMI settings)
-
Calling transfer_src_overlay seems to work; but I'm concerned their could be timing issues with the firmware and CHDK both calling this.
Have you come across any other way to tell the Canon code that a screen refresh is needed?
I haven't found a variable that would do that. But I do have an idea for a workaround. If I recall right, most or all drawing operations are done by the CtrlSrv task. If we tell that task to execute transfer_src_overlay, chances for a clash should become pretty low. There is a firmware function for that, I called it exec_via_ctrlsrv in the m100 source. I don't think it's in the sigfinders yet, its address in m100 100a is 0xE033F5E8. Takes a function pointer and another argument which will be passed to the function in r0.
About the order of layers: I'm sure that can be fixed somehow (either by rearranging them or maybe there is priority/z-order info in the ximr struct).
edit:
We could also consider executing just ximrexe instead of the whole transfer_src_overlay.
-
maybe there is priority/z-order info in the ximr struct
@srsa_4c None that I'm aware of. Layers are always drawn starting from zero. They are always referenced by ID while being added to XimrContext in both EOS and what I saw in M10 ROM.
I guess you want to draw over LV (zebras, etc) but still allow Canon GUI to be drawn over that? As you already alter XimrContext by hand, reordering them should be simple.
[e]
We could also consider executing just ximrexe instead of the whole transfer_src_overlay.
This is almost exactly what we do currently in Magic Lantern, as mentioned in my previous post.
And it is also how our "April fools" Doom 200D port was redrawing screen in ~20 fps (render code was still the bottleneck)
-
Additionally, somewhere in XimrContext structure there is scaling ratio (or really two ratios - horizontal and vertical) set.
Yes. I upscaled my own layer. It also can be flipped, mirrored, shifted in 4 directions. But sometimes it disappears. Probably CHDK can draw in 360*240 buffer and then upscale it using XIMR.
(https://chdk.setepontos.com/index.php?action=dlattach;topic=12788.0;attach=17084)
-
@Ant are you sure you upscaled only your layer? I see duplicated Canon GUI is upscaled too.
According to my knowledge you can set scaling ratio (multiplier) once for all layers. This is kind of confirmed by XCMStatus on R+ which displays scaling ratio in Output Chunk section, not per layer.
Which offset in XimrContext you used for that upscaling (and which camera?)
For reference, XCMStatus output (part of XimrContextMaker which is "userspace tool" for XCM on R+):
This should give you an idea what is set "per layer" and what "per context" (those in Output Chunk, XCM can manage 4 contexts at once, that have the same input layers but different output chunk - that's why there are 4 outputs listed).
K424[1]>XCMStatus
--- XimrContextMaker 0x00bce800 ---
[Input Layer] No:0, Enabled:1
VRMS Addr:0x02e18500, pImg:0x02c1e100, pAlp:0x00000000, W:960, H:540
Color:=0x05040100, Range:FULL
srcX:0120, srcY:0030, srcW:0720, srcH:0480, dstX:0000, dstY:0000
[Input Layer] No:1, Enabled:1
VRMS Addr:0x03012a00, pImg:0x02e18600, pAlp:0x00000000, W:960, H:540
Color:=0x05040100, Range:FULL
srcX:0120, srcY:0030, srcW:0720, srcH:0480, dstX:0000, dstY:0000
[Input Layer] No:2, Enabled:0
[Input Layer] No:3, Enabled:0
[Input Layer] No:4, Enabled:0
[Input Layer] No:5, Enabled:0
[OutputChunk] No:0, Enabled:1
VRMS Addr: 0x412ff900, pImg: 0x41100100, pAlp: 0x00000000, W:1024, H:682
Color:=0x11060200
LayerEnabledBit:ffffffff, isActualSize:0, isSetToContext:1
Output Offset X:0000, Y:0000
Resize fromX:0000, fromY:0000, outputW:1024, outputH:0682
Horizontal 64/45, filter:0, Vertical 341/240, filter:0
[OutputChunk] No:1, Enabled:0
[OutputChunk] No:2, Enabled:0
[OutputChunk] No:3, Enabled:0
[LUT] Addr:0x00000000 Type:LUT_RANGE_FULL
LUT is not enabled.
[Ximr Context] No:0, Addr:0x00bce810, Size:0x0000031c, Eanabled:1
//here goes XimrContext structure hex dump, so I skippped it
-
@Ant are you sure you upscaled only your layer? I see duplicated Canon GUI is upscaled too.
Sure. As you can see my upscaled layer is rendered over Canon's layer and over focus frame. I just copied Layer0 descriptor and put it after Layer1 descriptor.
Which offset in XimrContext you used for that upscaling (and which camera?)
This should be Byte+0x07 in InputLayer descriptor. 0x06 means both coordinates to be upscaling x2. EOS M3. LCD display type.
-
This should be Byte+0x07 in InputLayer descriptor. 0x06 means both coordinates x2 upscaling. EOS M3.
I need to test it on EOS, but this looks like a great find!
-
Thanks @Ant - that's a great find :)
This works on the G7X2 and works mostly ok on the G5X.
On the G5X when using the EVF the added RGBA layer gets clipped to 347 pixels wide.
In the attached screenshot the 4 blue boxes should all be the same size. The white line on the right is in column 346.
When using the LCD or HDMI the display is correct and the boxes are displayed fully.
Phil.
-
@reylay
I read in 5868:
Fix for CHDK menus to resize and position correctly if screen size is changed while menu is displayed. Can happen if switching between LCD, EVF and HDMI.
What I notice on the M3 is that when you switch between LV and EVF, the CHDK histogram does not get drawn in the 'correct' place, ie it seems to remain at its absolute (LCD based) position, rather than its position being scaled.
Just an observation.
Cheers
Garry
-
In case anyone is interested here is a patch of my current progress on using an RGBA Ximr layer for the CHDK UI.
I have implemented this for the G5X and G7X2 in this patch.
From what i have tested so far it works well - rock steady CHDK UI with no flickering.
I create a 360x240 (or 480x270 for HDMI) buffer inserted into the Canon display pipeline via the dry_memcpy patch.
This is then scaled 2x in both directions when rendered.
At the moment the CAM_DRAW_RGBA setting has to be in the makefile for the camera in order to build correctly - I'm not sure how to fix this at the moment.
I'm sure much of this could be done better so feedback is welcome.
Phil.
-
@philmoz
Looking forward to testing this on the M3.
-
@pigeonhill
Here is a test build for M3 1.20f.
Note this is very experimental. It may not work, it may crash or cause issues in areas I have not fully tested.
One change you will need to make for your script is the display size - the current code draws to a 720x480 display.
In this version the CHDK UI buffer is 360x240 pixels so you will need to adjust any drawing you do to the screen.
Phil.
-
@philmoz
Phil
Transformational!!!!!!! :)
The overlays are rock solid and 100% compatible with the Canon GUI, ie as I cycle through, including the Canon histogram.
I won't try and tweak my code yet, as I'm sure you will be refining things.
As soon as you think you have a stable configuration, I'll tweak my Bracketing script to match the new screen sizes.
Fantastic work and thanks for your efforts: and my M3 builds ;)
Cheers
Garry
-
In case anyone is interested here is a patch of my current progress on using an RGBA Ximr layer for the CHDK UI.
Why don't you use own YUV+Opacity buffers(as Ximr input layer) for drawing CHDK UI?
I also suggest not to patch dry_memcpy or TakeSemaphore. I think these functions are being called more intensively.
It's better to hook disabled debug messages inside mzrm_sendmsg function:
void __attribute__((naked,noinline)) MZRM_hook() {
asm volatile (
"ldr r0, =0xfc2fd873\n"
"cmp r0,lr\n"
"bne mh_exit\n"
"push {lr}\n"
"mov r1, r11\n" // MZRM message
"bl mylogfunc2\n"
"pop {pc}\n"
"mh_exit:\n"
"bx lr\n"
".ltorg\n"
);
}
EOS M3 v1.01a
But this require parsing the MZRM messages.
-
Why don't you use own YUV+Opacity buffers(as Ximr input layer) for drawing CHDK UI?
I would consider using the area where the firmware's yuv layer is drawn. By hooking the ximrexe call that creates it, we could reconfigure the yuv layer to be half height or width (and later double its height (or width) when it is used as input layer). The remaining space in that area is more than enough for a 720x240 RGBA buffer for CHDK - we wouldn't have to allocate any memory.
I found more than one byte in the layer struct where certain bits cause the layer to be rendered with double width and/or height. I don't know what this effect actually is, it's not a smooth bilinear operation, it just doubles pixels.
-
By hooking the ximrexe call that creates it, we could reconfigure the yuv layer to be half height or width
This will decrease the quality of Canon graphics
we wouldn't have to allocate any memory.
Is this a big problem to allocate a couple of megabytes from hundreds?
Currently I'm experimenting with my own YUV buffer created using exmem_ualloc. I use it as third layer to draw CHDK UI over Canon GUI.
-
Is this a big problem to allocate a couple of megabytes from hundreds?
It's virtually certain there's megabytes to spare *somewhere*, but that's not the same as knowing where they are or being able to allocate them without impacting the original firmware. For example, we've observed on earlier cams that using exmem can impact the maximum jpeg quality, as well as the conflicts with video buffers.
I also suggest not to patch dry_memcpy or TakeSemaphore. I think these functions are being called more intensively.
This would be my initial gut reaction too, but the hook is essentially just comparing LR with a constant and jumping back to the firmware if it doesn't match, which is negligible compared to the rest of the function.
Phil's version does slightly more, but could be optimized for the non-matching case. R12 and R3 are free to use. (edit: To be clear, I'm not against using the log function instead, I generally favor using the approach with lowest impact to other parts of the firmware. I just wouldn't worry much about hooking dry_memcpy)
-
Thanks @Ant - i was able to figure out patching the mzrm_sendmsg logging call and access the Ximr context data.
I am still able to then add the new layer in the Ximr context so no need to parse MZRM stuff.
This is more efficient (called less often), especially in record mode.
Phil.
-
so no need to parse MZRM stuff.
By parsing, I meant checking the message type number(the 1st word) and taking the address of the XIMR context (the 4th word). This can be done using assembler.
XIMR context in XimrExeGain message also can be modified.
How do you clear the CHDK layer when you enter canon menu?
P.S. Original canon buffers are aligned to 0x1000.
-
so no need to parse MZRM stuff.
By parsing, I meant checking the message type number(the 1st word) and taking the address of the XIMR context (the 4th word). This can be done using assembler.
XIMR context in XimrExeGain message also can be modified.
How do you clear the CHDK layer when you enter canon menu?
P.S. Original canon buffers are alligned to 0x1000.
Buffer is cleared using _bzero firmware function (previously used _memset32).
On the G7X2 and G5X the buffers are aligned to 0x100 byte boundary.
Phil.
-
Buffer is cleared using _bzero firmware function (previously used _memset32).
I'm trying to understand not how, but why it is cleaned, when we enter the Canon menu. Previously, the bitmap buffer was cleared when Canon drew its menu.
-
that using exmem can impact the maximum jpeg quality, as well as the conflicts with video buffers.
I got this problem during video playback when I allocated 16MB buffer in ExMem for my logs.
But there is a space between two bitmap buffers on EOS M3 that looks unused...
-
Buffer is cleared using _bzero firmware function (previously used _memset32).
I'm trying to understand not how, but why it is cleaned, when we enter the Canon menu. Previously, the bitmap buffer was cleared when Canon drew its menu.
Sorry, misunderstood the question.
Attached is an updated patch - in the lib.c update_ui() function for either G5X or G7X2 I have added logic to call gui_set_need_restore() if the camera is switched to play mode or the Canon menu is opened. This will erase the CHDK RGBA layer via the vid_bitmap_erase() function.
This also includes the change to use the debug logging function override instead of dry_memcpy.
EDIT: patch updated. I moved the above logic to the gui_redraw() function in gui.c.
Phil.
-
@philmoz
Phil if you have the time, and believe it would help your developments, I would love to continue to test things on my M3.
Does your previous guidance still apply regarding scaling things down by 2?
-
@philmoz
Phil if you have the time, and believe it would help your developments, I would love to continue to test things on my M3.
Does your previous guidance still apply regarding scaling things down by 2?
@pigeonhill - working on a few issues with it at the moment.
I will be busy with other things for a week or so, not sure when I will be able to do another test version.
Phil.
-
@philmoz
Fully understood.
I’ll wait for you to push test builds my way, when you are ready.
Cheers
Garry
-
Using a dedicated RGBA buffer for the CHDK UI definitely make the UI rock solid and avoids massive flickering regardless of what the Canon UI is doing.
One thing that will probably require discussion is what size to make the RGBA buffer?
I'm currently testing this with a quarter size buffer (36x240) and 2x scaling; but I'm sure there are arguments for going with a full size buffer (720x480) and no scaling.
Half size RGBA (360x480)
Pros:
- Requires less memory for buffer (.5MB vs 2MB)
- Drawing code is simpler and faster (and smaller)
- More compatible with scripts and existing logic that was built for this size screen
Cons:
- Does not take advantage of the higher resolution available
- Will require changes to the way the font size values are handled to ensure modules are compatible between YUV and RGBA drawing for Digic 6 & 7
- Changing from YUV to RGBA drawing version requires user reset their CHDK UI config settings on the camera (screen positions are wrong).
I'm sure there are other things I have not considered and would be interested in what others think.
-
@philmoz
When I tested the M3 build version you sent me, I started thinking about this, ie looking ahead to converting my scripts to the ‘new’ display space, ie if it had to be halved.
One thought I had was that we standardise the CHDK drawing area, eg let’s say it will always be 720/480, irrespective of the camera.
This camera independent space then gets scaled in the CHDK backend, on a camera specific basis, if required, and according to the RGBA buffer that is being used.
The main advantages of this approach are that older scripts should run without change and the Lua drawing API could be developed/evolved knowing that drawing space is always 720/480.
Scaling to, say, the EVF will/may introduce differential x/y stretching, but I can’t see this being an issue.
The prize here is to eliminate flickering, standardising/fixing user CHDK drawing space will allow the backend gurus, like you, to press ahead with developments, with the front end scripter, like me, carrying on developing their ideas, with both protected from each other and in sync.
Just my humble initial thoughts.
Cheers
Garry
-
I would consider using the area where the firmware's yuv layer is drawn. By hooking the ximrexe call that creates it, we could reconfigure the yuv layer to be half height or width (and later double its height (or width) when it is used as input layer). The remaining space in that area is more than enough for a 720x240 RGBA buffer for CHDK - we wouldn't have to allocate any memory.
I implemented this on my m10, using Phil's v1 patch. I went for 720x240, but will probably revert to 1:1 aspect because there is not enough space (in that area) for a full-screen 960x270 rgba buffer.
Note the numer and denom (numerator, denominator) members of ximr_context: these control the magnification of the output.
Index: platform/m10/lib.c
===================================================================
--- platform/m10/lib.c (revision 5875)
+++ platform/m10/lib.c (working copy)
@@ -204,6 +204,7 @@
}
+extern int displaytype;
#ifdef CAM_SUPPORT_BITMAP_RES_CHANGE
/*
* needed because bitmap buffer resolutions change when an external display is used
@@ -211,7 +212,6 @@
*/
void update_screen_dimensions() {
// see sub_fc177316 in 110d for the values
- extern int displaytype;
static int old_displaytype = -1;
if (old_displaytype == displaytype) {
@@ -278,3 +278,167 @@
extern char jpeg_count_str[];
return jpeg_count_str;
}
+
+// ximr stuff below
+
+// Ximr layer
+typedef struct {
+ unsigned char unk1[7];
+ unsigned char scale;
+ unsigned int unk2;
+ unsigned short color_type;
+ unsigned short visibility;
+ unsigned short unk3;
+ unsigned short src_y;
+ unsigned short src_x;
+ unsigned short src_h;
+ unsigned short src_w;
+ unsigned short dst_y;
+ unsigned short dst_x;
+ unsigned short enabled;
+ unsigned int marv_sig;
+ unsigned int bitmap;
+ unsigned int opacity;
+ unsigned int color;
+ unsigned int width;
+ unsigned int height;
+ unsigned int unk4;
+} ximr_layer;
+
+// Ximr context
+typedef struct {
+ unsigned short unk1;
+ unsigned short width1;
+ unsigned short height1;
+ unsigned short unk5;
+ unsigned int unk6[9];
+ unsigned int output_buf;
+ unsigned int output_opacitybuf;
+ unsigned int output_color;
+ int buffer_width;
+ int buffer_height;
+ unsigned int unk2[2];
+ ximr_layer layers[8];
+ unsigned int unk3[24];
+ unsigned char denomx;
+ unsigned char numerx;
+ unsigned char denomy;
+ unsigned char numery;
+ unsigned int unk7;
+ short width;
+ short height;
+ unsigned int unk4[27];
+} ximr_context;
+
+int display_needs_refresh = 0;
+
+#define FW_YUV_LAYER_BUF 0x41141000
+#define FW_YUV_LAYER_SIZE (960*270*2)
+#define FW_YUV_LAYER_FULLSIZE (960*270*2+960*270)
+#define CHDK_LAYER_BUF (((FW_YUV_LAYER_BUF+FW_YUV_LAYER_FULLSIZE)+0xff)&0xffffff00)
+
+unsigned char* chdk_rgba = 0;
+int chdk_rgba_init = 0;
+int bm_w;
+int bm_h;
+
+void vid_bitmap_erase()
+{
+ extern void _memset32(unsigned char *s, int n, unsigned int pattern);
+ _memset32(chdk_rgba, bm_w * bm_h * 4, 0);
+}
+
+int last_displaytype;
+
+/*
+ * Called when Canon is updating UI, via dry_memcpy patch.
+ * Sets flag for CHDK to update its UI.
+ * Also needed because bitmap buffer resolution changes when using HDMI
+ * LCD = 720 x 480
+ * HDMI = 960 x 540
+ */
+void update_ui(ximr_context* ximr)
+{
+ // Init RGBA buffer
+ if (chdk_rgba_init == 0)
+ {
+ chdk_rgba_init = 1;
+ chdk_rgba = (unsigned char*)CHDK_LAYER_BUF;
+ last_displaytype = -1;
+ }
+
+ // Make sure we are updating the correct layer - skip redundant updates for HDMI out
+ if (ximr->output_buf != (unsigned int)FW_YUV_LAYER_BUF)
+ {
+ // Update screen dimensions
+ if (last_displaytype != displaytype)
+ {
+ last_displaytype = displaytype;
+
+ if (ximr->buffer_width == 0x3c0) {
+ // no space for bigger horizontal res, unless...
+ bm_w = 720;
+ bm_h = 240;
+ } else {
+ bm_w = 720;
+ bm_h = 240;
+ }
+
+ camera_screen.width = bm_w;
+ camera_screen.height = bm_h;
+ camera_screen.buffer_width = bm_w;
+ camera_screen.buffer_height = bm_h;
+
+ // Reset OSD offset and width
+ camera_screen.disp_right = camera_screen.width - 1;
+ camera_screen.disp_width = camera_screen.width;
+
+ // Update other values
+ camera_screen.physical_width = camera_screen.width;
+ camera_screen.size = camera_screen.width * camera_screen.height;
+ camera_screen.buffer_size = camera_screen.buffer_width * camera_screen.buffer_height;
+
+ // Values for chdkptp live view
+ camera_screen.yuvbm_width = ximr->width;
+ camera_screen.yuvbm_height = ximr->height;
+ camera_screen.yuvbm_buffer_width = ximr->buffer_width;
+
+ // Clear buffer if size changed
+ vid_bitmap_erase();
+
+ // Tell CHDK UI that display needs update
+ display_needs_refresh = 1;
+ }
+
+ if (ximr->layers[0].bitmap == (unsigned int)FW_YUV_LAYER_BUF) {
+ ximr->layers[0].opacity = (unsigned int)(FW_YUV_LAYER_BUF+FW_YUV_LAYER_SIZE);
+ ximr->layers[0].src_h = 270;
+ ximr->layers[0].height = 270;
+ ximr->layers[0].scale = 4; // x2 scaling vertically for the canon yuv layer
+ }
+
+ if (chdk_rgba != 0)
+ {
+ // Copy canon layer
+ memcpy(&ximr->layers[3], &ximr->layers[1], sizeof(ximr_layer));
+
+ // Remove offset
+ ximr->layers[3].scale = 4; // x2 scaling vertically
+ ximr->layers[3].src_w = bm_w;
+ ximr->layers[3].src_h = bm_h;
+ ximr->layers[3].dst_x = 0;
+ ximr->layers[3].dst_y = 0;
+
+ // Set our buffer
+ ximr->layers[3].bitmap = (unsigned int)chdk_rgba;
+ ximr->layers[3].width = bm_w;
+ ximr->layers[3].height = bm_h;
+ }
+ }
+ else
+ {
+ ximr->output_opacitybuf = (unsigned int)(FW_YUV_LAYER_BUF+FW_YUV_LAYER_SIZE);
+ ximr->height = ximr->buffer_height = 270;
+ ximr->denomy = 0x6c;
+ }
+}
This will decrease the quality of Canon graphics
Samples attached.
-
Samples attached.
Untouched grid lines look better. :)
What about more detailed GUI elements like face frame, electronic level?
-
I tried the technique from srsa_4c on the G7X2 and it seems the affected layer is the one where the focus rectangle and grid lines are drawn.
It also only affects HDMI output on the G7X2, using the LCD there is no effect.
Original and half height screenshots from G7X2 attached (from HDMI output).
Phil.
-
I have created a 'ximr_draw_rgba' branch in SVN so this doesn't get lost.
Latest code patch is attached here as well.
This updates the build system to avoid module conflicts between YUV and RGBA versions for Digic 6/7.
@pigeonhill - attached is a test version for the M3.
This uses a 360x240 display size so you may want to use a different SD card - you will need to reset the CHDK OSD options to fix screen positions of CHDK UI elements. Your scripts will also need to take this into account.
Assuming it works can you check that the CHDK UI works on various output devices (LCD, EVF, HDMI, etc).
Zebra and Edge overlay have not been checked and may crash so I would avoid those.
Phil.
-
@philmoz
:)
Initial feedback is great work. No flickering :D
I also note that LCD vs EVF display is handled seamlessly. Before I had to detect if the LCD or EVF was active and scale things myself.
Of course, drawing space is restricted/reduced to 360x240, but that is a small price to pay for eliminating the flickering.
One advantage/disadvantage is that the CHDK histogram is huge :) Great for those of us with old eyes ;)
The histogram, if always on, goes away when the Canon Menu is displayed, great, but remains whatever Canon INFO state you are in. Do you think it would be possible to have the CHDK histogram disappear, as with the Canon Menu, when the cycle through the INFO states, ie only show if Canon stuff not showing. Or have an enhanced shoot feature that means you can toggle the histogram on and off by using a half shutter press, say.
Bottom line: great work and I'm more than happy to keep testing future developments.
UPDATE 1
One thing I have noticed is that switching to EVF seems to offset all CHDK drawing by about -15 pixels, ie everything is shifted up.
UPDATE 2
I think something is amiss with the histogram as when I set the exposure to the fastest, 1/4000 and have the lens cap on, the histogram shows highlights warnings at the highlight end, but only on the LCD, not the EVF ??? The green channel changes radically in the LCD, ie looks wrong in the LCD, but not the EVF.
UPDATE 3
My script refreshes the info bar every 1s. In LCD mode I see 'random', ie not correlated to a 1s interval, flashing of my bar, ie the drawing. In EVF mode this random flashing is noticeably less and near non existent.
UPDATE 4
I currently I use
lcd = get_gui_screen_width()
to detect LCD/EVF switching. The above now always gives 360. Is there another way to detect EVF or LCD, or even implement one, eg get_screen_type()
UPDATE 5
Have experimented with my drawing refresh logic, and concluded, that with this build, the best way forward is to only refresh my drawing IF DoF things change, eg focus; else don't redraw. This logic results in no flashing. The downside is that my drawing disappears when I switch between LCD and EVF, hence the need to detect LCD/EVF changes. A work around is that I've implemented a half shutter based refresh, ie in LCD or EVF mode pressing the half shutter refreshes my drawing stuff.
-
@pigeonhill
Thanks for testing and the feedback. My to-do list just got bigger :)
The switch between LCD & EVF should redraw the console and anything drawn with the 'drawings' library in Lua - not sure why this is not happening.
-
@philmoz
The switch between LCD & EVF should redraw the console and anything drawn with the 'drawings' library in Lua - not sure why this is not happening.
As I say, all the CHDK drawing gets drawn with a neg y offset in the M3 EVF.
For example, in the LCD ALT is drawn at the bottom of the LCD, in the EVF it's drawn displaced up by about 15 pixels.
-
@philmoz
The switch between LCD & EVF should redraw the console and anything drawn with the 'drawings' library in Lua - not sure why this is not happening.
As I say, all the CHDK drawing gets drawn with a neg y offset in the M3 EVF.
For example, in the LCD ALT is drawn at the bottom of the LCD, in the EVF it's drawn displaced up by about 15 pixels.
@pigeonhill
Is the top clipped (stuff missing) or is the display just taller with extra space at the bottom?
-
@philmoz
No clipping, just all the CHDK stuff offset in the neg y direction.
-
@philmoz
No clipping, just all the CHDK stuff offset in the neg y direction.
@pigeonhill
Thanks, it's probably like the G5X which has a taller EVF (360x270).
If you open the 'Enhanced Photo Operations' CHDK menu can you see the right hand side of the menu correctly in the EVF (with the scroll bar)?
-
If you open the 'Enhanced Photo Operations' CHDK menu can you see the right hand side of the menu correctly in the EVF (with the scroll bar)?
Confirmed. All I see is the neg y/vertical offset.
-
@philmoz
One additional thought, as you get this new display arrangement up and running.
Is there any chance you can implement a user accessible ‘guard pixel’ feature in the Lua api?
This will allow scripters to ensure their drawing can be auto refreshed if it disappears, eg as you switch between LCD and EVF, or, as in my use case, where I’m outside ALT mode, but the script is running, and I could be switching between Canon screens.
-
@philmoz
A short test of the HDMI out from the M3.
You can see the CHDK offset and the 'odd' flashing.
Cheers
Garry
https://www.dropbox.com/s/ctudp1uvu38n5mg/decodeVideo.MP4?dl=0 (https://www.dropbox.com/s/ctudp1uvu38n5mg/decodeVideo.MP4?dl=0)
-
I compiled this branch(5883) for EOS M3 101a and got a problem:
"ASSERT!! MakeOsdVram.c Line 603"
It happens when I turn on the camera in the Rec mode with HDMI cable connected.
When I turn on the camera in playback mode it's ok.
This is caused by _transfer_src_overlay. It seems that CHDK calls this function at an inappropriate moment.
Also the Viewfinder doesn't work in the CHDK-PTP program:
"chdkptp-r964\lua\gui_live.lua:559: width > buffer_width"
-
I compiled this branch(5883) for EOS M3 101a and got a problem:
"ASSERT!! MakeOsdVram.c Line 603"
It happens when I turn on the camera in the Rec mode with HDMI cable connected.
When I turn on the camera in playback mode it's ok.
This is caused by _transfer_src_overlay. It seems that CHDK calls this function at an inappropriate moment.
Likely similar to https://chdk.setepontos.com/index.php?topic=13993.msg142674#msg142674 possibly avoided by checking draw_is_suspended before redrawing, like elph130 does.
Also the Viewfinder doesn't work in the CHDK-PTP program:
"chdkptp-r964\lua\gui_live.lua:559: width > buffer_width"
If CHDK is drawing on a RGB buffer, but live view is using the YUV buffer, those dimensions will need to be identical or (more likely) disentangled.
-
Likely similar
But on previous builds(r5846) there was no this problem.
SRSA's method using FW_YUV_LAYER_BUF doesn't look beautiful on HDMI.
So I used the gap between two bitmap buffers. In the worst case(HDMI mode, don't know about EVF) it gives me:
0x415C1000-(0x41441000+960*540*2)=536064 Bytes > 480*270*4
Check your addresses...
-
When using the mzrm_sendmsg debug hook, both XimrExe and XimrExeGain messages need to be handled (same ximr struct is used in both). XimrExeGain is used when the Canon overlay is faded in/out. Ant actually mentioned this a few pages ago. Could be responsible for some of the display glitches reported by pigeonhill.
-
0x41441000+960*540*2
I have the yuv buffer's opacity buffer there, have you checked that? Nevermind. Not the same buffer.
-
On M3 opacity buffers are 0x41741000 and 0x41801000.
But the problem could be in EVF mode:
0x415C1000 - 0x41441000 = 1024*768*2 - no space for CHDK buffer
-
But on previous builds(r5846) there was no this problem.
The change appears to be from replacing the call to vid_bitmap_erase in update_ui with a call to gui_set_need_restore.
Still testing to see if just using vid_bitmap_erase is sufficient.
Phil.
-
You can see the CHDK offset and the 'odd' flashing.
@pigeonhill
Not sure about the flashing; but the console position is not offset - it's just that the HDMI buffer is taller (270 vs 240) so there is more space below it.
The <ALT> message is always anchored to the bottom of the screen; but the console position is set by the top left corner.
Attached is a new version to test.
The main change is the addition of a new Lua script function screen_needs_refresh() - if this returns true then the CHDK screen has been cleared and you should redraw your display.
After detecting screen_needs_refresh returning true be careful what you call. If anything you call triggers a CHDK UI refresh then this will set screen_refresh_true again and your code will spend a lot of time redrawing - it will likely flicker like crazy.
For example:
- do not call draw.redraw, use draw.overdraw instead. draw.redraw clears the CHDK UI and will trigger a screen_needs_refresh being set again
- if you want to refresh the console call console_redraw(1) to prevent the console from also triggering screen_needs_refresh being set again.
This screen_needs_refresh() function is just an idea I am playing with and it may change - I'm sure reyalp will have a better method to do this :)
The histogram size should also be correct now.
The EVf size has also been changed to 360x270.
Phil.
-
Phil
Initial testing looks good.
I used the screen_needs_refresh() to 'just' call draw.overdraw(), but this didn't seem to work. I then used it to recall my drawing function, which BTW also uses draw.overdraw(), and this did the trick. Thus, as I switch between LCD and EVF, my DoF info bar auto refreshes.
The odd flicker/glitch is still there, but random and not often.
The console and my drawing lateral offset to the left, in the HDMI out, is still there, as shown in the previous video.
The CHDK histogram is now drawn as 'normal', I miss that large histogram already :haha
One thing I have noticed, but it could have always been there, is the CHDK vs Canon histogram difference, and the CHDK LCD vs EVF histogram differences. I put the camera on a tripod, to freeze the scene, and looked at the CHDK LCD and EVF histograms, which are different.
Cheers
Garry
UPDATE 1
Forgot to say that the drawing overlay in the LCD is different to the EVF. In the LCD my bar, positioned at (0,0), and the ALT and console overlays the camera view. In the EVF, these sits outside the camera view.
UPDATE 2
The histogram remains persistent. Is there a way to switch off all CHDK drawing if the Canon stuff is being shown, ie the Q screen etc.
UPDATE 3
Further testing with my script, which allows the user to enter/exit ALT mode to do photo stuff, eg take pictures. If I do this, screen_needs_refresh() doesn't seem to work any more. Thus I need to do a manual refresh. But when I do, screen_needs_refresh() still doesn't work. It looks like going in and out of ALT mode impacts the functionality of screen_needs_refresh()...maybe?
-
@pigeonhill
New version to fix screen_needs_refresh when the script exits alt mode.
We don't currently detect if the Q screen is displayed so there is no option to disable histogram / CHDK OSD.
You can set the histogram to only show when the shutter is half pressed; but this does not work 100% in this version (it may leave old histogram data on screen).
The Canon OSD does not scale to fill the screen when using the EVF - it remains the same size but is centred. Ours expands so things are in different places relative to the Canon stuff.
Phil
-
Phil
That’s a little better, but I notice it gets confused and then stuck, eg: if I go out of ALT mode then in to the EVF from LCD, or the other way, the screen_needs_refresh() stops functioning. My manual refresh then brings the bar back, but screen_needs_refresh() then doesn't appear to be working as it should, ie doesn't detect the need for a refresh..
You can set the histogram to only show when the shutter is half pressed; but this does not work 100% in this version (it may leave old histogram data on screen).
Yes I have tried that, but as you say, it doesn't always work.
Still see histogram differences: LCD vs EVF and CHDK vs Canon.
UPDATE 1
Just noticed the console has shifted its (0,0) to the top of the screen. Any chance of the console position (0,0) being user positionable?
-
When re-using the buffer of the yuv layer, all variants of XimrExe need to be hooked. When XimrExeGain is left untouched, it will overwrite the whole buffer in HDMI mode. The dry_memcpy-based hooking method modified the original ximr structure, which was then subsequently used by XimrExe and XimrExeGain. The mzrm_sendmsg hook only gets a copy of that struct.
So, in case of M3, I'd do this:
Index: platform/m3/sub/120f/boot.c
===================================================================
--- platform/m3/sub/120f/boot.c (revision 5892)
+++ platform/m3/sub/120f/boot.c (working copy)
@@ -195,17 +195,23 @@
" ldr r0, =mzrm_sendmsg_ret_adr\n" // Is return address in mzrm_sendmsg function?
" cmp r0, lr\n"
" beq do_ui_update\n"
- "exit_debug_logging_my:"
+ "exit_debug_logging_my:\n"
" bx lr\n"
- "do_ui_update:"
+ "do_ui_update:\n"
" mov r0, r11\n" // mzrm_sendmsg 'msg' value (2nd parameter, saved in r11)
" ldr r1, [r0]\n" // message type
+ " mov r2, #0x24\n" // XimrExeGain?
+ " cmp r1, r2\n"
+ " beq handle_ximrexegain\n"
" mov r2, #0x23\n" // Ximr update? (3rd parameter to mzrm_createmsg)
" cmp r1, r2\n"
" bne exit_debug_logging_my\n"
" add r0, r0, #16\n" // Offset to Ximr context in 'msg'
" b update_ui\n"
+ "handle_ximrexegain:\n"
+ " add r0, r0, #24\n" // Offset to Ximr context in 'msg'
+ " b update_ui\n"
);
}
-
I did that more simply:
"ldr r0, =mzrm_sendmsg_ret_adr\n"
"cmp r0,lr\n"
"beq chk_msg_type\n"
"bx lr\n"
"chk_msg_type:\n"
"ldr r0, [r11]\n"
"cmp r0, 0x23\n" // message type XimrExe
"beq do_ui_update\n"
"cmp r0, 0x24\n" // message type XimrExeGain
"beq do_ui_update\n"
"bx lr\n"
"do_ui_update:\n"
"ldr r0, [r11, 0x0C]\n" //address of Ximr Context
"b update_ui\n"
-
@pigeonhill
Updated version;
- includes updated mzrm_sendmsg override logic from srsa_4c and Ant
- entering alt mode when a script is running fixed
- console position adjusted relative to the bottom of the screen if the screen size changes
- CHDK histogram should erase if not displayed
- screen_needs_refresh should work better
-
XimrExeGain is used when the Canon overlay is faded in/out.
Out of curiosity, it is used for some kind of animation? I see it uses the same structure, but takes 2 more params? I don't see any calls to XimrExeGain in 200D, M50, R. It seems to be missing at all from R6/Digic X. (but there's a new XimrExeDirect referenced there)
-
@philmoz
@pigeonhill
Updated version;
- includes updated mzrm_sendmsg override logic from srsa_4c and Ant
- entering alt mode when a script is running fixed
- console position adjusted relative to the bottom of the screen if the screen size changes
- CHDK histogram should erase if not displayed
- screen_needs_refresh should work better
Phil: looking good :)
Histogram disappears nicely, saved me one line of code, ie clearing the display ;)
In and out of ALT is solid.
Exit ALT, ie with a button other that full shutter, after I've been in and out of ALT, is solid.
The old console was always positioned at the bottom, this one is at the top. Not an issue but interested to know why the change?
Cheers
Garry
-
The old console was always positioned at the bottom, this one is at the top. Not an issue but interested to know why the change?
I made a change to try and keep the console position relative to the bottom of the screen when the screen height changes; but I think I got it wrong.
-
@pigeonhill
See if this version fixes the console.
-
Phil
That did it :)
BTW, I'll soon be posting a short video of my script running in the new CHDK version.
As I said elsewhere: the M3 is CHDK's flagship camera, or at least one of them ;)
Cheers
Garry
-
@philmoz
I did a test video quicker than I thought:
https://photography.grayheron.net/2021/05/exciting-things-happening-in-chdk.html (https://photography.grayheron.net/2021/05/exciting-things-happening-in-chdk.html)
Once again, thanks for all your hardwork, as well as others that have added their knowledge to the latest developments.
Cheers
Garry
UPDATE 1
Phil noticed a 'strangeness'. My script detects toggling beween ALT and non-ALT. In non-ALT the histogram is switch off via a set_config_value (https://chdk.fandom.com/wiki/Script_commands#set_config_value)() call. I've checked to see if CHDK registers this OK and it does. What I see is in ALT mode, ie set_config_value (https://chdk.fandom.com/wiki/Script_commands#set_config_value)(0), the histogram does not always disappear. If I go in and out of ALT a few times, it will disappear.
-
@philmoz
Addresses for EOS M3:
101a:
NHSTUB(VTMLock ,0xfc37eea1)
NHSTUB(VTMUnlock ,0xfc37f071)
DEF(debug_logging_ptr ,0x000286A0)
DEF(debug_logging_flag ,0x00028698)
DEF(mzrm_sendmsg_ret_adr ,0xfc2fd873)
121a:
NHSTUB(VTMLock ,0xfc37f241)
NHSTUB(VTMUnlock ,0xfc37f411)
DEF(debug_logging_ptr ,0x000286c0)
DEF(debug_logging_flag ,0x000286b8)
DEF(mzrm_sendmsg_ret_adr ,0xfc2fd8bb)
-
What I see is in ALT mode, ie set_config_value (https://chdk.fandom.com/wiki/Script_commands#set_config_value)(0), the histogram does not always disappear. If I go in and out of ALT a few times, it will disappear.
Does the histogram continue to update or is it a static image of the last values before it was switched off?
-
Addresses for EOS M3:
Thanks, I've added these to the test branch.
I assume the 'msg' parameter is in R11 for the debug logging patch and that the flag bit to enable logging is 0x200.
-
I assume the 'msg' parameter is in R11 for the debug logging patch and that the flag bit to enable logging is 0x200.
Yes. The flag bit is the same even for D6 DSLRs.
-
@philmoz
Does the histogram continue to update or is it a static image of the last values before it was switched off?
Just tested and, I'm embarrassed to say, I can't replicate the behaviour I saw yesterday. For now, as I switch between ALT and non ALT modes, with my script swtiching on and off the histogram, the histogram is removed OK.
What is a bigger issue, on the M3, is that the CHDK histogram is not reliable, as reported in https://chdk.setepontos.com/index.php?topic=14342.msg146032;topicseen#new
Thus, for me, the CHDK histogram is not usable on the M3: I'll 'just' be using the Canon histogram.
-
@philmoz
Partially ignore my last post, as I can replicate the problem: I had forgotten I coded a 'fix', ie clear the display when I switch between ALT modes ;-)
I can confirm the histogram freezes, ie it continues to show a static image.
-
I can confirm the histogram freezes, ie it continues to show a static image.
@pigeonhill
Please check if the attached version fixes this.
-
Phil
Looks to have fixed it.
See flashing of the histogram now and then, ie when clearing.
Do I assume this is just an artefact of your solution, ie loop until cleared?
However, as I said, until the CHDK histogram is ‘healed’, I won’t be using it on the M3.
Cheers
Garry
-
I modified the viewport dimensions for EOS M3.(in attachment)
I checked it in chdk-ptp with help of fase frame.
But values for EVF are theoretical.(I don't have it)
-
I modified the viewport dimensions for EOS M3.(in attachment)
I checked it in chdk-ptp with help of fase frame.
But values for EVF are theoretical.(I don't have it)
Thanks Ant.
@pigeonhill
Can you please check the edge overlay and zebra display in the EVF with the attached version.
-
@reyalp
Haven't used zebra before, so had to work out how to use it, ie read the manual ;)
Also, zebras don't work in ALT mode: intentional I guess?
All blinkies, blink every secondish, ie including solid. You can clearly see the blinkies being built, top to bottom, ie over about a sec, creating the additional blinking.
BTW I see there is no option to have blinkies on all the time, ie not needing to press the half shutter. IMHO this would work better when you are adjusting exposure and using blinkies.
EVF blinkies are displaced downwards. BTW I have the Canon EVF-DC2. The offset is about 3/4 of the Canon text showing exposure.
In EVF mode, as the blinkies (slowly) refresh, residue (sparse) pixels are left behind in random patterns.
Cheers
Garry
UPDATE 1
Tried pano edge overlays, with exposure warning on and off. Same result. big blocks of red, taking up about 1/3 of the screen height, with clear (slow) top to bottom scanning visible,
-
@pigeonhill
Test version for G7X 1.00d.
-
@philmoz
Quick test, eg with Canon histrogram and CHDK menu and OSD etc, looks good.
As I tweak my G7X bracketing script (different to M3 version, eg lens model and focus move) I will feedback any 'strangeness'.
Cheers
Garry
-
@philmoz
When you get a chance, could you also throw a 101d G5X build my way, or point me where to where I can download the build: sorry can't build myself.
Or are you only building to order at the moment?
Cheers
Garry
-
@philmoz
sorry can't build myself.
:D All You need is ...
https://chdk.setepontos.com/index.php?topic=12752.msg145097#msg145097
... and a mouse ... :-X
-
@Caefix
Thanks for the link.
I guess it’s more visceral that I don’t do C and build.
One day I’m sure I will make the transition.
Until then I ‘just’ stick with Lua :)
Cheers
Garry
-
@pigeonhill
G5X version.
-
Below is a summary of the changes needed in case anyone wants to try the Ximr layer drawing on another camera/firmware version.
As noted in the comments I find the Ghidra de-compiler view is the easiest way to check the values that may need updating.
Use existing port as a base for comparison
If camera has an EVF use G5X or M3 otherwise use G7X or G7X2
platform/CAMERA/makefile.inc
Add CAM_DRAW_RBGA = 1
platform/CAMERA/platform_camera.h
Delete CAM_SUPPORT_BITMAP_RES_CHANGE if present
Add CAM_HAS_DISPLAY_REFRESH_FLAG
Update CAM_BITMAP_WIDTH, CAM_BITMAP_HEIGHT, CAM_SCREEN_WIDTH and CAM_SCREEN_HEIGHT
platform/CAMERA/sub/FIRMWARE/stubs_entry2.S
Copy the definitions for debug_logging_ptr, debug_logging_flag and mzrm_sendmsg_ret_adr from the comparison port
Use the instructions in the comments to find the values for these
platform/CAMERA/lib.c
Copy the Ximr code from the comparison port - should be everything from the Ximr layer typedef to the end of the file
May also need to copy the definitions for displaytype, hdmi_out and evf_out (if camera has an EVF)
Check and update the value for FW_YUV_LAYER_BUF using the instructions in the comments
Delete the update_screen_dimensions function if present. Check if other functions are dependant on this code (e.g. viewport size functions using values set in this function). If so copy relevant logic to update_ui.
Check the implementation of vid_bitmap_refresh. Will probably need to refresh both buffers by calling transfer_src_overlay twice. If you see old CHDK frames randomly flashing on screen, such as CHDK menu after leaving ALT mode then try the double call to transfer_src_overlay.
platform/CAMERA/sub/FIRMWARE/boot.c
Copy the block of code containing debug_logging_my and patch_mzrm_sendmsg from the comparison port
Add the call to patch_mzrm_sendmsg to the boot function
Make sure the call is after any RAM initialisation otherwise the patch may get overwritten
Check the firmware disassembly and update the following in debug_logging_my
Source for the mzrm_sendmsg ‘msg’ parameter. Most ports store this in R11; but it may also be on the stack (e.g. G7X2)
Message types to detect calls to XimrExe and XimrExeGain
Edit: added note about vid_bitmap_refresh implementation in lib.c
Edit2: removed things that are now found by finish_thumb2
-
@philmoz
Phil, can you educate me on how your developments get incorporated into the trunks.
The reason I asking is, I'm reluctant to say too much about my G7X & G5X script updates on my blog, as they rely on your 'bespoke' builds.
So I guess I'm asking when, if at all, will we see your Ximr based solution in the trunks, albeit only enabled on selective cameras.
Cheers
Garry
-
So I guess I'm asking when, if at all, will we see your Ximr based solution in the trunks, albeit only enabled on selective cameras.
@pigeonhill
The changes are complex and could affect a lot of areas in CHDK.
They could also have a big impact on the the display system for Digic 6 & 7 cameras.
This means a lot of testing across all parts of CHDK.
I've tested quite a bit and your testing has also helped a lot - thanks.
It also means it's not just my call when and if this makes it into the trunk.
Everyone involved needs to agree that this is a worthwhile change and is happy to move it into the SVN trunk.
-
@philmoz
Fully understand what you have said.
I wonder, therefore, if there is any merit and appetite, on your part, to create a repository of Ximr dependent builds, that people like me can download and use.
This will allow you to continue to tweak/develop and push out experimental builds, a little like a Ximr trunk, albeit with limited cameras.
Just a thought.
Cheers
Garry
-
Below is a summary of the changes needed in case anyone wants to try the Ximr layer drawing on another camera/firmware version.
Thanks for posting this. I'll try to dig into this and port my other cameras soon, have been distracted with other stuff.
-
Sometimes I´ve "looked" in this ximr area:
https://app.assembla.com/spaces/chdk/subversion/commits/5881
...
https://app.assembla.com/spaces/chdk/subversion/commits/5902
Your summary seems to be the headline... :-[
-
One detail I'm not happy with is the vid_bitmap_refresh() implementation. This function is now called at least 10 times a second and it writes 2 entries in camera log. This is normally not a problem, except when it takes away space from useful log content. My attempts to find a suitable replacement failed so far.
And to answer this old one
XimrExeGain is used when the Canon overlay is faded in/out.
Out of curiosity, it is used for some kind of animation? I see it uses the same structure, but takes 2 more params?
So far, I've only seen XimrExeGain calls on m10 when
- exiting the "Q" menu and the normal shooting mode OSD fades in
- exiting the fullscreen mode selection menu
One of the added params is a percentage, probably visibility.
-
One detail I'm not happy with is the vid_bitmap_refresh() implementation. This function is now called at least 10 times a second and it writes 2 entries in camera log. This is normally not a problem, except when it takes away space from useful log content. My attempts to find a suitable replacement failed so far.
vid_bitmap_refresh should only get called if CHDK has changed something on its draw layer.
If you are frequently drawing something on the screen then it will trigger vid_bitmap_refresh calls.
One problem area I know of at the moment is the CHDK icons for battery, file space and USB.
The icon commands overdraw the same pixels with different colours which triggers an update even though the end result is the same as the previous frame.
I'm looking at adding an intermediate buffer to render the icons before drawing them on the screen which should reduce this overhead.
-
One detail I'm not happy with is the vid_bitmap_refresh() implementation. This function is now called at least 10 times a second and it writes 2 entries in camera log.
Probably this is because of _VTMLock/_VTMUnlock calls. What is the reason for these calls?
-
I'm looking at adding an intermediate buffer to render the icons before drawing them on the screen which should reduce this overhead.
In this way, you will soon get to use the zico core for icons' rendering... :)
-
@pigeonhill
I have uploaded builds of all cameras with ximr support to https://drive.google.com/drive/folders/1drk1xi6kMMIeF5xSqXgnpjGCffF8CVkd?usp=sharing (https://drive.google.com/drive/folders/1drk1xi6kMMIeF5xSqXgnpjGCffF8CVkd?usp=sharing)
I have changed the vid_bitmap_refresh logic to remove calls to VTMLock and VTMUnlock.
Can you please test the G7X and M3 versions from the above link to make sure the CHDK OSD, menus, etc work correctly.
-
@philmoz
Have just tried relevant builds for my M3 and G7X.
OSD display, menus and my camera specific bracketing scripts all appear normal and working as expected.
I will obviously flag up any anomalies if they appear.
BTW, will that google drive link remain for the foreseeable future? That is, so I can reference your (repository) link. Plus will you push new builds into the existing links, so they remain good for the foreseeable future?
Cheers
Garry
-
(M3 121a) :)
If the AF-frame is stable then the OSDs and menues are stable too ...
else eg the seconds are nervous in the clock (not during script runs).
-- No option to FW-update, (Usual build works with PS.FI2 I got from Ant) ...
-
the seconds are nervous in the clock (not during script runs).
This is because of this line (https://app.assembla.com/spaces/chdk/subversion/source/HEAD/branches/ximr_draw_rgba/platform/m3/lib.c#ln37) in lib.c
There need to update both bitmap buffers:
_transfer_src_overlay(0);
_transfer_src_overlay(1);
-
-- No option to FW-update, (Usual build works with PS.FI2 I got from Ant) ...
Firmware update booting for M3 is disabled in the makefile - comment states there are hardware initialisation issues.
-
BTW, will that google drive link remain for the foreseeable future? That is, so I can reference your (repository) link. Plus will you push new builds into the existing links, so they remain good for the foreseeable future?
Yes I can keep the link active and updated for the time being.
-
Yes I can keep the link active and updated for the time being.
Many thanks.
-
@philmoz
Just noticed a 'strangeness' that occurs on the G5X.
If you toggle to the blank Canon display (no Canon overlays), ie using the INFO button, then go into CHDK mode the ALT 'bar' at the bottom disappears/returns as the scene changes.
The disappearing only occurs with no Canon overlay.
On the G7X you always see some Canon overlay.
-
If you toggle to the blank Canon display (no Canon overlays), ie using the INFO button, then go into CHDK mode the ALT 'bar' at the bottom disappears/returns as the scene changes.
@pigeonhill
Can you try the latest version from the Google Drive link please.
-
Can you try the latest version from the Google Drive link please.
Yes: that fixed it :)
Looks like you are still tweaking/refining the C code?
-
Hi,
I had been pointed to this thread due to the boring flickering of CHDK OSD and menues on DIGIC-6 cams. As far as I understood the discussion there are builds under development for M3 and G7X that try to avoid this and probably some other flaws.
I can offer to test those stuff on my SX700HS (that has DIGIC-6 proc too) if someone can provide an appropriate build.
Regards
-
One detail I'm not happy with is the vid_bitmap_refresh() implementation. This function is now called at least 10 times a second and it writes 2 entries in camera log.
As it turned out, the variant with two transfer_src_overlay calls doesn't write unnecessary camera log entries. The firmware, however, does lots of VTMLock/Unlock when using a mode with frequent display updates (face tracking, "scene intelligent auto"). I made the mistake of dumping camera log while in such mode.
I noticed that the "fallback" HDMI mode (probably 480p) is not handled correctly on my camera with the current code (I still need to dump the ximr struct to see what's going on). This results in completely garbage display. I'm able to force the camera into this mode with some of my HDMI devices, but I'm not sure if others can do that. Connecting the camera to a digital monitor/TV with less than full HD native resolution should in theory help.
-
I noticed that the "fallback" HDMI mode (probably 480p) is not handled correctly on my camera with the current code (I still need to dump the ximr struct to see what's going on). This results in completely garbage display. I'm able to force the camera into this mode with some of my HDMI devices, but I'm not sure if others can do that. Connecting the camera to a digital monitor/TV with less than full HD native resolution should in theory help.
@srsa_4c
Is it just the CHDK display that is garbled or does it affect the Canon OSD as well?
-
Is it just the CHDK display that is garbled or does it affect the Canon OSD as well?
Both are affected. The buffer dimensions and aspect ratios are different, so it's not too surprising. It remains to be seen whether the firmware's implementation (of that display mode) on different models is similar or different.
-
I had been pointed to this thread due to the boring flickering of CHDK OSD and menues on DIGIC-6 cams. As far as I understood the discussion there are builds under development for M3 and G7X that try to avoid this and probably some other flaws.
I can offer to test those stuff on my SX700HS (that has DIGIC-6 proc too) if someone can provide an appropriate build.
@CanonUser9000
SX700 test versions uploaded to the link below.
Note the SX700 appears to have a different screen size to the other cameras already implemented so I've had to make some guesses here.
https://drive.google.com/drive/folders/1drk1xi6kMMIeF5xSqXgnpjGCffF8CVkd?usp=sharing (https://drive.google.com/drive/folders/1drk1xi6kMMIeF5xSqXgnpjGCffF8CVkd?usp=sharing)
-
@philmoz:
Thanks a lot.
I've tested the bulid for FW version 100e: not flickering any more and all the menues can be accessed.
Note the SX700 appears to have a different screen size to the other cameras already implemented
To help alignment of the OSD and CHDK menues I've atteched some screen shoots in comparison with build 1.6.0-5727 (DE).
-
To help alignment of the OSD and CHDK menues I've atteched some screen shoots in comparison with build 1.6.0-5727 (DE).
@CanonUser9000
I've uploaded a new version (file name is the same in Google Drive).
Can you see if this fixes the cropping on the right side.
-
@philmoz:
I've tested sx700hs-100e-1.6.0-5929-full.zip-20210601T083032Z-001:
OSD now perfectly aligned, no cropping any more, no flickering
Thank's a lot ::)
-
OSD now perfectly aligned, no cropping any more, no flickering
@CanonUser9000
Thanks for the update.
When you have time can you please test zebra and edge overlay.
-
I finally got around to trying the xmir build on g7x (thanks again philmoz for doing that :)) and noticed CHDK histogram was wildly different from the trunk, which probably explains at least some of what pigeonhill saw in https://chdk.setepontos.com/index.php?topic=14342.msg146058#msg146058
Turns out it was showing only the lower half, due to a THUMB_FW / LARGE_HISTO mixup. Update in r5938 should fix this (but not other various histogram bugs)
Note ifdefs depending on CAM_DRAW_RGBA in module / platform independent code breaks our portability rules and will need to be resolved before this gets merged into the trunk. Should be fine for development though if non-CAM_DRAW_RGBA aren't being built without a clean in between. (edit: oops :-[)
Other observations:
The UI is so stable and smooooooooth, even with Canon histogram or electronic level active. Huge improvement.
Zebra doesn't seem to draw at all on my g7x. Edge overlay works.
-
Turns out it was showing only the lower half, due to a THUMB_FW / LARGE_HISTO mixup. Update in r5938 should fix this (but not other various histogram bugs)
Thanks for that.
Note ifdefs depending on CAM_DRAW_RGBA in module / platform independent code breaks our portability rules and will need to be resolved before this gets merged into the trunk. Should be fine for development though if non-CAM_DRAW_RGBA aren't being built without a clean in between.
I thought this was covered by having CAM_DRAW_RGBA build into the .o4 and .o5 directories (makefile_base.inc).
Did I miss something?
-
I thought this was covered by having CAM_DRAW_RGBA build into the .o4 and .o5 directories (makefile_base.inc).
Did I miss something?
Nope, I totally missed that you'd already made them use separate object directories :-[
That said, in the long term, I'd definitely argue for converting all the d6 cams and eliminating the old style. It's already hard enough to maintain.
-
When you have time can you please test zebra and edge overlay.
on SX700:
edge overlay: works as expected, varios settings tested :D
zebara: no display of anything, regardless of settings used :(
-
zebara: no display of anything, regardless of settings used :(
Thanks for testing. I've uploaded a new build to Google Drive which should fix this (fingers crossed).
-
Zebra doesn't seem to draw at all on my g7x. Edge overlay works.
Should be fixed in revision 5940.
-
Should be fixed in revision 5940
regarding zebra: no zebra display with rev 5940 :(
One finding more: during video recording OSD and grid are still missaligned in x-direction and somewhat croped (see att.)
-
regarding zebra: no zebra display with rev 5940 :(
Hmm, not sure about this - will need to think about it.
One finding more: during video recording OSD and grid are still missaligned in x-direction and somewhat croped (see att.)
Seeing the same on the G7X2 and G5X - not sure what is going on here.
The rightmost 3rd of the CHDK bitmap image seems to get shifted left to the centre.
@srsa_4c - any thoughts?
Edit: If I allocate a full size RGBA buffer and remove the x2 scaling for the CHDK layer the weirdness when recording movies does not happen.
-
Should be fixed in revision 5940.
Does appear to be fixed on G7X.
One thing I noticed is OSD settings don't get reset switching between xmir and old style, so stuff that was positioned at the edges is no longer visible. Just something to be aware of for now, but if/when we move it into the trunk, we might want to reset OSD positions or something. Or at least note it.
Another oddity:
If zebra is enabled, the histogram is drawn, but in half press it doesn't actually update. This appears to be the case regardless of the zebra "restore" settings.
The old style tends to blow the histogram away complete if zebra is actually drawing anything, but with "restore OSD" enabled, it does update in half press.
Earlier cameras have the "Draw over zebra" option, which could perhaps be re-enabled for xmir.
This is all minor, I'm just noting it because I ran into while trying to understand other histogram bugs.
-
regarding zebra: no zebra display with rev 5940 :(
update: zebra on SX700
Only if the option "RGB-Zebra (overexp. only)" is aktivated overexposed area are marked correctly on the display. No zebra without this option. :-X
-
Only if the option "RGB-Zebra (overexp. only)" is aktivated overexposed area are marked correctly on the display. No zebra without this option. :-X
Can you check the zebra color settings for over and under exposure (CHDK Settings -> Color Settings).
Make sure they are valid colours and not transparent.
-
Can you check the zebra color settings for over and under exposure (CHDK Settings -> Color Settings).
Make sure they are valid colours and not transparent.
Also, the thresholds may need to be adjusted. Some (mostly earlier digic 6) cams use values in the 16-235 ish rather than 0-255, so to see anything in zebra the thresholds need to be large.
-
Seeing the same on the G7X2 and G5X - not sure what is going on here.
The rightmost 3rd of the CHDK bitmap image seems to get shifted left to the centre.
@srsa_4c - any thoughts?
I'm still saying that the "scaling bits" we're using are actually something else.
I dumped the ximr struct while recording and found it to be different from idle mode by a bit (literally). The 4th halfword in ximr_context (unk2[0] in case of g5x) is normally 0x500 but becomes 0x100 during recording. I tried modifying it to be always 0x500 and that seemingly worked (I see nothing wrong, but who knows).
-
I dumped the ximr struct while recording and found it to be different from idle mode by a bit (literally). The 4th halfword in ximr_context (unk2[0] in case of g5x) is normally 0x500 but becomes 0x100 during recording. I tried modifying it to be always 0x500 and that seemingly worked (I see nothing wrong, but who knows).
Thanks - that works for the G5X and G7X2; but it makes me a little uneasy.
If we had 2MB of free memory for all cameras we could use a full res buffer (960x540x4).
This will also slow down drawing and erasing though.
-
FWIW, I noticed on g7x that using analog video out (or force_analog_av) completely breaks both the Canon and CHDK UI. Example screenshot from video capture, with CHDK menu open. I haven't looked further and don't think this is an urgent issue, just noting it as a data point.
In normal video out, the Canon UI dimensions change compared to the LCD, to move the UI elements away from the edges of the screen. The overall viewport buffer dimensions are unchanged, at 720x480
-
FWIW, I noticed on g7x that using analog video out (or force_analog_av) completely breaks both the Canon and CHDK UI. Example screenshot from video capture, with CHDK menu open.
srsa_4c noted that earlier with HDMI output at less than full HD res.
Unfortunately I don't have any way to replicate either case.
-
Can you check the zebra color settings for over and under exposure (CHDK Settings -> Color Settings).
Make sure they are valid colours and not transparent.
Tested several color combinations w/o any influence.
Also, the thresholds may need to be adjusted. Some (mostly earlier digic 6) cams use values in the 16-235 ish rather than 0-255, so to see anything in zebra the thresholds need to be large.
::) Thats it! Noticable zebra is displayed if thresholds for underexp>=19 and overexp>=21
-
I added debug_logging_ptr, debug_logging_flag and mzrm_sendmsg_ret_adr to finsig_thumb2. I intentionally did this in the trunk sig finder and merged the changes to the ximr tree. May regret this later, but I think if we keep the actual stubs updates in a separate commit, it should work out ok.
edit:
and FW_YUV_LAYER_BUF as a DEF_CONST
::) Thats it! Noticable zebra is displayed if thresholds for underexp>=19 and overexp>=21
It seems like we will probably want a camera.h define / camera_info field to define which variant is used (if it's truly camera specific rather than settings or output device, as it seems to be so far). That would at least allow reasonable defaults for the zebra and histogram limits.
-
I added support for sx710hs and sx730hs.
With the sig finder additions, the main things that need to be manually verified are the register and message IDs in debug_logging_my, and any viewport dimension logic in update_ui
-
I added support for sx710hs and sx730hs.
With the sig finder additions, the main things that need to be manually verified are the register and message IDs in debug_logging_my, and any viewport dimension logic in update_ui
Thanks for that. Nice work on the sigfinder additions :)
I've added these to the Google Drive link if anyone wants to test them.
-
@philmoz
Just spotted and confirmed a strangeness with the G5X EVF.
As I only use M mode I had not spotted it before, plus this is the only non-M3 camera I have with a built in EVF.
In all modes, other than C, the EVF looks fine.
If CHDK is not on the card, or no card in the Cam, C mode is OK in the EVF.
With CHDK on the card, and enabled, ie locked, and in C mode, the LCD is OK, but the EVF is completely corrupted, ie 100% full of rubbish pink green dots in three horizontal bands.
BTW I'm using the latest build from your repository and the corruption was there before, ie I tested a previous build. Thus likely there all the time, but not spotted as I don't use C mode.
Cheers
Garry
-
Which Mode (AV, P, M...) is saved on C?
-
M
Update
Just tried resetting several times and problem has gone away. :)
-
With CHDK on the card, and enabled, ie locked, and in C mode, the LCD is OK, but the EVF is completely corrupted, ie 100% full of rubbish pink green dots in three horizontal bands.
Since this new drawing method isn't finalized yet, we'd really like to know more about these cases where it fails.
Just tried resetting several times and problem has gone away.
A missed opportunity, sadly.
What I'm thinking is: we could make copies of the ximr struct (one for normal, one for the yuv case), and write them to card when the debug shortcut is pressed. We could use the memory dumper mode (DmpRAM), but write our debug buffer instead.
-
@srsa_4c
A missed opportunity, sadly.
The problem was definitely there, ie only when CHDK was enabled on the card and I was in Manual C mode.
I then reset C mode to Av and then back to M mode and the problem disappeared.
I’ll keep looking out for ‘anomalies’ and report.
Cheers
Garry
-
With CHDK on the card, and enabled, ie locked, and in C mode, the LCD is OK, but the EVF is completely corrupted, ie 100% full of rubbish pink green dots in three horizontal bands.
@pigeonhill
I don't see any issues with the EVF on my G5X even in C mode - so there may be some Canon setting that is affecting the EVF that I am not using.
Can you list what settings you have saved to your C mode.
Also what firmware version is your camera.
-
Just tried resetting several times and problem has gone away. :)
@pigeonhill
Did you reset the Canon settings or the CHDK settings?
-
Did you reset the Canon settings or the CHDK settings?
I just changed the Canon custom setting, ie from M to Av and then back to M.
-
I've been doing some research on the Zico side, some of this may help clear up a few of the unknowns. I did not try any of the following on camera.
- There is an optional (output?) MARV struct, starting at byte offset 12 of ximr_context. At least two fields in the struct need to be nonzero for it to be recognized. I don't go in details as I doubt this is of any use.
- The halfword at byte offset 6 of ximr_context seems to be referred to as "DivSize". It gets compared with width1 (at byte offset 2). width1 and height1 seem to be the maximum width and height used in layers. When width1 is set to 0xffff, the layers are searched for the largest width.
- There is a color type 3 (probably not used) which needs some additional bytes of ximr_context filled (so it would be quite difficult for us to try).
- The first 18 bytes of ximr_layer are written to MMIO like this (I did this by hand, mistakes are possible):
*(uint32_t*)0xc80b0040=u8_14 | (u8_13<<2) | (u8_12<<6) | (u8_11<<8) | (u8_10<<10) | (u8_9<<12) | (u8_8<<14) | (u8_7<<16) | (u8_6<<18) | (u8_5<<20) | (u8_4<<22) | (u8_3<<24) | (u8_2<<26) | (u8_1<<28) | (u8_0<<30)
*(uint32_t*)0xc80b0044=u8_17 | (u8_16<<8) | (u8_15<<16)The bits are not masked before the OR operations, which explains why I found scale bits somewhere else. The 18 bytes are followed by 6 halfwords (which don't overlap like the first bytes can).
One more finding: there is an additional memory range that the Zico core sees: 0xBFF1xxxx. It contains a few kB of interface functions that write to MMIO. I had to memcpy it out using Zico side code as that range is inaccessible from ARM. Strangely, I can't find that code in the ROM dump(s) and I also couldn't find a piece of code that would fill it. So, it's either stored compressed/scrambled, or it's on-chip ROM.
-
@srsa_4c
Have you managed to activate zico's debug logging functions?
For example there is a function that parses jedidraw context(0x80af2d24 for EOS M3 101a). But I assume that it uses UART for output. Maby there is a way to redirect it's output to zico log in RAM?
-
For example there is a function that parses jedidraw context(0x80af2d24 for EOS M3 101a). But I assume that it uses UART for output. Maby there is a way to redirect it's output to zico log in RAM?
The optional debug info is always printed through function pointers. You'd need to set the pointer to an appropriate function. For that you'd need to make a wrapper to a known printf-like function (so that the source arguments are processed correctly).
The problem is, I don't see how to access arguments passed on stack. I would expect that the function would get them starting at the offset specified in the entry instruction (so, in case of entry a1, 32 the first stack param would be at a1 + 32). *But that does not seem to be the case. Do you happen to know an easy-to-understand tutorial that explains this?
edit:
*I found a function that does that, will try to make a wrapper to see if it works.
-
will try to make a wrapper to see if it works.
First try, it does not crash, but I can't see if it works. Handles up to 10 arguments, in theory.
# xtensa-elf-as try1.s -o try1.o
# xtensa-elf-objcopy -O binary try1.o try1.bin
# to check generated code: xtensa-elf-objdump -d try1.o
.text
.begin
.align 4
j myhack
.align 4
.literal_position
_logprintf:
.word 0xBFF23434
lpf_arg1:
.word 0xBFF04358
lpf_arg0:
.word 9
myhack:
entry a1, 64
l32r a8, _logprintf
l32r a10, lpf_arg0
l32r a11, lpf_arg1
mov a12, a2
mov a13, a3
mov a14, a4
mov a15, a5
s32i a6, a1, 0
s32i a7, a1, 4
l32i a2, a1, 64
s32i a2, a1, 8
l32i a2, a1, 68
s32i a2, a1, 12
l32i a2, a1, 72
s32i a2, a1, 16
l32i a2, a1, 76
s32i a2, a1, 20
callx8 a8
mov a2, a10
retw
.end
Binary:
unsigned char rawData[68] = {
0x06, 0x03, 0x00, 0x00, 0x34, 0x34, 0xF2, 0xBF, 0x58, 0x43, 0xF0, 0xBF,
0x09, 0x00, 0x00, 0x00, 0x36, 0x81, 0x00, 0x81, 0xFC, 0xFF, 0xA1, 0xFD,
0xFF, 0xB1, 0xFB, 0xFF, 0xCD, 0x02, 0xDD, 0x03, 0xED, 0x04, 0xFD, 0x05,
0x69, 0x01, 0x79, 0x11, 0x22, 0x21, 0x10, 0x29, 0x21, 0x22, 0x21, 0x11,
0x29, 0x31, 0x22, 0x21, 0x12, 0x29, 0x41, 0x22, 0x21, 0x13, 0x22, 0x61,
0x05, 0xE0, 0x08, 0x00, 0x2D, 0x0A, 0x1D, 0xF0
};It's portable, 3 words from offset 4 need to be adjusted as they are model/fw specific.
Loader:
zico_mem=0xbff27940 -- free space in zico code memory
zico_dbg_ptr=0x40c13540 -- 0xc13540 in xtensa
call_event_proc("System.Create")
buf=call_event_proc("AllocateMemory",1024)
imgfile=call_event_proc("Fopen_Fut","A/demo.bin","rb")
call_event_proc("Fread_Fut",buf,128,1,imgfile)
call_event_proc("Fclose_Fut",imgfile)
call_event_proc("memcpy",zico_mem,buf,128)
call_event_proc("FreeMemory",buf)
poke(zico_dbg_ptr,zico_mem) -- this might crash zico in case of caching issues
Addresses are for m10 101d, so need to be adjusted.
-
First try, it does not crash, but I can't see if it works.
On M3 I also don't see this...
I placed your function at 0xbff00100 because memory modification after zico_0 blob(0xbff277b8+) causes crash.
Probably this function was not called. Even with debug flag at 0x40c13414.
-
Another Zico logging variant, using sprintf. The following code does not add timestamps.
sprintf can be found by looking up the reference to this string:
LOG(%5d):%5u.%02usec(0x%04x)# xtensa-elf-as try1.s -o try1.o
# xtensa-elf-objcopy -O binary try1.o try1.bin
# to check generated code: xtensa-elf-objdump -d try1.o
.text
.begin
.align 4
j myhack
.align 4
.literal_position
_sprintf: # stub address
.word 0x80A28918
mybuf: # buffer somewhere in memory - there will be issues with xtensa side caches though
.word 0x1feb2400
bufsize: # size of buffer (0x200 is the safety margin)
.word 0x5ff02600 - 0x5feb2400 - 0x200
ptr: # buffer pointer is kept at this address, Xtensa data memory
.word 0xbff07ffc
myhack:
entry a1, 64 # note: usable area seems 32 bytes less than this due to space reserved for saved registers, when using call8 (caller or callee?)
# call12 (caller or callee?) further reduces the usable amount (-16 bytes)
l32r a8, ptr
l32i a15, a8, 0
l32r a9, bufsize
sub a9, a9, a15
bgez a9, lab1
movi a15, 0
lab1:
l32r a10, mybuf
add a10, a10, a15
l32r a8, _sprintf
mov a11, a2
mov a12, a3
mov a3, a15 # backup pointer val
mov a13, a4
mov a14, a5
mov a15, a6
s32i a7, a1, 0
l32i a2, a1, 64
s32i a2, a1, 4
l32i a2, a1, 68
s32i a2, a1, 8
l32i a2, a1, 72
s32i a2, a1, 12
l32i a2, a1, 76
s32i a2, a1, 16
callx8 a8
mov a11, a3 # restore pointer
add a11, a11, a10
l32r a12, ptr
s32i a11, a12, 0
mov a2, a10
retw
.end
unsigned char rawData[98] = {
0x06, 0x04, 0x00, 0x00, 0x18, 0x89, 0xA2, 0x80, 0x00, 0x24, 0xEB, 0x1F,
0x00, 0x00, 0x05, 0x00, 0xFC, 0x7F, 0xF0, 0xBF, 0x36, 0x81, 0x00, 0x81,
0xFE, 0xFF, 0xF8, 0x08, 0x91, 0xFC, 0xFF, 0xF0, 0x99, 0xC0, 0xD6, 0x29,
0x00, 0xF2, 0xA0, 0x00, 0xA1, 0xF8, 0xFF, 0xFA, 0xAA, 0x81, 0xF5, 0xFF,
0xBD, 0x02, 0xCD, 0x03, 0x3D, 0x0F, 0xDD, 0x04, 0xED, 0x05, 0xFD, 0x06,
0x79, 0x01, 0x22, 0x21, 0x10, 0x29, 0x11, 0x22, 0x21, 0x11, 0x29, 0x21,
0x22, 0x21, 0x12, 0x29, 0x31, 0x22, 0x21, 0x13, 0x29, 0x41, 0xE0, 0x08,
0x00, 0xBD, 0x03, 0xAA, 0xBB, 0xC1, 0xED, 0xFF, 0xB9, 0x0C, 0x2D, 0x0A,
0x1D, 0xF0
};zico_mem=0xbff27940 -- free space in zico code memory
zico_dbg_ptr=0x40c13538 -- 0xc13538 in xtensa
call_event_proc("System.Create")
buf=call_event_proc("AllocateMemory",1024)
imgfile=call_event_proc("Fopen_Fut","A/demo.bin","rb")
call_event_proc("Fread_Fut",buf,1024,1,imgfile)
call_event_proc("Fclose_Fut",imgfile)
call_event_proc("memcpy",zico_mem,buf,1024)
call_event_proc("FreeMemory",buf)
poke(0xbff07ffc,0) -- clear our debug counter (used by our xtensa binary)
poke(zico_dbg_ptr,zico_mem) -- this might crash zico in case of caching issues
edit:
Binary fixed to correspond to source. The 4 constants of code (which are model specific) can be found in binary at offset 4.
edit2:
fix the entry instruction (80 -> 64, stack arguments were not picked up correctly due to that)
-
First try, it does not crash, but I can't see if it works.
On M3 I also don't see this...
I placed your function at 0xbff00100 because memory modification after zico_0 blob(0xbff277b8+) causes crash.
Probably this function was not called. Even with debug flag at 0x40c13414.
I'm not sure if 0xbff0xxxx is suitable for code. A mistake in the constants can also result in a crash. In theory, the 0xbffxxxxx ranges don't use the Xtensa cache (but I can be wrong), but regular memory is cached.
Try the sprintf-based version, less chance for mistakes.
-
For example there is a function that parses jedidraw context(0x80af2d24 for EOS M3 101a).
I tried doing the same on m10. The function you mention is only called from a single function (a string "Management information" is referenced near its start). That parent function seems unreferenced, but it has no arguments. It can be called (in theory) if you write its address to an unused mzrm handler pointer (such as TerminateXimr @ 0x80A008B8 (m3 address)) and you call the ARM side function. If you see crashes after poking, you can try things like playback->rec->playback to beat most things out of Xtensa cache.
So, I planted the sprintf-based wrapper to the right function pointer, called the function and ... got nothing. The debug prints seem to be a bit more conditional.
The wrapped sprintf does work if I use it in other function pointers, such as the one that prints the mzrm handlers's names.
-
Another Zico logging variant, using sprintf. The following code does not add timestamps.
sprintf can be found by looking up the reference to this string:
Are you sure this function is really sprintf ?
I was trying to use this function with my arguments placed in a10 and a11 but didn't get any results.
I'm usung xtensa-esp32-elf-gcc8_2_0-esp32-2019r1-win32 toolchain. Hope it's compatible with zico.
Finally I managed to get some information about zico's DryOS:
System Memory Information
Start Address = 0x00c04008
End Address = 0x00c10000
Total Size = 0x0000bff8 ( 49144)
Allocated Size = 0x00003728 ( 14120)
Allocated Peak = 0x00003728 ( 14120)
Allocated Count = 0x00000005 ( 5)
Free Size = 0x000088d0 ( 35024)
Free Block Max Size = 0x000088d0 ( 35024)
Free Block Count = 0x00000001 ( 1)
Name ID State Pri Wait(ID) Stack StackTop StackEnd SP
GrphErrTas 00000004 WAIT 2 EVENT(00000002) 0168/0400 08 00c07228 00c07628 00c07530
MzrmRcvTas 00000003 RUNNING 3 ------- 0510/2000 08 00c05220 00c07220 --------
init 00000002 WAIT 16 SLEEP(00000002) 0288/1000 08 00c04218 00c05218 00c05000
ClkGearAut 00000005 READY 32 ------- 00e0/0100 08 00c07630 00c07730 00c076e0
idle 00000001 READY 33 ------- 0110/0200 08 00c04010 00c04210 00c04170
[Driver Entry]
total : 5 (DRV_ENTRY_MAX)
used : 2
[Created Devices]
drvNo name
0 /term
[Default Device]
device name :
[File Descriptor]
total : 11 (DM_FILE_MAX)
used : 3
open : 3
vers_dry DRYOS version 2.3, release #0055+p6
vers_mk 2.63
use_smp 0
act_spi_sem 1
act_spi_event 1
act_spi_mq 1
act_spi_mutex 1
act_spi_cond 0
act_spi_timer 1
act_spi_clock 1
act_spi_isr 0
act_spi_objlist 1
act_spi_objinfo 1
act_spi_objsetname 1
act_timeout 1
act_objname 1
dbg_stack_check 1
dbg_error_check 1
dbg_logging 0
pu_max 1
sys_mem_start 0x00c04000
sys_mem_max 49152
user_mem_start 0x00c00000
user_mem_max 12940
sys_objs_start 0x00c0328c
sys_objs_end 0x00c04000
priority_max 34
task_max 12
semaphore_max 32
event_max 13
message_q_max 4
mutex_max 0
condition_max 0
timer_max 4
vector_max 0
it4_mbx_max 0
it4_mpf_max 0
it4_mpl_max 0
level_low 0
level_timer 1
level_kern 1
prio_default 16
stack_default 4096
stack_idle 512
stack_init 4096
stack_addr_idle 0x00000000
stack_addr_init 0x00000000
use_barrier 0
barrier_max 0
-
Finally, I got "Management information" by patching 0x80ab96a8 address which points to 0x00c13420.
Something clears the pointer to my function at 0x00C13420. I did not find how.
-
Finally, I got "Management information" by patching 0x80ab96a8 address which points to 0x00c13420.
Something clears the pointer to my function at 0x00C13420. I did not find how.
Nice results. I also found that the pointer read back as zero despite the poke in script. Another poke through chdkptp seemed to survive for longer. My above sprintf wrapper was buggy due to me changing the entry amount without changing the access distance of stack arguments.
-
Another poke through chdkptp seemed to survive for longer.
It clears when I send mzrm message to execute handler's code on Zico.
My above sprintf wrapper was buggy due to me changing the entry amount without changing the access distance of stack arguments.
I used simple version without stack arguments:
.text
.begin
.align 4
j myhack
.align 4
.literal_position
_sprintf: # stub address
.word 0x80a27088
ptr: # buffer pointer is kept at this address
.word 0x803A0010
.align 4
myhack:
entry a1, 0x50
l32r a8, ptr
l32i a9, a8, 0
l32r a8, _sprintf
mov a15, a6
mov a14, a5
mov a13, a4
mov a12, a3
mov a11, a2
mov a10, a9
callx8 a8
l32r a8, ptr
l32i a9, a8, 0
add a9, a9, a10
s32i a9, a8, 0
movi a2,0x0
retw
.end
I have not seen more than three arguments yet...
-
FWIW, I noticed on g7x that using analog video out (or force_analog_av) completely breaks both the Canon and CHDK UI. Example screenshot from video capture, with CHDK menu open.
srsa_4c noted that earlier with HDMI output at less than full HD res.
Unfortunately I don't have any way to replicate either case.
Worked on this, and resolved for sx710 in r5968. g7x appears very similar (with slight variation because native LCD aspect is 3:2), but I haven't gone through all the permutations yet.
Some observations:
When sx710 or g7x is rendering to from YUV buffer (layer bitmap == fw_yuv_layer_buf), the layer always appears to be layer 1, not layer 0. Layer 0 is an RGB buffer (presumably, stuff like grid lines that doesn't get the extra scaling). This means that CHDK needs to copy layer 0 to get appropriate RGB defaults.
The names of numer* and denom* seem to be backwards. When drawing to the YUV buffer (output_buffer == fw_yuv_layer_buf), numerx and numery are 67, denomx and denomy are 60.
This scales down the original UI from the RGB buffer to accommodate the margins specified by dst_x, dst_y ( 42, 28 in SDl 56, 28 in HDMI). E.g. for height (28*2 + 480) * 60 / 67 = 480.
When drawing to the YUV buffer (output_buffer == fw_yuv_layer_buf), the RGB input layer is layer 1, and layer 0 is not enabled.
Changing layer.height does not appear to be required or effective.
ximr->layers[1].height = 240; on the YUV layer had no visible impact on the output.
I noticed the values at offsets 0x248 and 0x24a seem to be a height and width of some sort. When the rendering to from YUV buffer (layer bitmap == fw_yuv_layer_buf), they have values like 960x480 or 720x480 on sx710. In other cases they are 0. I haven't tried changing them.
On sx710, low res HDMI out appears to be identical to analog out as far as the ximr structure is concerned. Both of these use 720x480 (on a 736 buffer) for live view and the final bitmap, rather than 640x480 like the normal live view. The final output is presumably still intended to be 4:3.
For FHD HDMI, the final output is 960x540, but y is scaled by 54/48, so the CHDK input layer needs to be 240 (upscaled by 2 in the layer.)
Tools:
I used the attached patch for debugging. This is intended for the non-ximr trunk, to examine how the default firmware behaves in various modes. It records a circular buffer with a header (call count, tick, display type, message number) and the ximr_context structure. I also used this to experiment with ximr_context values, poking them in a function called from do_ximr_debug to avoid additional confusion from the CHDK stuff.
I captured this using up the ximr_debug address and dumping it with rmem, like
rmem (ximr_debug address) 6272 -f=dump.bin
I also wrote some chdkptp code to extract the values as text for easy diffing:
!xd=require'extras/ximrdesc'
!xd.export('sx710-hdmisd1.bin')
Note this requires chdkptp from svn 1026 or later, and expects .bin file to have the header as described above (although adapting it to work on just a xmir_context would be simple).
Example dumps of going from LCD to TV out and LCD to HDMI are attached.
-
In ximr branch r5983, I adjusted the histogram erase logic to handle histogram modes that display more than one histogram.
-
In ximr branch r5983, I adjusted the histogram erase logic to handle histogram modes that display more than one histogram.
Thanks. Google drive builds updated.
-
@philmoz
Phil I just posted on my script developments and added a few screen grabs. https://photography.grayheron.net/2021/07/m3-bracketing-exposure-survey-mode.html (https://photography.grayheron.net/2021/07/m3-bracketing-exposure-survey-mode.html)
These are taken via an HDMI Hollyland Mars X wireless device.
As you can see, the CHDK stuff is offset to the left, other than the central EXIT text.
I wonder if this is fixable, or do I need to just live with it?
Cheers
Garry
-
As you can see, the CHDK stuff is offset to the left, other than the central EXIT text.
The HDMI bitmap we draw on is wider than the LCD bitmap (480 pixels vs 360 pixels).
Canon centres the live view to maintain the correct aspect ratio for the image. Canon adjusts it's UI element positions so they remain at the same place relative to the live view.
You could use the get_gui_screen_width value to check for the wider bitmap and offset the elements drawn by your script.
Most of the CHDK UI positions are fixed relative to the top left corner, so the histogram position for example will not change. The 'exit' text is always centred on the bitmap.
-
You could use the get_gui_screen_width value to check for the wider bitmap and offset the elements drawn by your script.
I can’t see this is a script fix, eg my script doesn’t write the text in the bottom left, ie the script’s name.
In the camera all is ok.
The shift is only apparent in the HDMI out.
I guess I’ll be living with the ‘feature’ :) ;)
-
@reyalp @philmoz
I wonder if you would consider the following idea?
As you know, when outputting through the HDMI on the M3 there is an offset created, relative to the LCD bitmap.
My thought is to create a new drawing function that globally adjust the x/y position of the stuff that is being drawn and would be called, say, before draw.overdraw() is called.
For EVF and LCD drawing x and y would be zero.
Just a thought.
Cheers
Garry
PS BTW I've added a 'HDMI hack' check in my script to recover the offset, for when I'm recording the HDMI out ;-)
You could use the get_gui_screen_width value to check for the wider bitmap and offset the elements drawn by your script.
Thanks @philmoz at least the stuff I draw is now auto centred in all three modes: LCD, EVF and HDMI. The only thing not addressed is the script title box, but I can live with that ;-)
-
(ximr) :) If the AF-frame is stable then the OSDs and menues are stable too ...
Now lib.c has ...void vid_bitmap_refresh() {
extern void _transfer_src_overlay(int);
int n = active_bitmap_buffer;
_transfer_src_overlay(n); // *
_transfer_src_overlay(n^1);
}Maybe it´s possible to update both buffers only if needed, save time for zebra ...? :-*
if (!MF && !script_running && power_on) _transfer_src_overlay(n); // *
-
@Ant asked
@reyalp
What is the reason not to merge philmoz's branch?
I have been thinking about it recently. IMO, it's a good improvement. I've been using it exclusively on my D6 cams, and I think most users would prefer it.
But some decisions need to be made. Do we make it the standard for all D6/D7 cams. Do we continue to support both drawing methods in the source? I would really prefer not to support both drawing methods, because it's already a big maintenance headache just with two, but the old digic 6 method is probably easier to debug with early in a port.
If we standardize on ximr, a few cameras are unconverted, at least M10, G16, SX60 and the SX280 family cams.
IIRC @srsa_4c also had some unresolved concerns, but I didn't immediately see them scrolling back in the thread.
-
If we standardize on ximr, a few cameras are unconverted, at least M10, G16, SX60 and the SX280 family cams.
This is the sticking point IMHO.
If we could find people to test them it would probably not be too hard to add the missing ones.
Otherwise I guess we have to live with three drawing systems.
Phil.
-
If we could find people to test them it would probably not be too hard to add the missing ones.
I still have a couple of working G16's. That's one down , three to go.
Sent from my Pixel 4a using Tapatalk
-
Happy to test sx60hs
-
@Ant asked
IIRC @srsa_4c also had some unresolved concerns, but I didn't immediately see them scrolling back in the thread.
A couple of those:
Possibly abusing something unknown (in addition to the layer scaling hack):
https://chdk.setepontos.com/index.php?topic=12788.msg146381#msg146381
Loss of complete overlay when an unsupported video output device is in use (lo-res HDMI, analog video, optional EVF):
https://chdk.setepontos.com/index.php?topic=12788.msg146383#msg146383
And surprise cases like this:
https://chdk.setepontos.com/index.php?topic=12788.msg146449#msg146449
I still have the sx280 and m10 and will try to continue where I left off.
-
I still have a couple of working G16's. That's one down , three to go.
@waterwingz - which firmware version(s) do you have?
-
Happy to test sx60hs
@62ndidiot - which firmware version(s) do you have?
-
@waterwingz - which firmware version(s) do you have?
Just 1.01C
Sent from my Pixel 4a using Tapatalk
-
I have sx60hs firmware 100f
-
@waterwingz & @62ndidiot
Test versions for G16 1.01c and SX60 1.00f
I have not looked at this for a while so I may have missed something.
-
I tested sx60hs-100f-1.6.0-6027-full.zip . It seems to work very nicely. No more blinking when in shoot (Alt) mode. The menu is steady even with the electronic level displayed. :D Zebra, histogram, motion detect work. I was able to crash the camera in CHDK settings: Grid : a few messages flashed and then it shutdown, the SD card needed a file scan/repair after that. However, when I restored to version 1.5.1 choosing the GRID option also does not work, but it doesn't crash the camera. I suspect it is just something that was never right for this camera, as anything with grids is sensitive to the LCD resolution.
-
I was able to crash the camera in CHDK settings: Grid : a few messages flashed and then it shutdown.
Can you dump a ROMLOG please.
-
romlog for sx60hs 100f crash associated with chdk setttings: grid attached
-
I cannot reproduce the crash when setting grid. Now it shows nothing at all in 1.6.0-6027.
If I load a grid 3x8 from a file it shows a 3x3 grid. Not equal squares. A square in the middle, rectangles around it which are longer in the dimension orthogonal to the shared edge of the square. The histogram briefly blinks over the grid.
So I'm thinking the romlog I attached above might reflect a memory card error after the first crash. So I will use this for awhile and if any crashes occur I'll post a romlog for them. Sorry for confusion.
-
@waterwingz & @62ndidiot
Test versions for G16 1.01c and SX60 1.00f
I have not looked at this for a while so I may have missed something.
Downloaded and installed this version on my G16. Tested in shooting mode with auto focus tracking window enabled and active. Menus and OSD icons all stable with no "flashing". Very nice!
I'm not sure what needs to be tested but I enabled grids and histogram and that worked stably. Took some photos, used CHDK overrides, ran the motion detection script - everything worked perfectly.
I then tried zebra and edge overlay with less success. Using a card setup for 1.6.0-6026 I could see the overexposed regions in zebra mode and edge overlay outlines. Overwriting the older 6026 version on the card with the new 6027 zip file makes the zebra and edge overlay stop working. I went back and forth unzipping to the same card (i.e. same CHDK config each time) but no zebra or edge overlay with the new version. There was no observable response on the LCD to enabling these features.
EDIT : I forgot to say "thank you" to @philmoz for doing this.
-
I then tried zebra and edge overlay with less success. Using a card setup for 1.6.0-6026 I could see the overexposed regions in zebra mode and edge overlay outlines. Overwriting the older 6026 version on the card with the new 6027 zip file makes the zebra and edge overlay stop working. I went back and forth unzipping to the same card (i.e. same CHDK config each time) but no zebra or edge overlay with the new version. There was no observable response on the LCD to enabling these features.
When you get a chance can you try this version please.
This will display 4 numbers at the top left of the display - please post the 4 values from REC mode.
Edit: attachment removed - see later post for newer build.
-
When you get a chance can you try this version please.
This will display 4 numbers at the top left of the display - please post the 4 values from REC mode.
rec mode : 640 -3 480 0
play mode : 360 -3 240 0
video mode 640 -3 360 0
-
When you get a chance can you try this version please.
This will display 4 numbers at the top left of the display - please post the 4 values from REC mode.
rec mode : 640 -3 480 0
play mode : 360 -3 240 0
video mode 640 -3 360 0
Thanks - it looks like the ximr_context structure is different to all the other versions so far.
Here is a test build with what I think the new structure is.
-
Thanks - it looks like the ximr_context structure is different to all the other versions so far.
Here is a test build with what I think the new structure is.
Edge overlay and zebra now work as expected. I wasn't able to think of any other features to test that might be tied to display buffers. Do you have any things I should also try beyond the ones I listed above?
Also, don't forget to disable four debug numbers before you release this ;)
-
Do you have any things I should also try beyond the ones I listed above?
It would be good to check HDMI output from the camera if possible.
-
It would be good to check HDMI output from the camera if possible.
So after an interesting battle with connectors and cables, I found a combination that allowed me to connect my G16 to an HDMI capable monitor. Every things works fine when I don't load CHDK.
The first things I discovered is that the existing G16 port screws up the HDMI output. I didn't test HDMI when I did the port so perhaps that's not surprising. It looks like a buffer size issue - see the attached image.
Then I tried @philmoz 's new version and that crashed the camera when attached via an HDMI cable. When I say crashed, starting the camera in playback mode seems to begin normally based in the LED pattern. But no output appears on the HDMI port or the camera's LCD and after a couple seconds the camera simply powers off. No battery pull required to restart it - just press the playback or On/Off button again. ROMLOG attached in case it helps.
-
Then I tried @philmoz 's new version and that crashed the camera when attached via an HDMI cable.
Thanks for testing - I was afraid there would be problems with HDMI :(
I will need to create a version using the old display code that dumps the ximr_context structure data to a file.
Might take a little while.
-
I will need to create a version using the old display code that dumps the ximr_context structure data to a file.
Any thoughts on why CHDK screws up the HDMI output on the current trunk release? I don't recall anything in the porting process specific to HDMI output.
Might take a little while.
Well, I finished the port over four years ago and nobody yet has complained about the HDMI not working ....
-
Any thoughts on why CHDK screws up the HDMI output on the current trunk release? I don't recall anything in the porting process specific to HDMI output.
It probably needs the CAM_SUPPORT_BITMAP_RES_CHANGE flag and the implementation of update_screen_dimensions() in lib.c.
-
Any thoughts on why CHDK screws up the HDMI output on the current trunk release? I don't recall anything in the porting process specific to HDMI output.
HDMI needs the CAM_SUPPORT_BITMAP_RES_CHANGE found in many D6 ports.
FWIW, I believe the SX710 handles all the available output modes correctly, both in ximr tree and the trunk, and being a 640x480 cam, should be similar to G16 in terms of viewport/bitmap dimensions.
I will need to create a version using the old display code that dumps the ximr_context structure data to a file.
FWIW, my take on this is in https://chdk.setepontos.com/index.php?topic=12788.msg146511#msg146511
-
Here's a G16 XIMR build with the SX710HS HDMI values - on the chance that these are the same for the G16.
Thanks reyalp.
-
Here's a G16 XIMR build with the SX710HS HDMI values - on the chance that these are the same for the G16.
Thanks reyalp.
Bad news, good news.
The bad news is that your new version still crashes right away if HDMI is connected.
The good news is that I basically C&P'd the SX710HS code from its lib .c to the G16 and rebuilt the trunk. Now HDMI is stable for the G16, which suggests at least some of the SX710HS values work for the G16.
I'll post a patch file momentarily in the usual place.
-
The bad news is that your new version still crashes right away if HDMI is connected.
Here's a new test build - this is using the old display code and includes reyalps code for recording the ximr_context data.
When you have a chance can you do the following with this build.
- start in play mode on the lcd
- open the Canon menu a few times to fill the buffers to be saved
- connect chdkptp console to the camera (don't restart the camera)
- run this command in chdkptp
rmem 0x00325f3c 6272 -f=ximr_lcd_play.bin
- repeat all the above in REC mode; but change the filename in the chdkptp rmem command
- finally repeat the above connected to HDMI (both play and REC modes, changing filename each time).
If you can then upload the 4 .bin dump files please.
Edit: incorrect build removed.
-
Here's a new test build - this is using the old display code and includes reyalps code for recording the ximr_context data.
When you have a chance can you do the following with this build.
- start in play mode on the lcd
- open the Canon menu a few times to fill the buffers to be saved
- connect chdkptp console to the camera (don't restart the camera)
- run this command in chdkptp
rmem 0x00325f3c 6272 -f=ximr_lcd_play.bin
- repeat all the above in REC mode; but change the filename in the chdkptp rmem command
- finally repeat the above connected to HDMI (both play and REC modes, changing filename each time).
If you can then upload the 4 .bin dump files please.
I was pretty careful to follow your instructions step-by-step but the resulting files all see to be filled with NULs? (I ran the chdkptp gui and used the console from there if that matters). Files attached.
EDIT : my version of chdkptp is from April 2017 if that matters
-
I was pretty careful to follow your instructions step-by-step but the resulting files all see to be filled with NULs?
Sorry about that - my mistake. Here's a new version that should work (fingers crossed).
Edit: the chkdkptp rmem command should now be:
rmem 0x00326d84 6272 -f=dump_filename.bin
-
Sorry about that - my mistake. Here's a new version that should work (fingers crossed).
Edit: the chkdkptp rmem command should now be:
rmem 0x00326d84 6272 -f=dump_filename.bin
No problem - less than two minutes to rerun the tests as I left everything setup.
New files attached - non-zero contents so hoplefully that's more useful. I'll leave everything setup just in case.
-
Here are the dumps decoded with a slightly updated ximrdesc.lua (chdkptp r1081). Since dryos52 seems have a different layout, you can use something like
!xd=require'extras/ximrdesc'
!xd.export('ximr_hdmi_rec.bin',nil,{dry_ver=52})
I haven't looked at this stuff for a while, but the fields generally seem reasonable.
Also..
G16 supports HDMI out in rec, or does the HDMI turn off when you switch to rec? I thought this was only supported on the EOS M and newer cams like G7 X II and G5 X.
-
Reloaded the second version of @philmoz 's ximr G16 code (g16-101c-1.6.0-6032-full.zip). Crashes regardless of whether the HDMI cable is plugged in before boot or after boot. I've attached ROMLOG's from both cases.
G16 supports HDMI out in rec, or does the HDMI turn off when you switch to rec? I thought this was only supported on the EOS M and newer cams like G7 X II and G5 X.
G16 does not actually support HDMI out in rec. The files I posted were create using chdkptp while the camera was in REC mode with the HDMI cable connected (even though no HDMI output was active).
-
Reloaded the second version of @philmoz 's ximr G16 code (g16-101c-1.6.0-6032-full.zip). Crashes regardless of whether the HDMI cable is plugged in before boot or after boot. I've attached ROMLOG's from both cases.
Thanks for that. It's the same crash as earlier and it seems to be happening when CHDK tries to refresh the display before the display type has been set up properly.
Here is a new ximr version that does not try and refresh the display if the 'displaytype' variable is not valid.
Edit: removed non-working attachment.
-
Here is a new ximr version that does not try and refresh the display if the 'displaytype' variable is not valid.
No joy - crashes the same way, again regardless of when the HDMI cable is plugged in. ROMLOG attached although it seems to be the same as previous logs.
-
No joy - crashes the same way, again regardless of when the HDMI cable is plugged in. ROMLOG attached although it seems to be the same as previous logs.
Damn - yes it's the same crash. Guess it's more complicated than I thought.
Another test version - this time I've duplicated the 'transfer_src_overlay' code into CHDK and replaced the ASSERT with a return.
Make sure this works on the LCD before trying HDMI in case I messed up something else.
-
Another test version - this time I've duplicated the 'transfer_src_overlay' code into CHDK and replaced the ASSERT with a return.
It works!! Tested multiple boots and inserting the HDMI connector both before and after boot and playback display on my HDMI monitor works correctly every time.
Very nice. :)
-
It works!! Tested multiple boots and inserting the HDMI connector both before and after boot and playback display on my HDMI monitor works correctly every time.
Finally - thanks for testing :)
One more test version when you have time - this one just simplifies the added code by jumping back to the firmware where possible.
-
[One more test version when you have time - this one just simplifies the added code by jumping back to the firmware where possible.
Works fine as well. :xmas
-
@waterwingz - when you have a chance can you please test this G16 version for the HDMI crash issue.
I've changed this based on what srsa_4c did with the SX270/280 version which remove the need for the custom transfer_src_overlay function.
-
@waterwingz - when you have a chance can you please test this G16 version for the HDMI crash issue.
Can do but might not be until this weekend :)
-
@waterwingz - when you have a chance can you please test this G16 version for the HDMI crash issue.
Okay - here's what I observed. (tl;dr - same start up issue as before?)
1) Start camera with Play button or short press of power button and active HDMI cable attached. Camera starts and CHDK seems to start but then shuts back down just as CHDK logo draws. ROMLOG attached.
2) Start camera with long press of power button (i.e. force to start in shooting mode) and active HDMI cable attached. Camera starts up properly in shooting mode. Press Play button to go to playback mode. Video switches to HDMI output and external monitor takes over as the display. Playback mode works properly.
3) Start camera with Play button or short press of power button and HDMI cable unplugged. Wait for camera to finish startup and then plug in HDMI cable. Display works properly, switching from camera's LCD to external monitor and back as I cycle between play and shooting mode.
Edit: I confirmed that I had loaded your April 27 2022 09:39:44 rev 6089 build.
-
Okay - here's what I observed. (tl;dr - same start up issue as before?)
1) Start camera with Play button or short press of power button and active HDMI cable attached. Camera starts and CHDK seems to start but then shuts back down just as CHDK logo draws. ROMLOG attached.
Thanks for testing - does the previous version work in this scenario (starting in PLAY mode with HDMI cable attached?
-
does the previous version work in this scenario (starting in PLAY mode with HDMI cable attached?
Yes. Press PLAY with HDMI attached and camera starts up sending the LCD info to the HDMI port. All functions work normally.
Build Info for reference :
- CHDK Ver : 1.6.0
- Revision : 6037
- Date : Jan 3 2022
- Time : 08:58:24
-
Next steps?
All of the existing D6 & D7 cameras with working ports now have XIMR drawing support so what now?
I think it makes sense to promote 1.6 to release status and create a 1.7 dev branch before merging.
There is still a question on what to do with the YUV drawing code.
One option is to remove it and just keep the 8 bit and XIMR versions.
As reyalp pointed out earlier initial porting of other cameras may be easier with the YUV drawing system; but that means keeping three drawing variants.
-
I think it makes sense to promote 1.6 to release status and create a 1.7 dev branch before merging.
This seems reasonable. I might try to slip a few other things into 1.6.
There is still a question on what to do with the YUV drawing code.
One option is to remove it and just keep the 8 bit and XIMR versions.
As reyalp pointed out earlier initial porting of other cameras may be easier with the YUV drawing system; but that means keeping three drawing variants.
Yeah, I'm still not sure what the best approach is. I would really like not to have 3 different drawing codebases, but implementing the XIMR method in a brand new port might be ugly. I suppose if someone gets stuck on a port, it would be to hard to switch to the pre XIMR tree. If we keep the D6 YUV code but don't use it, there's a fair chance it will be broken when someone does go to use it.
The other idea I had is an ifdef with some minimal YUV draw capability, just enough to draw text or something, but I'm not sure this is doable or worthwhile.
-
I've updated the XIMR branch to make the RGBA drawing the default for Digic 6 and 7 cameras. I've kept the YUV drawing system.
I also reworked the gui_draw code to hopefully make it more manageable; the changes may not be to everyones liking and I'm open to suggestions to improve it.
-
Sorry to bump an old thread.
However I found something on EOS that may interest you.
https://www.magiclantern.fm/forum/index.php?topic=26024.msg244043#msg244043
A few days ago I was able to achieve this. Full double-buffered ML menu with hardware indexed rgb -> RGBA rendering on Zico.
While old method felt "laggy" and was prone to rendering glitches, this is so damn fast. Feels exactly like using 5D3.
This is all thanks to a single Zico function - GrypDsCoreDrawImageToVramForEqualPhase.
Caveats? Of course they are caveats :( Camera likes to randomly lock up (literally lock, UART output hangs mid-print) on Canon main menu enter.
This happens on R, I wasn't able to trigger it on 80D (D6) and 77D (D7). No other models were tested yet.
typedef struct Region{
uint32_t x;
uint32_t y;
uint32_t w;
uint32_t h;
} Region;
extern uint32_t mzrm_GrypDsCoreDrawImageToVramForEqualPhase
(struct MARV*, struct Region*,
uint32_t target_x, uint32_t target_y,
void * buf, uint32_t bits_per_pixel, uint32_t source_w, uint32_t source_h,
uint32_t source_cut_x, uint32_t source_cut_y, uint32_t source_cut_w, uint32_t source_cut_h,
uint32_t isTransparent);
uint8_t * pIndexedBuffer = some_indexed_rgb_buffer;
mzrm_GrypDsCoreDrawImageToVramForEqualPhase(pRgbaBuffer, NULL, 0, 0, pIndexedBuffer, 8, 960, 270, 0, 0, 960, 270, 1);
pIndexedBuffer+= 960*270;
mzrm_GrypDsCoreDrawImageToVramForEqualPhase(pRgbaBuffer, NULL, 0, 270, pIndexedBuffer, 8, 960, 270, 0, 0, 960, 270, 1);
This code allows hardware-accelerated indexed RGB -> RGBA conversion. I did it in two passes (top and bottom part of the buffer) as I wasn't able to make it process more than 960x500 at once (and target is 960x540). I tried to explore Zico code but found no direct explanation on that.
Anyway, this was tested on 80D, 77D, R (D6,D7,D8) models. Method is unstable on D8 (camera hard locks in some cases, D8 is out of context for CHDK anyway), seems to work fine but slow on D6/7.
If that works for you, then likely you can have single indexed RGB backend for all models, with just a little extra code to wrap it up on D67.
I found that this arg with Region struct pointer is ignored Zico-side, so it can be just nullptr. bits_per_pixel can be either 8 for colour and 1 for black and white image. Other values are ignored. RGBA buffer may need 0x100 alignment, but if you draw directly to Canon buffers they should be already aligned properly.