Please respect XDG Base Directory specification

[nazar-pc]

Feature request

Add support for XDG Base Directory specification on Linux, specifically using ~/.cache/hyperhdr, ~/.config/hyperhdr, ~/.local/share/hyperhdr, etc.

What problem does this feature solve?

Get rid of ~/.hyperhdr. Linux applications should split their storage logically and place the data in the corresponding location. It is annoying when every app thinks it deserves a place at the root of my home folder when a more logical place exists and plays nicer with backups (that skip ~/.cache), etc.

What does the proposed API look like?

No API change.

How should this be implemented in your opinion?

Default to XDG Base Directory specification in the future version, while supporting fallback to ~/.hyperhdr if it already exists from earlier installation.

Are you willing to work on this yourself?

Not my specialization, sorry. But I can provide feedback.

[awawa-dev]

Hi
changing the home folder path is a one‑minute job in the code. But AI says not so fast. I must admit I have to agree with that, so I say maybe someday in the future.

---

Technical Evaluation: Implementation of XDG Base Directory Specification

The proposal to transition HyperHDR to the XDG Base Directory specification on Linux has been evaluated. While the request aligns with modern Linux desktop standards, several technical and operational factors weigh against its implementation at this stage.

1. Backward Compatibility and Ecosystem Stability

   • A significant portion of the HyperHDR user base operates in environments where file paths are hardcoded or strictly defined.
   • Containerization: Many users deploy HyperHDR via Docker. Changing the default directory structure would break existing bind-mounts and volume mappings, leading to potential data loss or initialization failures.
   • Automation: Numerous third-party scripts, systemd service overrides, and integration tools rely on the ~/.hyperhdr path. Forcing a migration would necessitate a global update of all community-contributed resources.

2. Cross-Platform Parity and Documentation

   • Maintaining a unified directory structure across Linux, macOS, and Windows provides essential benefits for project sustainability:
   • Simplified Support: A single, predictable path allows for consistent troubleshooting instructions regardless of the host OS.
   • Documentation Integrity: Current tutorials, wikis, and video guides are built around the existing structure. Introducing platform-specific path logic (splitting data into .config, .local/share, and .cache) would significantly increase the complexity of the documentation and lead to user confusion.

3. Risk-to-Benefit Ratio

   • The proposed change is primarily cosmetic (organizational) and does not improve the core functionality or performance of the application.
   • Migration Risks: Automating the movement of databases and configuration files across various Linux distributions and permission sets introduces a high risk of regression.
   • Development Focus: Development resources are currently prioritized toward core feature stability and hardware compatibility.
   • Diverting these resources to manage a non-critical filesystem restructuring is not seen as an efficient allocation of time.

4. Industry Precedents

   • While XDG is a recommended standard, many major developer tools and high-traffic projects (e.g., Docker, npm, SSH, and various cross-platform frameworks) continue to utilize a single hidden directory in $HOME to ensure maximum portability and ease of manual access for the user.

Conclusion:

• At this time, maintaining the current ~/.hyperhdr structure is deemed necessary to ensure the stability of the existing installation base and the clarity of project documentation.

• For users who require XDG compliance for personal organization or backup management, the recommended approach is to utilize symbolic links or existing environment variables to redirect the application data folder as needed.

[nazar-pc]

Symbolic links do nothing about cleaning up the home folder though.

I do not suggest introducing this change in a patch version, but the next major version with a clear note in the changelog should be okay. Moreover, with the approach I have suggested, existing installations will continue to work after upgrade, it is only new installations using future major version that will be affected going forward.

BTW, Windows and macOS also have a similar logical structure that users might prefer. I only mentioned Linux because that is what I care about the most.

In Rust one can use a crate like https://docs.rs/dirs that gives you cross-platform mapping to OS-specific directories. Not sure about C++, but it should not be hard to hand-roll something basic for the 3 major OSs.

[awawa-dev]

Unfortunately, my experience shows that even with clear warnings in the changelog, many users skip the notes entirely. You’d be surprised how often this happens, last time when I warned in the v21 changelog about the v4l2 kernel bug on rpi3b/w zero... and then get upset and open lots of duplicate issues. I’d rather avoid that storm for something that is mostly cosmetic ;-)

[Entropy512]

Hmm. Perhaps maintain legacy config support for a period of time, e.g.:
If an existing config in the legacy location is detected, use that, and pop a warning that it is deprecated and will be removed in <insert future version here>
New installs use XDG compliant structures

Not sure if automigrating is a good idea or not.

[Danny3]

Also for Linux, is HDR at high resolutions and refresh rates really possible, especially without helping these guys first to solve the remaining problems?
mkopec/linux#18
XDG Base Directory specification is nice to have, but I rather have all the high quality supported and work well first.

[nazar-pc]

@Danny3 please do not abuse this issue with unrelated discussions. This issue is about a very specific feature request.

[Danny3]

@Danny3 please do not abuse this issue with unrelated discussions. This issue is about a very specific feature request.

Fine!

Could you also please do not abuse HDR as a search result term for a project that has nothing to do with HDR or very little?
As I don't see what an ambient lighting system has with HDR?
Can the project even analize a HDR image on Linux?
Can you do it at 4K?
Can you do it when the stream is also 10 bits?
Can it do it when the stream is 120 FPS? (Don't worry, I know the answer already as you couldn't have tested this until now anyway).

I think the project's description should include all the limitations is has on Linux as it's not fair to say it's cross-platform without showing the things that are missing on a platform compared to others.

Anyway, sorry! (you can delete the comment if it bothers you that much or tell me if you want to, but you can't).

As for the XDG base directory specification, it's good that it's a standard, but it's bad that the files are spread all over the place and backing and then restoring them is very hard.
Similar to how it's not with Firefox, which was very easy in the past to just backup the .mozilla directory and restore it later and you had all you opened tabs and in logins kept. Now it's a mess and it's very hard.
If it were up to me to design a Linux OS, I would've gone with the filesystem hierachy designed and proposed by GoboLinux developers.

[Entropy512]

HyperHDR can not, currently, capture P010 on Linux (edit: not without kernel patches written by HyperHDR's author!). But this is an issue that is known, acknowledged, and actively tracked: #967 (Fun fact: That issue is literally the first search result for "linux uvc p010" on el goog.)

HyperHDR is cross platform and DOES support P010 capture on other platforms.

If you had bothered to read the source, issues, and documentation prior to spamming an issue with unrelated crap (HyperHDR handles HDR input and tonemaps it, you're pointing to output issues which are completely irrelevant to HyperHDR since the whole point of the software is analyzing an image generated by another device), you would know the answers to the questions you asked.

[Danny3]

Thanks for the honest answer!
Fun facts:
When I search for HDR support I just search for "HDR" not for its competing standards / formats like HDR10, HDR10+, HLG and Dolby Vision, it's too much trouble.
Also, the only reason I found this repository is because I search HDR Linux". If the repository name didn't have HDR in it, I wouldn't have found it.
As for the company that had the long forgotten motto of "Don't be evil!" I stopped using it a decade ago and I haven't noticed that DDG to not be good enough for what I needed to find.
BTW, what is UVC supposed to mean, some Elgato device?
I don't have any Elgato device and I'm not familiar with them.
Isn't this one of the companies with bad Linux support?

And the P010 format is not part of the list on Wikipedia:
https://en.wikipedia.org/wiki/High-dynamic-range_television
I can see though explanations for it here:
https://wiki.hyperhdr.eu/P010-video-format
Which I guess comes from the author of this project here.

As far as I understand until now, you are only interested in the capturing part of HDMI and not about its output.
It's a shame, but not unexpected as there are others who only care only about their part, their thing, stuff that only affects them and not about the problems of others.
Do as you wish.
With this kind of attitude I'm also not interested into finding more about this project, recommend it to others or give a donation or make a subscription if one day it comes to that ore are requested from the community.
I only care about the people who collaborate with others and work together to improve things, find solutions, etc.
That's why I'm part of the Linux community and I want to see it succeed.
In the meantime I'm keeping my own personal list of the companies and projects which work towards that goad and which are not.

Custom, non-GPL and non-merged upstream patches also are not interesting to me as I prefer upstreamed patches and kernels built in a reproducible way, like Debian and Open Source maintainers do.

I took my star back that I initially gave this project to remember it and keep being notified.
I think I left enough feedback about what I think about the XDG base directory specification and other things.
Good luck anyway as at least the project is open source!

[Entropy512]

You have an extremely poor attitude towards open source developers. Everyone contributing to this project is a volunteer with limited time (I do plan on contributing myself, but I have a full time job so my contributions are going to be fairly minor), and you are insisting that they spend time on items that are completely outside of the scope of their project?

As to UVC: Again, you're asking questions that can be answered with a simple search: https://en.wikipedia.org/wiki/USB_video_device_class is literally the first result for the search term UVC

https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats is the first result for P010

Also, this repo isn't even in the first TEN pages of results for the search term "HDR Linux"

Also your assertion that just because a patch isn't upstreamed yet it's not GPL is utter BS. The patch is 100% GPL. It looks like attempts have been made to upstream it but the last attempt was stalled due to email formatting issues - https://patchwork.linuxtv.org/project/linux-media/patch/20251226065718.95504-1-ovcollyer@mac.com/

Edit: Weird my last edit on my previous comment never seems to have gone through, but P010 isn't even needed for HDR. The Sony 8-bit HLG era (see Kamacira Japan's A6500 and RX100VI footage on YouTube) proves that just changing transfer function and gamut gets you most of the way there even if it's still 8 bits.

[awawa-dev]

@Danny3

Wow, looks like the sewage pipe finally burst - and of course it had to happen in a some random Linux thread. Peak predictability, zero surprise.

I’m genuinely not sure if this is low-effort bait or if you’re actually this clueless, but since you’ve taken the time to write a whole manifesto while knowing jack shit about the project, let me clear the air for you:

• UVC/Elgato: Buddy, if you had even half a clue, you’d know I have zero love for Elgato after the shady stunt they pulled with one of their grabbers - something I personally discovered, tested, and publicly dragged them for. But sure, keep lecturing me like you’re the only one who’s ever been burned by bad Linux support. Adorable.

• P010 & upstreaming/ The “community” you love so much: Oh, the famous P010 format you couldn’t find on Wikipedia? Yeah, because I’m the one who actually uses this on Raspberry Pi OS every single day. I already submitted the patch upstream myself months ago: V4L2: support for P010 (HDR) video format for UVC devices raspberrypi/linux#6451 Conscience crystal clear. Since then nobody else bothered to port it to mainline. Maybe - just maybe - they didn’t feel like drowning in the exact same flood of toxic, non-technical whining you just gifted us. You’re literally the poster child. From our user reports I know that experimental (in Wayland not our software) HDR capture in Linux PipeWire actually works for them.. until the next random OS Linux update may break it - but hey, at least it’s not Windows Update, right? Silver linings! Here’s the fun part: why the hell would any sane person waste their unpaid free time fixing bugs, testing updates, or babysitting entitled users when the reward is exactly this kind of entitled tantrum? I’d rather spend my evenings on literally anything more enjoyable than being your personal open-source punching bag.

So go ahead: keep your sacred “personal blacklist”, take your star back, cling to your purity test about GPL-only upstream patches, and pat yourself on the back for being such a noble Linux warrior. Meanwhile I’ll just keep quietly building the thing you apparently needed so badly you rage-posted few hundred words about it.

Good luck with your next Google search for “HDR Linux” and your ever-growing list of villains. You’re doing amazing, sweetie. ✨

Any further comments unrelated to this PR (and don't even think about using it as a pretext to continue your off-topic rant) will be rewarded with a permanent ban.

[Entropy512]

Getting back on topic, I might attempt to take a crack at this once I start my HyperHDR buildout after I get back from a business trip next week.

At least preliminary requirements as I understand it from previous discussion so I don't bark up the wrong tree):

• The implementation shall preserve compatibility with the legacy configuration structure (at least for a period of time to be determined by @awawa-dev - 3 major versions? more? less?)
• The implementation shall warn the user that a deprecated configuration structure is in use and support will be removed in (insert version here), and provide instructions on migrating the configuration
• The implementation shall use the XDG standard for new installs where the legacy configuration structure is not detected
• The implementation shall prefer the new XDG structure if both configurations are detected and/or not even look for the legacy structure if the new one is detected (not sure on the details here, it might be beneficial to warn that a legacy configuration was detected but not used)
• The implementation shall support a method of assisting the user with migrating the structure (would it be OK if this is a separate script?)

[Danny3]

@Entropy512 and @awawa-dev,
I'm sorry!
I'll take it all back, please forgive me!

I thought that that you or others being passionate about video support on Linux, reading my comment, might be aware / interested and have the know-how to help other developers trying to figure things out and trying to improve hardware support in other parts of the open source community.
I misjudged you.
I've put my star back, even though the project doesn't seem to need it considering the count, but this way I will not forget about it.
Good luck an many thanks for all the explanations and patience!

[awawa-dev]

Apology accepted; thanks for the support and let's keep the focus on the technical side of the project moving forward.