Hi Ben,
Please consider
cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29
for application to the 3.2.y tree. It adds a PCI id to the i915 driver, making kms work. It was applied during the 3.4-rc2 cycle, so newer stable kernels don't need it.
Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok (thanks!).
Note that pre-2.4.34 versions of libdrm don't cope well with that card, with or without this patch:
- without this patch, modern X errors out instead of starting, because the intel driver requires kms. (In a hypothetical better world, userspace would know to fall back to vesa or something.)
- with this patch and with libdrm patch 2.4.34~22 (intel: add Ivy Bridge GT2 server variant, 2012-03-29), X should work great
- with this patch, without libdrm 2.4.34~22, but with libdrm patch 2.4.38~10 (intel: Bail gracefully if we encounter an unknown Intel device, 2012-07-25) applied, X should error out instead of starting
- with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10, X freezes at startup.
"No regressions" means you probably shouldn't take this patch without a safety to work around the old X userspace, unless you can shout enough in release notes to get people to apply 2.4.38~10 to libdrm and maintain sanity. ;)
Hmm? Jonathan
On Sun, 07 Oct 2012 15:01:17 +0100, Ben Hutchings ben@decadent.org.uk wrote:
The bugs Jonathan mentions are both in userspace packages; not recognising the existence of Bromlow, and then misprogramming it. There are no other kernel patches required specifically for this chipset, afaik. -Chris
On Sun, 2012-10-07 at 15:11 +0100, Chris Wilson wrote:
Yes, I understand that.
If upgrading the kernel currently triggers a (more) serious bug in typical userland then the kernel should work around that. If I've misunderstood, and the userland behaviour is roughly equally broken with or without this change, then I'll be happy to take it.
Ben.
On Sun, Oct 7, 2012 at 7:26 PM, Julien Cristau jcristau@debian.org wrote:
There's a corner case when X and the kernel know about the graphics device, but libdrm doesn't, in which case an assertion in the X driver fails and X doesn't start. Upstream libdrm has been okay for a few releases. A bug against Debian libdrm has been open for a while, but they seem to disagree about the importance, nothing has happened. In fairness, this device seems to be rare so far. I'm not really using mine any more, I put an extra graphics card in the box.
Maik Zumstrull wrote:
On Sun, Oct 7, 2012 at 7:26 PM, Julien Cristau jcristau@debian.org wrote:
On Mon, Oct 1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote:
[...]
I think Julien means the case where the kernel does not know about the graphics device. From [1]:
| 3.2 crashes as well, but not as hard as 3.4. With 3.2, X doesn't come | up, but you can switch to a console and reboot. 3.4 needs the reset | button.
X should have been able to start using the vesa or fbdev driver. I'm not sure why that doesn't happen --- do you have an Xorg log from booting and trying to start X with a 3.2.y kernel without the "drm/i915: add Ivy Bridge GT2 Server entries" patch?
Thanks, Jonathan
On Sun, Oct 7, 2012 at 7:44 PM, Jonathan Nieder jrnieder@gmail.com wrote:
No, and it would be a bit of fiddling to get one. Like I said, I've modified that system with a graphics card since. If it's important, I could get it done, but probably not next week, I'll be traveling and otherwise busy.
dri-devel@lists.freedesktop.org