[00:00] <stgraber> bryce_: I just removed and reinstalled the driver with fglrx, removing my xorg.conf after the uninstall. It didn't create a new one ...
[00:01] <stgraber> s/with fglrx/with jockey/
[00:02] <stgraber> but I see the code that should generate it, so maybe I still don't have the new jockey (my system is supposed to be up to date)
[00:03] <stgraber> Ah, just found the reason of why it wasn't in jockey. Jockey displays fglrx only if you are using something else than radeon
[00:04] <stgraber> in my case radeon works, I just don't have XV, DRI, ... working
[00:05] <superm1> make sure you have fglrx-modaliases installed stgraber 
[00:06] <stgraber> I do
[00:06] <stgraber> stgraber@castiana:~$ dpkg -l | grep fglrx-modalias
[00:06] <stgraber> ii  fglrx-modaliases                          2:8.543-0ubuntu1                      Identifiers supported by the ATI graphics dr
[00:08] <superm1> interesting.
[00:11] <stgraber> superm1: http://paste.ubuntu.com/57637/
[00:13] <superm1> stgraber, right so that doesn't force it upon you, but you should still be able to activate it as an available driver in jockey
[00:13] <superm1> eg it should be listed
[00:17] <stgraber> right, well now I have it listed by jockey but I'm not sure if that's because I'm actually using it :)
[00:17] <stgraber> does jockey have some kind of cache ?
[00:18] <stgraber> bryce_: btw, the fglrx driver works really well. I just gave it a try with ET:QuakeWars and it got me a nice 120FPS on a fullscreen 1680x1050/24bit game which was hmm .. the first time I see that on this lappy actually
[00:18] <stgraber> and the fan didn't go crazy as it used to do with that game
[00:18] <bryce_> sweet :-)
[00:18] <bryce_> stgraber: thanks for being the first fglrx tester :-)
[00:19] <stgraber> bryce_: yeah :) Compiz also worked just fine using my previous settings (hardy) I disabled it though as I like having XV working :)
[00:20] <bryce_> stgraber: weird that jockey isn't working right.  probably a question for pitti (but I think he may be offline currently)
[00:20] <stgraber> bryce_: well, my lappy is also far from what you could call a clean install :) It's basically alpha-1 updated until now. Lot of things could have gone wrong.
[00:21] <stgraber> I have a co-worker who also has an ATI-powered laptop with a fresh install, I'll ask him to give it a try when he appears on jabber
[00:21] <bryce_> cool
[00:23] <superm1> bryce_, does this driver have a BETA logo at the bottom right?
[00:23] <superm1> er well stgraber since you've ran it...
[00:24] <stgraber> superm1: where would I see that ?
[00:25] <superm1> stgraber, it would have stood out quite distinctively, so i'll take that as a "no" :)
[00:25] <stgraber> ok, so no :)
[00:25] <superm1> you would have seen it at all time
[00:26] <superm1> i've been on testing drivers so frequently that i never notice it anymore, but it's quite annoying at first
[00:29]  * stgraber is now looking for these HD movies he couldn't watch, will be a nice evening :)
[00:30] <superm1> is the flickering fixed by chance?
[00:30] <superm1> when you have compiz turned on and try watching something that uses xv?
[00:33] <stgraber> superm1: no
[00:33] <stgraber> I just turned off compiz for now
[00:33] <superm1> ah
[00:33] <stgraber> well, the driver is loaded without any option set, maybe there is a magic parameter that I don't know off :)
[00:34] <stgraber> *of
[00:35] <superm1> eg no xorg.conf changes?
[00:36] <stgraber> superm1: http://ubuntu.pastebin.com/f5ab1686c that's my current xorg.conf
[00:37] <superm1> stgraber, neat.  is that 24 bit depth thing actually necessary though?
[00:37] <stgraber> yes, see above :) fglrx just refuses to start without that
[00:37] <superm1> oh man. 
[00:38] <superm1> well i don't know that jockey knows this 
[00:38] <superm1> is it possible to change that behavior in the x-server so that 8bpp isn't ever created into the "default" screen config?
[00:38] <bryce_> superm1: yes jockey already knows about it
[00:39] <bryce_> or at least, I was able to find a 'fix released' jockey bug about it
[00:40] <stgraber> yeah, I saw some Xconfig code in the jockey fglrx handler generating that part
[00:42] <jcristau> superm1: again, the server does 24bpp by default.
[00:42] <jcristau> err. depth 24, 32 bpp
[00:42] <superm1> sorry i missed that in scrollback
=== bdmurray_ is now known as bdmurray
[04:56]  * wgrant ponders splitting https://wiki.ubuntu.com/X/Config into display and input sections, and Intrepid/Hardy pages for each.
[07:40]  * wgrant is quite amused at the people complaining on ubuntuforums about how crap fglrx is compared to radeon.
[07:43] <bryce_> lol
[07:47] <tseliot> hehe
[08:00] <wgrant> bryce_: Are you likely to get to that inputproto fix before RC freeze, or will I have to work out how to convince slangasek to let it in later? I've not dealt much with main before...
[08:04] <tjaalton> wgrant: what does it need in addition to uploading?-)
[08:05] <wgrant> tjaalton: 0
[08:06] <wgrant> I've four positive reports on amd64, and it works fine on i386 too, so I think the testing is done.
[08:07] <tjaalton> and the patch is upstream too
[08:07] <wgrant> It is.
[08:15] <tjaalton> wgrant: what was the bug #?
[08:17] <bryce_> #267611.
[08:17] <bryce_> sorry, didn't get to it today, but if tjaalton doesn't do it, I'll make sure it's uploaded tomorrow
[08:20] <tjaalton> bryce_: ok, I can upload it soon
[08:21] <tjaalton> wrapping things up before the freeze
[08:29] <tjaalton> wgrant: inputproto uploaded, libxi to follow
[08:29] <wgrant> tjaalton: Great, thanks.
[09:14] <Kano> https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/247376
[09:14] <ubottu> Launchpad bug 247376 in fglrx-installer "undefined symbols when trying to load fglrx" [Critical,Fix released] 
[09:14] <Kano> where is that driver?
[09:15] <Kano> bryce_: it seems you have a driver, tell me where it is...
[09:17] <tjaalton> try the archive?
[09:17] <Kano> tjaalton: i want the original url
[09:17] <tjaalton> then you should ask AMD
[09:18] <Kano> also when i seek for fglrx-installer on packages.ubuntu.com there is no result?
[09:18] <bryce_> fglrx-installer is new to intrepid.
[09:19] <Kano> multiverse?
[09:19] <tjaalton> p.u.c has it
[09:19] <tjaalton> actually, p.u.c only lists binary packages
[09:20] <tjaalton> ..by default
[09:20] <Kano> well found the source in multi now
[09:20] <tjaalton> fglrx-installer is the source package
[09:21] <Kano> could you upload the ati installer package?
[09:22] <Kano> x740 is interesting...
[09:22] <Kano> so you have to check for xserver 1.5 it seems
[09:22] <tseliot> Kano: https://launchpad.net/ubuntu/+source/fglrx-installer/2:8.543-0ubuntu1
[09:23] <tseliot> the source is there ^^
[09:23] <Kano> tseliot: the source has got not the run installer which was the base
[09:23] <Kano> just downloaded it
[09:23] <tseliot> aah, you use the installer
[09:24] <Kano> yes, i want to optimize my script
[09:28] <Kano> as it has got a signature then it should be an official driver usually, but i see nowhere 8-10?
[09:28] <mvo> bryce_, while testing the fglrx module I noticed that it failed to build the dkms modules (because my linux-headers were not up-to-date). I wonder if we should present a debconf note in that case so that the user knows what is going on. probably not for intrepid, but for jaunty?
[09:29] <bryce_> mvo, hmm
[09:29] <bryce_> mvo, yeah probably worthwhile for jaunty
[09:30] <bryce_> kano, you have to wait for amd to publish the .run file
[09:30] <Kano> but you could use it before, thats really nice...
[09:31] <Kano> for .orig i dont think i want stripped down version
[09:31] <Kano> i want all
[09:31] <Kano> not only x740
[09:33] <mvo> bryce_, talking about fglrx, have you seen bug #278963 ?
[09:33] <ubottu> Launchpad bug 278963 in linux-restricted-modules-2.6.24 "fglrx kernel module crashes system hard during hardy to intrepid upgrade" [Undecided,New] https://launchpad.net/bugs/278963
[09:35] <Kano> mvo: fglrx was crap and will every be crap. when you switch from ati -> fglrx even when you unload drm/radeon it can lockup. that happens often when i try with rv410. switching from vesa->fglrx it not problematic
[09:37] <mvo> hmm, its kind of bad when that happens in the middle of a upgrade
[09:38] <bryce_> mvo, hmm bummer, guess that needs sorted out, although I'm not sure what needs done exactly
[09:38] <mvo> the scary bit is that lars writes that he was not even using fglrx
[09:38] <mvo> it was just installed
[09:39] <mvo> bryce_, do you have a test machien to verify that?
[09:39] <bryce_> Kano: regarding your /msgs, you will need to wait for AMD to publish the .run file
[09:40] <bryce_> mvo: I can set one up, but not right now (almost 2am) :-)
[09:41] <mvo> bryce_, heh :) sure
[09:42] <bryce_> mvo, have you talked with superm1 about it?  he'd probably be better than me to know what needs sorted out
[09:42] <bryce_> I've also added an fglrx-installer task, since I think this bug is due to the hand-over from lrm-2.6.24 to fglrx-installer
[09:43] <mvo> bryce_, I have not talked to superm1 about it yet, but thanks for the hint, will do
[09:45] <tseliot> bryce_: but fglrx-installer wasn't installed and therefore no other fglrx.ko was installed (other than the one from the lrm)
[09:46] <tseliot> from what I remember, at least...
[09:47] <tseliot> as fglrx-installer would have built the module with dkms first
[09:51] <bryce_> hmm
[09:52] <bryce_> tseliot: despite that, the upgrade still needs to hand over cleanly
[09:53] <bryce_> tseliot: so like the lrm-2.6.24 stuff may need to be cleaned up as part of the process... but I'm not really sure how this changeover is supposed to work.  and it's late and my brain's mush now :-)
[09:53] <tseliot> bryce_: yes, of course, and it would be nice to find the cause of the problem
[09:54] <tseliot> bryce_, mvo: maybe it would be a good idea to deal with the restricted modules at the beginning of the dist-upgrade
[09:54] <bryce_> tseliot: also even if it's not fglrx-installer at fault, I put the task in so the issue would be noticed more easily.  But if it's proven for sure that it's not something fglrx-installer needs to worry about, feel free to invalidate that task
[09:54] <bryce_> like, maybe it needs a task against update-manager instead
[09:55] <tseliot> bryce_: very litte is certain at this point. Let's consider all possibilities
[09:55] <tseliot> something modprobed fglrx.ko
[09:56] <tseliot> of course knowing what did it would help ;)
[09:57] <bryce_> I've suggested to liw this would be a good point to re-test the bug
[09:57]  * tseliot nods
[09:58] <bryce_> ok, I think I'm going to hit the sack, and hope tomorrow I'll be able to make better progress through my todo list
[09:58] <bryce_> night
[09:58] <tseliot> good night bryce
[09:58] <mvo> tseliot, in what way should it do that? 
[09:58] <mvo> night bryce_ 
[09:58] <tseliot> mvo: "it" what?
[09:59] <tseliot> what are we talking about?
[09:59] <mvo> tseliot, "deal with the restricted modules at the beginning of the dist-upgrade" <- what is the right thing to do for the release upgrader here (or might be the right thing)?
[10:00] <tseliot> mvo: I meant to say that maybe we should upgrade the restricted modules first
[10:00] <tseliot> i.e. they should be the 1st thing we upgrade
[10:01] <tseliot> so that
[10:01] <mvo> tseliot, aha, thanks. that is very hard to do, bascily the release upgrader has no influcense on the ordering of the upgrade 
[10:01] <tseliot> fglrx.ko and nvidia.ko will go away
[10:01] <tseliot> ah
[10:01] <mvo> but its a good idea, we could hack something if it turns out that this is needed
[10:02] <tseliot> mvo: maybe we could ask Lars to upgrade the lrm first (manually) and then try the dist-upgrade with Update Manager
[10:03] <tseliot> so as to see if he can reproduce the problem
[10:05] <mvo> tseliot, right, could you please put that into the bug as suggestion?
[10:08] <tseliot> mvo: sure
[10:11] <mvo> thanks
[11:49] <mvo> hm, looking over the upgrade bug reports I see issues with nvidia-glx and nvidia-glx-new (e.g. #280928)
[13:20] <tseliot> mvo: let me know if you need a hand with dist-upgrade issues that have to do with nvidia
[13:21] <mvo> tseliot, excellent, thanks. I asked for the logs for two issues I saw today and reassigned them to nvidia-glx
[13:22] <mvo> tseliot, would be nice if you could have a look, I suspect its something with the diverts again (or maybe with installing the nvidia driver from nvidia directly)
[13:22] <tseliot> mvo: in the latter case I guess there is little we can do
[13:23] <mvo> tseliot, hm, can't we detect this somehow and bang it into shape so that our packages install?
[13:24] <tseliot> mvo: maybe we could test the existence of some symlink
[13:25] <tseliot> mvo: usually (but not always) reinstalling libgl1-mesa-glx and xserver-xorg-core does the trick
[13:25] <tseliot> (before installing the nvidia packages)
[13:28] <mvo> hm, would be nice if we could handle it as graceful as possible
[13:28]  * tseliot nods
[13:56] <Kano> whats the live cheat to force vesa?
[13:59] <tjaalton> a boot parameter
[13:59] <Kano> which one
[13:59] <tjaalton> forcevesa IIRC
[13:59] <Kano> because the nv driver does not work
[13:59] <tjaalton> known
[14:00] <tjaalton> well, it doesn't support every nvidia device there is
[14:00] <tjaalton> but the server will try to use it anyway
[14:00] <Kano> well my device is supported but that stupid drivers wants to use dvi output but vga is connected
[14:11] <Kano> tjaalton: shouldit it be xforcevesa?
[14:12] <tjaalton> Kano: seems like it. xserver-xorg.postinst reveals that
[14:15] <tseliot> mvo: this is a very common error: https://bugs.launchpad.net/bugs/283747
[14:15] <ubottu> Launchpad bug 283747 in nvidia-graphics-drivers-177 "package nvidia-glx-177 177.80-0ubuntu1 [modified: usr/bin/nvidia-bug-report.sh usr/bin/nvidia-xconfig usr/lib/xorg/modules/drivers/nvidia_drv.so usr/share/man/man1/nvidia-xconfig.1.gz] failed to install/upgrade: trying to overwrite `/usr/lib/xorg/modules/extensions/libglx.so', which is also in package xserver-xorg-core" [Undecided,New] 
[14:16] <mvo> tseliot, not sure
[14:17] <mvo> hm, is this "(WW) RADEON(0): Direct rendering disabled" is new, that used to work with my r500 
[14:17] <mvo> (some days/weeks ago)
[14:19] <tjaalton> mvo: is fglrx loaded?
[14:19] <tjaalton> the kernel module I mean
[14:19] <mvo> possible, I did not load it deliberately
[14:19] <mvo> but I have it installed
[14:19] <tseliot> mvo: /usr/lib/xorg/modules/extensions/libglx.so should be a symlink to (in my case) libglx.so.177.80
[14:20] <tseliot> mvo: make sure that no nvidia or fglrx package is installed.
[14:20] <tseliot> ogra had a similar problem
[14:20] <tseliot> that broke direct rendering with his card
[14:21] <tseliot> if no such package is installed then it must be something else ;)
[14:22] <tjaalton> right, the library link is enough to break it
[14:29] <Kano> tjaalton: but why is xforcevesa not used in live mode, there is no vesa writen in the xorg.conf
[14:29] <Kano> with 8.10 daily/betas
[14:30] <tjaalton> Kano: beats me
[14:30] <superm1> it stopped working for me too 
[14:30] <superm1> probably a bug in casper 
[14:30] <superm1> once that nv bug is sorted out though it won't be necessary
[14:31] <Kano> even when i remove the xorg.conf and run your postinstall script it is not there
[14:31] <superm1> mvo, fglrx diverts libglx, so if you have xorg-driver-fglrx installed, you would possibly run into troubles
[14:32] <mvo> oh, right
[14:32] <mvo> thanks superm1
[14:33] <superm1> mvo, this makes me really think that there should be something that forces fglrx w/o your xorg.conf for jaunty
[14:33] <superm1> it's pretty much start that or start a broken radeon when it's installed
[14:33] <mvo> superm1: that would make sense Imo, its kind of unexpected - maybe some better string in the log as well
[14:33] <jcristau> i don't understand why fglrx needs to divert libglx.so instead of installing and loading libglx-fglrx.so...
[14:34] <superm1> jcristau, it's supposed to replace regular calls to libglx.so I believe
[14:34] <superm1> not just for it's own calls
[14:36] <jcristau> hmm. there's probably no way for it to stop the server from loading the vanilla libglx.so
[14:36] <jcristau> oh well
[14:36] <tjaalton> Kano: the casper log would be helpful
[14:41] <tjaalton> the postinst and dexconf look fine
[14:44] <albert23> tjaalton: I tested evdev from your PPA, but is still crashes when I press a key on my gamepad (bug 274203)
[14:44] <ubottu> Launchpad bug 274203 in xserver-xorg-input-evdev "Joystick detected as mouse, crashes X" [Undecided,Fix committed] https://launchpad.net/bugs/274203
[14:45] <tjaalton> albert23: ok, thanks for testing
[14:45] <albert23> tjaalton: Isn't the 64k memory protection Ubuntu specific, so maybe upstream does not know about the pDev->key=0x0 preblem?
[14:46] <tjaalton> albert23: upstream knows
[14:49] <jcristau> albert23: accessing memory at 0x0 crashes everywhere..
[14:50] <tseliot> superm1: did you have a look at this? https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/283765
[14:50] <jcristau> tjaalton: did you fix up the check in daniel's patch?
[14:50] <ubottu> Launchpad bug 283765 in fglrx-installer "package xorg-driver-fglrx 2:8.543-0ubuntu1 failed to install/upgrade: EOF on stdin at conffile prompt" [Undecided,New] 
[14:50] <albert23> jcristau: OK, thanks
[14:50] <tjaalton> jcristau: yes
[14:51] <jcristau> need a new backtrace then i guess
[14:52] <superm1> tseliot, hum interesting.
[14:53] <superm1> i wonder if he modified that himself or what
[14:53] <tseliot> superm1: what is /etc/ati/atiogl.xml ? Some alternative to xorg.conf for amdcccle?
[14:53] <jcristau> albert23: can you get a trace from the new crash?
[14:54] <superm1> tseliot, i'm not sure, it's not present on my current hardy system. it must have been introduced in the last release or two
[14:54]  * tseliot should package the latest fglrx driver (in lrm-envy) for Hardy but it's a bit scaried...
[14:54] <tseliot> s/it's/he's/
[14:55] <albert23> tjaalton: http://paste.ubuntu.com/57893/
[14:56] <superm1> tseliot, ah that file provides profiles for different apps
[14:56] <superm1> workstation applications
[14:56] <tseliot> aah
[14:57] <superm1> but if he didn't change it himself, then the we'll need to catch this behavior somehow
[14:57] <superm1> i'm not sure how/when that file is written out
[14:59] <tseliot> hmm... I haven't tested fglrx for a long time
[14:59] <jcristau> albert23: sadness. thanks.
[15:00] <jcristau> albert23: can you pastebin the log too?
[15:02] <albert23> jcristau: Xorg.0.log?
[15:03] <jcristau> yeah
[15:04] <albert23> jcristau: http://paste.ubuntu.com/57900/
[15:13] <jcristau> albert23: thanks. now to find out why the keyboard stuff still doesn't get initialized
[15:27] <jcristau> albert23: what does /proc/bus/input/devices say about that 'Logitech Logitech RumblePad 2 USB'?
[15:28] <albert23> jcristau: http://paste.ubuntu.com/57905/
[15:29] <jcristau> meh. why does evdev not find the keys?
[15:30] <albert23> jcristau: can I try to capture the detection in gdb?
[15:31] <jcristau> albert23: i guess, try to step through EvdevProbe. you'll need debugging symbols from the driver
[15:32] <Kano> tseliot: http://paste.ubuntu.com/57906/
[15:32] <albert23> jcristau: can I use evdev from the archive or do you prefer the PPA version? (I can create dbgsym for the PPA if needed)
[15:32] <Kano> tseliot: thats pxe boot
[15:33] <jcristau> albert23: preferrably the ppa version
[15:33] <albert23> jcristau: OK, I will do a local build to create a dbgsym package
[15:34] <tseliot> Kano: do you want me to look at a specific part of it or is it just to show me what it does?
[15:34] <jcristau> albert23: sorry this is such a pain..
[15:34] <Kano> tseliot: you see that vesa is preconfigured,but it is NOT in xorg.conf
[15:35] <Kano> but driver is later ""
[15:35] <Kano> maybe low is the wrong priority
[15:36] <albert23> jcristau: no problem
[15:37] <tseliot> Kano: why is driver ""? Is it because none is set in xorg.conf?
[15:37] <Kano> there nothing set, i guess priority is too low
[15:38] <Kano> or something else is wrong
[15:38] <Kano> the xorg.conf is just the same with or without xforcevesa
[15:38] <tseliot> Kano: what is it supposed to do? Load nvidia or nv instead?
[15:38] <Kano> tseliot: i want only vesa with xforcevesa, not more not less
[15:39] <tseliot> aah
[15:40] <tseliot> Kano: I'm afraid I'm not right person to talk to about this as I've never played with pxe
[15:41] <Kano> tseliot: it does not matter how you boot it, thats only what you see in the first 3 lines
[15:41] <Kano> the problem is the xconfig
[15:41] <tjaalton> Kano: add a 'set -x' to dexconf, and run it
[15:49] <Kano> see nothing special, but vesa it not in the log
[15:50] <tjaalton> pastebin the output of the command
[15:53] <Kano> tjaalton: what you really need to know is that the xserver-xorg/config/device/driver is still set to select (using debconf-get-selections)
[15:54] <tjaalton> Kano: ok
[16:02] <Kano> does it work for you?
[16:02] <tjaalton> haven't tried
[16:03] <tjaalton> don't know why it would clear the value in the postinst
[16:03] <tseliot> superm1: BTW problem solved with nvidia-xconfig and 173
[16:03] <Kano> you could mount --bind a text file over /proc/cmdline to try withtou reboot
[16:06] <tjaalton> Kano: the problem is not the cmdline, it works. but for some reason the value is cleared after it is set
[16:07] <tjaalton> the debconf value
[16:08] <Kano> maybe because driver is set to select not string?
[16:11] <Kano> and it must be checked against something
[16:12] <Kano> before reconfigure showed all drivers first
[16:15] <tjaalton> it's the same in hardy, and there it works
[16:20] <Kano> well something must be different
[16:21] <tjaalton> but the postinst looks the same in that regard
[16:21] <tjaalton> and it's 'select' on hardy too
[16:24] <Kano> yes it is always select,but where are the possible selections stored?
[16:25] <tjaalton> oh right, choices is empty
[16:26] <tjaalton> because $DRIVERS_LIST is empty
[16:27] <tjaalton> maybe just hardcode it, so it's allowed to be vesa if forced
[16:28] <Kano> or use string?
[16:29] <tjaalton> whatever works
[16:29] <jcristau> DRIVERS_LIST used to be filled in with whatever's in /usr/lib/xorg/modules/drivers, right?
[16:29] <tjaalton> right
[16:29] <tjaalton> now it's done only for sparc
[16:29] <tjaalton> or something related
[16:32] <Kano> basically you could fill it with that
[16:32] <Kano> but only the _drv.so files
[16:32] <Kano> without that suffix
[16:35] <jcristau> yeah. on etch i have http://paste.debian.net/19286/
[16:46] <elmargol> tseliot, do you have a minute?
[16:46] <elmargol> I think  * Fixed a bug that caused system hangs when using the NV-CONTROL interface to change GPU clock frequencies.
[16:46] <elmargol>  <- i think that bug is back
[16:47] <tseliot> elmargol: what's the bugreport?
[16:47] <elmargol> tseliot, still the olm bug where the driver crashes.
[16:48] <elmargol> Bug #278029
[16:48] <ubottu> Launchpad bug 278029 in nvidia-graphics-drivers-177 "Xserver crashes, scrambled terminals random lines and patterns (dup-of: 270617)" [Undecided,New] https://launchpad.net/bugs/278029
[16:48] <ubottu> Launchpad bug 270617 in nvidia-graphics-drivers-177 "Display corruption after short period" [Undecided,Confirmed] https://launchpad.net/bugs/270617
[16:48] <elmargol> I did find out that I can triger this bug if i change the clock speed of my GPU using nvclock
[16:49] <elmargol> Maybe there is a power saving feature or something new to intrepid that underclocks my gpu or something?
[16:50] <tseliot> elmargol: as far as I know NVIDIA does things its way
[16:51] <tseliot> elmargol: can you add this new detail on nvclock to the bug report and subscribe Aaron Plattner (from NVIDIA) to the bug report?
[16:52] <elmargol> I try to
[16:52] <tseliot> ok
[16:54] <elmargol> comment is on
[16:54] <elmargol> God I hope someone can help me :(
[16:54] <elmargol> not beeing able to use google earth sucks
[16:55] <elmargol> tseliot, Aaron works for nvidia?
[16:55] <tseliot> yep
[16:56] <elmargol> I guess since every mac uses nvidia now we are getting nice linux support soon :D
[17:50] <Awsoonn> the flgrx driver uploaded today fails to install in jockey (bug reported) and when I apt-get instal xorg-fglrx-driver and reboot, x fails to start
[17:50] <Awsoonn> known issue or shall I make a report?
[17:53] <crevette> I don't know, I would say do a report
[17:54] <albert23> jcristau: How does this look? (II) Logitech Logitech RumblePad 2 USB: Configuring as keyboard
[17:54] <albert23> and no more segfault
[17:58] <albert23> jcristau: full xlog http://paste.ubuntu.com/57959/
[18:17] <tseliot> Awsoonn: can I see your bug report?
[18:21] <bryce_> Awsoonn: tell us what the error it prints is when you run startx
[18:21] <bryce_> Awsoonn: perhaps it's just the defaults-to-8bit issue stgraber saw yesterday
[18:24] <Awsoonn> bryce_: http://pastebin.com/d12639b66 that is my xorg.log
[18:25] <Awsoonn> I havn't made a bug report for x failing to start yet, I thought Id ask here first to see if it was a transient issue
[18:26] <bryce_> Awsoonn: use startx or look in your /var/log/gdm/ logs to get the error message
[18:26] <jcristau> albert23: what did you change for it to start working?
[18:26] <Awsoonn> I did use startx
[18:26] <bryce_> startx should have printed an error message to stdout
[18:27] <bryce_> ahh wait, nevermind I see
[18:27] <bryce_> Awsoonn: ok you've got a backtrace in your Xorg.0.log, so something crashed
[18:28] <bryce_> Awsoonn: according to your log it was trying to load -ati rather than -fglrx
[18:28] <bryce_> so make sure you have "fglrx" listed in your /etc/X11/xorg.conf
[18:29] <albert23> jcristau: I replaced if (i >= BTN_MISC && i < KEY_OK) by if (i >= BTN_MISC && i < BTN_GAMEPAD) in the evdev patch
[18:29] <Awsoonn> I will reinstall and give it a shot, in the meantime her eis the gdm log, I think...
[18:29] <Awsoonn> http://pastebin.com/d53774d6
[18:29] <bryce_> #
[18:29] <bryce_> xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call
[18:29] <bryce_> Awsoonn: ^ include that in your bug report
[18:30] <jcristau> albert23: ugh.
[18:30] <bryce_> Awsoonn: you may actually have two different bugs here
[18:30] <albert23> jcristau: because the key codes of my gamepad are below KEY_OK, so were skipped
[18:30] <jcristau> albert23: sigh
[18:30] <jcristau> why is BTN_GAMEPAD sent as a key press?
[18:32] <jcristau> oh, crap.
[18:32] <jcristau> button = EvdevUtilButtonEventToButtonNumber(ev.code);
[18:32] <jcristau> if (button)
[18:32] <jcristau> xf86PostButtonEvent(pInfo->dev, 0, button, value, 0, 0);
[18:32] <jcristau> else
[18:32] <Awsoonn> bryce_: that would not surprise me in the least :) 
[18:32] <jcristau> PostKbdEvent(pInfo, &ev, value);
[18:32] <mnemo> the intel guys asked me to verify a fix they've commited for a bug I reported... (bug here: https://bugs.freedesktop.org/show_bug.cgi?id=17905 ) they want me to test against "drm-intel-next", but i'm not sure how to do it... in particular, is it necessary to build and boot a whole new kernel or can I just rebuild some specific modules?
[18:32] <jcristau> sounds like EvdevUtilButtonEventToButtonNumber is busted
[18:32] <ubottu> Freedesktop bug 17905 in Driver/intel "[G45] -intel git freezes X after login (on gigabyte GA-EG45M-DS2H with Intrepid)" [Normal,New] 
[18:34] <bryce_> mnemo: what's "drm-intel-next"?
[18:34] <mnemo> bryce: it's eric anholt's git tree at kernel.org
[18:34] <mnemo> http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=summary
[18:35] <mnemo> they are developing some kernel modules in that tree, like for instance the drm-intel module
[18:35] <Awsoonn> how should I go about addin fglrx to my xorg.conf? Like this?: http://pastebin.com/d5b407dd3
[18:36] <mnemo> i know how to build the 2d part (xf86-intel) and I can also build libdrm.. so I think what I need is the modules agpgart, intel-agp, drm and i915 (and possibly also I kernel, which is what I am unsure about)
[18:37] <bryce_> mnemo: yeah not sure, I've not built that branch before.  It wouldn't be unusual to need to rebuild some kernel modules as well
[18:38] <bryce_> building git libdrm and git -intel sometimes also involves needing a git mesa as well
[18:38] <bryce_> (but maybe that's what you mean by i915)
[18:39] <mnemo> yea I think that's what I mean
[18:39] <bryce_> the kernel itself probably doesn't need to be rebuilt though, although I'm not totally up on how everything's knitted together on the kernel end of things
[18:39] <mnemo> it's a lot to learn before you can build it correctly
[18:39] <bryce_> yeah :-/
[18:39] <mnemo> i'll go ask the intel guys though
[18:40] <mnemo> thanks
[18:40] <jcristau> albert23: thanks again for the debugging, hopefully we'll be able to get that fixed properly now
[18:41] <albert23> jcristau: you're welcome
[18:50] <bryce_> rebooting to test new xserver; brb
=== federico1 is now known as f_shower
[19:15] <Awsoonn> bryce:  adding fglrx to my xorg.conf did not apear to help, not garenteeing that I did it corectly however 
[19:16] <Awsoonn> here are the logs from that run: http://pastebin.com/d730d3844
[19:16] <Awsoonn> I'll file a bug report later tonight though, since it seems to be an genuine issue.
[19:19] <superm1> Awsoonn, #
[19:19] <superm1> (II) fglrx(0): Creating default Display subsection in Screen section
[19:19] <superm1> #
[19:19] <superm1>         "Default Screen" for depth/fbbpp 8/8
[19:19] <superm1> #
[19:19] <superm1> (EE) fglrx(0): Given depth (8) is not supported by fglrx driver
[19:19] <superm1> that's the issue.
[19:19] <superm1> (sorry for the paste guys, i should have realized it would spawn that many lines)
[19:19] <superm1> Awsoonn, you couldn't enable it via jockey?  It would have handled this part for you
=== f_shower is now known as federic1
[19:41] <Awsoonn> superm1: jockey crashes when atempting to install fglrx on my system
[19:41] <bryce> superm1: yeah he had some other problem with jockey
[19:41] <superm1> oh that's not good.
[19:41] <bryce> Awsoonn: so that looks indeed like the defaulting-to-8bit-depth bug
[19:42] <bryce> Awsoonn: you need to manually specify 24 bit depth in your xorg.conf with -fglrx (jockey takes care of this for you, but when you manually install, you have to do this step too)
[19:43] <Awsoonn> hm, well, I jsu tdid updates and tryed jockey again, it didnt crash this time, let me reboot :)
[19:45] <philwyett> Evening all o/