Arch Linux

I've attached the diff between the Xorg.0.log files generated by bootups using linux 3.6.11 and 3.7.4, and there appears to be little difference, except for the moving around of some of the input and event devices. The only other difference is that the VESA virtual address changed, which isn't unexpected given that memory will shift around some when booting from different kernel versions. This does appear to come down to some difference in the kernels.

Is it possible that there is some config option that was missed when building the 3.7.4 kernel - some option that was set for 3.6.11?

In case this might help at all, I did find this bug thread that might shed some light on the issue:

https://bugs.freedesktop.org/show_bug.cgi?id=53926

If this is related, then there might not be a resolution for this issue until linux 3.8 becomes available (which is unfortunate because I was hoping to also resolve my vt1705 audio issues with the 3.7+ kernel). The bug referenced above alludes to issues in 3.7 with kms.

Just an FYI that neither linux 3.7.5 nor 3.7.6 fixes this issue. I have yet to try 3.7.7, but the Changelog doesn't mention any graphics fixes other than for Radeon, so it's a good bet that 3.7.7 doesn't fix it either.

Another FYI that linux 3.7.7 doesn't fix this issue either. linux 3.7.8 was just released but its Changelog shows fixes almost exclusively to network issues, with a single graphics fix for nouveau/drm - so, again, not much hope that 3.7.8 will make any difference.

Still holding at linux 3.6.11.

Apparently the last xf86-video-intel version + linux 3.7 + "video=LVDS-1:d" on the kernel command line finally results in a boot to a live screen instead of the black-screen-of-death. It also blacks out all boot logging to the screen after the modeset, so you lose half of the usual visual feedback, but its better than having to stay at linux-3.6.11.

Still not resolved, but better - at least there's a workaround. Lets hope linux-3.8 gives us a real fix.

Status on 3.8?

I have a similar issue with xf86-video-nouveau and dualhead. The second monitor never gets video with linux 3.7 or 3.8. Reverting to LTS allows it to work again.

Tobias - what is the status of 3.8? It's now flagged as mainline at kernel.org, so I'm expecting it to show up as an Arch update any time now. Any idea on the ETA?

Jeff, 3.8.1 is in the [testing] rep.

Thanks, Dale. That's great. I know quite a bit of work went into 3.8 to fix some kms anomolies introduced in the 3.7 series, so I'm very keen to find out if it fixes this issue. I'm also hoping that maybe some progress was made in the support of this crummy gma3600 chipset - not holding my breath though.

Jeff, Please try it and report back.

Will do. I'm about halfway thru a 3 hour distro build on that system at the moment, but will give it a try when it's done.

Well, that was disappointing. No change - still needs the "video=LVDS-1:d" or it boots to a blank screen. I've tryed a few different xorg.conf settings, specifically trying the fbdev and modesetting drivers, which "work" without the kernel command line mod, but not correctly - can't get it to sync. So, still stuck with vesa 800x600 and the LVDS kernel parameter.

You could always try to build nouveau from GIT and see if that helps:

http://nouveau.freedesktop.org/wiki/InstallDRM#out-of-tree_build_.28alternative.29

Unfortuntely, nouveau is for nVidia, I have an Intel gma3600 (or pvr gma500, however you want to look at it). Am extremely frustrated now. There are so many comments from others with the same chipset that the modesetting driver just works at the native resolution, but I'm still suffering from sync issues with mine. At this point, I've scavenged the edid data from windows and installed it in firmware/edid, added drm_kms_helper.edid_firmware=edid/1024x600.bin (the edid blob scavenged from windows), confirmed the edid is valid using parse-edid from ubuntu's read-edid package, and used the resulting monitor section in my xorg.conf. Everything lines up, Xorg.0.log is showing that it's properly loading the edid blob, it's using the correct modeline, the correct h & v frequencies, the correct display size, and it still won;t sync properly. Under openbox the bottom of the screen is continually flickering; in kdm, the bottom 2/3 of the screen is shunted up, overlapping the top 1/3 and leaving about a 1/4 inch of noise at the bottom; and in kde... it's just bad - split screen with noise bands at the bottom of the top half and the bottom half. Not sure where to go from here. It should be working flawlessly at this point.

Dale/Tobias - Unless someone else is having this same issue, I have to assume that this issue is probably closed. Unlike linux-3.6.11, one does now have to disable LVDS-1 from the kernel command line to get the default VESA 800x600 display, at least where the D2500/GMA3600 combo is concerned, but I'm no longer certain this is a bug.

I'm more concerned that my inability to get native resolution using the modesetting driver has something to do with lack of kernel-level (gma500_gfx/modesetting) support for the specific D2500/GMA3600 combo. From what I've been reading, only the D2500 and N2600 drive the GMA3600 at 400MHz. It'd be great to get some input from anybody else who has one of these combinations to see if they're having the same issues with timing/sync. Since others have been able to use the GMA3600 in native resolution using the modesetting driver, and given that, in my case, X is correctly probing the timing details and correctly decoding the EDID blob when provided but losing sync, that the issue must be at the kernel level and must have something to do with my specific hardware. Since the LVDS screen is standard and not likely to be the cause, that only leaves the GPU configuration - and the only difference between mine and most others is the graphics core engine frequency. When using the EDID blob, X is picking up every other detail right down to the gamma corrections and display size. I have done some poking around in the kernel gpu code for the gma500 and noted that it appears that the core is initialized to 200MHz (cdv_device.c - cdv_get_core_freq - used to set up the bios).

Anyway, I'm attaching my Xorg log - the one that uses the EDID blob, and the accompanying xorg.conf and a screen dump of my running parse-edid on the EDID blob in case anyone wants to take a look. I've also attached my non-EDID-driven xorg.conf and Xorg log for comparison. Otherwise I'm not sure where to go next with this. Maybe submit it as a kernel bug?

Sorry - one more thing I'd intended to add.

I downloaded the live images of all Linux versions that claimed to support the GMA3600 or GMA500, including MeeGo, Fedora, Ubuntu (12.04 and 12.10), Knoppix, Joli OS, LivePixie, and found they all had the same issue I'm seeing here. JoliOS and LivePixie came up using the default VESA 800x600, but all the others had the same timing/sync issue I'm seeing with Arch. The closest I got was Fedora that appeared to work fine until I actually opened an app, then all hell broke loose, graphically speaking... in the same way it all collapses in Arch/openbox with the app window header repeating 10 or so times down the screen. I even went so far as to install a 32-bit version of Arch in case the 64-bit kernel was causing the problem with the 32-bit GPU, but got the same results.

Thought it was interesting to see the same results across multiple OS's.

OK. I'm finally able to get native resolution using uvesafb/v86d and 915resolution. The performance isn't bad and the display is stable. Glxgears is showing over 100 FPS and video streams nicely in full screen.

I provided a new patch for 915resolution-static to handle the GMA3600 and you can find the packages and PKGBUILD archives at http://bluestarlinux.org/index.php?action=downloads;cat=312. I also wrote out configuration instructions in an article there as well, although the Arch Wiki instructions are probably more complete and better written (https://wiki.archlinux.org/index.php/Uvesafb).

Anyone else who has been experiencing the same problem with their gma3600 would well be advised to go this route. I've searched the internet over and found nothing that works properly using the xorg modesetting or fbdev drivers. I even built the cedarview_gfx kernel driver and its associated drm modules provided by thomas001 (http://gh.codehum.com/thomas001/cedarview-drm) and still couldn't acheive more than an 800x600 resolution with a stable display.

Hope that provides some much needed help for some folks.

Fixed the /usr/lib/initcpio/install/915resolution syntax, which appeared to be out-dated, updated the PKBUILD archive file and re-versioned 915resolution-static package to 0.5.3-10 with the syntax fix for both i686 and x86_64.

They're available at the same location - http://bluestarlinux.org/index.php?action=downloads;cat=312

Not sure if this article is saying these fixes will be available in linux 3.9 or 3.10, but it appears there is some new work from Intel for the GMA x3000 series coming:

http://www.phoronix.com/scan.php?page=news_item&px=MTMyMTQ

The one that caught my eye was the "VBlank fixes for old Intel "Gen2" through "Gen4" (GMA X3000 series) graphics" since this is, I believe, the "timing/sync" issuse I was talking about. I believe that with that fixed, the modesetting driver should work on the gma3600.

Just and FYI that 3.8.3 has the same problem - boots to blank screen without adding video=LVDS-1:d to the kernel command line.

Status on 3.9?

Still exactly the same. Need to add video=LVDS-1:d to the kernel command line options to get a resolution of 800x600. I'm current running linux 3.9.4 and using 915resolution to get a native resolution of 1024x600. Still need the kernel option though to get the gma500_gfx driver to work (with or without 915resolution). Don't know if this is a hardware issue, or a failure on the part of the video driver to recognize a certain hardware configuration. I do know that modesetting with this driver is pretty dodgy, so I'd be more inclined to chalk this up to a driver bug. Unfortunately there's not much work being done on the gma500_gfx driver now that Alan Cox is no longer in the picture. There has been exactly one fix made to this driver since the end of last year. I wish "they" would put someone on this driver full-time to clean it up once and for all, and maybe even add 3d acceleration.

Status on 3.10.x series?

Delay in response due to working on new distro release - probalem still exists.

I'm still having the same problem I was in Feb, but I'm not sure it's 100% related.

linux-lts 3.0.89-1
libdrm-nouveau1 2.4.33-1
nouveau-dri 9.1.6-1
xf86-video-nouveau 1.0.9-1

Comment by Dale Blount (dale) - Wednesday, 27 February 2013, 10:00 GMT-5 — Edit
I have a similar issue with xf86-video-nouveau and dualhead. The second monitor never gets video with linux 3.7 or 3.8. Reverting to LTS allows it to work again.

Possibly similar issue: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1041428

Still there, unfortunately, with a new green screen that appears just before it goes blank - so something's changed, but not fixed.

Dale - these are likely both KMS driver issues. The gma500 KMS driver has always been a little dodgy anyway, so it wouldn;t surprise me if that's where the issue lies. I use fbsplash to display a boot splash and the gma500 driver won't provide a seamless splash when the module name is added to the MODULES section of mkinitcpio.conf, like it's supposed to. I also have kms-related issues with pm-utils that I've had to hack around. Unfortunately, development on the gma500 driver has slowed to a crawl after the exit of Alan Cox, so as for my issue, the resolution might take awhile - not holding my breath anyway.

Status on 3.11.1?

Same issue with X startup when the "video=LVDS-1:d" boot param is removed. Not surprising since there has been little progress on the gma500_gfx driver. However, a developer has been assigned to this driver, and my understanding is that there will be some progress coming either in 3.11 or 3.12 vis-a-vis 2D acceleration. I do read through all the kernel changelogs to keep track of gma500 changes.

One interesting change I did see was that the boot splash reacted differently this time around - it looked as if KMS was working properly when the LVDS boot param was removed. Instead of going to a black screen after the initial driver load, it reloaded the splash screen, which is expected if KMS is working as it should.

So perhaps there has been some progress on the driver. I do know there were some fixes to gma500_gfx rendering that came through the changelogs a few minor revisions ago. I'm hoping there's some real work going on to fix this driver properly and that we'll see that come through within the next couple of months.

You need to get in touch with upstream developers, I cannot do anything here.