Hands-on Projects for the Linux Graphics Subsystem New book from Christos Karayiannis Available in Amazon Kindle format at: amazon.com   amazon.co.uk   amazon.de   amazon.es   amazon.fr   amazon.it

PCI Experiments (part II)

In the current section we continue with the lspci Unix command and see some and this time we use the -v (verbose) option:

sudo lspci -v

Notice that root privilege (sudo) is required for lspci in order to reveal the values in the 'Capabilities' field. The output in our system in the Display and VGA part that is discussed here was:

As we see in the previous image lspci indicates at the Kernel modules field the Intel i915 driver. This is a misconception since the driver currently used by our system is vesa. In the following figure we see that xorg.conf, the configuration file for the X Server, uses the vesa driver:

Also looking at the Xorg.0.log file, the X Server log file for display 0, we find in the driver list loaded by the X Server the vesa driver (vesa_drv.so):

more /var/log/Xorg.0.log | grep Loading

The output is the following:

The following text tries to present an explanation for the i915 appearance in the lspci output starting with depmod.

In the depmod man page we find when depmod runs:

The normal use of depmod is to include the line

       /sbin/depmod -a

       somewhere in the rc-files in /etc/rc.d,  so  that  the  correct  module
       dependencies  will  be  available immediately after booting the system.

As we read in the depmod man page (a different man page):

       -m        This  overrides  any  possible  configuration file setting of
                 make_map_files and forces the generation of legacy map files,
                 such as modules.pcimap.

modules.pcimap file is used then by lspci. As we read in its man page:

       -p 
              Use  as the map of PCI ID's handled by kernel modules.  By
              default,  lspci uses /lib/modules/kernel_version/modules.pcimap.
              Applies only to Linux systems with recent enough module tools.

The following figure shows the results of searching the modules.pcimap file of our system for 3582:

The output is formatted in the following patter:

# pci module vendor device subvendor subdevice class class_mask driver_data

We notice that the i915 module has a vendor id 0x8086 and also a device id 0x3582.

As we recall from section 4.2.4 0x3582 represents the device id of the video card and 0x8086 represents the vendor id of Intel. The next figure shows the output of lspci -x as we saw it in section 4.2.4:

Since for Linux lspci searches modules.pcimap and in our case it found the same vendor id and device id it included in the output the module i915, which is the one that appears in the modules.pcimap.