How to get BIOS Device Name from Linux, same as Windows Device Manager format

Question

My laptop has a display adapter and from Windows 10 I can see its BIOS Device Name from..

Device Manager > Display Adapters > Properties > Details > "BIOS device name"

And from there I get a pop up window saying something like: \_SB.PCI0.GFX0

How can I get that information if the same laptop is running Linux?

Cheers

Update

I need this information because I am building a hackintosh and need to build a SSDT to create a display backlight fix. I would like to help out at the Opencore project and provide a method to do this in Linux as currently the only method is to switch in to Windows and use Device Manager

I tried dmidecode and lspci and they don't give me a BIOS device name in the format that Windows does and is needed to create the SSDT.

I tried acpidump and it's getting me closer but the decompiled output has disassembly errors. It contains the string I am looking for \_SB.PCI0.GFX0 but I don't know how I would create a script to read that file and correlate it to my particular display adapter. e.g: Intel(R) HD Graphics 4000.

These are the commands I have tried so far with acpidump
I dump the ACPI tables from my system to a text file:

sudo acpidump -o acpidump.out

Extract the binary ACPI tables from acpidump output

acpixtract -a acpidump.out

I now have seven ssdt*.data files. I disassemble the binary table of ssdt1.dat into human source

iasl -d ssdt1.dat

This gives a large .dsl file, this is just the first 60 lines of over a thousand..

/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20190509 (64-bit version)
 * Copyright (c) 2000 - 2019 Intel Corporation
 * 
 * Disassembling to symbolic ASL+ operators
 *
 * Disassembly of ssdt1.dat, Mon Jun  7 09:54:08 2021
 *
 * Original Table Header:
 *     Signature        "SSDT"
 *     Length           0x00001EED (7917)
 *     Revision         0x01
 *     Checksum         0x9C
 *     OEM ID           "COMPAL"
 *     OEM Table ID     "CRV ORB "
 *     OEM Revision     0x00001000 (4096)
 *     Compiler ID      "ACPI"
 *     Compiler Version 0x00040000 (262144)
 */
DefinitionBlock ("", "SSDT", 1, "COMPAL", "CRV ORB ", 0x00001000)
{
    /*
     * iASL Warning: There was 1 external control method found during
     * disassembly, but only 0 were resolved (1 unresolved). Additional
     * ACPI tables may be required to properly disassemble the code. This
     * resulting disassembler output file may not compile because the
     * disassembler did not know how many arguments to assign to the
     * unresolved methods. Note: SSDTs can be dynamically loaded at
     * runtime and may or may not be available via the host OS.
     *
     * To specify the tables needed to resolve external control method
     * references, the -e option can be used to specify the filenames.
     * Example iASL invocations:
     *     iasl -e ssdt1.aml ssdt2.aml ssdt3.aml -d dsdt.aml
     *     iasl -e dsdt.aml ssdt2.aml -d ssdt1.aml
     *     iasl -e ssdt*.aml -d dsdt.aml
     *
     * In addition, the -fe option can be used to specify a file containing
     * control method external declarations with the associated method
     * argument counts. Each line of the file must be of the form:
     *     External (<method pathname>, MethodObj, <argument count>)
     * Invocation:
     *     iasl -fe refs.txt -d dsdt.aml
     *
     * The following methods were unresolved and many not compile properly
     * because the disassembler had to guess at the number of arguments
     * required for each:
     */
    External (_SB_.PCI0.GFX0, DeviceObj)
    External (_SB_.PCI0.GFX0._DOD, IntObj)
    External (_SB_.PCI0.GFX0.AINT, MethodObj)    // Warning: Unknown method, guessing 2 arguments
    External (_SB_.PCI0.GFX0.DD01._ADR, IntObj)
    External (_SB_.PCI0.GFX0.DD01._DGS, IntObj)
    External (_SB_.PCI0.GFX0.DD02._ADR, IntObj)
    External (_SB_.PCI0.GFX0.DD02._BCL, IntObj)
    External (_SB_.PCI0.GFX0.DD02._BCM, IntObj)
    External (_SB_.PCI0.GFX0.DD02._BQC, IntObj)

I think maybe I need to dissasemble ssdt1.dat such that I don't get disassembly errors and then is there a way to search that disassembled file for a device by a name like 'Intel(R) HD Graphics 4000' or that would at least be obvious this is the BIOS Device Name for my display adapter?

Maybe dmidecode, lspci and acpidump can all be combined into a script?

Any other help much appreciated.

Flex

Answer 1

I don't know if this is the best solution or if it will work on every Linux distro but I can find the information I need \_SB_.PCI0.GFX0 with this command:

# cat /sys/class/pci_bus/0000:00/device/0000:00:02.0/firmware_node/path

This is also known as the ACPI path. Why does this command work for me?

Explanation
In Linux a PCI device is identified with a 16-bit domain number, an 8-bit bus number, a 5-bit device number and a 3-bit function number; the last three numbers are commonly referred to as the device's BDF or B/D/F (for bus/device/function).

The lspci command can display this identification number using...

# lspci -D
..
0000:00:02.0 VGA compatible controller: VMware SVGA II Adapter
..

The format of this number 0000:00:02.0 is domain:bus:device:function.

Now use this command from a Terminal to find the ACPI path of your display adapter

# cat /sys/class/pci_bus/<domain:bus>/device/<domain:bus:device:function>/firmware_node/path

Again, I don't know much about this topic or if this procedure will work on all distros but it does work on my Ubuntu mate 20.04.1.

Another hacky method might be to follow the steps in my initial question with acpidump, acpixtract and iasl. Then just search the resulting disassembled .dsl file for DeviceObj. So finding the string: External (SB.PCI0.GFX0, DeviceObj) would mean the ACPI path is \_SB_.PCI0.GFX0

References
Interpreting the output of lspci
Helpful reddit post