From: Jani Nikula <jani.nikula@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: "Michał Grzelak" <michal.grzelak@intel.com>,
igt-dev@lists.freedesktop.org, suraj.kandpal@intel.com
Subject: Re: [PATCH i-g-t v2 5/8] tools/vbt_decode: guess devid from VBT signature
Date: Thu, 11 Jun 2026 12:58:32 +0300 [thread overview]
Message-ID: <a43e799387cd3b6bca43ebc8ca01533e61944fbe@intel.com> (raw)
In-Reply-To: <ail_J2_jB238ws74@intel.com>
On Wed, 10 Jun 2026, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Wed, Jun 10, 2026 at 05:42:58PM +0300, Jani Nikula wrote:
>> On Mon, 08 Jun 2026, Michał Grzelak <michal.grzelak@intel.com> wrote:
>> > Nowadays Device ID needs to be passed to decode VBT precisely. VBT lacks
>> > it since VBT has been moved from PCI ROM into opregion.
>> >
>> > However we can narrow from which platform VBT originated basing on VBT
>> > signature.
>> >
>> > Add a command-line option to guess devid using VBT signature. Create an
>> > array of signatures and check if any of those is a substring of
>> > signature extracted from given VBT. Map each signature into first Device
>> > ID of a platform picked from include/drm/intel/pciids.h. Log that devid
>> > has not been matched if signature is not found.
>> >
>> > Note that the platform-specific name should appear after "$VBT ", hence
>> > the match.
>> >
>> > Suggested-by: Jani Nikula <jani.nikula@intel.com>
>> > Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
>> > ---
>> > tools/intel_vbt_decode.c | 36 +++++++++++++++++++++++++++++++++++-
>> > 1 file changed, 35 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/tools/intel_vbt_decode.c b/tools/intel_vbt_decode.c
>> > index 5681643f4b..ec82b00939 100644
>> > --- a/tools/intel_vbt_decode.c
>> > +++ b/tools/intel_vbt_decode.c
>> > @@ -77,6 +77,7 @@ struct context {
>> > uint32_t devid;
>> > int panel_type, panel_type2;
>> > int sdvo_panel_type;
>> > + bool devid_from_signature;
>> > bool dump_all_panel_types;
>> > bool hexdump;
>> > };
>> > @@ -3693,6 +3694,31 @@ static int get_sdvo_panel_type(struct context *context)
>> > return panel_type;
>> > }
>> >
>> > +static int
>> > +get_devid_from_signature(const char *vbt_signature)
>> > +{
>> > + int i;
>> > +
>> > + const char *signature[] = {"PANTHERLAKE",
>> > + "LUNARLAKE",
>> > + "METEORLAKE",
>> > + "JASPERLAKE",
>
> That's a somewhat weird selection of platforms.
Come to think of it, I wonder how hard and/or useful it would be to add
some fuzzy lookup into intel_device_info.c based on the signature. It
would bypass the need to add anything here.
>
>> > + NULL};
>> > +
>> > + int devid[] = {0xB080, /* PTL */
>> > + 0x6420, /* LNL */
>> > + 0x7D40, /* MTL */
>> > + 0x4E51, /* JSL */
>> > + 0x0};
>>
>> Please use a struct, something along the lines of:
>>
>> static const struct {
>> const char *signature;
>> uint16_t devid;
>> } devids[] = {
>> { .signature = "PANTHERLAKE", .devid = 0xb080, },
>> ...
>> };
>>
>> Then you can also ditch the /* PTL */ etc. comments.
>>
>> > +
>> > + for (i = 0; signature[i]; i++)
>> > + if (strstr(vbt_signature, signature[i]))
>> > + return devid[i];
>> > +
>> > + fprintf(stderr, "Warning: cannot find devid for signature %s\n", vbt_signature);
>>
>> This should be a fallback, please don't warn anything here. Only one
>> warning for the whole devid thing.
>>
>> > + return 0;
>> > +}
>> > +
>> > static int
>> > get_device_id(unsigned char *bios, int size)
>> > {
>> > @@ -4108,6 +4134,7 @@ enum opt {
>> > OPT_PANEL_TYPE2,
>> > OPT_PANEL_EDID,
>> > OPT_PANEL_EDID2,
>> > + OPT_VBT_DEVID,
>> > OPT_ALL_PANELS,
>> > OPT_HEXDUMP,
>> > OPT_BLOCK,
>> > @@ -4162,6 +4189,8 @@ int main(int argc, char **argv)
>> > { "panel-edid", required_argument, NULL, OPT_PANEL_EDID },
>> > { "panel-type2", required_argument, NULL, OPT_PANEL_TYPE2 },
>> > { "panel-edid2", required_argument, NULL, OPT_PANEL_EDID2 },
>> > + { "devid-from-signature",
>> > + no_argument, NULL, OPT_VBT_DEVID },
>> > { "all-panels", no_argument, NULL, OPT_ALL_PANELS },
>> > { "hexdump", no_argument, NULL, OPT_HEXDUMP },
>> > { "block", required_argument, NULL, OPT_BLOCK },
>> > @@ -4207,6 +4236,9 @@ int main(int argc, char **argv)
>> > case OPT_PANEL_EDID2:
>> > panel_edid2 = optarg;
>> > break;
>> > + case OPT_VBT_DEVID:
>> > + context.devid_from_signature = true;
>> > + break;
>> > case OPT_ALL_PANELS:
>> > context.dump_all_panel_types = true;
>> > break;
>> > @@ -4313,6 +4345,8 @@ int main(int argc, char **argv)
>> > context.bdb = (const struct bdb_header *)(VBIOS + bdb_off);
>> > context.size = size;
>> >
>> > + if (!context.devid && context.devid_from_signature)
>> > + context.devid = get_devid_from_signature((char *) vbt->signature);
>>
>> This should be last. The priority should be:
>>
>> 1. command-line, if set
>> 2. environment variable, if set
>> 3. VBIOS, if available
>> 4. deduce from signature, if requested
>>
>> Come to think of it, not sure about the "if requested". Maybe just use
>> it if not otherwise specified. This is userspace decoding, not kernel,
>> after all.
>>
>> Ville, thoughts?
>
> Yeah, could probably just take the fallback when we don't know
> any better.
>
> But I'm thinking we should just add the devid to the VBT dump produced
> by the kernel. Would avoid having to guess, especially since vendors
> have been known to sometime reuse older VBTs across platforms. Perhaps
> just prepend the VBT image with a PCIR structure which can then be
> parsed by the code in get_device_id().
Maybe should've thought of that when we added i915_vbt... I wonder
what's going to break if we do this?
Anyway, even if we added it, not all VBTs are going to have it. I think
the idea behind the patch at hand is sound, and it should be added as a
fallback. The kernel part can be added separately, and if we follow the
order outlined above, it'll take precedence over the guesses here.
BR,
Jani.
>
>>
>> > if (!context.devid) {
>> > const char *devid_string = getenv("DEVICE");
>> > if (devid_string) {
>> > @@ -4326,7 +4360,7 @@ int main(int argc, char **argv)
>> > if (!context.devid)
>> > context.devid = get_device_id(VBIOS, size);
>> > if (!context.devid)
>> > - fprintf(stderr, "Warning: could not find PCI device ID!\n");
>> > + fprintf(stderr, "Warning: could not find PCI device ID! Use --devid or --devid-from-signature\n");
>> >
>> > if (context.panel_type == -1)
>> > context.panel_type = get_panel_type(&context, false);
>>
>> --
>> Jani Nikula, Intel
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-06-11 9:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 12:41 [PATCH i-g-t v2 0/8] Vswing / Pre-emphasis Override decoding Michał Grzelak
2026-06-08 12:41 ` [PATCH i-g-t v2 1/8] tools/vbt_decode: fix tables' offset reading Michał Grzelak
2026-06-08 12:41 ` [PATCH i-g-t v2 2/8] tools/vbt_decode: rename VBT#57 related vars Michał Grzelak
2026-06-08 12:41 ` [PATCH i-g-t v2 3/8] tools/vbt_decode: return 0 from get_device_id() Michał Grzelak
2026-06-11 9:47 ` Jani Nikula
2026-06-08 12:41 ` [PATCH i-g-t v2 4/8] tools/vbt_decode: validate DEVICE env var Michał Grzelak
2026-06-11 9:51 ` Jani Nikula
2026-06-08 12:41 ` [PATCH i-g-t v2 5/8] tools/vbt_decode: guess devid from VBT signature Michał Grzelak
2026-06-10 14:42 ` Jani Nikula
2026-06-10 15:13 ` Ville Syrjälä
2026-06-11 9:58 ` Jani Nikula [this message]
2026-06-08 12:41 ` [PATCH i-g-t v2 6/8] tools/vbt_decode: parse & dump VS/PE-O tables for LT Michał Grzelak
2026-06-08 12:41 ` [PATCH i-g-t v2 7/8] tools/vbt_decode: parse & dump VS/PE-O tables for Snps Michał Grzelak
2026-06-08 12:41 ` [PATCH i-g-t v2 8/8] tools/vbt_decode: parse & dump VS/PE-O tables for Combo Michał Grzelak
2026-06-09 0:04 ` ✓ Xe.CI.BAT: success for Vswing / Pre-emphasis Override decoding Patchwork
2026-06-09 0:18 ` ✓ i915.CI.BAT: " Patchwork
2026-06-09 5:04 ` ✗ Xe.CI.FULL: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a43e799387cd3b6bca43ebc8ca01533e61944fbe@intel.com \
--to=jani.nikula@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=michal.grzelak@intel.com \
--cc=suraj.kandpal@intel.com \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox