Haswell GPU Support for stable/10

[kami]

Summary

This diff is a port of the Haswell GPU support:
https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8

It is based on the work of Masachika ISHIZUKA who ported the state of the i915/drm2 support as of r297231 to FreeBSD 10.3:
http://www17.plala.or.jp/ish-org/i915-patch-r297231-for-10.x.tar.xz

This differential the result of applying the patch to stable/10 (svn patch was actually able to apply it cleanly with a bit of fiddling).

My positive test results are:

• glxinfo confirms direct rendering
• Opengl1 acceleration works (tested using ioquake3-devel)
• Opengl2 acceleration works (tested using ioquake3-devel)
• xrandr detects all outputs
• xrandr detects screen sizes
• xrandr --output FOO --auto does the right thing
• Performance is amazing, after all those years with vesa/scfb

Inconveniences:

• HDMI1 comes up with a Full-HD 50Hz interlaced mode, even though Full-HD progressive is the default mode as reported by xrandr and selected by xrandr --output HDMI1 --auto
• xdpyinfo reports 96 DPI (everything is really, really, *REALLY* tiny), even though the screen size is detected correctly

Workarounds in the Xorg configuration:

• Set Option "PreferredMode" "1920x1080" for the HDMI1 monitor section
• Set DisplaySize for eDP1 (internal screen of the laptop), I use the values that are detected automatically

For reference, here is my /usr/local/etc/X11/xorg.conf.d/video.conf:

Section "Device"
        Identifier "video0"
        Option "XvMC"           "true"
        Option "Monitor-eDP1"   "monitor_eDP1"
        Option "Monitor-HDMI1"  "monitor_HDMI1"
EndSection

Section "Monitor"
        Identifier  "monitor_eDP1"
        DisplaySize 309 173         # In mm, used to calculate DPI
EndSection

Section "Monitor"
        Identifier "monitor_HDMI1"
        Option     "PreferredMode" "1920x1080"
EndSection

Test Plan

Just don't load the module in /boot/loader.conf, it causes the kernel to halt during boot. Loading in rc.conf using kld_list reportedly works fine.

[kami]

After some discussion on IRC, due to there being no current plans for a 10.4 release, the consent is that it would be more beneficial for 10.x users to have a solution in the ports tree.

Work on this is pending.

[kami]

Seeing that there is still plenty of activity in stable/10, I think it's a good idea to MFC this after all.

Making a port on the other hand is bound to be painful, especially with the need to load a changed AGP module and making the kernel use it instead of its own.

[kami]

Obsolete due to 11.0 release.