[01:09] <Sarvatt> apw: do you think we could bring the karmic kernel to the jaunty in edgers? that would make packaging easier and everyone using it would be using the kernel most likely anyway
[01:10] <Sarvatt> cworth mentioned it in his latest blog post and it seems like a good idea to me - http://cworth.org/intel/driver_stability/
[01:11] <Sarvatt> theres some problems on the intel side using the jaunty config the mainline PPA kernels use and activating KMS, plus it would get rid of the trickery we have to do replacing linux-libc-dev on jaunty for building libdrm
[01:13] <Sarvatt> is there any trickery needed to build them on a PPA or can we just copy them straight from the archive?
[01:14] <Sarvatt> hmm i guess LPIA might be a problem
[01:17] <bryce> what I've heard is that building kernel debs is really not much different than other packages, however I've not given it a try yet myself
[02:28] <Sarvatt> well, going to copy it over since it'll take a few hours to build so it'll be ready to repackage stuff against it tomorrow morning. hopefully someone will be around to delete it if anyone pops on and has it break things or if it was a bad idea for other reasons :D
[02:28] <bryce> :-)
[02:28] <bryce> fwiw, I'm going to be away the next few days.  Going up to Seattle for my sister's graduation
[02:36] <Sarvatt> ohh, have a good trip! hopefully alpha 2 wont be so bad for bug reports so you wont have to come home to a mess :D
[02:36] <bryce> hehe
[06:49] <tjaalton> whee, wacom moving to fd.o
[06:49] <tjaalton> and apparently getting support for input properties
[07:54] <pwnguin> tjaalton: orly?
[08:00] <tjaalton> pwnguin: yep, ping posted on xorg-devel about it
[08:01] <tjaalton> and about changing the license gpl->mit
[08:23] <apw> Sarvatt, we would likely want to rebuild it, but otherwise it should be doable.
[18:49] <Sarvatt> hmm  i see xserver-xorg-video-nv doesnt have any support for 7xxx and newer IGP chipsets in it, anyone know if thats by design or just missing pciids?
[18:50] <jcristau> hmm?
[18:51] <tjaalton> Sarvatt: does anyone care?-)
[18:52] <Sarvatt> well its picking nv on startup for alpha 2 instead of vesa so theres alot of people having problems with it - http://launchpadlibrarian.net/27754976/XorgLog.txt
[18:52] <tjaalton> we should switch to nouveau instead
[18:53] <jcristau> Sarvatt: that's fixed by removing xorg.conf
[18:53] <tjaalton> that too
[18:54] <jcristau> and yeah, the status of nv looks like nvidia wants people to switch to nouveau
[18:54] <Sarvatt> thats weird, livecd-rootfs should be deleting and touching an empty xorg.conf looking at the code for that
[18:55] <tjaalton> yep, our xorg is buggy
[18:55] <tjaalton> fixed in debian
[19:11] <Sarvatt> ah i see, fedora-pci-primary.diff
[19:11] <tjaalton> no, the logic in xserver-xorg.postinst was busted
[19:15] <jcristau> plus preinst was creating an empty xorg.conf
[19:15] <tjaalton> yeah
[19:29] <tjaalton> Sarvatt: what bug # was that?
[19:30] <Sarvatt> https://bugs.launchpad.net/bugs/385658
[19:30] <ubottu> Launchpad bug 385658 in xorg-server "karmic alpha2 candidate doesn't boot up on Studio XPS 1340" [Undecided,New]
[19:30] <tjaalton> thanks, I'll add a bug-closer for that
[19:37] <tjaalton> Sarvatt: in this case it tried to use the wrong device, so you were right that the patch makes a difference
[19:46] <jcristau> that bug shows that dexconf was run, somehow
[19:46] <jcristau> how did that happen?
[19:48] <superm1> live cd
[19:49] <superm1> just booted up off the karmic a2 candidate and hit a failure
[19:49] <superm1> i'd guess that dexconf runs because of casper?
[19:51] <superm1> casper runs the equivalent of dpkg-reconfigure xserver-xorg
[19:52] <superm1> and the xserver-xorg postinst runs dexconf
[19:54] <jcristau> it shouldn't. but maybe karmic a2 had an older version that still did that.
[19:55] <tjaalton> yeah could be
[19:56] <tjaalton> it isn't run when doing a preseeded installation
[19:56] <tjaalton> but a "normal" installation apparently runs it
[19:56] <superm1> so should dpkg-reconfigure xserver-xorg not be called out by casper anymore then?
[19:56] <tjaalton> it'll be unnecessary soon
[19:56] <superm1> just drop the 20xconfig?
[19:57] <tjaalton> although I'm not sure what bryce thought about it..
[19:58] <superm1> well what about that problem at hand though. that fallback to vesa? did that ever get submitted upstream? was there a reason they said no?
[19:58] <jcristau> superm1: in latest sid dpkg-reconfigure xserver-xorg basically doesn't do anything
[19:59] <superm1> yeah then 20xconfig makes very little sense to keep once next merge happens
[20:00] <tjaalton> superm1: in this case it matches the G98 device, which nv does support, but the server tries to use the C79 one
[20:01] <superm1> it's a hybrid device, so i'd guess the one selected is the primary one hooked up to the display
[20:02] <tjaalton> you never know for sure how the autoconfig logic works ;)
[20:07] <jcristau> 'not quite always sanely' :)
[20:08] <tjaalton> once we stop using the .ids files it'll be a lot simpler :)
[20:08] <tjaalton> and without the conffile
[20:08] <jcristau> yeah it's mostly the conffile
[20:27] <superm1> so all .ids are going away then?
[20:27] <tjaalton> yes
[20:37] <hyperair> if the .ids go, then how will xorg determine which driver to load?
[20:39] <tjaalton> the server knows what driver to try
[20:39] <tjaalton> based on the vendor id
[20:39] <tjaalton> and if that fails, it'll fall back to whatever is the fallback driver for that platform
[20:39] <tjaalton> for x86 it's vesa
[20:40] <tjaalton> but it only works if there's no conffile at all
[20:40] <tjaalton> even if it's empty, the codepath is different
[20:43] <hyperair> ah i see
[20:44] <hyperair> and about x64?
[20:44] <tjaalton> the same
[20:44] <tjaalton> but ppc, sparc use something else
[20:44] <tjaalton> for instance
[20:46] <tjaalton> well, sparc has wsfb, the rest use fbdev
[20:46] <Sarvatt> if thats the case, might need to change things here for the livecds? http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/annotate/head%3A/livecd.sh  -- line 477
[20:46] <jcristau> tjaalton: wsfb is only on solaris iirc
[20:47] <tjaalton> jcristau: right, for linux it's sunffb
[20:47] <tjaalton> #elif defined(__sparc__) && !defined(sun) matches[i++] = xnfstrdup("sunffb");
[20:48] <tjaalton> Sarvatt: uh.. madness
[20:49] <jcristau> tjaalton: made sense when xserver-xorg.preinst did the same thing :)
[20:52] <tjaalton> jcristau: hmm yeah, I remember that now
[20:53] <jcristau> awful hack though
[21:19] <superm1> tjaalton, well when uEFI comes around with no BIOS compatibility mode, VESA doesn't exist on x86
[21:19] <superm1> you have to use fbdev
[21:20] <tjaalton> superm1: heh, ok
[21:22] <superm1> which unfortunately will be coming sooner than I hope
[21:25] <tjaalton> oh, when exactly?-)
[21:26] <superm1> soon enough that i have a roadmap for such things happening
[21:29] <bdmurray> bryce: bug 357901 looks like an x bug and has a patch even.
[21:29] <ubottu> Launchpad bug 357901 in ubuntu "xinerama mouse cursor on every screen" [Undecided,Confirmed] https://launchpad.net/bugs/357901
[21:40] <tjaalton> bdmurray: I'll reassing it to xorg-server
[21:40] <tjaalton> -sign
[21:40] <tjaalton> heh, I've done that before
[23:14] <virtuald> is it possible to choose screen resolutions for radeon kms boot? i have two monitors of different sizes