structpci_dev { structpci_dev *next;/* Next device in the chain */ u16 domain_16; /* 16-bit version of the PCI domain for backward compatibility */ /* 0xffff if the real domain doesn't fit in 16 bits */ u8 bus, dev, func; /* Bus inside domain, device and function */
/* These fields are set by pci_fill_info() */ unsignedint known_fields; /* Set of info fields already known (see pci_fill_info()) */ u16 vendor_id, device_id; /* Identity of the device */ u16 device_class; /* PCI device class */ int irq; /* IRQ number */ pciaddr_t base_addr[6]; /* Base addresses including flags in lower bits */ pciaddr_t size[6]; /* Region sizes */ pciaddr_t rom_base_addr; /* Expansion ROM base address */ pciaddr_t rom_size; /* Expansion ROM size */ structpci_cap *first_cap;/* List of capabilities */ char *phy_slot; /* Physical slot */ char *module_alias; /* Linux kernel module alias */ char *label; /* Device name as exported by BIOS */ int numa_node; /* NUMA node */ pciaddr_t flags[6]; /* PCI_IORESOURCE_* flags for regions */ pciaddr_t rom_flags; /* PCI_IORESOURCE_* flags for expansion ROM */ int domain; /* PCI domain (host bridge) */ pciaddr_t bridge_base_addr[4]; /* Bridge base addresses (without flags) */ pciaddr_t bridge_size[4]; /* Bridge sizes */ pciaddr_t bridge_flags[4]; /* PCI_IORESOURCE_* flags for bridge addresses */ u8 prog_if, rev_id; /* Programming interface for device_class and revision id */ u16 subsys_vendor_id, subsys_id; /* Subsystem vendor id and subsystem id */ structpci_dev *parent;/* Parent device, does not have to be always accessible */ int no_config_access; /* No access to config space for this device */
/* Fields used internally */ structpci_access *access; structpci_methods *methods; u8 *cache; /* Cached config registers */ int cache_len; int hdrtype; /* Cached low 7 bits of header type, -1 if unknown */ void *aux; /* Auxiliary data for use by the back-end */ structpci_property *properties;/* A linked list of extra properties */ structpci_cap *last_cap;/* Last capability in the list */ };
FourCC format code是Linux内核DRM子系统用来描述framebuffer像素格式。它们被定义在内核源码include/uapi/drm/drm_fourcc.h. 基本上FourCC format code足以描述framebuffer中像素的内容了,但是随着GPU的更新,原来线性排列的buffers,为了获取更好的性能,可能会采取vendor specific的布局方式。另外,这些buffer也可能保存的是各种不同的压缩数据,这样一来,原来的FourCC format code就无法携带新的buffer
layout或compression format的信息,DRM format modifier就是用来解决这些问题的。
Given that a difficulty to add a custom X11 device driver or module or extension for Xserver, I try to find out how an Xserver is built and its dependent drivers and modules and extensions are orgnized together by building it from source.
The data for a XYPixmap is organized as a set of bitmaps representing individual bit planes, with the planes appearing from MSB to LSB in bit order just as demonstrated below. Every pixel value is 0x55 (b’01010101) in this example.