Created attachment 49539 [details]
3.0 + drm-intel-fixes dmesg

this is 3.0 plus these commits from drm-intel-fixes


commit a2cab1b24a4ea75a68fa21bfb7d5b1a45121583c
Author: Adam Jackson <ajax@redhat.com>

    drm/i915/dp: Explicitly request 8/10 channel coding

commit 71ba9000e673d6171a52f2a8b14e0419087f7199
Author: Adam Jackson <ajax@redhat.com>

    drm/i915/dp: Retry DPCD fetch on G4X too

commit ac66ae8346fff704301e24ac55da1d76020660b2
Author: Adam Jackson <ajax@redhat.com>

    drm/i915/dp: Better hexdump of DPCD

commit 9de88e6e89a2222061af8e1448f6f346e3413fc8
Author: Adam Jackson <ajax@redhat.com>

    drm/i915/dp: Read more DPCD registers on connection probe

commit 1b9be9d09d85b3697418dc444db30d069203ff7d
Author: Adam Jackson <ajax@redhat.com>

    drm/i915/dp: Move DPCD dump to common code instead of PCH-only

commit 97cdd7101079adc3c626d159c62d43de949516c8
Author: Adam Jackson <ajax@redhat.com>

    drm/i915/dp: Zero the DPCD data before connection probe

commit 9c54c0dd948d715ccfd79e97d852f80eeb53254a
Author: Jesse Barnes <jbarnes@virtuousgeek.org>

    drm/i915: load the LUT before pipe enable on ILK+

commit f3234706a77bd6e1592ae71fb3268e04cb030dba
Author: Keith Packard <keithp@keithp.com>

    drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri

commit 842d452985300f4ec14c68cb86046e8a1a3b7251
Author: Ole Henrik Jahren <olehenja@alumni.ntnu.no>

    drm/i915: Fix typo in DRM_I915_OVERLAY_PUT_IMAGE ioctl define

Created attachment 49540 [details]
lspci -vvnn

Created attachment 49541 [details]
Xorg.0.log with drm-intel-fixes kernel

Created attachment 49542 [details]
intel_reg_dumper output from a VT while typing blind on the fixes kernel

Created attachment 49543 [details]
vbios

Created attachment 49544 [details]
dmesg after forcing mode via kernel command line option on fixes kernel

Created attachment 49545 [details]
xrandr --verbose

Keith is playing with some more patches for DP, but as far as I can see they are primarily targeted at hotplug. The aborted DP training is a new feature of 3.0. Do we fare any better if we go back to 3.0-rc6 i.e. before the DP fixes

(In reply to comment #8)
> Keith is playing with some more patches for DP, but as far as I can see they
> are primarily targeted at hotplug. The aborted DP training is a new feature of
> 3.0. Do we fare any better if we go back to 3.0-rc6 i.e. before the DP fixes

On 3.0-rc6 the screen works in grub, powers off, powers back on (black screen with backlight, no text) then powers off and the system is unresponsive. It never gets to X and the logs dont make it to disk. That is the same experience as with 2.6.38.8. Hard to get more info out of these macs with no serial or ethernet ports. I'll see if I can figure out what in -fixes made it stop dying and apply that to 3.0-rc6

(In reply to comment #9)
> [...]
> Hard to get more info out of these macs with no serial or
> ethernet ports. I'll see if I can figure out what in -fixes made it stop dying
> and apply that to 3.0-rc6

I was able to move /etc/init/lightdm.conf out of /etc/init and reboot.  Still got the blank screen, but was able to SSH into the macbook air from another machine.  Any chance this might help you get additional information?

There have been quite a few more adventures in modesetting with a very old bug fixed that is quite possibly the root cause of many bugs. Can you please try keithp/drm-intel-fixes and see if we make any further progress?

(In reply to comment #11)
> There have been quite a few more adventures in modesetting with a very old bug
> fixed that is quite possibly the root cause of many bugs. Can you please try
> keithp/drm-intel-fixes and see if we make any further progress?

No difference from the previous drm-intel-fixes kernel unfortunately, kernel is here if anyone else wants to try:

http://kernel.ubuntu.com/~sarvatt/macair/

Is it possible to up the severity of this bug?  The blurriness of the fbdev driver on the MBA display essentially renders any X11 app unusable.  Many users have (prematurely) wiped MacOSX from their system due to limited storage space (being an ultra portable w/SSD).  Since the MBA uses proprietary video out hardware it is entirely possible that users are stuck at blurry 1024x768 resolution or nothing.

Don't know if this is helpful or not but here is a comment from one of the Mactel users in ubuntuforums:

http://ubuntuforums.org/showpost.php?p=11117172&postcount=72

Re: MacBookAir4,1 & MacBookAir4,2 (MBA 2011) support
FYI, I booted my MBA 2011 with Ubuntu installed while having my new mini display port to HDMI-cable attached to my external widescreen monitor. I did not use "nomodeset" while booting.

No image on laptop screen but 1920x1080 resolution external monitor, using Intel drivers.

Not much help when you want to go mobile but at least it seems the intel driver is working fine, just not together with the laptop screen (yet).

This may or may not be useful information but I believe it could be relevant.

When I boot my MacBookAir4,2 on 2.6.38-10-generic (Ubuntu Natty) without nomodeset and with the fbdev driver specified in xorg.conf, the screen stays black but the system doesn't hang like it does with the intel driver. Inspecting Xorg.0.log reveals 100s of:
   (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument

Interestingly, this account is at odds with another user's account:

"...I am able to boot without nomodeset so long as I use the fbdev driver.  I get a full resolution display, but it seems that the framebuffer is boxed into 1280x800 in the upper left corner. The remaining pixels at right and below show repeated garbage of the upper right sides. This is all happening on a stock 2.6.38-10 kernel from natty."

One difference between our MBA's is the display (despite both being the same model purchased at the same time):

My display is (apparently) an LG/Philips.:
$ sudo get-edid 2> /dev/null | strings -5
LP133WP1-TJA3
Color LCD

while the other user has (apparently) a Samsung display:
$ sudo get-edid 2> /dev/null | strings -5
LTH133BT01A03
Color LCD

I have the dual i5-2557M cpu and I do not know if the other user has the i5 or i7.

[Note: when using the intel driver I reach the stage where the Ubuntu new session audio plays. The system then apparently freezes at which point the audio gets stuck looping until I reset. At no point do I see the typical boot process although I do faintly see the apple logo.]

> 
> [Note: when using the intel driver I reach the stage where the Ubuntu new
> session audio plays. The system then apparently freezes at which point the
> audio gets stuck looping until I reset. At no point do I see the typical boot
> process although I do faintly see the apple logo.]

I should mention that I think the logo is coming from the exterior case logo.  Also, when I SSH into the fbdev boot, xrandr reports:
Screen 0: minimum 1280 x 800, current 1280 x 800, maximum 1280 x 800
default connected 1280x800+0+0 0mm x 0mm
   1280x800        0.0* 

which is consistent with the other user's report (except that I have a black screen).

(In reply to comment #15)
> This may or may not be useful information but I believe it could be relevant.
> [...] 
> One difference between our MBA's is the display (despite both being the same
> model purchased at the same time):
> 
> My display is (apparently) an LG/Philips.:
> $ sudo get-edid 2> /dev/null | strings -5
> LP133WP1-TJA3
> Color LCD

I have this display as well.

> I have the dual i5-2557M cpu and I do not know if the other user has the i5 or
> i7.

berto@g550:~$ dmesg | grep -i 'intel.*core'
[    0.128350] CPU0: Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz stepping 07

Given instructions I'm happy to run some commands on this sytem to gather more information.

Thanks.

> I have the dual i5-2557M cpu and I do not know if the other user has the i5 or
> i7.

The other user to whom I was referring does indeed have a same model cpu (i5-2557M).  Just to restate: only the display manufacturer is different yet he can book into 1280x800 using fbdev and for me it is a blank screen.

(In reply to comment #4)
> Created an attachment (id=49542) [details]
> intel_reg_dumper output from a VT while typing blind on the fixes kernel

So the obvious next step in debugging is to dump the registers under
MacOS X, with a working screen, and see what's different. Logging into
a MacOS X machine and running "find /dev -group video" shows just three
entries (agpgart, fb0, pmu), apparently nothing as low-level as the PCI
access available under Linux, so reading the registers means writing a
new MacOS X device driver. Apple seems to document how to do this but
talking to an existing MacOS X programmer might be more efficient than
starting from scratch.

This particular hardware (the new MacBook Air) seems to be quickly
turning into the world's most popular laptop, so having Linux not work
on it is more than a little bit embarrassing.

(In reply to comment #19)
> (In reply to comment #4)
> > Created an attachment (id=49542) [details] [details]
> > intel_reg_dumper output from a VT while typing blind on the fixes kernel
> 
> So the obvious next step in debugging is to dump the registers under
> MacOS X, with a working screen, and see what's different. Logging into
> a MacOS X machine and running "find /dev -group video" shows just three
> entries (agpgart, fb0, pmu), apparently nothing as low-level as the PCI
> access available under Linux, so reading the registers means writing a
> new MacOS X device driver. Apple seems to document how to do this but
> talking to an existing MacOS X programmer might be more efficient than
> starting from scratch.
> 
> This particular hardware (the new MacBook Air) seems to be quickly
> turning into the world's most popular laptop, so having Linux not work
> on it is more than a little bit embarrassing.

There is a growing number of people on this thread willing to make a bounty to get this issue to the top of the queue; $200 US thus far:

http://ubuntuforums.org/showpost.php?p=11144552&postcount=107

Comments welcome.

Created attachment 50187 [details]
intel_reg_dumper output after booting with nomodeset, starting x with fbdev 1024x768

Just in case the driver bug is something really obvious, I booted with
nomodeset, started X with fbdev in 1024x768 (highest resolution offered
by the BIOS), ran intel_reg_dumper, and attached the output (50187).

There aren't a huge number of differences from the blind output (49542)
posted by Sarvatt from the latest Intel driver. One of the questions
that comes to mind: Why is the "panel fitter" disabled in the blind
output, if the resolution is 1280x800 for a panel that's physically
1440x900? Sorry if this is a stupid question; last time I really played
with graphics registers was two decades ago, and cards were just a tad
simpler back then. :-)

Its been a month with no updates. Any way we can get a picture of where things are at?  Is it realistic to hope for a bugfix on this in the near-term or will this one persist?
Cheers,
Josh

Created attachment 50855 [details]
script to make the fbdev experience slightly more tolerable

The attached script is the result of sitting down for a little while with a new MacBook Air and the Intel HD3000 manual. It doesn't produce real 1440x900 but it does fix the aspect ratio, the blurriness, and the full-intensity backlight.

At this point I'm convinced that the mode-setting trouble in the existing Intel driver is simple sloppiness, not something subtle. Doing the Right Thing might take effort, but making a workaround for MacBook Air users should be a tiny patch. A few days from now I'll have time to look at what the driver is doing.

I have my new MacBook Air running Ubuntu in full 1440x900 mode now.


Comments first to other Linux MacBook Air users:

The necessary kernel patch is, as predicted, very small.
I started with the mainline (currently 3.1.0-rc4) kernel
(git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)
and edited drivers/gpu/drm/i915/intel_bios.c to add the lines

   panel_fixed_mode->hdisplay = 1440;
   panel_fixed_mode->hsync_start = 1504;
   panel_fixed_mode->hsync_end = 1546;
   panel_fixed_mode->htotal = 1652;
   panel_fixed_mode->vdisplay = 900;
   panel_fixed_mode->vsync_start = 903;
   panel_fixed_mode->vsync_end = 909;
   panel_fixed_mode->vtotal = 926;
   panel_fixed_mode->clock = 91540;
   panel_fixed_mode->type = 0x48;
   panel_fixed_mode->flags = 0xa;

after the "Found panel mode in BIOS VBT tables" line.
Then I compiled (45 minutes), installed, took out "nomodeset", and rebooted.
I haven't checked what I need to do to get wireless working on this kernel.
Yes, yes, I know that this isn't a complete HOWTO; my apologies.

In retrospect I see that I should have added

   drm_mode_set_name(panel_fixed_mode);

after the lines shown above so that the 1440x900 mode would be
correctly labelled "1440x900" instead of "1280x800".
But this is a minor aesthetic tweak; the mode works fine.


Now comments to the people maintaining this unholy mess of a driver:

You must be suffering from a neverending series of complaints
when the driver thinks that the panel has one resolution
while the user knows perfectly well that it has another.
Why don't you let the user specify the panel size on the command line?

For this particular hardware, you could have seen from Sarvatt's
https://bugs.freedesktop.org/attachment.cgi?id=49539
more than a month ago that the driver received 1280x800 from the BIOS:

   Jul 25 16:19:28 kyoko kernel: [    6.347998] [drm:parse_lfp_panel_data], Found panel mode in BIOS VBT tables:
   Jul 25 16:19:28 kyoko kernel: [    6.348001][drm:drm_mode_debug_printmodeline], Modeline 0:"1280x800" 0 72500 1280 1328 1360 1423 800 803 809 846 0x8 0xa

Later the driver saw 1440x900 but rejected it as being above 1280x800:

   Jul 25 16:19:32 kyoko kernel: [   10.313992] [drm:intel_dp_detect], DPCD: 0000000000000000
   Jul 25 16:19:32 kyoko kernel: [   10.316001] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2
   Jul 25 16:19:32 kyoko kernel: [   10.356230] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2
   Jul 25 16:19:32 kyoko kernel: [   10.358254] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2
   Jul 25 16:19:32 kyoko kernel: [   10.398466] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2
   Jul 25 16:19:32 kyoko kernel: [   10.398480] [drm:drm_mode_debug_printmodeline], Modeline 24:"1280x800" 60 72500 1280 1328 1360 1423 800 803 809 846 0x8 0xa
   Jul 25 16:19:32 kyoko kernel: [   10.398484] [drm:drm_mode_prune_invalid], Not using 1280x800 mode -3
   Jul 25 16:19:32 kyoko kernel: [   10.398487] [drm:drm_mode_debug_printmodeline], Modeline 28:"1440x900" 0 91540 1440 1504 1546 1652 900 903 909 926 0x48 0xa
   Jul 25 16:19:32 kyoko kernel: [   10.398490] [drm:drm_mode_prune_invalid], Not using 1440x900 mode 29

My impression is that this "DP" information is relatively clean data
from the display, without all the BIOS historical baggage,
so surely you should prefer the "DP" information when there's a conflict.

Haven't tried yet but Thank You poster!

Maybe a naive question...but what why not have a bool parm that prevents the prune_invalid altogether?

Confirming that the hack works.  Many thanks poster!

kernel
3.0.0-10-generic #16-Ubuntu SMP Fri Sep 2 18:32:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

libdrm
2.4.26+git20110808.2acaf160-0ubuntu0sarvatt

xserver-xorg-video-intel
2:2.16.0+git20110901.695e7115-0ubuntu0sarvatt

Exact steps I took:
http://www.almostsure.com/mba42/fix-i915.sh

(In reply to comment #27)
> Confirming that the hack works.  Many thanks poster!
> 
> kernel
> 3.0.0-10-generic #16-Ubuntu SMP Fri Sep 2 18:32:04 UTC 2011 x86_64 x86_64
> x86_64 GNU/Linux
> 
> libdrm
> 2.4.26+git20110808.2acaf160-0ubuntu0sarvatt
> 
> xserver-xorg-video-intel
> 2:2.16.0+git20110901.695e7115-0ubuntu0sarvatt
> 
> Exact steps I took:
> http://www.almostsure.com/mba42/fix-i915.sh

(In reply to comment #25)
> I have my new MacBook Air running Ubuntu in full 1440x900 mode now.
> 
> 
> Comments first to other Linux MacBook Air users:
> 
> The necessary kernel patch is, as predicted, very small.
> I started with the mainline (currently 3.1.0-rc4) kernel
> (git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)
> and edited drivers/gpu/drm/i915/intel_bios.c to add the lines
> 
>    panel_fixed_mode->hdisplay = 1440;
>    panel_fixed_mode->hsync_start = 1504;
>    panel_fixed_mode->hsync_end = 1546;
>    panel_fixed_mode->htotal = 1652;
>    panel_fixed_mode->vdisplay = 900;
>    panel_fixed_mode->vsync_start = 903;
>    panel_fixed_mode->vsync_end = 909;
>    panel_fixed_mode->vtotal = 926;
>    panel_fixed_mode->clock = 91540;
>    panel_fixed_mode->type = 0x48;
>    panel_fixed_mode->flags = 0xa;
> 
> after the "Found panel mode in BIOS VBT tables" line.
> Then I compiled (45 minutes), installed, took out "nomodeset", and rebooted.
> I haven't checked what I need to do to get wireless working on this kernel.
> Yes, yes, I know that this isn't a complete HOWTO; my apologies.
> 
> In retrospect I see that I should have added
> 
>    drm_mode_set_name(panel_fixed_mode);
> 
> after the lines shown above so that the 1440x900 mode would be
> correctly labelled "1440x900" instead of "1280x800".
> But this is a minor aesthetic tweak; the mode works fine.
> 
> 
> Now comments to the people maintaining this unholy mess of a driver:
> 
> You must be suffering from a neverending series of complaints
> when the driver thinks that the panel has one resolution
> while the user knows perfectly well that it has another.
> Why don't you let the user specify the panel size on the command line?
> 
> For this particular hardware, you could have seen from Sarvatt's
> https://bugs.freedesktop.org/attachment.cgi?id=49539
> more than a month ago that the driver received 1280x800 from the BIOS:
> 
>    Jul 25 16:19:28 kyoko kernel: [    6.347998] [drm:parse_lfp_panel_data],
> Found panel mode in BIOS VBT tables:
>    Jul 25 16:19:28 kyoko kernel: [   
> 6.348001][drm:drm_mode_debug_printmodeline], Modeline 0:"1280x800" 0 72500 1280
> 1328 1360 1423 800 803 809 846 0x8 0xa
> 
> Later the driver saw 1440x900 but rejected it as being above 1280x800:
> 
>    Jul 25 16:19:32 kyoko kernel: [   10.313992] [drm:intel_dp_detect], DPCD:
> 0000000000000000
>    Jul 25 16:19:32 kyoko kernel: [   10.316001] [drm:i2c_algo_dp_aux_xfer],
> dp_aux_xfer return 2
>    Jul 25 16:19:32 kyoko kernel: [   10.356230] [drm:i2c_algo_dp_aux_xfer],
> dp_aux_xfer return 2
>    Jul 25 16:19:32 kyoko kernel: [   10.358254] [drm:i2c_algo_dp_aux_xfer],
> dp_aux_xfer return 2
>    Jul 25 16:19:32 kyoko kernel: [   10.398466] [drm:i2c_algo_dp_aux_xfer],
> dp_aux_xfer return 2
>    Jul 25 16:19:32 kyoko kernel: [   10.398480]
> [drm:drm_mode_debug_printmodeline], Modeline 24:"1280x800" 60 72500 1280 1328
> 1360 1423 800 803 809 846 0x8 0xa
>    Jul 25 16:19:32 kyoko kernel: [   10.398484] [drm:drm_mode_prune_invalid],
> Not using 1280x800 mode -3
>    Jul 25 16:19:32 kyoko kernel: [   10.398487]
> [drm:drm_mode_debug_printmodeline], Modeline 28:"1440x900" 0 91540 1440 1504
> 1546 1652 900 903 909 926 0x48 0xa
>    Jul 25 16:19:32 kyoko kernel: [   10.398490] [drm:drm_mode_prune_invalid],
> Not using 1440x900 mode 29
> 
> My impression is that this "DP" information is relatively clean data
> from the display, without all the BIOS historical baggage,
> so surely you should prefer the "DP" information when there's a conflict.

Thank you phantom savior poster! 

I have used your recipe to allow my mid-2011 11inch MBA to work in 1366x768 in Fedora 17 which was never possible until this tweak, and a recompile.

Linux 3.1.0-0.rc4.git0.0.i915mod.fc15.x86_64 #1 SMP Tue Sep 6 20:52:44 
xorg-x11-drv-intel-2.16.0-2.fc17.x86_64
libdrm-2.4.26-1.fc16.x86_64
xorg-x11-server-Xorg-1.10.99.902-1.20110818.fc17.x86_64

#intel_bios.c

panel_fixed_mode->hdisplay 	= 1366;
panel_fixed_mode->hsync_start 	= 1380;
panel_fixed_mode->hsync_end 	= 1436;
panel_fixed_mode->htotal 	= 1500;
panel_fixed_mode->vdisplay 	= 768;
panel_fixed_mode->vsync_start 	= 769;
panel_fixed_mode->vsync_end 	= 772;
panel_fixed_mode->vtotal 	= 800;
panel_fixed_mode->clock 	= 91540;#<--- GUESS based on prev posters output
panel_fixed_mode->type 		= 0x48;
panel_fixed_mode->flags 	= 0xa;
drm_mode_set_name(panel_fixed_mode);

(In reply to comment #28)
> #intel_bios.c
> 
> panel_fixed_mode->hdisplay     = 1366;
> panel_fixed_mode->hsync_start     = 1380;
> panel_fixed_mode->hsync_end     = 1436;
> panel_fixed_mode->htotal     = 1500;
> panel_fixed_mode->vdisplay     = 768;
> panel_fixed_mode->vsync_start     = 769;
> panel_fixed_mode->vsync_end     = 772;
> panel_fixed_mode->vtotal     = 800;
> panel_fixed_mode->clock     = 91540;#<--- GUESS based on prev posters output
> panel_fixed_mode->type         = 0x48;
> panel_fixed_mode->flags     = 0xa;
> drm_mode_set_name(panel_fixed_mode);

I can confirm this patch works on MacbookAir4,1. The clock corresponds to the modeline given by drm_debug, so that should be fine.

(In reply to comment #26)
> Haven't tried yet but Thank You poster!
> 
> Maybe a naive question...but what why not have a bool parm that prevents the
> prune_invalid altogether?

Stopping prune_invalid wouldn't be enough. The driver tries to, and needs to, figure out the physical screen resolution that it's aiming for; in this case it ends up with an incorrect 1280x800. The driver then scales all other resolutions (with the "panel fitter") accordingly; for example, if 1440x900 weren't pruned then the driver would scale it to 1280x800. The physical screen ends up seeing 1280x800 and apparently responds by displaying all blanks.

To summarize, it's important for the driver to not merely see the 1440x900 option, but to aim for a 1440x900 physical screen resolution.

(In reply to comment #30)
> (In reply to comment #26)
> > Haven't tried yet but Thank You poster!
> > 
> > Maybe a naive question...but what why not have a bool parm that prevents the
> > prune_invalid altogether?
> 
> Stopping prune_invalid wouldn't be enough. The driver tries to, and needs to,
> figure out the physical screen resolution that it's aiming for; in this case it
> ends up with an incorrect 1280x800. The driver then scales all other
> resolutions (with the "panel fitter") accordingly; for example, if 1440x900
> weren't pruned then the driver would scale it to 1280x800. The physical screen
> ends up seeing 1280x800 and apparently responds by displaying all blanks.
> 
> To summarize, it's important for the driver to not merely see the 1440x900
> option, but to aim for a 1440x900 physical screen resolution.

Ah, I see--thanks for explaining!  I doubt this is much better than your suggestion of allowing a manual modeset--which I think should ALSO be added in addition to what I suggestion--but how about a choose_max bool parm which selects the "largest" mode (ie num pixels).

I think its a nice fallback to be able to manually specify the modeline, but it seems that, at least in our case, we need only nudge the hardware discovery heuristic.

Confirmed that the hack works for Arch Linux as well. Thank you very much. 

To get wi-fi working is easy, just blacklist bcma and reboot, the kernel has support for the wifi out of the box. The module is brcmsmac which should get loaded automatically. For some reason the kernel loads bcma which conflicts with brcmsmac and causes wifi not to work.

Created attachment 50970 [details] [review]
MacBook Air 4,1 hacky patch

Patch for the MBA 11" to implement the forced-timing hack above.  A little easier to apply than editing the file manually.

"me too" -- works for me, however hacky it may be...

On a side note, I also get this in dmesg when the module loads (there's a 2-3s pause when I modprobe it; I assume this part is the pause):

[drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled]

This gets repeated 8 times, and then I get the same thing again (8 times each), but with each of the following instead of "disabled": ssc, vga, panel, dpc, dpb, reserved, dpd.

That seemed to be a little different for me then for some of the other logs posted.  This is on 3.1.0-rc4+, with drm-intel-fixes also applied.  Maybe it's useful.

(In reply to comment #33)
> Created an attachment (id=50970) [details]
> MacBook Air 4,1 hacky patch
> 
> Patch for the MBA 11" to implement the forced-timing hack above.  A little
> easier to apply than editing the file manually.
> 
> "me too" -- works for me, however hacky it may be...

Hmm, this doesn't work for me.  I applied this patch against 3.1.0-rc4, removed the nomodeset, and now I get a really messed up display on my 11", like something is out of sync.  Without the patch, I just get garbage on the left hand side of the screen and lines off the bottom on the console.

(In reply to comment #35)
> (In reply to comment #33)
> > Created an attachment (id=50970) [details] [details]
> > MacBook Air 4,1 hacky patch
> > 
> > Patch for the MBA 11" to implement the forced-timing hack above.  A little
> > easier to apply than editing the file manually.
> > 
> > "me too" -- works for me, however hacky it may be...
> 
> Hmm, this doesn't work for me.  I applied this patch against 3.1.0-rc4, removed
> the nomodeset, and now I get a really messed up display on my 11", like
> something is out of sync.  Without the patch, I just get garbage on the left
> hand side of the screen and lines off the bottom on the console.

Hi Nathan,

Please take a look at the following thread and post back the output of the command "lsusb".  That thread is putting together all the necessary bits to get all the laptop's components working:

http://ubuntuforums.org/showpost.php?p=11234021&postcount=236

(In reply to comment #35)
> (In reply to comment #33)
> > Created an attachment (id=50970) [details] [details]
> > MacBook Air 4,1 hacky patch
> > 
> > Patch for the MBA 11" to implement the forced-timing hack above.  A little
> > easier to apply than editing the file manually.
> > 
> > "me too" -- works for me, however hacky it may be...
> 
> Hmm, this doesn't work for me.  I applied this patch against 3.1.0-rc4, removed
> the nomodeset, and now I get a really messed up display on my 11", like
> something is out of sync.  Without the patch, I just get garbage on the left
> hand side of the screen and lines off the bottom on the console.

Bizarre, working fine for me.  This coming week I'm going to try to look into why the driver is unable to find the correct mode...

I can confirm that the given patch fixes modesetting, backlight control and OpenGL in Fedora 16 beta.

Thanks, DJB.

(In reply to comment #37)
> (In reply to comment #35)
> > (In reply to comment #33)
> > > Created an attachment (id=50970) [details] [details] [details]
> > > MacBook Air 4,1 hacky patch
> > > 
> > > Patch for the MBA 11" to implement the forced-timing hack above.  A little
> > > easier to apply than editing the file manually.
> > > 
> > > "me too" -- works for me, however hacky it may be...
> > 
> > Hmm, this doesn't work for me.  I applied this patch against 3.1.0-rc4, removed
> > the nomodeset, and now I get a really messed up display on my 11", like
> > something is out of sync.  Without the patch, I just get garbage on the left
> > hand side of the screen and lines off the bottom on the console.
> 
> Bizarre, working fine for me.  This coming week I'm going to try to look into
> why the driver is unable to find the correct mode...

Well, it looks like I get a 

"[drm:drm_mode_debug_printmodeline], Modeline 0:"1366x768" 0 91540 1366 1380 1436 1500 768 769 772 800 0x48 0xa"

from the kernel, so I think I applied the patch right.  This patch is supposed to work with clean 3.1.0-rc4, right?  No other patches required?

(In reply to comment #39)
> Well, it looks like I get a 
> 
> "[drm:drm_mode_debug_printmodeline], Modeline 0:"1366x768" 0 91540 1366 1380
> 1436 1500 768 769 772 800 0x48 0xa"
> 
> from the kernel, so I think I applied the patch right.  This patch is supposed
> to work with clean 3.1.0-rc4, right?  No other patches required?

Two things:

1.  I'm booting in EFI mode, not BIOS mode.  I'm not sure if this works in BIOS mode.
2.  You shouldn't *need* any other patches, though I do have a few others in my kernel.  Definitely works on 3.1.0-rc4, though I'm running 3.1.0-rc6+ right now.  My kernel is here:

https://github.com/kelnos/linux (branch macbook-air-4,1)

And my kernel config is here:

http://spurint.org/stuff/kernel-config-macbookair4,1

(In reply to comment #40)
> (In reply to comment #39)
> > Well, it looks like I get a 
> > 
> > "[drm:drm_mode_debug_printmodeline], Modeline 0:"1366x768" 0 91540 1366 1380
> > 1436 1500 768 769 772 800 0x48 0xa"
> > 
> > from the kernel, so I think I applied the patch right.  This patch is supposed
> > to work with clean 3.1.0-rc4, right?  No other patches required?
> 
> Two things:
> 
> 1.  I'm booting in EFI mode, not BIOS mode.  I'm not sure if this works in BIOS
> mode.
> 2.  You shouldn't *need* any other patches, though I do have a few others in my
> kernel.  Definitely works on 3.1.0-rc4, though I'm running 3.1.0-rc6+ right
> now.  My kernel is here:
> 
> https://github.com/kelnos/linux (branch macbook-air-4,1)
> 
> And my kernel config is here:
> 
> http://spurint.org/stuff/kernel-config-macbookair4,1

(In reply to comment #39)
> (In reply to comment #37)
> > (In reply to comment #35)
> > > (In reply to comment #33)
> > > > Created an attachment (id=50970) [details] [details] [details] [details]
> > > > MacBook Air 4,1 hacky patch
> > > > 
> > > > Patch for the MBA 11" to implement the forced-timing hack above.  A little
> > > > easier to apply than editing the file manually.
> > > > 
> > > > "me too" -- works for me, however hacky it may be...
> > > 
> > > Hmm, this doesn't work for me.  I applied this patch against 3.1.0-rc4, removed
> > > the nomodeset, and now I get a really messed up display on my 11", like
> > > something is out of sync.  Without the patch, I just get garbage on the left
> > > hand side of the screen and lines off the bottom on the console.
> > 
> > Bizarre, working fine for me.  This coming week I'm going to try to look into
> > why the driver is unable to find the correct mode...
> 
> Well, it looks like I get a 
> 
> "[drm:drm_mode_debug_printmodeline], Modeline 0:"1366x768" 0 91540 1366 1380
> 1436 1500 768 769 772 800 0x48 0xa"
> 
> from the kernel, so I think I applied the patch right.  This patch is supposed
> to work with clean 3.1.0-rc4, right?  No other patches required?

Not sure what distro you are using, but if you have not already, check out this thread on the ubuntu forums:

http://ubuntuforums.org/showthread.php?t=1810275

Throughout the post there are copies of a post-install script that works for Ubuntu Oneiric (11.10).  If you're using ubuntu you should be good to go; otherwise maybe you can extract any magic it may contain.

There's also a copy on github:

https://gist.github.com/1205289/475a44d11c751376ee5b2fe494143f0cf15815bb

Best.

(In reply to comment #41)
> 
> There's also a copy on github:
> 
> https://gist.github.com/1205289/475a44d11c751376ee5b2fe494143f0cf15815bb

From a quick read, that looks like it only works on the 13".  Nathan and I have the 11" model.

(In reply to comment #42)
> (In reply to comment #41)
> > 
> > There's also a copy on github:
> > 
> > https://gist.github.com/1205289/475a44d11c751376ee5b2fe494143f0cf15815bb
> 
> From a quick read, that looks like it only works on the 13".  Nathan and I have
> the 11" model.

Maybe I didn't update github properly; check out this post:

http://ubuntuforums.org/showpost.php?p=11255179&postcount=281

(In reply to comment #41)
> Not sure what distro you are using, but if you have not already, check out this
> thread on the ubuntu forums:
> 
> http://ubuntuforums.org/showthread.php?t=1810275
> 
> Throughout the post there are copies of a post-install script that works for
> Ubuntu Oneiric (11.10).  If you're using ubuntu you should be good to go;
> otherwise maybe you can extract any magic it may contain.
> 
> There's also a copy on github:
> 
> https://gist.github.com/1205289/475a44d11c751376ee5b2fe494143f0cf15815bb
> 
> Best.

I expected hacks to get Linux on Macbook working, so Gentoo :).  Also, booting with Grub2 and EFI makes no difference, the hacky patch just does not seem to work at all for me - I just get a messed up framebuffer console in a different way than without the patch.  It looks like a small section of the screen is tiled 12 times around the display.  Starting X gives me a trippy white display with vertical stripes.

Without the 11" version of the patch, I get a framebuffer console that has a line or two off the bottom of the screen.

On the bright side, everything else does work (wireless, keyboard, trackpad, sensors, even backlight control through /sys!).

Nathan, what are the specs on your laptop?  I have the maxed-out 11": Core i7 1.8GHz, 4GB RAM, 256GB SSD.  I recall with last year's Air model, differing amounts of RAM did actually change things wrt graphics memory addressing, though that was with a nvidia chipset, and I'm not sure how that could possibly change video timings.  But perhaps there's something there...

Berto why keep old copies of my script floating around? ...I update it daily.... Also I'm not sure how its relevant here.

(In reply to comment #46)
> Berto why keep old copies of my script floating around? ...I update it
> daily....

The idea was mainly so that the script could be accessed without having to go through the entire ubuntu forums thread.  But, you do have a point, maybe I should have pointed directly to your version:

http://almostsure.com/mba42/post-install-oneiric.sh

That said, my thought is the likelyhood of the almostsure version disappearing is greater than github's going away.  ;)

> Also I'm not sure how its relevant here.

Maybe others can figure out how to get things working on other platforms by referencing your script.

FWIW, on Fedora, I found it generally useful to go to http://almostsure.com/mba42 and take a look at the kernel patches there, plus the "new" post-install script.

One note of caution is that the kernel patches seem to be against the Ubuntu kernel(?) so the latest patches in there add support for the "6A" version (which I believe is the 11"?), but I had to add lines for the 6 version as well to my kernel.

(I'm almost wishing I had followed Nathan's steps and gone with my usual Gentoo, but wasn't sure how much time I wanted to spend getting the system up and running :-)  )

Going through the (new) post-install script there gave some useful insight into other things, such as the best order in which to load certain modules.

I'm generally kind of a forums hater, because (as that thread shows) it's nearly impossible to extract the "current" useful information out of a forum thread without way too much time spent parsing what's still relevant, what's not, and where to find bits and pieces. Perhaps Joshua, or someone else (I can't in the next week at least) can start a generic, distro-independent page or wiki page somewhere containing up-to-date information on the patches required for the kernel, what software provides what support for different pieces of hardware, and so on.

That all said, this is a thread about the i915 driver, so I apologize to all for the mostly non-i915 chatter in this post, but I figured it might be useful as we're all running into this problem for the same mba-related reason  :-)

The script downloads several additional files (some text, some deb and some from my site , some elsewhere ) so those would need to be posted too and the script modified. and of course it changes frequently ...

As far as kernel patches, some I have submitted to mainline. I'm waiting to hear how the 11" people fair with my new patches before submitting those.

please let's continue this offtopic chatter at ubuntu forums where much of what I am saying here has already been said.

Brian, would you mind telling us how you set-up pure EFI boot in the Ubuntu thread?  This is still on my TODO list.
http://ubuntuforums.org/showthread.php?t=1810275&goto=newpost

Brian, would you mind telling us how you set-up pure EFI boot in the Ubuntu thread?  This is still on my TODO list.
http://ubuntuforums.org/showthread.php?t=1810275&goto=newpost

(In reply to comment #45)
> Nathan, what are the specs on your laptop?  I have the maxed-out 11": Core i7
> 1.8GHz, 4GB RAM, 256GB SSD.  I recall with last year's Air model, differing
> amounts of RAM did actually change things wrt graphics memory addressing,
> though that was with a nvidia chipset, and I'm not sure how that could possibly
> change video timings.  But perhaps there's something there...

I've got the "Low End" 11", 2G ram and the 64G SSD.  Right now, I have the plain vanilla 3.1.0-rc4 kernel with no patches except the one to change display timing/resolution for the 11", and I'm booting pure EFI.

What's odd is now when I EFI boot, the EFI framebuffer comes up fine, then loading the i915 driver without modeswitch corrupts everything but the 4 penguins up top.  With modeswitch, I get the same behavior as before - funky screen tiling.

(In reply to comment #52)
> (In reply to comment #45)
> > Nathan, what are the specs on your laptop?  I have the maxed-out 11": Core i7
> > 1.8GHz, 4GB RAM, 256GB SSD.  I recall with last year's Air model, differing
> > amounts of RAM did actually change things wrt graphics memory addressing,
> > though that was with a nvidia chipset, and I'm not sure how that could possibly
> > change video timings.  But perhaps there's something there...
> 
> I've got the "Low End" 11", 2G ram and the 64G SSD.  Right now, I have the
> plain vanilla 3.1.0-rc4 kernel with no patches except the one to change display
> timing/resolution for the 11", and I'm booting pure EFI.
> 
> What's odd is now when I EFI boot, the EFI framebuffer comes up fine, then
> loading the i915 driver without modeswitch corrupts everything but the 4
> penguins up top.  With modeswitch, I get the same behavior as before - funky
> screen tiling.

The screen corruption with modeswitch disabled is a refcount bug in the kernel, triggered by plymouth. Booting with rd_NO_PLYMOUTH might work-around that particular corruption.

(In reply to comment #45)
> 
> The screen corruption with modeswitch disabled is a refcount bug in the kernel,
> triggered by plymouth. Booting with rd_NO_PLYMOUTH might work-around that
> particular corruption.

Oh, no Plymouth for me, I don't think Gentoo does that.  I tried setting the flag anyway, and it does nothing.

Oh hey, EFI framebuffer gives me a modeline in my Xorg log file - 

[   152.990] (II) FBDEV(0): Modeline "current"x0.0  104.92  1366 1398 1566 1734  768 772 776 792 -hsync -vsync -csync (60.5 kHz)


So, I put those numbers in intel_bios.c and got a slightly less messed up screen.  The fonts look odd, however it does seem to modeswitch to 1366x768 properly now.  I think the "clock" setting is wrong since I don't know what to put there, and left it at 91540.

So, right now I have -

        DRM_DEBUG_KMS("Found panel mode in BIOS VBT tables:\n");

        panel_fixed_mode->hdisplay     = 1366;
        panel_fixed_mode->hsync_start     = 1398;
        panel_fixed_mode->hsync_end     = 1566;
        panel_fixed_mode->htotal     = 1734;
        panel_fixed_mode->vdisplay     = 768;
        panel_fixed_mode->vsync_start     = 772;
        panel_fixed_mode->vsync_end     = 776;
        panel_fixed_mode->vtotal     = 792;
        panel_fixed_mode->clock     = 91540;
        panel_fixed_mode->type         = 0x48;
        panel_fixed_mode->flags     = 0xa;
        drm_mode_set_name(panel_fixed_mode);

If you turn on drm debugging then a reasonable 1366x768 modeline from the BIOS will show up later in dmesg. (I'd guess that the clock wants to be 72000, but there's no reason to guess.)

Does this mean that the 1366x768 mode information in #28 is not correct?  Is there reason to think that there would be multiple modelines for the same machine?  (It is known that apple uses LG and Samsung monitors for all 2011 Air lines.)

Please let me know what works and I will try to modify the fix-i915 script. I suppose I can use `sudo get-edid 2> /dev/null | strings -5` to make the distinction.

Just looking over this random survey I found:

https://spreadsheets.google.com/spreadsheet/ccc?key=0Aq4LUv8YJH25dHFhcmFieEZzMmtSZjdwWDNhNVlPOFE&hl=en_US#gid=0

Using cut/uniq I count:
# CNT Field
#  3 MBA11 - i5,
# 18 MBA11 - i5,LP116WH4-TJA3
# 32 MBA11 - i5,LTH116AT01A04
#  3 MBA11 - i5,LTH133BT01A03
#  6 MBA11 - i7,
# 18 MBA11 - i7,LP116WH4-TJA3
#  1 MBA11 - i7,LP133WP1-TJA3
# 17 MBA11 - i7,LTH116AT01A04
#  1 MBA11 - i7,LTH133BT01A03
#
#  4 MBA13 - i5,
#  1 MBA13 - i5,?
#  1 MBA13 - i5,IDK. I have an LP
#  2 MBA13 - i5,LP116WH4-TJA3
#114 MBA13 - i5,LP133WP1-TJA3
#  2 MBA13 - i5,LTH116AT01A04
# 99 MBA13 - i5,LTH133BT01A03
#  1 MBA13 - i7,
# 75 MBA13 - i7,LP133WP1-TJA3
# 47 MBA13 - i7,LTH133BT01A03

And conclude (after tossing 16 noise responses):

# MacBookAir4,1:
# 38 LP116WH4-TJA3
# 51 LTH116AT01A04
#
# MacBookAir4,2:
# 190 LP133WP1-TJA3
# 150 LTH133BT01A03

So at most I suppose we have four mode-lines to find for this temporary hack to work for everyone.

(In reply to comment #56)
> If you turn on drm debugging then a reasonable 1366x768 modeline from the BIOS
> will show up later in dmesg. (I'd guess that the clock wants to be 72000, but
> there's no reason to guess.)

Close, 72500.  So, to make i915 work on MY 11", I have -

        DRM_DEBUG_KMS("Found panel mode in BIOS VBT tables:\n");

        drm_mode_debug_printmodeline(panel_fixed_mode);

        panel_fixed_mode->hdisplay     = 1366;
        panel_fixed_mode->hsync_start     = 1398;
        panel_fixed_mode->hsync_end     = 1566;
        panel_fixed_mode->htotal     = 1734;
        panel_fixed_mode->vdisplay     = 768;
        panel_fixed_mode->vsync_start     = 772;
        panel_fixed_mode->vsync_end     = 776;
        panel_fixed_mode->vtotal     = 792;
        panel_fixed_mode->clock     = 72500;
        panel_fixed_mode->type         = 0x48;
        panel_fixed_mode->flags     = 0xa;
        drm_mode_set_name(panel_fixed_mode);

        drm_mode_debug_printmodeline(panel_fixed_mode);

X and GLX seem to work fine now as well.  Is there a way to find out what sort of panel I have?

#57

On Ubuntu you can install read-edid to get the command get-edid.

"get-edid,  parse-edid - read-edid tools to retrieve and interpret moni‐
tor specifications using the VESA VBE DDC protocol"

Oh, and it's in the Xorg log - my display is apparently a LTH116AT01A04.

Thanks Nathan. Hack script updated.
http://almostsure.com/mba42/fix-i915.sh

Keith Packard is doing some magic regarding this problem here:

http://cgit.freedesktop.org/~keithp/linux/log/?h=fix-edp-vdd-power

Good news is, it works! Kernels for Ubuntu available here:

http://kernel.ubuntu.com/~sarvatt/mba-fix-edp-vdd-power/

(In reply to comment #63)
> Keith Packard is doing some magic regarding this problem here:
> 
> http://cgit.freedesktop.org/~keithp/linux/log/?h=fix-edp-vdd-power
> 
> Good news is, it works! Kernels for Ubuntu available here:
> 
> http://kernel.ubuntu.com/~sarvatt/mba-fix-edp-vdd-power/

Doesn't work for me on a MacBookAir4,1 (11"). The backlight is on (and the OS running, I can see the backlight dimming after inactivity), but a big black empty screen in place of the desktop.

New kernel with further fixes in it, all patches are in the directory and they apply to git://kernel.ubuntu.com/ubuntu/ubuntu-p.git master-next branch


http://kernel.ubuntu.com/~sarvatt/macbook-air/

Wow! Thanks Robert!

(In reply to comment #64)
> (In reply to comment #63)
> > Keith Packard is doing some magic regarding this problem here:
> > 
> > http://cgit.freedesktop.org/~keithp/linux/log/?h=fix-edp-vdd-power
> > 
> > Good news is, it works! Kernels for Ubuntu available here:
> > 
> > http://kernel.ubuntu.com/~sarvatt/mba-fix-edp-vdd-power/
> 
> Doesn't work for me on a MacBookAir4,1 (11"). The backlight is on (and the OS
> running, I can see the backlight dimming after inactivity), but a big black
> empty screen in place of the desktop.

It looks like things broke again, monday morning at 1 AM EST I built this one that is working

http://kernel.ubuntu.com/~sarvatt/mba-working/

Then I rebuilt it the next day after new commits were added and that one is not working here either

http://kernel.ubuntu.com/~sarvatt/mba-fix-edp-vdd-power/

Today's is also not working

http://kernel.ubuntu.com/~sarvatt/macbook-air/

Unfortunately I lost the patch stack that was used for the first kernel which worked..

Can you try the 'macbook-air-partial' branch from my repo?

git://people.freedesktop.org/~keithp/linux

That's got the first part of the patch sequence which makes everything legal, the latter patches clean things up and make them faster.

At this point, it should take a *long* time (10-20 seconds?) for mode setting, during which you'll see a bunch of screen flashing.

If it works, please try the other patches on the 'macbook-air' branch to see where things break.

(In reply to comment #68)
> Can you try the 'macbook-air-partial' branch from my repo?
> 
> git://people.freedesktop.org/~keithp/linux
> 
> That's got the first part of the patch sequence which makes everything legal,
> the latter patches clean things up and make them faster.
> 
> At this point, it should take a *long* time (10-20 seconds?) for mode setting,
> during which you'll see a bunch of screen flashing.
> 
> If it works, please try the other patches on the 'macbook-air' branch to see
> where things break.

I built that one here in case anyone else wants to try

http://kernel.ubuntu.com/~sarvatt/macbook-air-partial/

It doesn't work unfortunately, waited for the screen to stop powering on and off while black every 1 second or so for 5 minutes. I've built 5 other intermediate kernels and haven't found a point in the current git history where it works properly, but I'm 100% sure the checkout from sunday night worked properly because I just reinstalled that built kernel and it does still work. I believe the newest commit at that point in time was removing an #if 0 block of code and enabling it elsewhere

Odd, both the macbook-air and macbook-air-partial branches work fine on my 4,1.  The latter has super slow modesetting, the former is reasonably speedy.

I still get all those "[drm] GMBUS timed out, falling back to bit banging on pin 0" messages in my kernel log, though, which appears to slow down initial module load by ~4 seconds.

(In reply to comment #70)
> Odd, both the macbook-air and macbook-air-partial branches work fine on my 4,1.
>  The latter has super slow modesetting, the former is reasonably speedy.
> 
> I still get all those "[drm] GMBUS timed out, falling back to bit banging on
> pin 0" messages in my kernel log, though, which appears to slow down initial
> module load by ~4 seconds.

Sorry, its been discussed out of band in #intel-gfx on freenode that the failures seem to be limited to bios emulation and hasn't been mentioned here. EFI booting does work which I'm guessing you're using?

Ah, yup, I'm booting in EFI mode.

To anyone wanting to use the crappy work-around, I now have all four modelines for the MBA4 in:
http://almostsure.com/mba42/fix-i915.sh

Its written for Ubuntu but you should be able to easily modify it to your distribution of choice.

I noticed that I get blank display on my macbookair with linux-3.2rc1 + hacky patch. It works fine with linux-3.1 + the patch.

Does anybody try 3.2rc1 kernel? Should I boot it in EFI mode instead of legacy BIOS?

Same here, everything gets blank at startup, kernel 3.1.1 on a MacBook Air 4,2

Grub starts ok, but when KMS try to switch the video mode, it get all blank.

X starts, switches the screen from blank (black with backlight) to off (not back light) to blank (black with backlight).

No patch in 3.1.2 seems to deal with this issue

rEFIt booting is still broken in drm-intel-next as of 11/25/2011, still have to use http://kernel.ubuntu.com/~sarvatt/mba-working/. Oh how I wish I didn't lose that patch stack :(

This is actually fixed in 3.2 final, rEFIt booting works out of the box.

Confirmed, with Archlinux stable, shipping a 3.2.1 kernel, no patch needed anymore.

Thanks guys!!