[gentoo-amd64] video driver / system state question

[gentoo-amd64] video driver / system state question

[Mark Knecht]

Hi,
   I've been working on trying to get this new machine to run X. So
far no luck but I'm learning so it's interesting.

   My quick question goes like this - if I boot with no drivers I get
a VGA console. If I modprobe a frame buffer driver at boot time then I
get a nice looking but slow frame buffer console. All good so far.
However my graphics adapter is supposed to use the i915 driver and
when I modprobe that - either in auto-load or at the command like
after logging in - my screen goes 'black'. I'm wondering what I do -
other than look at what's in dmesg - to figure out what state the
machine is in. Is the screen turned off? Is the driver running and
putting out 'black'?

   What do I look at to understand what the driver is doing and what
the system thinks is the state of the screen before I start X?

   It turns out there are flags you can turn on to debug drm that show
me the system is finding my monitors and lots of mode line info, but
then the screen is black so it seems like somethings not right. Are
there any tools to query this sort of situation?

Thanks,
Mark

Re: [gentoo-amd64] video driver / system state question

[Bob Sanders]

Mark Knecht, mused, then expounded:
> far no luck but I'm learning so it's interesting.
> 
>    My quick question goes like this - if I boot with no drivers I get
> a VGA console. If I modprobe a frame buffer driver at boot time then I
> get a nice looking but slow frame buffer console. All good so far.
> However my graphics adapter is supposed to use the i915 driver and
> when I modprobe that - either in auto-load or at the command like
> after logging in - my screen goes 'black'. I'm wondering what I do -
> other than look at what's in dmesg - to figure out what state the
> machine is in. Is the screen turned off? Is the driver running and
> putting out 'black'?
>

The "black" is the monitor being driven beyond it's spec in either
vertical or horitizontal or both.

For it to work, you'll need a proper mode line that can be stolen from
some other Linux system  via a google search or by downloading puppy
linux and using that to work out what X is doing.

With X and gfx, /var/log/Xorg.0.log is your friend.  Especially when
used with a google search on the error message.

Bob 
-  

Re: [gentoo-amd64] video driver / system state question

[Drake Donahue]

On Mon, 2010-01-25 at 16:09 -0800, Bob Sanders wrote:
> Mark Knecht, mused, then expounded:
> > far no luck but I'm learning so it's interesting.
> > 
> >    My quick question goes like this - if I boot with no drivers I get
> > a VGA console. If I modprobe a frame buffer driver at boot time then I
> > get a nice looking but slow frame buffer console. All good so far.
> > However my graphics adapter is supposed to use the i915 driver and
> > when I modprobe that - either in auto-load or at the command like
> > after logging in - my screen goes 'black'. I'm wondering what I do -
> > other than look at what's in dmesg - to figure out what state the
> > machine is in. Is the screen turned off? Is the driver running and
> > putting out 'black'?
> >
> 
> The "black" is the monitor being driven beyond it's spec in either
> vertical or horitizontal or both.
> 
> For it to work, you'll need a proper mode line that can be stolen from
> some other Linux system  via a google search or by downloading puppy
> linux and using that to work out what X is doing.
> 
> With X and gfx, /var/log/Xorg.0.log is your friend.  Especially when
> used with a google search on the error message.
> 
> Bob 
> -  
> 
> 
have you emerged a window manager/desktop? twm and xterm are no longer
provided with the server.

Re: [gentoo-amd64] video driver / system state question

[Mark Knecht]

On Mon, Jan 25, 2010 at 4:23 PM, Drake Donahue <donahue95@comcast.net> wrote:
> On Mon, 2010-01-25 at 16:09 -0800, Bob Sanders wrote:
>> Mark Knecht, mused, then expounded:
>> > far no luck but I'm learning so it's interesting.
>> >
>> >    My quick question goes like this - if I boot with no drivers I get
>> > a VGA console. If I modprobe a frame buffer driver at boot time then I
>> > get a nice looking but slow frame buffer console. All good so far.
>> > However my graphics adapter is supposed to use the i915 driver and
>> > when I modprobe that - either in auto-load or at the command like
>> > after logging in - my screen goes 'black'. I'm wondering what I do -
>> > other than look at what's in dmesg - to figure out what state the
>> > machine is in. Is the screen turned off? Is the driver running and
>> > putting out 'black'?
>> >
>>
>> The "black" is the monitor being driven beyond it's spec in either
>> vertical or horitizontal or both.
>>
>> For it to work, you'll need a proper mode line that can be stolen from
>> some other Linux system  via a google search or by downloading puppy
>> linux and using that to work out what X is doing.
>>
>> With X and gfx, /var/log/Xorg.0.log is your friend.  Especially when
>> used with a google search on the error message.
>>
>> Bob
>> -
>>
>>
> have you emerged a window manager/desktop? twm and xterm are no longer
> provided with the server.
>

No - I haven't since I cannot even startx and see anything.

- Mark

Re: [gentoo-amd64] video driver / system state question

[Drake Donahue]

On Mon, 2010-01-25 at 19:09 -0800, Mark Knecht wrote:
> On Mon, Jan 25, 2010 at 4:23 PM, Drake Donahue <donahue95@comcast.net> wrote:
> > On Mon, 2010-01-25 at 16:09 -0800, Bob Sanders wrote:
> >> Mark Knecht, mused, then expounded:
> >> > far no luck but I'm learning so it's interesting.
> >> >
> >> >    My quick question goes like this - if I boot with no drivers I get
> >> > a VGA console. If I modprobe a frame buffer driver at boot time then I
> >> > get a nice looking but slow frame buffer console. All good so far.
> >> > However my graphics adapter is supposed to use the i915 driver and
> >> > when I modprobe that - either in auto-load or at the command like
> >> > after logging in - my screen goes 'black'. I'm wondering what I do -
> >> > other than look at what's in dmesg - to figure out what state the
> >> > machine is in. Is the screen turned off? Is the driver running and
> >> > putting out 'black'?
> >> >
> >>
> >> The "black" is the monitor being driven beyond it's spec in either
> >> vertical or horitizontal or both.
> >>
> >> For it to work, you'll need a proper mode line that can be stolen from
> >> some other Linux system  via a google search or by downloading puppy
> >> linux and using that to work out what X is doing.
> >>
> >> With X and gfx, /var/log/Xorg.0.log is your friend.  Especially when
> >> used with a google search on the error message.
> >>
> >> Bob
> >> -
> >>
> >>
> > have you emerged a window manager/desktop? twm and xterm are no longer
> > provided with the server.
> >
> 
> No - I haven't since I cannot even startx and see anything.
> 
> - Mark
> 
I believe the black screen is in fact a running xserver that has no
display manager no window manager no desktop and thus nothing to
display. Recommend you emerge your favorites.
Alternate run:
X -retro to start xserver that will show the old black/white stipple and
a mouse cursor.
Note: you will have to do a power off to get out of X.

Re: [gentoo-amd64] video driver / system state question

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

On 01/26/2010 12:05 AM, Drake Donahue wrote:
> Alternate run:
> X -retro to start xserver that will show the old black/white stipple and
> a mouse cursor.
> Note: you will have to do a power off to get out of X.
>

If this actually works, you should be able to use ctrl-alt-F1 or 
whatever to get back to your virtual console and kill your server.  Or, 
if you configure your xorg.conf appropriately you can do a 
ctrl-alt-backspace.  (For some reason that I can't fathom they decided 
to disable this by default.)


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3670 bytes --]

Re: [gentoo-amd64] video driver / system state question

[Richard Freeman]

On 01/26/2010 12:05 AM, Drake Donahue wrote:
> Alternate run:
> X -retro to start xserver that will show the old black/white stipple and
> a mouse cursor.
> Note: you will have to do a power off to get out of X.
>

If this actually works, you should be able to use ctrl-alt-F1 or 
whatever to get back to your virtual console and kill your server.  Or, 
if you configure your xorg.conf appropriately you can do a 
ctrl-alt-backspace.  (For some reason that I can't fathom they decided 
to disable this by default.)

[gentoo-amd64] Re: video driver / system state question

[Nikos Chantziaras]

On 01/26/2010 01:20 AM, Mark Knecht wrote:
> Hi,
>     I've been working on trying to get this new machine to run X. So
> far no luck but I'm learning so it's interesting.
>
>     My quick question goes like this - if I boot with no drivers I get
> a VGA console. If I modprobe a frame buffer driver at boot time then I
> get a nice looking but slow frame buffer console. All good so far.
> However my graphics adapter is supposed to use the i915 driver and
> when I modprobe that - either in auto-load or at the command like
> after logging in - my screen goes 'black'. I'm wondering what I do -
> other than look at what's in dmesg - to figure out what state the
> machine is in. Is the screen turned off? Is the driver running and
> putting out 'black'?

I might be wrong, but it sounds like the driver tries to use KMS (kernel 
mode setting) which conflicts with other framebuffer drivers (KMS 
provides a fast framebuffer console on its own).

So two things to try here:

A. Completely disable the vesafb driver.
B. Disable KMS in the i915 driver:
    . When built as a module, use the "modeset=0" parameter
    . When built in the kernel, use "i915.modeset=0" in Grub

Of course this assumes that KMS is indeed the problem.

Re: [gentoo-amd64] Re: video driver / system state question

[Mark Knecht]

On Mon, Jan 25, 2010 at 4:10 PM, Nikos Chantziaras <realnc@arcor.de> wrote:
> On 01/26/2010 01:20 AM, Mark Knecht wrote:
>>
>> Hi,
>>    I've been working on trying to get this new machine to run X. So
>> far no luck but I'm learning so it's interesting.
>>
>>    My quick question goes like this - if I boot with no drivers I get
>> a VGA console. If I modprobe a frame buffer driver at boot time then I
>> get a nice looking but slow frame buffer console. All good so far.
>> However my graphics adapter is supposed to use the i915 driver and
>> when I modprobe that - either in auto-load or at the command like
>> after logging in - my screen goes 'black'. I'm wondering what I do -
>> other than look at what's in dmesg - to figure out what state the
>> machine is in. Is the screen turned off? Is the driver running and
>> putting out 'black'?
>
> I might be wrong, but it sounds like the driver tries to use KMS (kernel
> mode setting) which conflicts with other framebuffer drivers (KMS provides a
> fast framebuffer console on its own).
>
> So two things to try here:
>
> A. Completely disable the vesafb driver.
> B. Disable KMS in the i915 driver:
>   . When built as a module, use the "modeset=0" parameter
>   . When built in the kernel, use "i915.modeset=0" in Grub
>
> Of course this assumes that KMS is indeed the problem.

First - answering Bob -  I don't *think* the monitor is being driven
beyond spec because at least in the past when I did that the monitor
pops up a display that says the input is out of spec. Still, I'll keep
it in mind.

OK, so for A I think the frame buffer is turned off, but if there
something more I need to do let me know. IIRC the few that are modular
are GPL stuff being selected by either the Intel DRM or i915 driver,
but I'll double check.

firefly linux # cat .config | grep FRAMEBUFFER
# CONFIG_FRAMEBUFFER_CONSOLE is not set
firefly linux # cat .config | grep FB
CONFIG_FB=m
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
firefly linux # cat .config | grep VESAFB
firefly linux # cat .config | grep VESA
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
firefly linux #

As for B, it's modular overall but already turned off for the i915:


firefly linux # cat .config | grep KMS
CONFIG_DRM_KMS_HELPER=m
# CONFIG_DRM_I915_KMS is not set
firefly linux #

Is there an app that can query what resolution and frequency the
system thinks it's driving the monitor?

Again, this isn't X - it's just the driver getting loaded.

None the less I have LOTS of data from running drm.debug=0x06. If
there's a way to use it more intelligently I'd love to learn.

I'll go back and check whether this was with frame buffer turned on.
See the very last couple of lines as to why. But mostly the modeline
suff is interesting as I think those really are the two monitors that
are attached. I've got a 17" 1280x1024 on the VGA port and a 1680x1050
on the digital port. I'm not using HDMI is the part that concerns me
unless the HDMI and the new, rectangular digital VGA are really one in
the same. Anyway, there's lots of data there, and as I said earlier, I
can run console mode frame buffer which may be where some of this data
came from.


i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 0000:00:02.0: setting latency timer to 64
mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining
[drm] MTRR allocation failed.  Graphics performance may suffer.
[drm] set up 31M of stolen space
[drm:intel_dp_i2c_init], i2c_init DPDDC-C
[drm:intel_dp_i2c_init], i2c_init DPDDC-D
[drm:drm_helper_probe_single_connector_modes], VGA-1
[drm:drm_helper_probe_single_connector_modes], Probed modes for VGA-1
[drm:drm_mode_debug_printmodeline], Modeline 39:"1280x1024" 60 108000
1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5
[drm:drm_mode_debug_printmodeline], Modeline 35:"1280x1024" 75 135000
1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 30:"1152x864" 75 108000
1152 1216 1344 1600 864 865 868 900 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 24:"1024x768" 75 78800
1024 1040 1136 1312 768 769 772 800 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 36:"1024x768" 75 78750
1024 1040 1136 1312 768 769 772 800 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 25:"1024x768" 70 75000
1024 1048 1184 1328 768 771 777 806 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 32:"1024x768" 60 65000
1024 1048 1184 1344 768 771 777 806 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 27:"832x624" 75 57284 832
864 928 1152 624 625 628 667 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 29:"800x600" 72 50000 800
856 976 1040 600 637 643 666 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 37:"800x600" 75 49500 800
816 896 1056 600 601 604 625 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 33:"800x600" 60 40000 800
840 968 1056 600 601 605 628 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 17:"800x600" 56 36000 800
824 896 1024 600 601 603 625 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 38:"640x480" 75 31500 640
656 720 840 480 481 484 500 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 19:"640x480" 73 31500 640
664 704 832 480 489 491 520 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 20:"640x480" 67 30240 640
704 768 864 480 483 486 525 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 21:"640x480" 60 25200 640
656 752 800 480 490 492 525 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 34:"640x480" 60 25175 640
656 752 800 480 489 492 525 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 22:"720x400" 70 28320 720
738 846 900 400 412 414 449 0x40 0x6
[drm:drm_helper_probe_single_connector_modes], HDMI Type A-1
[drm:drm_helper_probe_single_connector_modes], HDMI Type A-1 is disconnected
[drm:drm_helper_probe_single_connector_modes], HDMI Type A-2
usb 1-1: new high speed USB device using ehci_hcd and address 2
[drm:drm_helper_probe_single_connector_modes], Probed modes for HDMI Type A-2
[drm:drm_mode_debug_printmodeline], Modeline 54:"1680x1050" 60 119000
1680 1728 1760 1840 1050 1053 1059 1080 0x48 0x9
[drm:drm_mode_debug_printmodeline], Modeline 50:"1680x1050" 60 146250
1680 1784 1960 2240 1050 1053 1059 1089 0x40 0x6
[drm:drm_mode_debug_printmodeline], Modeline 42:"1280x1024" 75 135000
1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 51:"1280x1024" 60 108000
1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 52:"1280x960" 60 108000
1280 1376 1488 1800 960 961 964 1000 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 53:"1152x864" 75 108000
1152 1216 1344 1600 864 865 868 900 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 43:"1024x768" 75 78800
1024 1040 1136 1312 768 769 772 800 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 44:"1024x768" 70 75000
1024 1048 1184 1328 768 771 777 806 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 45:"1024x768" 60 65000
1024 1048 1184 1344 768 771 777 806 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 46:"832x624" 75 57284 832
864 928 1152 624 625 628 667 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 48:"800x600" 72 50000 800
856 976 1040 600 637 643 666 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 47:"800x600" 75 49500 800
816 896 1056 600 601 604 625 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 18:"800x600" 60 40000 800
840 968 1056 600 601 605 628 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 23:"800x600" 56 36000 800
824 896 1024 600 601 603 625 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 28:"640x480" 73 31500 640
664 704 832 480 489 491 520 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 26:"640x480" 75 31500 640
656 720 840 480 481 484 500 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 31:"640x480" 67 30240 640
704 768 864 480 483 486 525 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 40:"640x480" 60 25200 640
656 752 800 480 490 492 525 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 41:"720x400" 70 28320 720
738 846 900 400 412 414 449 0x40 0x6
[drm:drm_helper_probe_single_connector_modes], DisplayPort-1
[drm:drm_helper_probe_single_connector_modes], DisplayPort-1 is disconnected
[drm:drm_helper_probe_single_connector_modes], DisplayPort-2
[drm:drm_helper_probe_single_connector_modes], DisplayPort-2 is disconnected
[drm:drm_setup_crtcs],
[drm:drm_enable_connectors], connector 5 enabled? yes
[drm:drm_enable_connectors], connector 7 enabled? no
[drm:drm_enable_connectors], connector 9 enabled? yes
[drm:drm_enable_connectors], connector 11 enabled? no
[drm:drm_enable_connectors], connector 13 enabled? no
[drm:drm_target_preferred], looking for cmdline mode on connector 5
[drm:drm_target_preferred], looking for preferred mode on connector 5
[drm:drm_target_preferred], found mode 1280x1024
[drm:drm_target_preferred], looking for cmdline mode on connector 9
[drm:drm_target_preferred], looking for preferred mode on connector 9
[drm:drm_target_preferred], found mode 1680x1050
[drm:drm_setup_crtcs], picking CRTCs for 8192x8192 config
[drm:drm_setup_crtcs], desired mode 1280x1024 set on crtc 3
[drm:drm_setup_crtcs], desired mode 1680x1050 set on crtc 4
fb0: inteldrmfb frame buffer device
registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0


Thanks!

Cheers,
Mark

[gentoo-amd64] Re: video driver / system state question

[Duncan]

Nikos Chantziaras posted on Tue, 26 Jan 2010 02:10:23 +0200 as excerpted:

> On 01/26/2010 01:20 AM, Mark Knecht wrote:
>> Hi,
>>     I've been working on trying to get this new machine to run X. So
>> far no luck

=:^(

>> but I'm learning so it's interesting.

=:^)

>>     My quick question goes like this - if I boot with no drivers I get
>> a VGA console. If I modprobe a frame buffer driver at boot time then I
>> get a nice looking but slow frame buffer console. All good so far.
>> However my graphics adapter is supposed to use the i915 driver and when
>> I modprobe that - either in auto-load or at the command like after
>> logging in - my screen goes 'black'. I'm wondering what I do - other
>> than look at what's in dmesg - to figure out what state the machine is
>> in. Is the screen turned off? Is the driver running and putting out
>> 'black'?
> 
> I might be wrong, but it sounds like the driver tries to use KMS (kernel
> mode setting) which conflicts with other framebuffer drivers (KMS
> provides a fast framebuffer console on its own).

Yes.  See below...

> So two things to try here:
> 
> A. Completely disable the vesafb driver.

> B. Disable KMS in the i915 driver:
>     . When built as a module, use the "modeset=0" parameter . When built
>     in the kernel, use "i915.modeset=0" in Grub
> 
> Of course this assumes that KMS is indeed the problem.

I'm using the Intel X driver on my netbook now, so am beginning to follow 
it, but I don't know as much about it, particularly the xorg.conf settings 
as so far I've been running entirely xorg.conf-less, as I do the radeon 
freedomware driver I use on my desktop.  However...

If I'm remembering what I've been reading correctly, the newest Intel 
drivers are KMS *ONLY* -- they have *NO* non-kms mode.  Of course, the 
kernel vgacon should still work for text mode, but once X starts, you'll 
get, probably, a black screen, unless you're running KMS.  KMS being the 
only choice, you better make sure that's what the kernel is using, no 
vgacon, and no vesafb (thus choice A above).

That said, "newest" is new enough it's probably not yet gentoo-stable, so 
if you're running stable, you can probably use choice B, if desired.  But 
it's probably wise to get KMS working now, since that's soon to be the 
only choice (unless you want to run the unaccelerated X vesa-framebuffer 
driver, IDR the exact name ATM, instead of the intel driver). 

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: video driver / system state question

[Mark Knecht]

On Mon, Jan 25, 2010 at 4:10 PM, Nikos Chantziaras <realnc@arcor.de> wrote:
> On 01/26/2010 01:20 AM, Mark Knecht wrote:
>>
>> Hi,
>>    I've been working on trying to get this new machine to run X. So
>> far no luck but I'm learning so it's interesting.
>>
>>    My quick question goes like this - if I boot with no drivers I get
>> a VGA console. If I modprobe a frame buffer driver at boot time then I
>> get a nice looking but slow frame buffer console. All good so far.
>> However my graphics adapter is supposed to use the i915 driver and
>> when I modprobe that - either in auto-load or at the command like
>> after logging in - my screen goes 'black'. I'm wondering what I do -
>> other than look at what's in dmesg - to figure out what state the
>> machine is in. Is the screen turned off? Is the driver running and
>> putting out 'black'?
>
> I might be wrong, but it sounds like the driver tries to use KMS (kernel
> mode setting) which conflicts with other framebuffer drivers (KMS provides a
> fast framebuffer console on its own).
>
> So two things to try here:
>
<SNIP>
> B. Disable KMS in the i915 driver:
>   . When built as a module, use the "modeset=0" parameter

I rebooted the machine clean to the command line prompt and then typed

modprobe i915 modeset=0

and except for the first 3 lines everything below was created in
dmesg. At this point the screen s black and the light on the front is
blinking like it does when the computer is turned off.

I haven't been able to solve the MTRR thing yet. I've tried a bunch of
different settings but it doesn't change those results.

Is it typical to call the device a 'fb0: inteldrmfb frame buffer
device'? I assume that's not the i915 but rather the drm?

- Mark

e100: eth0 NIC Link is Up 10 Mbps Half Duplex
NET: Registered protocol family 10
eth0: no IPv6 routers present
[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 0000:00:02.0: setting latency timer to 64
mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining
[drm] MTRR allocation failed.  Graphics performance may suffer.
[drm] set up 31M of stolen space
[drm:intel_dp_i2c_init], i2c_init DPDDC-C
[drm:intel_dp_i2c_init], i2c_init DPDDC-D
[drm:drm_helper_probe_single_connector_modes], VGA-1
[drm:drm_helper_probe_single_connector_modes], Probed modes for VGA-1
[drm:drm_mode_debug_printmodeline], Modeline 39:"1280x1024" 60 108000
1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5
[drm:drm_mode_debug_printmodeline], Modeline 35:"1280x1024" 75 135000
1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 30:"1152x864" 75 108000
1152 1216 1344 1600 864 865 868 900 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 24:"1024x768" 75 78800
1024 1040 1136 1312 768 769 772 800 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 36:"1024x768" 75 78750
1024 1040 1136 1312 768 769 772 800 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 25:"1024x768" 70 75000
1024 1048 1184 1328 768 771 777 806 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 32:"1024x768" 60 65000
1024 1048 1184 1344 768 771 777 806 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 27:"832x624" 75 57284 832
864 928 1152 624 625 628 667 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 29:"800x600" 72 50000 800
856 976 1040 600 637 643 666 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 37:"800x600" 75 49500 800
816 896 1056 600 601 604 625 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 33:"800x600" 60 40000 800
840 968 1056 600 601 605 628 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 17:"800x600" 56 36000 800
824 896 1024 600 601 603 625 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 38:"640x480" 75 31500 640
656 720 840 480 481 484 500 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 19:"640x480" 73 31500 640
664 704 832 480 489 491 520 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 20:"640x480" 67 30240 640
704 768 864 480 483 486 525 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 21:"640x480" 60 25200 640
656 752 800 480 490 492 525 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 34:"640x480" 60 25175 640
656 752 800 480 489 492 525 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 22:"720x400" 70 28320 720
738 846 900 400 412 414 449 0x40 0x6
[drm:drm_helper_probe_single_connector_modes], HDMI Type A-1
[drm:drm_helper_probe_single_connector_modes], HDMI Type A-1 is disconnected
[drm:drm_helper_probe_single_connector_modes], HDMI Type A-2
[drm:drm_helper_probe_single_connector_modes], Probed modes for HDMI Type A-2
[drm:drm_mode_debug_printmodeline], Modeline 54:"1680x1050" 60 119000
1680 1728 1760 1840 1050 1053 1059 1080 0x48 0x9
[drm:drm_mode_debug_printmodeline], Modeline 50:"1680x1050" 60 146250
1680 1784 1960 2240 1050 1053 1059 1089 0x40 0x6
[drm:drm_mode_debug_printmodeline], Modeline 42:"1280x1024" 75 135000
1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 51:"1280x1024" 60 108000
1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 52:"1280x960" 60 108000
1280 1376 1488 1800 960 961 964 1000 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 53:"1152x864" 75 108000
1152 1216 1344 1600 864 865 868 900 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 43:"1024x768" 75 78800
1024 1040 1136 1312 768 769 772 800 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 44:"1024x768" 70 75000
1024 1048 1184 1328 768 771 777 806 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 45:"1024x768" 60 65000
1024 1048 1184 1344 768 771 777 806 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 46:"832x624" 75 57284 832
864 928 1152 624 625 628 667 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 48:"800x600" 72 50000 800
856 976 1040 600 637 643 666 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 47:"800x600" 75 49500 800
816 896 1056 600 601 604 625 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 18:"800x600" 60 40000 800
840 968 1056 600 601 605 628 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 23:"800x600" 56 36000 800
824 896 1024 600 601 603 625 0x40 0x5
[drm:drm_mode_debug_printmodeline], Modeline 28:"640x480" 73 31500 640
664 704 832 480 489 491 520 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 26:"640x480" 75 31500 640
656 720 840 480 481 484 500 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 31:"640x480" 67 30240 640
704 768 864 480 483 486 525 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 40:"640x480" 60 25200 640
656 752 800 480 490 492 525 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 41:"720x400" 70 28320 720
738 846 900 400 412 414 449 0x40 0x6
[drm:drm_helper_probe_single_connector_modes], DisplayPort-1
[drm:drm_helper_probe_single_connector_modes], DisplayPort-1 is disconnected
[drm:drm_helper_probe_single_connector_modes], DisplayPort-2
[drm:drm_helper_probe_single_connector_modes], DisplayPort-2 is disconnected
[drm:drm_setup_crtcs],
[drm:drm_enable_connectors], connector 5 enabled? yes
[drm:drm_enable_connectors], connector 7 enabled? no
[drm:drm_enable_connectors], connector 9 enabled? yes
[drm:drm_enable_connectors], connector 11 enabled? no
[drm:drm_enable_connectors], connector 13 enabled? no
[drm:drm_target_preferred], looking for cmdline mode on connector 5
[drm:drm_target_preferred], looking for preferred mode on connector 5
[drm:drm_target_preferred], found mode 1280x1024
[drm:drm_target_preferred], looking for cmdline mode on connector 9
[drm:drm_target_preferred], looking for preferred mode on connector 9
[drm:drm_target_preferred], found mode 1680x1050
[drm:drm_setup_crtcs], picking CRTCs for 8192x8192 config
[drm:drm_setup_crtcs], desired mode 1280x1024 set on crtc 3
[drm:drm_setup_crtcs], desired mode 1680x1050 set on crtc 4
fb0: inteldrmfb frame buffer device
registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
firefly ~ #

Re: [gentoo-amd64] Re: video driver / system state question

[Peter Humphrey]

On Tuesday 26 January 2010 01:13:59 Mark Knecht wrote:

> mtrr: type mismatch for c0000000,10000000 old: write-back new:
> write-combining [drm] MTRR allocation failed.  Graphics performance may
> suffer.

This rings a bell. Your kernel line in grub.conf has something like 
"video=inteldrmfb:mtrr:3,ywrap", no? The 3 is causing the error above, or 
you may have a 4. Google should be able to find you the docs on this. The 
options are write-combining and write-back; if one doesn't work the other 
should.

-- 
Rgds
Peter.

Re: [gentoo-amd64] Re: video driver / system state question

[Mark Knecht]

On Tue, Jan 26, 2010 at 2:59 AM, Peter Humphrey
<peter@humphrey.ukfsn.org> wrote:
> On Tuesday 26 January 2010 01:13:59 Mark Knecht wrote:
>
>> mtrr: type mismatch for c0000000,10000000 old: write-back new:
>> write-combining [drm] MTRR allocation failed.  Graphics performance may
>> suffer.
>
> This rings a bell. Your kernel line in grub.conf has something like
> "video=inteldrmfb:mtrr:3,ywrap", no? The 3 is causing the error above, or
> you may have a 4. Google should be able to find you the docs on this. The
> options are write-combining and write-back; if one doesn't work the other
> should.
>
> --
> Rgds
> Peter.
>
>

Hi all,
   OK - it's working and gentoo-amd64 is the first email recipient
from my new i5-661 running Gentoo Linux and XFCE4. THANKS TO EVERYONE!

   I'll need to document what I did to get it going as well as archive
files so as to protect myself from some sort of infant mortality or
operator error. None the less at least it's up and usable.

   This seems to be one of those cases where I cannot recognize
exactly who had the final answer as there were a lot of things I did
last night to get the machine going, both based on information from
this thread as well as a thread at intel-gfx. Clearly I'm still
learning/confused about the exact technology here so I want to iron
that out over the next few days.

   The main points, subject to me getting schooled on what's really
happening here:

1) The new i5-661 processor and i915 running X are ONLY supported
using KMS so there seem to be two ways to do this:
a) Build the kernel with AGP, DRM and KMS into the kernel, or
b) Build the kernel with AGP, DRM and KMS modular and then use
i915.modeset=1 on the boot command line

I am using b) at this time.

2) Use drm.debug=0x06 to get lots of nice messages from DRM about
what's going on.

3) Configure the kernel to support frame buffers but turn off
everything except these 4, and possibly only the first and last ones:
(grep for "FB" and "FRAMEBUFFER")

CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
CONFIG_FRAMEBUFFER_CONSOLE=y

 The CFB entries are probably not necessary but I haven't figured out
where they are in the kernel yet to turn them off. They do load
modules so they might be required.

4) In make.conf use these lines among others:

CFLAGS="-O2 -march=native -pipe"
USE="hal dts mmx sse sse2 ssse3 sse4 -gnome -kde"
INPUT_DEVICES="evdev"
VIDEO_CARDS="intel fbdev"

to set up for X and get a normal text boot which I think is taking
place in the frame buffer.

5) As root run

Xorg -configure
Xorg -config /root/xorg.conf.new

If things go right I'm to the point where Drake was correct. X is up
but the screen is blank. Copy xorg.conf.new to /etc/X/xorg.conf

X -retro does work. Thanks Drake!

6) emerge xfce4-meta and then as user put "exec startxfce4" in
.xinitrc, and then startx

   Assuming I haven't made any omissions or stupid mistakes that gets
me into xfce4. I don't know if I'm running X over a frame buffer or
using a more native VGA.

   I will of course review this in more depth as I document it for
real but I wanted to say thanks for the answers as they were all
helpful.

Cheers,
Mark

[gentoo-amd64] Re: video driver / system state question

[Nikos Chantziaras]

On 01/26/2010 07:30 PM, Mark Knecht wrote:
> On Tue, Jan 26, 2010 at 2:59 AM, Peter Humphrey
> <peter@humphrey.ukfsn.org>  wrote:
>> On Tuesday 26 January 2010 01:13:59 Mark Knecht wrote:
>>
>>> mtrr: type mismatch for c0000000,10000000 old: write-back new:
>>> write-combining [drm] MTRR allocation failed.  Graphics performance may
>>> suffer.
>>
>> This rings a bell. Your kernel line in grub.conf has something like
>> "video=inteldrmfb:mtrr:3,ywrap", no? The 3 is causing the error above, or
>> you may have a 4. Google should be able to find you the docs on this. The
>> options are write-combining and write-back; if one doesn't work the other
>> should.
>>
>> --
>> Rgds
>> Peter.
>>
>>
>
> Hi all,
>     OK - it's working and gentoo-amd64 is the first email recipient
> from my new i5-661 running Gentoo Linux and XFCE4. THANKS TO EVERYONE!
>
>     I'll need to document what I did to get it going as well as archive
> files so as to protect myself from some sort of infant mortality or
> operator error. None the less at least it's up and usable.
>
>     This seems to be one of those cases where I cannot recognize
> exactly who had the final answer as there were a lot of things I did
> last night to get the machine going, both based on information from
> this thread as well as a thread at intel-gfx. Clearly I'm still
> learning/confused about the exact technology here so I want to iron
> that out over the next few days.
>
>     The main points, subject to me getting schooled on what's really
> happening here:
>
> 1) The new i5-661 processor and i915 running X are ONLY supported
> using KMS so there seem to be two ways to do this:
> a) Build the kernel with AGP, DRM and KMS into the kernel, or
> b) Build the kernel with AGP, DRM and KMS modular and then use
> i915.modeset=1 on the boot command line
>
> I am using b) at this time.
>
> 2) Use drm.debug=0x06 to get lots of nice messages from DRM about
> what's going on.
>
> 3) Configure the kernel to support frame buffers but turn off
> everything except these 4, and possibly only the first and last ones:
> (grep for "FB" and "FRAMEBUFFER")
>
> CONFIG_FB=y
> CONFIG_FB_CFB_FILLRECT=m
> CONFIG_FB_CFB_COPYAREA=m
> CONFIG_FB_CFB_IMAGEBLIT=m
> CONFIG_FRAMEBUFFER_CONSOLE=y
>
>   The CFB entries are probably not necessary but I haven't figured out
> where they are in the kernel yet to turn them off. They do load
> modules so they might be required.
>
> 4) In make.conf use these lines among others:
>
> CFLAGS="-O2 -march=native -pipe"
> USE="hal dts mmx sse sse2 ssse3 sse4 -gnome -kde"
> INPUT_DEVICES="evdev"
> VIDEO_CARDS="intel fbdev"
>
> to set up for X and get a normal text boot which I think is taking
> place in the frame buffer.
>
> 5) As root run
>
> Xorg -configure
> Xorg -config /root/xorg.conf.new
>
> If things go right I'm to the point where Drake was correct. X is up
> but the screen is blank. Copy xorg.conf.new to /etc/X/xorg.conf
>
> X -retro does work. Thanks Drake!
>
> 6) emerge xfce4-meta and then as user put "exec startxfce4" in
> .xinitrc, and then startx
>
>     Assuming I haven't made any omissions or stupid mistakes that gets
> me into xfce4. I don't know if I'm running X over a frame buffer or
> using a more native VGA.

Enable compositing ("effects") in XFCE.  If it works, you're on native.

Re: [gentoo-amd64] Re: video driver / system state question

[Mark Knecht]

On Tue, Jan 26, 2010 at 10:37 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
> On 01/26/2010 07:30 PM, Mark Knecht wrote:
<SNIP>
>>
>>    Assuming I haven't made any omissions or stupid mistakes that gets
>> me into xfce4. I don't know if I'm running X over a frame buffer or
>> using a more native VGA.
>
> Enable compositing ("effects") in XFCE.  If it works, you're on native.
>
>
>

Humm, then I'm thinking maybe I don't, but I'm still looking around
for the right controls in the xfce4 settings editors. glxgears is
failing but I haven't even looked for instructions yet on enabling 3d
so maybe that's expected.

I added this to xorg.conf

Section "Extensions"
	Option "Composite" "Enable"
EndSection

and restarted the server. The xfce website said to select and hover
over the title bar of a window and then roll the mouse. The window
should become more or less transparent. That's the only test I know to
do right now.

Thanks,
Mark

mark@firefly ~/Desktop $ xrandr
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y
axis) 338mm x 270mm
   1280x1024      60.0*+   75.0
   1152x864       75.0
   1024x768       75.1     75.0     70.1     60.0
   832x624        74.6
   800x600        72.2     75.0     60.3     56.2
   640x480        75.0     72.8     66.7     60.0     59.9
   720x400        70.1
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 connected 1280x1024+0+0 (normal left inverted right x axis y
axis) 474mm x 296mm
   1680x1050      59.9 +
   1280x1024      75.0     60.0*
   1280x960       60.0
   1152x864       75.0
   1024x768       75.1     70.1     60.0
   832x624        74.6
   800x600        72.2     75.0     60.3     56.2
   640x480        72.8     75.0     66.7     60.0
   720x400        70.1
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
mark@firefly ~/Desktop $


firefly ~ # glxgears
Unrecognized deviceID 42
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Serial number of failed request:  27
  Current serial number in output stream:  29
firefly ~ # glxinfo
name of display: :0.0
Unrecognized deviceID 42
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Serial number of failed request:  21
  Current serial number in output stream:  24
firefly ~ # emerge -pv xorg-server

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] x11-base/xorg-server-1.6.5-r1  USE="hal ipv6 nptl sdl
xorg -debug -dmx -kdrive -minimal -tslib" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB
firefly ~ # emerge -pv xorg-drivers

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] x11-base/xorg-drivers-1.6  INPUT_DEVICES="evdev
-acecad -aiptek -citron -elographics -fpit -hyperpen -joystick
-keyboard -mouse -mutouch -penmount -synaptics -tslib -virtualbox
-vmmouse -void -wacom" VIDEO_CARDS="fbdev intel vmware -apm -ark -ast
-chips -cirrus -dummy -epson -fglrx (-geode) -glint -i128 (-i740)
(-impact) -mach64 -mga -neomagic (-newport) -nv -nvidia -r128 -radeon
-radeonhd -rendition -s3 -s3virge -savage -siliconmotion -sis -sisusb
(-sunbw2) (-suncg14) (-suncg3) (-suncg6) (-sunffb) (-sunleo) (-suntcx)
-tdfx -tga -trident -tseng -v4l -vesa -via -virtualbox (-voodoo)
(-xgi)" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB
firefly ~ #

Re: [gentoo-amd64] Re: video driver / system state question

[Drake Donahue]

[-- Attachment #1: Type: text/plain, Size: 4982 bytes --]

On Tue, 2010-01-26 at 09:30 -0800, Mark Knecht wrote:
> On Tue, Jan 26, 2010 at 2:59 AM, Peter Humphrey
> <peter@humphrey.ukfsn.org> wrote:
> > On Tuesday 26 January 2010 01:13:59 Mark Knecht wrote:
> >
> >> mtrr: type mismatch for c0000000,10000000 old: write-back new:
> >> write-combining [drm] MTRR allocation failed.  Graphics performance may
> >> suffer.
> >
> > This rings a bell. Your kernel line in grub.conf has something like
> > "video=inteldrmfb:mtrr:3,ywrap", no? The 3 is causing the error above, or
> > you may have a 4. Google should be able to find you the docs on this. The
> > options are write-combining and write-back; if one doesn't work the other
> > should.
> >
> > --
> > Rgds
> > Peter.
> >
> >
> 
> Hi all,
>    OK - it's working and gentoo-amd64 is the first email recipient
> from my new i5-661 running Gentoo Linux and XFCE4. THANKS TO EVERYONE!
> 
>    I'll need to document what I did to get it going as well as archive
> files so as to protect myself from some sort of infant mortality or
> operator error. None the less at least it's up and usable.
> 
>    This seems to be one of those cases where I cannot recognize
> exactly who had the final answer as there were a lot of things I did
> last night to get the machine going, both based on information from
> this thread as well as a thread at intel-gfx. Clearly I'm still
> learning/confused about the exact technology here so I want to iron
> that out over the next few days.
> 
>    The main points, subject to me getting schooled on what's really
> happening here:
> 
> 1) The new i5-661 processor and i915 running X are ONLY supported
> using KMS so there seem to be two ways to do this:
> a) Build the kernel with AGP, DRM and KMS into the kernel, or
> b) Build the kernel with AGP, DRM and KMS modular and then use
> i915.modeset=1 on the boot command line
> 
> I am using b) at this time.
> 
> 2) Use drm.debug=0x06 to get lots of nice messages from DRM about
> what's going on.
> 
> 3) Configure the kernel to support frame buffers but turn off
> everything except these 4, and possibly only the first and last ones:
> (grep for "FB" and "FRAMEBUFFER")
> 
> CONFIG_FB=y
> CONFIG_FB_CFB_FILLRECT=m
> CONFIG_FB_CFB_COPYAREA=m
> CONFIG_FB_CFB_IMAGEBLIT=m
> CONFIG_FRAMEBUFFER_CONSOLE=y
> 
>  The CFB entries are probably not necessary but I haven't figured out
> where they are in the kernel yet to turn them off. They do load
> modules so they might be required.
> 
> 4) In make.conf use these lines among others:
> 
> CFLAGS="-O2 -march=native -pipe"
> USE="hal dts mmx sse sse2 ssse3 sse4 -gnome -kde"
> INPUT_DEVICES="evdev"
> VIDEO_CARDS="intel fbdev"
> 
> to set up for X and get a normal text boot which I think is taking
> place in the frame buffer.
> 
> 5) As root run
> 
> Xorg -configure
> Xorg -config /root/xorg.conf.new
> 
> If things go right I'm to the point where Drake was correct. X is up
> but the screen is blank. Copy xorg.conf.new to /etc/X/xorg.conf
> 
> X -retro does work. Thanks Drake!
> 
> 6) emerge xfce4-meta and then as user put "exec startxfce4" in
> .xinitrc, and then startx
> 
>    Assuming I haven't made any omissions or stupid mistakes that gets
> me into xfce4. I don't know if I'm running X over a frame buffer or
> using a more native VGA.
> 
>    I will of course review this in more depth as I document it for
> real but I wanted to say thanks for the answers as they were all
> helpful.
> 
> Cheers,
> Mark
> 
Attachment to circumvent mail client text wrapping
>Attachment provided to circumvent mail client text wrapping>
If you want <CTRL ALT BACKSPACE> to be able to shutdown X:

If you don't have /etc/hal/fdi/policy/10-keymap.fdi:
run:
'cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/10-keymap.fdi'

open /etc/hal/fdi/policy/10-keymap.fdi and add as the last <merge key:
'<merge key="input.xkb.options"
type="string">grp:alt_shift_toggle,terminate:ctrl_alt_bksp</merge>'

here the modified /etc/hal/fdi/policy/10-keymap.fdi looks like:
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keymap">
      <append key="info.callouts.add"
type="strlist">hal-setup-keymap</append>
    </match>

    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.rules" type="string">base</merge>

      <!-- If we're using Linux, we use evdev by default (falling back
to
           keyboard otherwise). -->
      <merge key="input.xkb.model" type="string">keyboard</merge>
      <match
key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.xkb.model" type="string">evdev</merge>
      </match>

      <merge key="input.xkb.layout" type="string">us</merge>
      <merge key="input.xkb.variant" type="string" />
      <merge key="input.xkb.options"
type="string">terminate:ctrl_alt_bksp</merge>
    </match>
  </device>
</deviceinfo>

[-- Attachment #2: hal ctrl alt backspace --]
[-- Type: text/plain, Size: 1421 bytes --]

If you want <CTRL ALT BACKSPACE> to be able to shutdown X:
If you don't have /etc/hal/fdi/policy/10-keymap.fdi:
run:
'cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/10-keymap.fdi'

open /etc/hal/fdi/policy/10-keymap.fdi and add as the last <merge key:
'<merge key="input.xkb.options" type="string">grp:alt_shift_toggle,terminate:ctrl_alt_bksp</merge>'

here the modified /etc/hal/fdi/policy/10-keymap.fdi looks like:
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keymap">
      <append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
    </match>

    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.rules" type="string">base</merge>

      <!-- If we're using Linux, we use evdev by default (falling back to
           keyboard otherwise). -->
      <merge key="input.xkb.model" type="string">keyboard</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.xkb.model" type="string">evdev</merge>
      </match>

      <merge key="input.xkb.layout" type="string">us</merge>
      <merge key="input.xkb.variant" type="string" />
      <merge key="input.xkb.options" type="string">terminate:ctrl_alt_bksp</merge>
    </match>
  </device>
</deviceinfo>