Reply To: OSSC Pro firmware v0.75

NewHome › Forums › OSSC, OSSC Pro and DExx-vd isl › OSSC – Discussion and support › OSSC Pro firmware v0.75 › Reply To: OSSC Pro firmware v0.75

May 1, 2024 at 6:37 AM #61495
jaffa225man
Participant

    In your code at software/sys_controller/av_controller.c, I see you setup the custom EDID in a file called edid.bin which is loaded from the update_edid() function, but I don’t see where that’s called from.  Is there a menu option you’re planning on adding to run it?  More importantly, will I be able to revert that custom EDID back to your default after setting it, either by deleting the edid.bin file or by using another method?

    I think I may have gotten lucky and fooled the Analogue DAC into working enough (when I only have a Pocket/Dock which hasn’t yet had support added to the DAC) to read its EDID.  I found that an extra bright white LED turned on when I disconnected the audio from my MiSTer/Pocket SCART cable which I’d adapted from its stereo 1/8″ minijack to the 2 RCA cables needed on the DAC.  Although that LED is on after reconnecting the stereo minijack, audio remains all that’s passed from the DAC, other than analogue’s simple notice of “NO SIGNAL” on the display.  With that, I disconnected the Dock from the HDMI cable, which I then connected to a laptop to notice a previously unseen EDID that’s not similar to the internal display, which incidentally can’t be enabled or switched to for output use.

    So I’m hopeful I captured it, but am unsure, and will wait with bated breath.

    I made a silly mistake and had used the filename edid.bin.bin on my microsd card, so that may have been an issue, but the Analog Dock still isn’t using the lower resolutions offered by the custom edid.bin either which may be due to the Pocket/Dock not yet supporting the DAC.

    When it is working, I hope you’ll add a menu method (probably in “AV4 video in opt.”) that’s saved per-profile to selectively turn off the custom EDID for systems that use other resolutions.  Better yet, that option could have multiple choices for edid1.bin, edid2.bin, etc. in case people end up needing more complex setups, but this idea would just be future-proofing for me.

    Edit: I didn’t wait.  The captured EDID must have been a connection from the previous owner of the computer.  I finally got the correct Analogue DAC EDID (which doesn’t even contain a valid EDID header) by using an HD Fury Dr. HDMI 4K to sink the downstream EDID and read it through USB on a computer.  Since I was able to save it and add it to my OSSC Pro’s micro-SD card named edid.bin, I can definitely state that the OSSC indeed reports itself as the Analogue DAC.  I verified it again, by sinking the downstream connection (this time of the OSSC Pro) using the HD Fury Dr. HDMI 4K via a computer running their USB program.

    I consider the lack of a standard EDID header from the Analogue DAC’s “EDID” Analogue’s way of copy-protecting it, since nothing other than their devices will consider it worthy of utilization and hence recognition of it.  Computers would probably need a kernel driver to capture it because of this.  The HD Fury Dr. HDMI is designed to work with any sinked downstream EDID, so it does, but their USB software doesn’t recognize this nonstandard EDID as “hex format” for loading back from a saved .bin file onto the Dr. HDMI, presumably because it’s missing the EDID header.  If it’s sinked from downstream HDMI and saved to one of its custom EDID slots, it will be able to use it, however.

    Edit: GNU/Linux does on startup (probably re-readable through dmesg) saying it’s corrupt while still listing all the hexadecimal bytes, so I hope others can save that money at least.  Analogue’s probable attempt to sell more DACs can be worked around.

    I do hope you add that nice feature I envisioned earlier, although seemingly not necessary for my use yet, in order to disable and enable multiple EDID files spread across different profiles.  I have captured the OSSC Pro’s own EDID too now, although I think since its own EDID is already in the code, it should be capable of disabling EDID spoofing without providing the OSSC Pro’s EDID in a file.

    Thanks for the upgrade, as always! 🙂

    • This reply was modified 1 year, 10 months ago by jaffa225man. Reason: Better clarity
    • This reply was modified 1 year, 10 months ago by jaffa225man.
    • This reply was modified 1 year, 10 months ago by jaffa225man. Reason: Sorted out and truly tested at last!
    • This reply was modified 1 year, 9 months ago by jaffa225man. Reason: GNU/Linux for the win (as always)!