Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
The migration is almost done, at least the rest should happen in the background. There are still a few technical difference between the old cluster and the new ones, and they are summarized in this issue. Please pay attention to the TL:DR at the end of the comment.
This series adds support to display format modifier tokens in a human readable form, and expose a way to deliver that information to users up the stack. A static table holds that information, with the possibility of adding customized/specialized version to un-pack more complex forms of/for the format modifier (AMD or ARM FBC for instance). Even so, there are some examples in that table that show that is possible to combine/pack even complex representation of the format modifier, straight in.
libdrm seems a more natural place to have this in rather that up the stack in order to minimize some potential delta that might arise, but not also between kernel uapi and user-space, but also between different tools, so unifying it in libdrm seems the most appropriate.
It first syncs up with drm-next to catch up with the latest changes in drm_fourcc header (including adding new vendors and format modifiers).
The immediate user of this is modetest which was modified to make use of this change.
PS: I have a small follow-up for drm-next to let users modifying kernel uapi drm_fourcc header that they should also sync up w/ this table when new vendors, or format modifier token have been added. Will post a link to that once I git-mail that up.