[00:09] <bryce> if it's correct that it worked with alpha6 but not beta, then something is misfiring with how X is being set up.  hmm
[00:10] <bryce> the 1.5.1 merge was sep 24
[00:10] <bryce> timo put in a driver fallback patch sept 9, was that pre-alpha6 though?
[00:11] <bryce> tjaalton: you around? ^^
[00:11] <bryce> hmm, sept 9 was between alpha 5 and 6, so I don't think timo's patch would be to blame
[00:12] <bryce> lemme look at what went into 1.5.1
[00:14] <bryce> bdmurray: did you see any of the bugs where they posted an Xorg.0.log from their alpha6 session?
[00:14] <bryce> I'm wondering if previously the livecd put them on -vesa
[00:16] <tjaalton> bryce: there was a freeze exception for this
[00:16] <tjaalton> bryce: but it didn't get in for beta
[00:17] <bryce> tjaalton: oh you know of the fix?
[00:17] <tjaalton> bryce: it's committed alread
[00:17] <tjaalton> y
[00:17] <bryce> ah okay, what was the change?
[00:17] <tjaalton> jcristau knows more about it.. brown paper bag stuff :)
[00:18] <bryce> was it a fix to xorg-server or -nv or...?
[00:18] <tjaalton> the .ids -stuff didn't work like before
[00:18] <tjaalton> xorg-server
[00:18] <bryce> ahh
[00:19] <tjaalton> got to hit the hay, so.. have a nice weekend :)
[00:20] <bdmurray> I'm not sure I'm following everything, X is broken for some Live CD users with Beta?
[00:20] <bryce> ok, night
[00:21] <bryce> bdmurray: in the past, debian/ubuntu had it's own mechanism for mapping driver to pci id's
[00:21] <bryce> bdmurray: but with xserver 1.5, they've added code in the core system for doing this now
[00:22] <bryce> so debian has switched over to this new system, and apparently in doing so there was an issue that made it behave somewhat differently than the old system
[00:22] <jcristau> not quite
[00:23] <jcristau> when gravity's code went upstream, it was modified to look in some #defined location instead of hardcoded /usr/share/xserver-xorg/pci/
[00:23] <jcristau> except we didn't define it, so it didn't look anywhere at all
[00:24] <jcristau> bryce: btw look at NVIsSupported, it matches on id & 0xfff0, so it works on more cards than are explicitly listed
[00:26] <bryce> jcristau: hm, what was I not quite right about?
[00:26] <jcristau> that we switched to a new system
[00:27] <jcristau> it's the same system, just in the upstream tarball instead of debian/patches/ :)
[00:29] <bryce> bdmurray: anyway, so looks like that issue is what's causing the different detection behavior with the livecds
[00:29] <bryce> bdmurray: guess we'll be getting a lot of bug reports on this one
[00:30] <bdmurray> bryce: maybe we should get it added to the caveats then?
[00:30] <bryce> bdmurray: yeah
[00:31] <bryce> bdmurray: 261977 seems to be the master bug for this
[01:14] <bdmurray> bryce: so I'll mark bug 277452 as a dupe of 261977 and any others I find. sound good?
[01:18] <bryce> bdmurray: sounds very good
[01:19] <bryce> thanks for doing that
[01:19] <bryce> I'm working on a new git snapshot for -ati which should close a slew of bugs
[01:20] <bdmurray> bryce: yep, I might mail the bug squad too
[01:44] <wgrant> bryce: Are you aware of the -synaptics config GUI in System->Preferences-Mouse?
[01:44] <bryce> wgrant: yeah
[01:44] <bryce> wgrant: not familiar with the internals tho
[01:44] <wgrant> bryce: Just wondering why you advised LaserJock to write a fdi file for the config options exposed there.
[01:47] <bryce> wgrant: wasn't aware that synaptics was special cased
[01:48] <wgrant> bryce: Ah. Well, it turns out all of the options that he needed were exposed there.
[01:48] <bryce> great
[01:49] <bryce> mjg59 had written the synaptics gui earlier, but I didn't know it worked with input hotplug
[01:49] <wgrant> bryce: I ported it to XInput properties a couple of months ago.
[01:50] <wgrant> I believe we've even dropped the awful hack from -synaptics.
[01:50] <bryce> ok good, didn't know that
[01:52] <wgrant> LaserJock points out that we really need to fix up docs, as lots are broken by input-hotplug... I'm trying to update various Synaptics-related ones now.
[01:54] <wgrant> I wonder if I can get a UI freeze exception to add a couple of extra often wanted options to the GUI (two-finger scrolling).
[01:55] <bryce> worth a try
[01:56] <wgrant> Is that an ubuntu-release question, or some docteam?
[02:03] <bryce> hmm, I'm not sure who officially approves UI freeze exceptions, but I'd probably start by asking slangasek
[02:04] <wgrant> I just did. Thanks.
[02:10] <bryce> jcristau, tjaalton: how's -nouveau coming along in your opinion?  something we should look at for intrepid?
[02:21] <bryce> ok, sync'd it from experimental
[08:20] <tjaalton> bryce: haven't tried for a while, but it needs a snapshot of libdrm to be useful
[08:42] <tjaalton> *in a while..
[13:53] <jcristau> bryce, tjaalton: not just libdrm, nouveau needs drm modules from git
[13:58] <tjaalton> oh that too
[15:20] <tseliot> tjaalton: I'm thinking of removing (i.e. not including) nvidia-xconfig in the nvidia packages. This would fix https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/248327
[15:21] <tseliot> I'm also working on this (a FFE will be required for a new upstream release): https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/274866
[15:21] <tseliot> tjaalton: what do you think about the problem with nvidia-xconfig?
[15:34] <tjaalton> tseliot: if there's no source for -xconfig, then dropping it might be wise
[15:36] <tseliot> tjaalton: the source is not in the nvidia installer. There is only a binary "nvidia-xconfig"
[15:36] <tjaalton> tseliot: ok, but the -settings one should be fixable?
[15:37] <tseliot> tjaalton: yes, I have packaged a new release
[15:37] <tseliot> which solves the problem (at least the changes in code seem to suggest that the problem is solved)
[15:45] <superm1> tjaalton, tseliot and i were talking about the repercussions of removing nvidia-xconfig.  there are some projects that use it still (but not explicitly in rdepends), so I proposed a compatibility shim instead 
[15:45] <superm1> that uses xkit to turn on the driver
[15:45] <superm1> at least basic functionality - not reimplementing "all" of nvidia-xconfig
[15:46] <tseliot> tjaalton: we should add a dependency on python-xkit (which is in main) and install a script named nvidia-xconfig to /usr/bin which enables the nvidia driver
[16:50] <mnemo> does the x.org intel driver use a frame buffer by default?
[17:31] <tjaalton> superm1, tseliot: ok, sounds like a plan
[17:45] <tseliot> ok
[17:46] <tseliot> I'll work on it
[18:45] <mnemo> if I disable DRI for the intel driver, am I still using the code from the drm and mesa repositories listed here: http://www.intellinuxgraphics.org/download.html
[18:45] <mnemo> ??
[18:46] <tjaalton> mnemo: no
[18:52] <crevette> hello
[18:52] <crevette> is an ubuntu repository for intel driver snapshots?
[18:57] <tjaalton> crevette: not that I know of
[18:58] <crevette> hello tjaalton
[18:58] <mnemo> tjaalton: so if DRI is disabled and I dont have the "drm" kernel module loaded... how does the xserver communicate with the graphics card?
[18:59] <tjaalton> mnemo: um, with the intel DDX driver?
[18:59] <mnemo> tjaalton: so basically the xserver is sending data directly to the graphics card then?
[19:00] <jcristau> well, yes, that's what a driver does..
[19:04] <mnemo> I got a crash on intel G45 hardware with DRI off and EXA (no compiz) and this is my xorg.log --> http://rafb.net/p/RVwNLB13.html
[19:05] <mnemo> so can I be sure that this bug is in the 2D xorg driver for intel? i.e. the xserver-xorg-video-intel code??
[19:06] <jcristau> pretty much
[19:06] <tjaalton> AIUI even the 2.5 prereleases still have bugs with G45
[19:06] <mnemo> yes I tried git head as well, same bug
[19:07] <mnemo> im trying to analyze it though so I can file a usable bug report
[19:07] <tjaalton> you should probably file it upstream too
[19:07] <mnemo> yup
[19:07] <tjaalton> thanks :)
[19:09] <mnemo> from the xorg log it seems that the ring buffer (used for sending commands to the GPU) becomes full and the intel driver loaded into xorg waits for 2 seconds and then it assumes something it wrong because the ring buffer is not being emptied/processed
[19:10] <mnemo> the code refers to this buffer as an "LP" buffer, do you know what LP means in this context?
[19:10] <mnemo> I tried to read the intel docs but "LP" is not mentioned in there
[19:14] <tjaalton> no idea