HD OSD on non Inav FC? about msp-osd

[bri3d]

How does this work in general:

It's a custom extension to MSP DisplayPort built by the HDZero team and various FC developers. It's currently only supported in iNav. There are PRs open in ArduPilot for support : ArduPilot/ardupilot#19762 . I'm scared of even trying to bring it up with the BetaFlight developers, although supposedly there are new management there who may be more receptive.

The mechanics are quite simple: a new custom MSP DisplayPort message 5 was added, which specifies a "font number" (currently unused, the idea is you can have multiple fonts on your SD card but no FC supports it yet) and "HD mode." If HD mode is set to true, the MSP DisplayPort character map size extends to 50x18, providing a much larger drawing canvas to work with.

In the case of my and the HDZ OSD implementations, this also means the character size changes from 3x back to 2x in order to fit, giving a more "zoomed out" OSD feel.

[DimitarKrastev]

Great, thanks. I have a proposal for similar implementation open in another issue:
#16

Basically the idea is to use the coordinates as indexes multiplied by a given factor. That should give more effective resolution even if the sending side doesn't support that. I think DJI is using something similar as approach as their OSD is much higher resolution and "zoomed out". The only downside to it is the addressability of the position of the elements. If we draw twice as many character boxes in the OSD, but the sending side only know about half of them it would mean that moving an OSD element 1 box to the right will result to 2 boxes of movement in the goggles, but I think thats a small price to pay.

Can you take a look and let me know what you think?
Thanks!

[TomAlperin]

I was thinking something like this would be a good idea. It would be like if Fake HD had space between all the cells so they filled the screen but the cells would only set the starting point. The additional letters would be the correct spacing from the previous. Fake HD makes it difficult to position some long elements without them being split.

[benlumley]

This approach isn't really that practical for various reasons (eg: inav likes to do partial updates; BF sends each character individually, some elements span multiple lines - nothing would line up, some elements grow/shrink depending on their data).

I am intending to add some configurability to the grid - so you can have space for longer elements; which should solve your problem here.