[00:13] <Ng> well going by Xorg.0.log it does seem like the trackpoint device appears again after resume
[00:16] <bryce> tjaalton: do you know of any other major issues we absolutely must sort out before the beta freeze tonight?
[02:13] <bryce> tjaalton: when you do the mesa upload, would you mind checking these fedora patches and mark them 'reviewed' if we don't need them?  http://daniel.holba.ch/harvest/handler.py?pkg=mesa
[03:30] <DBO> hey all
[03:30] <bryce> hi
[03:30] <DBO> mind giving a bit of help trying to get a more recent i915.ko?  suspend is broken on my system when the drm module is loaded
[03:31] <DBO> so I am trying to get things a bit more up to date (I should mention I am already on intrepid)
[03:32] <bryce> sorry, pretty busy atm (beta-freeze is tonight).
[03:33] <DBO> =/ does that mean that suspend bugs will not be fixed?
[03:34] <bryce> if you have a patch ready, I can look at putting it in
[03:35] <DBO> unfortunately no, I am only just now figuring out what is causing the problem
[03:35] <DBO> but it seems to be somehow related to DRM not suspending pretty
[03:35] <bryce> although most suspend bugs are kernel issues so you'd probably need a kernel engineer to approve your patch
[03:35] <DBO> it is a kernel module bug
[03:35] <DBO> drm.ko
[03:36] <bryce> you probably need the kernel guys then
[03:46] <DBO> bryce, do you know what version of X i need for GEM?
[04:17] <pwnguin> bryce: hope you get better luck working with linuxwacom than i did =/
[04:45] <bryce> pwnguin: do tell?
[04:47] <pwnguin> well, ive tried forwarding bugs to their tracker, but they basically said not to use the bug tracker.
[04:47] <pwnguin> (should it come with a INTERNAL USE ONLY notice?)
[05:00] <bryce> huh
[05:00] <bryce> so why don't they disable it?
[05:00] <bryce> *boggle*
[05:18] <pwnguin> maybe i'm just extra stupid
[05:21] <pwnguin> http://sourceforge.net/tracker/index.php?func=detail&aid=1987565&group_id=69596&atid=525124
[06:50] <tjaalton> bryce: I already uploaded it :)
[06:51] <tjaalton> bryce: but i'll have a look at those patches
[06:51] <tjaalton> bryce: also, wacom is busted for some weeks now
[06:51] <tjaalton> since the 0.8.1.3 upload (which was requested by many..)
[06:52] <tjaalton> kernel support is lacking
[06:52] <tjaalton> but I'll package 0.8.1.4
[06:52] <tjaalton> maybe we can get the kernel driver synced to that
[07:05] <tjaalton> bryce: should we just drop -unichrome from the archive?
[07:08] <tjaalton> upstream has ported it to libpciaccess, but still..
[09:03] <soren> tseliot: you said you sent me an e-mail.. I don't think I see it. To which address did you send it?
[09:04] <tseliot> soren: sorry, I meant Soren Sandmann, the maintainer of the Screen Resolution capplet
[09:04] <soren> tseliot: Oh. haha!
[09:04] <tseliot> ;)
[09:04] <soren> tseliot: I'm just so used to being the only one called Soren around these parts.
[09:05] <soren> No worries :)
[09:05] <tjaalton> pwnguin: wacom-tools uploaded, and a patch being sent for kernel-team
[09:06] <tseliot> soren: I can understand you. I bet there aren't many people named Alberto around either ;)
[09:06] <soren> tseliot: :)
[10:49] <Ng> so whoever writes the xinput thing is going to be my newest hero, losing the scrolling after each suspend is starting to really annoy me, and I was only just getting used to not having the scrolling at all ;)
[13:38] <tjaalton> soren: https://bugs.freedesktop.org/show_bug.cgi?id=17468
[13:40] <soren> GTK_IM_MODULE=xim doesn't help.
[13:41] <soren> Also, my problem is the opposite (I have no dead keys at all).
[13:41] <soren> ..but I understand that the problems might have been related.
[13:42] <tjaalton> hum, ok
[13:42] <soren> tjaalton: Heh..
[13:43] <soren> xev says "dead_acute", when I press the dead acute button.
[13:43] <soren> I'm not entirely sure what to make of that. :)
[13:48] <tjaalton> that's what I get as well, so.. really strange that it doesn't work for you
[14:07] <MacSlow> yo there
[14:07] <tjaalton> wazzup?
[14:09] <MacSlow> hopefully not much (at least bug-wise)
[14:09] <tjaalton> MacSlow: oh, I thought you had a problem ;)
[14:10] <MacSlow> tjaalton, I used to have (Xorg didn't come back after gnome-screensaver blanking) but after yesterdays update it didn't happen again
[14:11] <tjaalton> MacSlow: with intel? that was fixed before alpha6
[14:11] <MacSlow> tjaalton, oh yeah sure it was on X3100/G965
[14:14] <tjaalton> MacSlow: yep, vblank broke it
[14:24] <MacSlow> i see
[14:25] <MacSlow> bryce, you know if cworth can or cannot come to FOSScamp/UDS?
[14:46] <Ng> seb128: fyi, I don't appear to be able to reproduce bug #173350 in intrepid, but I was definitely getting it on this machine in hardy
[14:48] <seb128> Ng: good, close the bug maybe then ;-)
[14:49] <Ng> yeah, I thought just after I hit enter "wtf am I telling him on IRC" ;/
[14:49] <seb128> ;-)
[14:59] <Kano64> hi, just tested latest daily with my nvidia 8800 gts and without binary driver i get just black screen
[14:59] <Kano64> http://paste.ubuntu.com/50492/
[14:59] <Kano64> thats the logfile, i see basically no error,but i see nothing.
[15:00] <Kano64> monitor is just black, 19" crt
[15:02] <tjaalton> a CTX from '98?
[15:02] <Kano64> yes, it is pretty old
[15:03] <Kano64> i guess the card tries to use digital port not the vga one
[15:03] <Kano64> (II) NV(0): Output DVI1 connected 
[15:03] <Kano64> but i use a dvi->vga connector
[15:05] <Kano64> i can install binary drivers and then i see something
[15:06] <tjaalton> they probably have some quirks for such monitors
[15:06] <Kano64> http://paste.ubuntu.com/50495/
[15:07] <Kano64> thats with binary driver
[15:08] <Kano64> (II) NVIDIA(0): Assigned Display Device: CRT-1 
[15:09] <Kano64> the old crt is detected as dvi with the oss driver
[15:09] <tjaalton> nv is crap
[15:09] <Kano64> it should be fixed...
[15:09] <jcristau> Kano64: bugs.freedesktop.org is ----> that way
[15:10] <tjaalton> you could try a newer driver.. .12 available
[15:10] <tjaalton> we have .10
[15:10] <Kano64> is there a deb
[15:10] <tjaalton> no
[15:18] <Kano64> so packaged .12, will try now
[15:19] <Kano> tjaalton: nv .12 does not help
[15:20] <Kano> have to go,bbl
[15:25] <mvo> so what happens if a driver (say "ati") does understand options in the "device" section (because this section was e.g. switched from fglrx to ati) - does the driver just ignore the unknown options (my tests indidcate this is the case)
[15:27] <jcristau> yes
[15:53] <mvo> excellent, thanks! 
[16:48] <Le-Chuck_ITA> Hi all. Do you think git://git.freedesktop.org/git/xorg/driver/xf86-video-intel is the correct git master for xserver-xorg-video-intel? I am a bit confused by the "xf86" at the beginning of the module name
[16:48] <Le-Chuck_ITA> I need to test that to complete a bug report against 
[16:48] <Le-Chuck_ITA> X
[16:49] <jcristau> use anongit.fd.o rather than git.fd.o, but otherwise yes
[16:50] <Le-Chuck_ITA> I used "git.fd.o" and it worked :) should I redownload or is it just a matter of resource usage?
[16:50] <jcristau> it's ok
[16:52] <Le-Chuck_ITA> aargh. I installed build-deps but it requires librdm 2.4. Am I going into a hell of unsatisfied dependencies? If so I have to decline the request
[16:52] <jcristau> libdrm should be all you need
[16:53] <jcristau> git clone git://anongit.freedesktop.org/git/mesa/drm
[16:58] <Ng> isn't there some magic you need to do to build current libdrm without GEM?
[17:10] <tjaalton> Ng: apart from patching the source, doubtful
[17:10] <tjaalton> configure checks that you have >= 2.4.0
[17:10] <jcristau> libdrm doesn't have any build-deps...
[17:13] <Ng> hrm, ok, I did vaguely give it a try and didn't get very far, but that may have been my fault ;)
[17:26] <tjaalton> superm1: hey, I uploaded a new fglrx-installer earlier today, and added the Provides: xserver-xorg-video-2, which should prevent upgrades hosing the machine
[17:26] <superm1> tjaalton, yeah i saw.  that's a good solution for now
[17:26] <superm1> i was thinking about another thing here
[17:27] <tjaalton> ie. it should be removed on upgrade from hardy
[17:27] <tjaalton> ok, shoot
[17:27] <jcristau> the hardy version provides -video-2 too?
[17:27] <superm1> tjaalton, bryce tseliot would it be possible to ship an fdi file that set xorg.conf options for enabling the nvidia driver instead?
[17:27] <superm1> and fglrx when it's fixed
[17:27] <tjaalton> jcristau: yes, it does
[17:27] <jcristau> ok :)
[17:28] <superm1> since so many other things can be turned on/off via fdi files, it seems like it should be sensible enough to do for X proprietary drivers too
[17:28] <tjaalton> superm1: unfortunately driver properties aren't supported yet
[17:28] <superm1> tjaalton, oh i see
[17:28] <tseliot> too bad
[17:28] <tjaalton> er, video driver properties
[17:28] <jcristau> superm1: xorg only uses hal for input devices
[17:28] <superm1> jcristau, ah i see
[17:29] <tjaalton> I asked about it a couple of weeks ago, and it's WIP
[17:29] <jcristau> maybe you could ship /usr/share/xserver-xorg/nvidia.ids though
[17:30] <jcristau> with the pci ids of the supported chips for the driver, if you have that
[17:30] <superm1> perhaps that'd be something that can be something that should be looked at UDS this winter again then, see where it's at and if there is anything that can be helped from this level to push it along
[17:30] <superm1> jcristau, i tried to do that with fglrx at one point a couple of months ago, and it didn't work as gracefully as you'd hope
[17:30] <tjaalton> there's a commit in xserver master (and in our package too..) that allows to use a list of drivers to try for a given hw vendor
[17:31] <tjaalton> too bad that it's useful only if there's no xorg.conf at all
[17:31] <tseliot> too bad we have 4 versions of the same nvidia driver
[17:32] <tseliot> the module is named "nvidia" in all cases
[17:32] <superm1> what's the game plan for those 2 non functional versions?  they stay in the archive?
[17:32] <superm1> tseliot, well for that idea of nvidia.ids, it would be included in each of the packages for the nvidia driver 
[17:32] <superm1> so you'd only have that functionality working when the driver was to be installed
[17:32] <tseliot> I was planning to blacklist those 2 drivers in jockey
[17:32] <superm1> well you don't really have to blacklist, can't you just not install their modaliases?
[17:33] <tjaalton> jcristau: actually, there are some bugs that suggest that the ids are not used at all with 1.5..
[17:33] <tseliot> superm1: ah, right
[17:33] <jcristau> tjaalton: that's quite possible...
[17:33] <tjaalton> jcristau: and instead the vendor id and the driver is loaded even if it doesn't support it
[17:33] <jcristau> oh well.
[17:34] <tjaalton> there's one annoying bug where it loads nv and it fails miserably
[17:34] <tseliot> superm1: I can change the dependencies of nvidia-common
[17:35] <tseliot> tjaalton: that might be because the nvidia module gets loaded first?
[17:35] <tseliot> not that it makes any sense
[17:36] <jcristau> or it might be because it's a card that's not supported by nv, and they would be better off with vesa
[17:38] <tjaalton> even the fallback-patch won't help there, since vesa can't initialize after nv has poked it
[17:38] <tjaalton> tseliot: no, nvidia supports it fine
[17:39] <jcristau> tjaalton: uh. i thought you aren't allowed to touch the hardware in preinit...
[17:39] <tseliot> tjaalton: which bug is it?
[17:40] <tjaalton> bug 261977
[17:40] <tjaalton> it's quite messy
[17:42] <tjaalton> the log in https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/261977/comments/23
[17:42] <tjaalton> it might be something different though
[17:45] <tseliot> maybe it relies on the fact that the card id begins with 10de?
[17:45] <tseliot> I haven't read the code that does autodetection
[17:45] <tjaalton> yes, that's with the patch
[17:45] <tjaalton> so the detection part works ok, but vesa doesn't work
[17:46] <jcristau> tjaalton: looks like we're not setting PCI_TXT_IDS_DIR?
[17:46] <tseliot> so if it's an NVIDIA card the nv driver is loaded even if the card is not supported???
[17:46] <jcristau> tseliot: correct
[17:46] <jcristau> which makes sense, if you're able to fall back to vesa
[17:47] <jcristau> if you're not, then it leads to epic fail
[17:47] <tseliot> are we sure that the fall back mechanism works?
[17:47] <jcristau> timo says it doesn't
[17:48] <tseliot> tjaalton: can I see the patch, please?
[17:48] <tjaalton> tseliot: it's in xorg-server
[17:48] <tjaalton> patch 141 IIRC
[17:49] <tjaalton> it's only functional if there's no xorg.conf
[17:49] <tjaalton> so even without it the autoloading is busted
[17:49] <tjaalton> what we had already in hardy
[17:51] <jcristau> i'll unbreak the .ids stuff for -2..
[17:52] <jcristau> this is brown paper bag material
[17:53] <tjaalton> heh, ok
[17:53] <jcristau> (testing now to make sure...)
[17:54] <tjaalton> I'll also drop that patch since it didn't prove to be that useful
[17:57] <jcristau> should be easy to change autoConfigDevice to add new device sections for the fallback drivers, in addition to the chooseVideoDriver() one
[17:59] <jcristau> too much stuff on the todo list :/
[18:01] <mvo> will fglrx be loaded automatically if it is instaleld and no xorg.conf is provided?
[18:03] <superm1> mvo, no not at this point 
[18:03] <bryce> mvo, don't think we're there yet
[18:03] <bryce> but tjaalton put in a patch a few weeks ago that moves us towards being able to do that
[18:03] <mvo> thanks, makes my life easier :)
[18:05] <bryce> mvo, btw did you get my patch for blacklisting compiz on eaglelake?
[18:06] <jcristau> tjaalton: pushed the fix.
[18:15] <mvo> bryce: yes, thanks, I haven't put it in yet though
[18:15] <bryce> mvo, great thanks
[18:27] <bryce> Freeze is in effect
[18:53] <federico1> hmm, what's mpt's email?
[19:10] <Kano> hi tjaalton , do you have got the 2 pastebins with the xorg log files of my nv card?
[19:11] <Kano> or somebody else
[19:12] <superm1> Kano, if you posted them here, they should have been caught by the log bot
[19:12] <superm1> !logs | Kano 
[19:14] <Kano> thx
[19:15] <bryce> federico1: mpt@canonical.com maybe?
[19:16] <bryce> federico1: yep.  matthew.thomas@canonical.com and mpt@myrealbox.com shoudl work too
[19:36] <federico1> bryce: great, thanks
[20:44] <tjaalton> jcristau: heh, that was simple
[20:44] <tjaalton> bryce: actually, currently it only works when there's no xorg.conf, but if jcristau is right that should be fixable
[20:45] <bryce> tjaalton: which what?
[20:45] <tjaalton> bryce: the autoconfig patch
[20:45] <bryce> ahh
[21:20] <tjaalton> hum, so tdfx doesn't like xserver 1.5 either
[21:35] <superm1> tjaalton, did you say you have a solution for when nv is getting selected when it shouldn't?
[21:35] <superm1> i've got hardware exhibiting such a problem..
[21:36] <superm1> makes it quite difficult to boot up intrepid alpha6 live disk :)
[21:37] <Kano> add S
[21:37] <superm1> S?
[21:37] <Kano> single mode
[21:38] <Kano> or does forcevesa still work
[21:39] <superm1> well i hand modified it - but the point is that it tried to use nv when it shouldn't have
[21:39] <superm1> nv doesn't support this device yet
[21:43] <tjaalton> superm1: yes, merge the latest commit to xorg-server in experimental
[21:43] <tjaalton> which jcristau did a couple of hours ago
[21:43] <superm1> tjaalton, it's not critical (i can work around it for now), so i'll be glad to test it when it's in a package form
[21:44] <tjaalton> superm1: will be in for beta
[21:44] <superm1> i added my log to the bug, but i suppose not necessary anymore
[21:44] <superm1> okay :)
[21:44] <tjaalton> looks like libx11 also has a memory leak that's fixed, so that should be synced again :)
[21:45] <superm1> tjaalton, given that beta freeze is active, you might want to make sure you remember to milestone bug 261977 so that it gets put in place
[21:46] <tjaalton> superm1: sure
[21:47] <Kano> usually nv is chosen when the vendor is nvidia
[21:47] <superm1> Kano, but if the nv driver doesnt support your card yet, your only option will be vesa
[21:48] <Kano> yes, that should be better. or let the fallback handle it. i have got a differnt problem
[21:49] <Kano> nv card 8800 gts 512, edid is correctly read out, xorg logfile is fine, but dvi is selected not vga. only binary driver handles it correctly
[21:49] <Kano> maybe it is the same case for your card? what says the log?
[21:49] <superm1> (WW) NV: Ignoring unsupported device 0x10de0866 at 03@00:00:0
[21:50] <Kano> and fallback is not used?
[21:50] <superm1> well it goes into the failed graphics, do you want to reconfigure
[21:51] <superm1> but reconfiguring just rewrites out an xorg.conf that doesn't specify the driver, so it will boot nv the next time still
[21:51] <Kano> no vesa force mode?
[21:51] <superm1> i didn't see that on the list of options in the failed graphics screen
[21:52] <superm1> but i can of course switch to a vt, hand write in vesa and get things up
[21:52] <Kano> did you try the old forcevesa option
[21:52] <superm1> and that's what i did
[21:52] <Kano> i think that also does not work
[21:52] <superm1> i haven't tried xforcevesa in a long time 
[21:52] <superm1> i'm not sure 
[21:59] <Kano> i dont think it works