[backport 25.1] xfree86: ddc: new entry point for EDID parsing

[metux]

The old ones didn't know the block size, so couldn't deduce the block
type version. With upcoming new features, eg. HDR, we need to know the
block type version in order to know what we can extract from it.

This new function should now be used by all drivers, the old ones shall
be phased out.

That commit should be backported to 25.0 and 25.1 releases, so drivers
can remain compatible with all existing release lines.

Signed-off-by: Enrico Weigelt, metux IT consult info@metux.net

[metux]

@algrid @cepelinas9000 @stefan11111

[stefan11111]

Aren't backports meant for bugfixes? This feels like a new feature/redesign instead.

[metux]

Aren't backports meant for bugfixes? This feels like a new feature/redesign instead.

Yes, but in this special case I'd like to have this function available in older Xservers, so drivers can start using it w/o having to depend on newer Xserver.
An alternative would be extra checks and ifdef's in drivers.

[stefan11111]

Aren't backports meant for bugfixes? This feels like a new feature/redesign instead.

Yes, but in this special case I'd like to have this function available in older Xservers, so drivers can start using it w/o having to depend on newer Xserver. An alternative would be extra checks and ifdef's in drivers.

If the other members of the team agree, I won't oppose.
However, there have been plenty of regressions added to master, which were later found and fixed.
Sticking to only backporting bugfixed has shielded the release branches from such regressions until now.

I'm also concerned about the Bool to bool change here, because we're already getting reports of -Wlto-type-mismatch in drivers because of such changes: https://forums.gentoo.org/viewtopic-t-1176678.html

[metux]

If the other members of the team agree, I won't oppose. However, there have been plenty of regressions added to master, which were later found and fixed. Sticking to only backporting bugfixed has shielded the release branches from such regressions until now.

I see your point. The goal of this is preventing the need for extra compile-time checks in drivers, in order to keep them compatible with both newer and older Xservers - I really hated those 'compat-api.h' headers.
But maybe it's not worth the risk. Do you have some alternative idea ?

I'm also concerned about the Bool to bool change here, because we're already getting reports of -Wlto-type-mismatch in drivers because of such changes: https://forums.gentoo.org/viewtopic-t-1176678.html

Where is Bool/bool involved here ? (in the public interface).

[stefan11111]

Where is Bool/bool involved here ? (in the public interface).

Didn't see it's only used in a static function.
Should not be a problem then.

[algrid]

It would be nice to add a deprecation warning (comment) into the header file.

[metux]

Where is Bool/bool involved here ? (in the public interface).

Didn't see it's only used in a static function. Should not be a problem then.

No problem :)

Any objections to this PR left ?

[metux]

It would be nice to add a deprecation warning (comment) into the header file.

Yes, but just on master, not this 25.1 release branch.
Feel free to submit PR :)