# 4.3.x DRM_I915_FBDEV ... no framebuffer!!

## khayyam

hello ...

I've not been able to build a (3.x) kernel since 3.13.11 (or thereabouts), I'm now able to build 4.3.4 but am completely unable to get a framebuffer. I've built 4.3.4 27 times this morning, all with various combinations of X86_SYSFB, DRM_I915/DRM_FBDEV_EMULATION, FB_SIMPLE, FB_EFI, enabled, disabled, and what-have-you. Nothing but a blackscreen ... 

Added to that whoever wrote the "help" for X86_SYSFB and FB_SIMPLE needs shooting, I mean, who can tell me what the "new generic system-framebuffer drivers" are? Apparently such a thing exists, and there are various gotchas with regards to "legacy fbdev drivers [...] not be[ing] able to pick up generic system framebuffers if this option [X86_SYSFB] is selected". So, I should "say Y" and am "highly encouraged" to also enable simplefb.

It doesn't matter however, as no matter what combination of the above I try I get nothing on the display. Previously I had DRM_I915, DRM_I915_KMS, DRM_I915_FBDEV enabled (and nothing under framebuffers =>) and got inteldrmfb, with 4.3.4 there doesn't seem to be any means of getting a famebuffer with a similarly enabled .config ... nor with the "new generic system-framebuffer drivers" (which right now I can only assume is ... singularly ... simplefb).

So, what is it you're supposed to enable to get inteldrmfb ... or *any* framebuffer? Is there some magic combination of options I apparently missed? Can anyone make any sense of the X86_SYSFB "help", and explain what "legacy" and "new generic system framebuffers" mean, or what is being explained?

Thanks in advance ... khayLast edited by khayyam on Sat Apr 01, 2017 1:07 pm; edited 2 times in total

----------

## charles17

No explanation, sorry.  But from gentoo-sources-4.4.0-r1 I have the following: *Quote:*   

> $ grep -i 'drm\|fb_' .config | grep '=y\|=m'
> 
> CONFIG_DRM=y
> 
> CONFIG_DRM_MIPI_DSI=y
> ...

 

And framebuffer worksforme.

----------

## NeddySeagoon

khayyam,

Simple framebuffer expects to be able to draw in the framebuffer without doing any set up.

It expects that whatever runs before it comes along has done that.

Now, I have no idea what does the setup, or what chipsets it might apply to.

While that may be an interesting factoid, its probably not helping with your problem.

I have an Intel 945 chip on 4.x and its framebuffer works.  I can pastebin its .config file if that helps, or you can pastebin yours.

----------

## ennui

Are you booting using BIOS or UEFI? Can you see anything relevant in the initial kernel output during boot from dmesg? For example, my simple framebuffer shows up as:

```
[    0.570790] simple-framebuffer simple-framebuffer.0: framebuffer at 0xf9000000, 0x300000 bytes, mapped to 0xffffc90002c00000

[    0.570799] simple-framebuffer simple-framebuffer.0: format=a8r8g8b8, mode=1024x768x32, linelength=4096

[    0.573266] Console: switching to colour frame buffer device 128x48

[    0.576451] simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
```

----------

## khayyam

Thanks to all who've replied so far ... I should probably have emphasised that I think I've tried every possible combination of options, with the 27 builds reflecting that fact. The above post was more a case of my having given up and/or the hope I'd overlooked something ... anyhow:

@charles17 ... those options are exactly as I'd had enabled at the outset, and have since replicated, nothing. As an aside, two pattern searches, I'd generally use the following rather than 'grep | grep' ...

```
% awk '!/(^#|^$)/&&/(DRM|FB_)/' /usr/src/linux/.config
```

@NeddySeagoon ... yes, if you could pastebin your config I can compare ... thanks.

@ennui ... I don't get a framebuffer, so there is nothing to see, and unfortunately I don't have a secondary machine I could use to ssh in and read 'dmesg'. I could probably remedy that fact by getting a loan of a machine but I'm fairly sure the issue isn't simplefb, but that the 'legacy' mechanism no longer works with whatever changes were made in the introduction of X86_SYSFB/SIMPLE_FB. My problem is really the frustration that comes with fact that though experienced, and competent, with building a kernel I simply don't understand the explanation provided, so I can't figure out if the issue is the change itself, or my understanding what I should/shouldn't enable. I'd hoped it might be something I was overlooking ... but having tried everything I can't but come to the conclusion that kernel development is such that if something works its pure luck.

Before anyone suggests a 'git bisect', my last working kernel was 3.13.11 ... I wasn't able to build any other 3.x series since. I'd been waiting for 4.x to be better tested before attempting to build one, and though I can build it I can't get around the above issue ... so, no.

Thanks again & best ... khay

----------

## charles17

khayyam, 

There was a similar problem for me with kernel 3.14.  

I had to connect to a VGA monitor (which could stay power off) to see anything on the laptop's built-in screen.

And, thanks for the awk advise.  I'm not much experienced with sed and awk  :Sad: 

----------

## fpemud

I encountered the same problem. I solved it by selecting DRM_FBDEV_EMULATION.Last edited by fpemud on Fri Jan 29, 2016 2:11 pm; edited 2 times in total

----------

## s4e8

build i915 driver as module, and add it to /etc/modprobe.d/blacklist.conf. Boot new kernel and running "dmesg -n 8; modprobe i915".

----------

## genoobish

I use the same driver, and have the same problem. But my 4.3.3 works, the 4.4.0 is the one that despite thousands of attempts (changing kernel config and recompiling) stiil has no framebuffer.

The drm loads however, so X also loads (I have it autologin).

looking at the dmesg, inteldrmfb says it loads:

```
[    3.938253] fb: switching to inteldrmfb from simple

[    3.938286] Console: switching to colour dummy device 80x25

[    3.938625] [drm] Replacing VGA console driver

[    3.945193] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).

[    3.945196] [drm] Driver supports precise vblank timestamp query.

[    3.945215] [drm] DMAR active, disabling use of stolen memory

[    3.945280] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem

[    3.955379] ath: phy0: Disable PLL PowerSave

[    3.956746] AVX version of gcm_enc/dec engaged.

[    3.956748] AES CTR mode by8 optimization enabled

[    3.960943] ath: phy0: timeout (1000 us) on reg 0x15f18: 0x00000000 & 0x00000007 != 0x00000004

[    3.963651] ath: phy0: ASPM enabled: 0x42

[    3.963655] ath: EEPROM regdomain: 0x60

[    3.963657] ath: EEPROM indicates we should expect a direct regpair map

[    3.963659] ath: Country alpha2 being used: 00

[    3.963661] ath: Regpair used: 0x60

[    3.969104] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)

[    3.973690] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input15

[    3.973765] [drm] Initialized i915 1.6.0 20151010 for 0000:00:02.0 on minor 0

[    3.990673] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'

[    3.990860] ieee80211 phy0: Atheros AR9485 Rev:1 mem=0xffffc90001400000, irq=17

[    4.012009] BTRFS info (device sdb3): disk space caching is enabled

[    4.019277] intel_rapl: Found RAPL domain package

[    4.019281] intel_rapl: Found RAPL domain core

[    4.019282] intel_rapl: Found RAPL domain uncore

[    4.036059] fbcon: inteldrmfb (fb0) is primary device
```

https://bpaste.net/show/5c78ca6e8311

simple framebuffer gives me a screen right before it mounts root. After that, intel takes over and screen goes black.

 :Rolling Eyes: 

----------

## s4e8

My IVB require CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=y since 4.4.0.

 *genoobish wrote:*   

> I use the same driver, and have the same problem. But my 4.3.3 works, the 4.4.0 is the one that despite thousands of attempts (changing kernel config and recompiling) stiil has no framebuffer.
> 
> 

 

----------

## khayyam

 *fpemud wrote:*   

> I encountered the same problem. I solved it by selecting DRM_FBDEV_EMULATION.

 

fpemud ... which I've had enabled/disabled in combination with every possible X86_SYSFB, SIMPLE_FB, EFI_FB permutation.

 *s4e8 wrote:*   

> build i915 driver as module, and add it to /etc/modprobe.d/blacklist.conf. Boot new kernel and running "dmesg -n 8; modprobe i915".

 

s4e8 ... I don't think you understand, I can't get a framebuffer no matter what is sellected/disabled. So, I can't disable i915 and have efifb, or simplefb, provide one ... none of that works.

 *genoobish wrote:*   

> I use the same driver, and have the same problem. But my 4.3.3 works, the 4.4.0 is the one that despite thousands of attempts (changing kernel config and recompiling) stiil has no framebuffer.

 

genoobish ... ahhh ... so this may be something introduced to 4.4 and then backported to 4.3.4, that at least gives me some hope, and narrows down what changelogs I might search. Could you provide a pastebin of your 4.3.3 .config ... thanks.

Again, thanks to all for the comments/suggestions ... khay

ps: @charles17, your welcome, if it isn't clear what that awk is doing then ask, it's fairly simple 'not' the first regex '!/(^#|^$)/' && the next '/(DRM|FB_)/'

----------

## s4e8

You means no efifb? Did you enable the CONFIG_FRAMEBUFFER_CONSOLE

 *khayyam wrote:*   

> s4e8 ... I don't think you understand, I can't get a framebuffer no matter what is sellected/disabled. So, I can't disable i915 and have efifb, or simplefb, provide one ... none of that works.
> 
> 

 

----------

## ennui

 *khayyam wrote:*   

> @ennui ... I don't get a framebuffer, so there is nothing to see, and unfortunately I don't have a secondary machine I could use to ssh in and read 'dmesg'. I could probably remedy that fact by getting a loan of a machine but I'm fairly sure the issue isn't simplefb, but that the 'legacy' mechanism no longer works with whatever changes were made in the introduction of X86_SYSFB/SIMPLE_FB. My problem is really the frustration that comes with fact that though experienced, and competent, with building a kernel I simply don't understand the explanation provided, so I can't figure out if the issue is the change itself, or my understanding what I should/shouldn't enable. I'd hoped it might be something I was overlooking ... but having tried everything I can't but come to the conclusion that kernel development is such that if something works its pure luck.

 

Hey khay,

Perhaps I misunderstood something, but the system is still bootable, right? You just can't get a display. And you have another working kernel that will give you a display, right?

If this is the case, then assuming you're using OpenRC, I suggest modifying /etc/conf.d/dmesglog, setting log_dmesg="YES" and previous_dmesg=yes. Thus you can boot once on your kernel which is not showing the buffer, capturing the dmesg output in /var/log/dmesg, then boot the kernel which is giving you the display and find the dmesg output in /var/log/dmesg.old.

-N

----------

## khayyam

 *ennui wrote:*   

> Perhaps I misunderstood something, but the system is still bootable, right? You just can't get a display. And you have another working kernel that will give you a display, right? If this is the case, then assuming you're using OpenRC, I suggest modifying /etc/conf.d/dmesglog, setting log_dmesg="YES" and previous_dmesg=yes. Thus you can boot once on your kernel which is not showing the buffer, capturing the dmesg output in /var/log/dmesg, then boot the kernel which is giving you the display and find the dmesg output in /var/log/dmesg.old.

 

ennui ... yes, I can boot (blind) so, good idea! I'm a little bit burnt out on the problem right now, and have other more pressing things to look to, but I'll try this shortly. Thanks ...

best ... khay

----------

## genoobish

 *khayyam wrote:*   

> ...Could you provide a pastebin of your 4.3.3 .config ... thanks.
> 
> 

 

sure: https://bpaste.net/show/c44acc7a646a

edit: I'd like to add that I've also tried the vanilla sources, with same results.

----------

## khayyam

 *s4e8 wrote:*   

>  *khayyam wrote:*   s4e8 ... I don't think you understand, I can't get a framebuffer no matter what is sellected/disabled. So, I can't disable i915 and have efifb, or simplefb, provide one ... none of that works. 
> 
> You means no efifb? Did you enable the CONFIG_FRAMEBUFFER_CONSOLE

 

s4e8 ... I mean that if I disable/enable one or other (so inteldrmfb, efifb, simplefb in some combination, or individually) I don't get a framebuffer ... and yes FRAMEBUFFER_CONSOLE is enabled.

@genoobish ... thanks, I'll compare with mine.

best ... khay

----------

## Anon-E-moose

I run nouveau and radeon but these are what I have set for graphics/fb/console in the .config for 4.3.3

 *Quote:*   

> #
> 
> # Graphics support
> 
> #
> ...

 

----------

## s4e8

efifb is very simple, the kernel just take over the framebuffer and writting pixel to it. If you built all fbdev/drm driver as module except efifb, you should get a visible console, unless the kernel panic very earlier, before fbdev/fbcon initialzed. Kernel panic beforefbdev/ fbcon it's very bad situation, there's no good way to debug it unless you can setup serial console. There's kernel parameter earlyprintk=efi would print some very earlier message, after dummy console take over, and before fbcon/fbdev full initialized, you can't see any error messages.

[quote="khayyam"] *s4e8 wrote:*   

> 
> 
> s4e8 ... I mean that if I disable/enable one or other (so inteldrmfb, efifb, simplefb in some combination, or individually) I don't get a framebuffer ... and yes FRAMEBUFFER_CONSOLE is enabled.
> 
> @genoobish ... thanks, I'll compare with mine.
> ...

 

----------

## Ant P.

Is it possible 4.3.x thinks your primary display is different, possibly unconnected?

Might sound insane, but I've seen i915 do insane things in the past: one device (internal LVDS with no external monitor port) thought it had two screens mapped to the same display region for a long time... turns out the kernel driver was at fault there too.

----------

## khayyam

 *Ant P. wrote:*   

> Is it possible 4.3.x thinks your primary display is different, possibly unconnected? Might sound insane, but I've seen i915 do insane things in the past: one device (internal LVDS with no external monitor port) thought it had two screens mapped to the same display region for a long time... turns out the kernel driver was at fault there too.

 

Ant ... yeah, that is a known snafu with inteldrmfb, providing 'video=SVIDEO-1:d' as a parameter is suposed to resolve it ... though it didn't work in my case.

I've since made some headway, I can now get a framebuffer, the only change being I'd run 'make clean', so it seems to have been an inexplicable build issue. I can get simplefb, or efifb, at boot, when i915 loads subsequently the screen goes blank. I haven't had time to look any further ... tommorow perhaps, I'll report back as and when I get to it.

Thanks again to all for the comments and suggestions ... khay

----------

## genoobish

Ok, I think I'vie found a workaround.

I'm able to get the framebuffer if the vga monitor is not connected (wtf) on the 4.5.0-rc2 vanilla(that's the only one I tried though). The vga monitor got accidentally disconnected at boot time just as I was testing with the kernel, it may work with others too though. With just the laptop or the hdmi monitor it works fine.

 This is the config: https://bpaste.net/show/c907c7d5b448

And the vga monitor still works fine on X, but if I want to switch to the console, I have to unplug it for the frambuffer to work(the normal behaviour would be that it would mirror the lsvd, and the hdmi would stay blank).

and my dmesg: https://bpaste.net/show/2c872ce7093f

Please, don't tell me your monitor is not vga   :Laughing: 

if it is indeed a vga montior, can you test with a digital monitor?

----------

## khayyam

 *genoobish wrote:*   

> This is the config: https://bpaste.net/show/c907c7d5b448

 

genoobish ... are you sure inteldrmfb is in use? I ask because you have CONFIG_AGP=n (and so CONFIG_AGP_INTEL=n) and CONFIG_DRM_I915 states "AGP support is required for this driver to work" (at least on 4.3.4 and every other kernel I've built). 

 *genoobish wrote:*   

> And the vga monitor still works fine on X, but if I want to switch to the console, I have to unplug it for the frambuffer to work (the normal behaviour would be that it would mirror the lsvd, and the hdmi would stay blank). and my dmesg: https://bpaste.net/show/2c872ce7093f

 

I can't attatch an external display, I don't have the required connector (its an macbook1,1 with apple's dumb "Mini DisplayPort"). Note in that dmesg:

```
fb: switching to inteldrmfb from simple

[...]

[drm] Initialized i915 1.6.0 20151218 for 0000:00:02.0 on minor 0
```

... which boogles the mind ...

I haven't really had time to look further, I'd expect not to have to waste so much time on a suposedly "stable" kernel ... and if it looks like I need to go to 4.5.0-rc2 then I'd rather not.

Thanks & best ... khay

----------

## s4e8

AGP is optional since 3.14:

00fe639 drm/i915: Make AGP support optional

 *khayyam wrote:*   

>  *genoobish wrote:*   This is the config: https://bpaste.net/show/c907c7d5b448 
> 
> genoobish ... are you sure inteldrmfb is in use? I ask because you have CONFIG_AGP=n (and so CONFIG_AGP_INTEL=n) and CONFIG_DRM_I915 states "AGP support is required for this driver to work" (at least on 4.3.4 and every other kernel I've built). 
> 
> 

 

----------

## khayyam

 *s4e8 wrote:*   

> AGP is optional since 3.14: 00fe639 drm/i915: Make AGP support optional

 

s4e8 ... oh ... well, the help for CONFIG_DRM_I915 states otherwise. This might explain the various issues above, I have PCIe, and not AGP, and if changed I imagine they are nolonger compatible options.

thanks for the heads up ... khay

----------

## genoobish

 *khayyam wrote:*   

>  *s4e8 wrote:*   AGP is optional since 3.14: 00fe639 drm/i915: Make AGP support optional 
> 
> s4e8 ... oh ... well, the help for CONFIG_DRM_I915 states otherwise. This might explain the various issues above, I have PCIe, and not AGP, and if changed I imagine they are nolonger compatible options.
> 
> thanks for the heads up ... khay

 

I didn't read the help for the i915 driver before disabling it, I simply thought that a system with integrated graphics wouldn't need it. It seems to make no difference no difference in my setup.

 *khayyam wrote:*   

> I can't attatch an external display, I don't have the required connector (its an macbook1,1 with apple's dumb "Mini DisplayPort"). 

 

The thing is that in my case the vga monitor being plugged in is what caused the framebuffer to go blank while apparently being fine. Unplugging it made the framebuffer work properly with either the hdmi monitor or the laptop internal monitor. So it seems to be something else, or something "half-fixed" in the rc2 kernel...?

----------

## Logicien

khayyam, in Bios mode, have you try the vesafb and uvesafb framebuffers? Those generic ones are supposed to work with any graphic card who support the Vesa 2 norm. You will not be able to use the Intel Xorg module and possibly not have the native resolution of your screen but, your card will be supported by Linux. I don't see your graphic card specification. Maybe i915 will work too in Bios mode. What does lspci say?

Do you have /dev/fb0 ? If so, if you can ssh in Gentoo from an other machine, you can see what's going on with fbset, setterm and other tools and try to change things lively like unblank the screen.

----------

## khayyam

 *Logicien wrote:*   

> khayyam, in Bios mode, have you try the vesafb and uvesafb framebuffers? Those generic ones are supposed to work with any graphic card who support the Vesa 2 norm. You will not be able to use the Intel Xorg module and possibly not have the native resolution of your screen but, your card will be supported by Linux. I don't see your graphic card specification. Maybe i915 will work too in Bios mode. What does lspci say?

 

Logicien ... that's not really the problem. I boot efi, I can (now) get a framebuffer (either efifb, or simplefb) but at the point inteldrmfb is initalised the screen blanks. Perviously, I'd used inteldrmfb without any other framebuffer, as it was builtin, and never had any issues. Something has changed since 3.3.11 (the last kernel I was effectively able to build until 4.3.4 ... at least of those I tried) and whatever this change was it has made the initialisation of inteldrmfs baulk. I suspect (but haven't tested) that it is as s4e8 suggests, and gentoobish's config somewhat confirms, INTEL_AGP being enabled on PCIe.

 *Logicien wrote:*   

> Do you have /dev/fb0 ? If so, if you can ssh in Gentoo from an other machine, you can see what's going on with fbset, setterm and other tools and try to change things lively like unblank the screen.

 

As I mentioned above, I don't have a secondary machine with which to ssh.

best ... khay

----------

## khayyam

 *genoobish wrote:*   

> The thing is that in my case the vga monitor being plugged in is what caused the framebuffer to go blank while apparently being fine. Unplugging it made the framebuffer work properly with either the hdmi monitor or the laptop internal monitor. So it seems to be something else, or something "half-fixed" in the rc2 kernel...?

 

genoobish ... ok, but in my case, with 4.3.4, there is no external display, and once inteldrmfb is initalised the screen blanks. If I get some time in the next few days I'm going to have another bash at it ... I'd figured, now having rebuild the kernel and modules some 30 times (once with a 'make clean'), its probably a waste of effort (which is why I haven't bothered too much).

best ... khay

----------

## Logicien

i915 requiere firmware files /lib/firmware/i915/bxt_dmc_ver1.bin /lib/firmware/i915/i915/skl_dmc_ver1.bin and /lib/firmware/i915/skl_guc_ver4.bin . Do you have those in the path? Is dmesg complain about them? I remember a time where i915 did'nt need any external firmwares.

----------

## khayyam

 *Logicien wrote:*   

> i915 requiere firmware files /lib/firmware/i915/bxt_dmc_ver1.bin /lib/firmware/i915/i915/skl_dmc_ver1.bin and /lib/firmware/i915/skl_guc_ver4.bin . Do you have those in the path? Is dmesg complain about them? I remember a time where i915 did'nt need any external firmwares.

 

Logicien ... no I don't, and I can't see how it would be the case that suddenly I need firmware for a driver that has functioned without it.

After moving to 4.3.6 I did some blind boots (and also booted blacklisting i915), the issue is that the module effectively crashes on loading:

```
Feb 25 14:32:59 aporia kernel: Console: switching to colour frame buffer device 160x50

Feb 25 14:32:59 aporia kernel: i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

Feb 25 14:33:08 aporia kernel: ------------[ cut here ]------------

Feb 25 14:33:08 aporia kernel: WARNING: CPU: 1 PID: 108 at drivers/gpu/drm/drm_atomic.c:491 drm_atomic_check_only+0x48f/0x5f0 [drm]()

Feb 25 14:33:08 aporia kernel: Modules linked in: i915 intel_gtt i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm vfat fat applesmc led_class snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore coretemp

Feb 25 14:33:08 aporia kernel: CPU: 1 PID: 108 Comm: kworker/1:2 Tainted: G        W       4.3.6-ck #1

Feb 25 14:33:08 aporia kernel: Hardware name: Apple Computer, Inc. MacBook1,1/Mac-F4208CC8, BIOS     MB11.88Z.0061.B03.0610121324 10/12/06

Feb 25 14:33:08 aporia kernel: Workqueue: events output_poll_execute [drm_kms_helper]

Feb 25 14:33:08 aporia kernel:  00000000 00000000 f590bb8c c11d9f6f 00000000 f590bbc0 c1040a41 c14a7544

Feb 25 14:33:08 aporia kernel:  00000001 0000006c f8b3a53e 000001eb f8b2c64f 000001eb f8b2c64f f616f800

Feb 25 14:33:08 aporia kernel:  00000000 f507fae8 f590bbd0 c1040aed 00000009 00000000 f590bc20 f8b2c64f

Feb 25 14:33:08 aporia kernel: Call Trace:

Feb 25 14:33:08 aporia kernel:  [<c11d9f6f>] dump_stack+0x48/0x69

Feb 25 14:33:08 aporia kernel:  [<c1040a41>] warn_slowpath_common+0x81/0xb0

Feb 25 14:33:08 aporia kernel:  [<f8b2c64f>] ? drm_atomic_check_only+0x48f/0x5f0 [drm]

Feb 25 14:33:08 aporia kernel:  [<f8b2c64f>] ? drm_atomic_check_only+0x48f/0x5f0 [drm]

Feb 25 14:33:08 aporia kernel:  [<c1040aed>] warn_slowpath_null+0x1d/0x20

Feb 25 14:33:08 aporia kernel:  [<f8b2c64f>] drm_atomic_check_only+0x48f/0x5f0 [drm]

Feb 25 14:33:08 aporia kernel:  [<f8b2b9e5>] ? drm_atomic_set_crtc_for_plane+0x65/0xf0 [drm]

Feb 25 14:33:08 aporia kernel:  [<f8b2c7c1>] drm_atomic_commit+0x11/0x60 [drm]

Feb 25 14:33:08 aporia kernel:  [<f8d2abaa>] intel_get_load_detect_pipe+0x3ea/0x5c0 [i915]

Feb 25 14:33:08 aporia kernel:  [<c11e4854>] ? vsnprintf+0x2d4/0x3b0

Feb 25 14:33:08 aporia kernel:  [<f8d607d6>] intel_tv_detect+0xe6/0x5d0 [i915]

Feb 25 14:33:08 aporia kernel:  [<f8b269b0>] ? drm_get_edid+0x20/0x3c0 [drm]

Feb 25 14:33:08 aporia kernel:  [<f8b8fb2b>] drm_helper_probe_single_connector_modes_merge_bits+0x26b/0x4a0 [drm_kms_helper]

Feb 25 14:33:08 aporia kernel:  [<f8b8fd72>] drm_helper_probe_single_connector_modes+0x12/0x20 [drm_kms_helper]

Feb 25 14:33:08 aporia kernel:  [<f8b99229>] drm_fb_helper_probe_connector_modes.isra.7+0x39/0x60 [drm_kms_helper]

Feb 25 14:33:08 aporia kernel:  [<f8b9a4d2>] drm_fb_helper_hotplug_event+0x52/0xd0 [drm_kms_helper]

Feb 25 14:33:08 aporia kernel:  [<f8d3aed5>] intel_fbdev_output_poll_changed+0x15/0x20 [i915]

Feb 25 14:33:08 aporia kernel:  [<f8b8f48c>] drm_kms_helper_hotplug_event+0x1c/0x20 [drm_kms_helper]

Feb 25 14:33:08 aporia kernel:  [<f8b8f648>] output_poll_execute+0x178/0x1b0 [drm_kms_helper]

Feb 25 14:33:08 aporia kernel:  [<c1053302>] process_one_work+0xf2/0x310

Feb 25 14:33:08 aporia kernel:  [<c1053809>] worker_thread+0x39/0x430

Feb 25 14:33:08 aporia kernel:  [<c10537d0>] ? rescuer_thread+0x2b0/0x2b0

Feb 25 14:33:08 aporia kernel:  [<c1057c86>] kthread+0x96/0xb0

Feb 25 14:33:08 aporia kernel:  [<c13f2f01>] ret_from_kernel_thread+0x21/0x30

Feb 25 14:33:08 aporia kernel:  [<c1057bf0>] ? kthread_create_on_node+0x110/0x110

Feb 25 14:33:08 aporia kernel: ---[ end trace 58bf095d70179b74 ]---
```

The same happens with 4.3.4 so that's pretty much what is happening above, its not the sceen blanking but the driver cashing when switching from efifb/simplefb to inteldrmfb.

best ... khay

----------

## khayyam

All ... so, one year later, and after much reading and faffing about, I finally resolved the issue. My first real clue came in reading Documentation/EDID/HOWTO.txt, which suggested the issue was with EDID data ... this is what I did:

First I created an edid:

```
# emerge --oneshot x11-misc/read-edid

# mkdir /lib/firmware/edid

# get-edid --quiet > /lib/firmware/edid/mb1_1_edid.bin
```

Then I modified the kernel .config to have 

```
CONFIG_EXTRA_FIRMWARE="edid/mb1_1_edid.bin"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

CONFIG_DRM_LOAD_EDID_FIRMWARE=y
```

Then EFI_FB=y was set (to provide a framebuffer when the initramfs prompts for mounting enc_root), and CONFIG_DRM_I915=m

```
CONFIG_DRM=m

CONFIG_DRM_KMS_HELPER=m

CONFIG_DRM_I915=m

CONFIG_DRM_I915_KMS=y

CONFIG_FB_EFI=y
```

I then added the following as a kernel parameter:

```
drm_kms_helper.edid_firmware=edid/mb1_1_edid.bin
```

... removed the blacklist for i915 I'd set in /etc/modules.d/blacklist.conf, and rebooted. When the 'modules' service runs, i915 was loaded (replacing efifb), and KMS enabled ... and lo!! no black screen!!! ... no more having to load the module and login blind!!! 

Note that you should be able to add 'edid_firmware=edid/name.bin' to /etc/modprobe.d/ and this should function in the same way as the kernel parameter:

```
options drm_kms_helper edid_firmware=edid/mb1_1_edid.bin
```

Hopefully that can help someone else in some way.

best ... khay

----------

## khayyam

All ...

Nope, that was a fluke, all three subsequent reboots have the same blank display on i915 loading, and now that I think about it how could it be the display EDID, it functioned perfectly fine before 3.12.

best ... khay

----------

