README
1
2This is the "graphics/DRM" gate, in which we build the
3DRM kernel modules and related DRM libraries.
4
5
6Introduction:
7
8DRM stands for Direct Rendering Manager, which is a collection of
9kernel modules and libraries that allow programs like the Xorg
10server to operate hardware-accelerated graphics cards. This
11software currently supports Intel (R) integrated graphics devices
12with hardware acceleration, video memory management, Graphics
13Execution Manager (GEM), and kernel modesetting (KMS).
14
15
16How to build:
17
18Clone this repo. onto an OpenIndiana or similar build system
19with the "build-essential" packages installed, then:
20 cd (top of clone)
21 make install
22 make package
23
24
25Overview:
26
27The major kernel components are:
28
29 usr/src/uts/intel/io/i915 i915 driver
30 usr/src/uts/common/io/drm/ DRM "misc" support
31 usr/src/uts/intel/io/agpmaster AGP master support
32 usr/src/uts/intel/io/agpgart AGP GART, AGP target
33
34 Dependendencies:
35 i915 -> drm
36 drm -> agpmaster, gfx_private
37
38The user-level libraries are:
39
40 usr/src/lib/libdrm/ DRM driver
41 usr/src/lib/libdrm_* H/W-specific DRM support
42 usr/src/lib/libkms Kernel Mode Setting support
43
44Note that the source for those libraries is EXTERNAL, and
45NOT checked into this gate. At build time, the library
46sources are downloaded from:
47 http://dri.freedesktop.org/libdrm/
48and then unpacked and patched under:
49 usr/src/common/libdrm/
50
51That makes this gate a little unusual, sort of a "hybrid"
52between how illumos-gate does things and how the "userland"
53gate does things. There are good reasons for this.
54
55The kernel code is very much operaging-system-specific,
56and therefore can not simply track some "upstream" like
57the user-level library code can. It's also a little
58tricky to build kernel code "correctly", which is why
59the kernel build parts of this gate are based on the
60"ON skeleton" gate: https://github.com/gwr/on-skel
61
62The user-level libraries here are built with minimal
63changes relatative to the upstream, and therefore can
64use a strategy similar to that in the "userland" gate:
65 https://github.com/OpenIndiana/oi-userland
66
67
68Development and testing:
69
70If you find you need to make changes to library code
71(such as when updating to a new version) the easiest
72way is to save a copy of the unpacked library source
73before patching (use "make unpack"), then go ahead
74and edit files as needed, and once you're happy with
75the changes use "diff -u saved-lib edited-lib" to
76update the files in the patches directory. Use:
77 usr/src/common/libdrm/Check-patches
78to check that your patches are in sync with edits.
79
80When doing incremental work in the gate, i.e. fixing
81compilation errors, it's handy to run an editor in a
82"bldenv" environment, as follows:
83 ksh93 tools/bldenv -d myenv.sh
84
85That gets you a new shell, in which you can run an
86emacs if you like "meta-x compile", or whatever.
87Just cd to where the top-level make had problems
88and run make. Then fix bugs, open pull requests.
89
90Please run the tests before submitting pull requests.
91They're installed as /opt/drm-test/*
92