22:35:13 < keithp> we're looking forward to blowing away UMS shorly :-)
22:35:19 < jcristau> eww.
22:35:29 < jcristau> how shortly?
22:35:32 < keithp> jcristau: Q4
22:35:39 < keithp> so, end of december release
22:35:47 < anholt> jcristau: so, it sounds like debian kernels are moving to kms?
22:36:11 < remi`> keithp, kms+xv overlay ?
22:36:11 < jcristau> can't really turn kms on by default before the next stable
22:36:20 < anholt> even on unstable?
22:36:38 < jcristau> it's the same package that will end up in stable, so yeah
22:37:10 < keithp> remi`: we're putting together a list of gaps in the current KMS support; we'll try to fix most of them before releasing
22:38:41 < remi`> keithp, well there's this bug I reported a little while ago on 855, anholt bumped it to major but I don't know how/if it affects a lot of people
22:39:04 < anholt> remi`: cworth's supposed to be working on some 8xx issues right now
22:39:10 < remi`> so far only me and another fellow (Maxi) managed to reproduce it
22:39:13 < keithp> remi`: 8xx support is not just a KMS vs UMS issue at this point
22:39:32 < remi`> great to hear that :)
22:41:27 < cworth> remi`: I've got an 865 machine successfully reproducing "X locks up in less than 10 seconds with any rendering at all (2D or 3D)". So we clearly need to fix that.
22:41:47 -!- lavish_ [n=lavish@gentoo/user/lavish] has joined #intel-gfx
22:41:48 < remi`> anyhow, now it's mostly performance issues that are troubling a few users, I don't think I've had a crasher report in over a month or two
22:41:57 < sh> It would be nice to have some more bugfixes before you yank UMS out. KMS in 2.6.31-rc7 doesn't work for me at all.
22:42:17 < remi`> cworth, indeed, that's worse than 855
22:43:27 < remi`> keithp, ok so I should start asking people to test KMS too then. So far I've been telling users to try UMS first before doing anything else
22:43:43 < keithp> remi`: yup, UMS is going away as we've been promising for years now
22:44:11 < remi`> noted, it feels soon though
22:44:14 -!- lavish [n=lavish@gentoo/user/lavish] has quit [Read error: 148 (No route to host)]
22:44:34 < keithp> remi`: the alternative is to try and back-port patches from KMS to UMS, which is a huge pain
22:44:48 < remi`> yeah, it must be
22:45:15 < keithp> in particular, laptops will come with eDP panels, and UMS can't support that
22:45:35 < remi`> can't support it at all, or was the code only written for KMS?
22:46:42 < keithp> can't reasonably support as you have to retrain on unplug/replug, which is signalled with an IRQ
22:47:08 < keithp> also, yes, it's KMS only at present, and again, not interested in supporting two sets of similar-but-different code
22:47:20 < keithp> also, the driver is about to get a million times simpler
22:47:40 < keithp> that's the real goal here; reducing our code paths so everyone uses the same stuff and we can test things
22:48:25 < remi`> I fully understand, I saw the benefits of the first code removal, I think everyone did
22:50:17 < jcristau> sounds like that's going to be a pain for squeeze..  we'll need to figure out an upgrade path somehow..
22:52:29 < keithp> jcristau: you just can't push post-Q3 bits into testing as they'll depend on a newer kernel with KMS
22:52:35 < keithp> so, squeeze gets the Q3 bits
22:52:43 < keithp> I don't see a problem here
22:52:53 < jcristau> squeeze won't get released before end of 2010
22:53:01 < keithp> with which kernel?
22:53:05 < keithp> Surely something with KMS
22:53:23 < jcristau> (at least that's my guess)
22:53:45 < keithp> so the unstable->testing migration will block until a suitable kernel moves
22:54:03 < keithp> they can't freeze the kernel a year before the release, that's madness
22:54:38 < jcristau> yes, but it'd be nice to have userspace bits in squeeze that don't break when run on 2.6.26
22:54:52 < jcristau> which is what's in lenny
22:55:15 < keithp> 'nice' may not get his day in court this time
22:55:46 < anholt> yeah, given how 2.8 series runs 2.6.26...
22:56:05 < anholt> (upgrade to the vesa driver)
22:59:56 < jcristau> i guess it'd be possible to load vesa instead of intel if the kernel is too old?
23:00:18 < anholt> at this point, it would be a good idea
23:00:58 -!- gerhard7 [n=gerhard7@195-240-70-203.ip.telfort.nl] has quit ["Leaving"]
23:01:28 < remi`> I've had reports of vesa being faster than intel on a !drm kernel
23:01:44 < anholt> easily
23:02:57 -!- NexT||eVo [n=Ivan@kernelpanic.org.ru] has quit [Remote closed the connection]
23:04:10 < fritschy_> about that vesa being faster... how is that possible? ;) (i used vesa some time long when intel-drm wasn't running for me)
23:06:08 < anholt> because the fake bufmgr we use for ancient kernels is terrible.