Need help untangling Xorg behavior on Haswell board, KMS, etc. etc.

Tue Jul 23 11:00:52 UTC 2013

Hi!

I'll try to answer all your questions below, as well as try to answer
things from your follow-up mail.  Hopefully no confusion will arise.

On 2013-07-19 21:42, John Reynolds wrote:
> Hello all, I recently put together a new box with very new hardware--an
> ASRock Z87 "haswell" board with i-4770k proc. I've successfully
> installed 9.2-PRERELEASE (amd64) on it with the help of some folks on
> -stable, but am having a heck of a time trying to get Xorg working. I've
> used FreeBSD for years and years but have always used Nvidia cards and
> their config tool always just barfed out an xorg.conf file that worked
> no fuss no muss. I'm trying like crazy to get this integrated GPU to work.

When buying/building computers based on new hardware, remember that it
might take a little while before support for it shows up in FreeBSD.  In
general most things work out of the box, but sometimes that is not the
case.  I am not sure the Haswell GPU is supported by our graphics stack yet.
> 
> I did some research and found out that I needed WITH_NEW_XORG=1 in
> /etc/make.conf and I've got that all compiled now with a ports tree
> freshly updated via portsnap. I have xorg 7.7 port and all of things it
> pulls in including version 2.21.9 of the xf86-video-intel port.

Yes, WITH_NEW_XORG= is needed to get modern intel graphics hardware to
work with X.  We are working on making this the default, but there are
some things left to iron out.  This versio

> 
> Could some kind soul out there give me some pointers on what the
> "preferred" method for setting up X should be at this point using the
> "new" Xorg and this very new H/W?
> 
> If I do what the handbook and other tutorials say to do and run
> 
>    Xorg -configure
> 
> that creates me a file that defines two screens/monitors, etc. That's
> great and all, but I don't use a dual-head setup. yes, I can hack the
> file and take out the other monitor stuff. But my buddy who lives in the
> Linux world asked me "why are you creating a xorg.conf file? I haven't
> used one in YEARS. You don't hardly need one for 'modern' hardware where
> everything is probable and works nicely with each other." So that got me
> to wondering "yeah, why am i creating it?"

In general, running without a xorg.conf should work, but there are a lot
of different hardware and setups out there, and just because it works on
Linux does not mean it works on FreeBSD without xorg.conf.  If you want
to have more control of exactly what's going on, a config is probably to
prefer.
If you use xorg without HAL, you must have a config at least detailing
your input devices for them to work properly.  The same probably goes
for dual-head setups.  Remember that graphics cards today have more than
one output, and this maybe confuse X as well.
> 
> So, in the expert opinion of people working actively with Xorg on this
> list, what should "most people" do (most people buying 'modern' hardware
> these days and not using CRT monitors from the 1980's anymore :)? I have
> fired up "xinit" (using just a simplistic .xinitrc and a tmp non-root
> user for testing) with the setup file created from above AND without any
> setup file at all. Both seem to work. xdpyinfo shows that the resolution
> is 1920x1200 which I want by default, color depth seems fine, etc. What
> is the "preferred" setup style?
> 
> Now onto the problems / questions: No matter what I do whether firing up
> with the xorg.conf file or without anything, if I exit the window
> manager and expect to come back to the console it doesn't do it. It just
> locks the machine HARD. I searched quite a bit about this and on this
> list's archives (here
> <http://lists.freebsd.org/pipermail/freebsd-x11/2013-July/013446.html>)
> I see some mention that something called KMS is now being used in the
> Intel driver/Xorg and that something doesn't react well with our newcons
> console driver. What exactly is KMS and why is it important? Also if I
> look at my Xorg.0.log file as it's firing up I get tons of messages
> about dri devices not being found, etc.

KMS, or Kernel Mode Setting, is the "new" way of handling graphics in X.
 basically a lot of stuff regarding the graphics card was previously
done in userland, however this makes it hard to get working graphics
acceleration and stuff, so a lot of this has moved into the kernel,
which means new kernel drivers are needed.  An Intel KMS driver was
ported by kib@ and comitted a little over a year ago.  Currently an
ATI/AMD KMS driver is under development, however it will take some time
before it is done.   Without these drivers, we loose support for a lot
of modern hardware, which is part of the reason we have two xorg
distributions today.
This new KMS driver isn't without some issues though.  Currently, when
you enable it by loading the kld (which is done when starting X) the VT
console no longer works, since it doesn't understand and support KMS.
This is one of the reasons that the new xorg distribution isn't the
default.  Once newcons is finished and pushed into the FreeBSD source
tree, the console should work with KMS.  This might be what you perceive
as a lockup.  Generally, it is possible to shut down the computer either
from a xterm (or other terminal emulator) or using the powerbutton once
out of X.  However, there might be issues between the new graphics card
and FreeBSD that makes it hang.
> 
> [    41.710] drmOpenDevice: node name is /dev/dri/card0
> [    41.710] Failed to change owner or group for file /dev/dri! 2: No
> such file or directory
> [    41.710] Failed to change owner or group for file /dev/dri/card0! 2:
> No such file or directory
> [    41.710] drmOpenDevice: open result is -1, (No such file or directory)
> [    41.710] Failed to change owner or group for file /dev/dri/card0! 2:
> No such file or directory
> [    41.710] drmOpenDevice: open result is -1, (No such file or directory)
> [    41.710] drmOpenDevice: Open failed
> [    41.710] drmOpenByBusid: Searching for BusID pci:0000:00:02.0

This is probably normal, it is looking for the graphics card device, but
can't find it.  Either the kernel module didn't attached to the graphics
card, or it just shows up as a different device.  What does dmesg and
kldstat say once you've started X?
> 
> Is there something that must be done in a custom kernel or something to
> remedy this? I have dri-8.0.5_3,2 installed and right now I am just
> running the GENERIC kernel from the install.

A custom kernel should not be needed.

[ Snipped from another mail in the thread]

> Yes, upon further inspection, what I thought was "success" I think
> fall-back to using VESA. In my Xorg.0.log:
>
> [ 17861.411] (II) intel: Driver for Intel Integrated Graphics Chipsets:
> i810,
>         i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
915G,
>         E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
>           ....
>         Haswell CRW Server (GT1), Haswell CRW Server (GT2),
>         Iris(TM) Pro Graphics 5200, Haswell CRW (GT1), Haswell CRW (GT2),
>         Iris(TM) Pro Graphics 5200, Haswell CRW (GT1), Haswell CRW (GT2),
>         Iris(TM) Pro Graphics 5200, ValleyView PO board
>
> So it did load the driver and at least print this out, but later on in
> the file after a bunch of:
>
> [ 17861.959] drmOpenDevice: node name is /dev/dri/card0
> [ 17861.959] Failed to change owner or group for file /dev/dri! 2: No
> such file or directory
> [ 17861.959] Failed to change owner or group for file /dev/dri/card0! 2:
> No such file or directory
> [ 17861.959] drmOpenDevice: open result is -1, (No such file or directory)
> [ 17861.959] Failed to change owner or group for file /dev/dri/card0! 2:
> No such file or directory
> [ 17861.959] drmOpenDevice: open result is -1, (No such file or directory)
> [ 17861.959] drmOpenDevice: Open failed
> [ 17861.959] drmOpenByBusid: Searching for BusID pci:0000:00:02.0
> [ 17861.959] drmOpenDevice: node name is /dev/dri/card0
>
> I see
>
> [ 17861.961] (II) VESA(0): initializing int10
> [ 17861.962] (II) VESA(0): Primary V_BIOS segment is: 0xc000
> [ 17861.964] (II) VESA(0): VESA BIOS detected
> [ 17861.964] (II) VESA(0): VESA VBE Version 3.0
> [ 17861.964] (II) VESA(0): VESA VBE Total Mem: 262080 kB
> [ 17861.964] (II) VESA(0): VESA VBE OEM: Intel(R) HSW Mobile/Desktop
> Graphics Chipset Accelerated VGA BIOS
> [ 17861.964] (II) VESA(0): VESA VBE OEM Software Rev: 0.0
> [ 17862.017] (==) VESA(0): Depth 24, (--) framebuffer bpp 32
> [ 17862.017] (==) VESA(0): RGB weight 888
> [ 17862.017] (==) VESA(0): Default visual is TrueColor
> [ 17862.017] (==) VESA(0): Using gamma correction (1.0, 1.0, 1.0)
> [ 17862.017] (II) Loading sub module "ddc"
> [ 17862.017] (II) LoadModule: "ddc"
> [ 17862.017] (II) Module "ddc" already built-in
> [ 17862.017] (II) VESA(0): VESA VBE DDC supported
> [ 17862.017] (II) VESA(0): VESA VBE DDC Level 2
> [ 17862.017] (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec.
> [ 17862.029] (II) VESA(0): VESA VBE DDC read successfully
> ....
>
> I don't know if this was simply a fall-back or if my xorg.conf file is
> telling it to use vesa. As I was saying, I used the file generated by
> Xorg -configure and it set things up for two monitors and it has two
> "Device" sections, one that uses the "intel" driver and one that uses
> "vesa." I have not tried using no configuration file just yet.

Looking at this log, it seems that it first loads the intel driver, but
since that doesn't work, it falls back to using the VESA driver.  You
can try to force the use of the intel driver in xorg.conf, however, this
might render your X unusable.  I suggest you post your dmesg and kldstat
after you've started X, to see if the intel kms kernel module is loaded
and attached to the graphics card.  It might very well be that the
current kernel driver doesn't support haswell.  Have you tried CURRENT
as well?
>
> So, are there developers with the Haswell boards and it's just a matter
> of time before kinks get worked out? Do you suggest using no xorg.conf
> file?
>
> Also, as reported once I go into X via 'startx' on a console there's no
> coming back out. If I try it is a hard wedge. I know that's being
> currently worked on. If there's any kernel module or kernel config
> option or something that I need to have in order to even remotely have a
> chance at making this GPU work, please let me know. As of this moment
> I'm just running GENERIC/amd64, but I plan on recompiling things going
> forward.
>

It does not hard wedge, however, the console doesn't work after loading
the KMS drivers, as stated above.
Regards!
-- 
Niclas