[00:17] <jtholmes> wondered if anyone is interested that reporter of bug 363533 says not installing the proprietary drivers cures the hibernation problem?
[00:17] <ubottu> Launchpad bug 363533 in pm-utils "ATI Radeon HD 3670 Proprietary FGLRX Drivers break Suspend, Hibernate and major performance issues." [Undecided,New] https://launchpad.net/bugs/363533
[00:34] <bryce_> jtholmes: that's interesting info, although in Karmic we're going to be pushing to move away from -fglrx and favor -ati more heavily
[00:34] <bryce_> so while it is useful to have that bug there for other users that encounter the problem, it's unlikely we'll do anything about it ourselves.
[00:35] <bryce_> jtholmes: well, aside from redoubling efforts to fix whatever issues with -ati drove the user to try -fglrx to begin with ;-)
=== bryce_ is now known as bryce
[01:29] <jtholmes> bryce, ok thanks, i have had lots of hibernation bugs i have responded to and wondered what the status quo was concerning them and you answered that, thx
[02:00] <Sarvatt> well thats not good, findutils in karmic was broken causing linux-libc-dev to not build right but still get published, but the fixed findutils cant build because linux-libc-dev is broken and most builds are failing
[02:02] <bryce> >.<
[03:36] <Sarvatt> looks like https://bugs.freedesktop.org/show_bug.cgi?id=20152 is still rearing its ugly head for me on intel, at least i've never triggered the crash unless it was on purpose
[03:36] <ubottu> Freedesktop bug 20152 in Driver/intel "[G45/GM965 UXA] cannot view JPG in firefox when running UXA (lots of errors in dmesg)" [Major,New]
[10:28] <apw> anyone know why the xserver is directly interfering with mtrr assignments
[10:37] <apw> bryce, ... need some intsite into the x-servers mind when you are about
[10:55] <mnemo> im speculating but maybe intel cards use mtrr to reserve a chunk of memory for their graphics memory?
[13:34] <tseliot> jcristau: I'm getting this error? Any ideas as to why this is happening?  undefined reference to `_XiGetDevicePresenceNotifyEvent(_XDisplay*)'
[13:35] <tseliot> s/I'm getting this error?/I'm getting this error/
[13:36] <tseliot> jcristau: I get that when I call DevicePresence (display, device_presence_event_type, event_class)
[13:40] <tjaalton> tseliot: don't be shy, just try #xorg-devel ;)
[13:41] <tseliot> tjaalton: you're right, I wrote it in the wrong chatroom (I clicked on the wrong tab in pidgin) ;)
[13:44] <tseliot> tjaalton: now that I think about it, isn't this a bug in the ubuntu package? nm /usr/lib/libXi.so | grep _XiGetDevicePresenceNotifyEvent
[13:44] <tseliot> nm: /usr/lib/libXi.so: no symbols
[13:45] <seb128> tseliot: nm --dynamic /usr/lib/libXi.so ?
[13:46] <tseliot> seb128: ah, now it says 00006920 T _XiGetDevicePresenceNotifyEvent
[13:47] <seb128> so it seems correctly defined
[13:47] <seb128> ldd binary | grep libXi
[13:47] <seb128> you might have a local install taking over?
[13:48] <seb128> is your error a build time or run time one ?
[13:48] <tseliot> no, I didn't install libXi from external sources
[13:48] <tseliot> build time
[13:48] <seb128> you lack a -lXi then
[13:48] <seb128> you pkg-config call might not be listing xi
[13:49] <tseliot> seb128: but I can use Xi otherwise: http://ubuntu.pastebin.com/m399e04a9
[13:49] <tseliot> this is the first time it happens
[13:51] <seb128> you get the same issue by running
[13:51] <seb128> "g++  -o daemon debug/main.o debug/xmlhandler.o debug/loopthread.o debug/xevents.o debug/moc_inputdaemon.o debug/moc_loopthread.o debug/moc_xevents.o    -L/usr/lib -lXi -lQtDBus -lQtXml -lQtGui -lQtCore -lpthread"
[13:51] <seb128> in your source?
[13:52] <tseliot> yep
[13:52] <seb128> what is xevents.cpp:110 exactly?
[13:52] <seb128> can you copy the line there ?
[13:52] <tseliot> DevicePresence (display, device_presence_event_type, event_class);
[13:53] <seb128> where is the `_XiGetDevicePresenceNotifyEvent(_XDisplay*)' call?
[13:55] <tseliot> DevicePresence() in XInput.h: http://ubuntu.pastebin.com/d2b978c05
[13:56] <tseliot> in /usr/include/X11/extensions/XInput.h that is
[13:57] <seb128> ok so I don't know, maybe that's a c++ thing or a libxi issue
[13:58] <seb128> usually if you have the correct .h included and the -lXi that should work
[13:58] <tseliot> ok, thanks
[13:59] <jcristau> the _XiGetDevicePresenceNotifyEvent decl should be protected by extern "C" in c++
[14:00] <tseliot> jcristau: how do I do that?
[14:01] <tseliot> aah, I get it
[14:03] <jcristau> http://cgit.freedesktop.org/xorg/lib/libXi/tree/include/X11/extensions/XInput.h#n160
[14:04] <tseliot> jcristau: ok, so I would have to patch the ubuntu package to do that in the header file
[14:11] <tseliot> jcristau: that did it, thanks a lot
[14:13] <tseliot> tjaalton: do you mind if I write a patch about it ^^ for an SRU? 
[14:15] <tjaalton> tseliot: no, it's needed in jaunty?
[14:16] <tseliot> tjaalton: yes, otherwise we can't use Xinput notifications in C++
[14:17] <tjaalton> tseliot: sure, go ahead
[14:17] <tseliot> tjaalton: ok
[14:18] <jcristau> tseliot: preventing use of c++ sounds like a feature :)
[14:18] <tseliot> :-P
[17:04] <mnemo> bryce: just FYI --> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/368049/comments/36   im not sure at all it's something to be concerned about but I thought you might want to know about it
[17:04] <ubottu> Ubuntu bug 368049 in mesa "compiz crashes gnome desktop using default ati driver (radeon X600)" [Undecided,Fix committed]
=== pwnguin_ is now known as pwnguin_grmn
[17:18] <jbarnes> hm according to 358608 claws plugins have been 'synced', but apparently only in karmic, according to the claws-mail-extra-plugins page
[17:35] <tjaalton> jbarnes: yes, syncing happens only in the devel release, but it appears jaunty needs fixing too
[17:35] <tjaalton> so the bug needs a jaunty task
[17:35] <jbarnes> yeah I can't see html mail! :)
[17:36] <tjaalton> what a drag :)
[17:43] <tjaalton> jbarnes: I opened a jaunty task, so hopefully it'll be fixed soon ;)
[17:43] <jbarnes> tjaalton: cool thanks
[17:46] <tjaalton> the problem is that claws-mail in jaunty is 3.6.1, when karmic has 3.7.1, so a matching -extra-plugins should be obtained somewhere
[17:49] <jbarnes> right I think it's mainly a matter of building the plugins against what's in jaunty though
[17:50] <tjaalton> ah
[17:54] <tjaalton> ok so it's really trivial.. I'll upload it to proposed
[17:55] <jbarnes> tjaalton: thanks a lot
[17:55] <jbarnes> what's the url for that?  I can try it now
[17:56] <tjaalton> we only have source uploads, so the binary will be ready once it is
[17:58] <jbarnes> ah ok
[18:05] <tjaalton> jbarnes: 32 or 64bit?
[18:05] <jbarnes> 64
[18:05] <tjaalton> damn
[18:06] <tjaalton> would've built it for you :)
[18:06] <tjaalton> because I think it'll take a while until it's accepted
[18:07] <jbarnes> oh there's no big hurry
[18:07] <jbarnes> on my other machine I just downloaded the karmic packages
[18:07] <jbarnes> but I'd rather not do that this time
[18:07] <tjaalton> heh, ok
[18:55] <bdmurray> bryce: with regards to libGL.so crashes it can be provided by how many packages?
[19:12] <bryce> mesa, fglrx, and -nvidia
[19:13] <bryce> so, counting the 3 nvidia source packages, there are 5 packages that provide it afaik
[19:15] <bdmurray> Okay, I was thinking about a package hook for rss-glx and xscreensaver but if there are basically 3 choices it may be unnecessary
[19:16] <bdmurray> because fglrx and nvidia should show up as proprietary modules
[19:17] <bryce> right
[19:23] <tseliot> bdmurray: do you still have that script that you used on launchpad with X-Kit to validate xorg.conf files?
[19:26] <bdmurray> tseliot: probably
[19:27] <bdmurray> tseliot: However, it was written using python-launchpad-bugs and not launchpadlib.  Then again I think launchpadlib would be inadequate for part of it.
[19:27] <tseliot> bdmurray: I have to give a speech on X-Kit at an event organised by a LUG and I was wondering if I could show a snippet from your script to show the different uses of X-Kit
[19:27] <tseliot> it doesn't have to work, it should be something that I can show
[19:28] <tseliot> well, only some small parts
[19:29] <bdmurray> tseliot: when do you need it by?
[19:29] <tseliot> bdmurray: my presentation will be on May 15
[19:30] <tseliot> but I'm writing it with Latex so it would be nice to have the script a few days before that date
[19:30] <bryce> tseliot: where are you presenting?
[19:30] <bryce> er sorry
[19:30] <bryce> bdmurray: where are you presenting?
[19:31] <bdmurray> bryce: you were right the first time
[19:31] <tseliot> bryce: here in Lecce, Italy
[19:31] <tseliot> it's a "geek evening"
[19:32] <bryce> cool
[19:33] <bdmurray> tseliot: I've e-mailed it to you
[19:33] <tseliot> bdmurray: fantastic! Thanks
[19:34] <bryce> heya jbarnes
[19:35] <jbarnes> hi
[20:54] <Sarvatt> ohh, didnt notice the 2.7.1 updates already started making it in 2.7 branch, lets see if it was those 3 commits that fixed the random UXA hangs I got
[21:14] <bryce> cool
[21:14] <bryce> I've just finished merging 2.7.0 and uploaded it to karmic
[21:15] <bryce> Sarvatt: if you can match up 2.7.1 patches to bug's in launchpad that get fixed, would you mind mentioning that on the bug report, or updating the title to say (Needs 2.7.1)?
[21:16] <bryce> that way when I pull in 2.7.1 it'll make it easier to know what bugs get closed by it
[21:16] <jbarnes> bryce: likewise if there are patches in git master that you want in 2.7.1 send a note to intel-gfx
[21:17] <bryce> jbarnes: ok, when does that release?
[21:17] <jbarnes> rsn
[21:17] <jbarnes> cworth is soliciting nominations
[21:18] <bryce> hrm, ok well technically I'm supposed to be off today, so guess I'll wait and cherrypick later as needed
[21:18] <Sarvatt> sure, i really need to sit down and figure out which commit fixed the random UXA hangs I got for months, it was fixed somewhere between 2.7.99.1 snapshot and Call down to lower CloseScreen before shutting down DRM allocator, only8 commits between those
[21:18] <jbarnes> bryce: heh yeah enjoy your time off :)
[21:19] <Sarvatt> 3 of those are already in 2.7.1 so i'm testing that right now :D
[21:20] <bryce> jbarnes: I've got a few quirks I should send in, but not critical for 2.7.1
[21:21] <bryce> also patch 119_drm_bo_unreference_needs_null.patch seems like it should be upstreamed... I'm fairly sure I had sent a bug report in on it so not sure why it wasn't in 2.7.0 so need to research that some more
[21:21] <bryce> it fixed a bunch of crashers for us, and I think you thumbed up it for us
[21:21] <jbarnes> the libdrm patch? I think that's in libdrm already, though maybe not part of a release yet
[21:22] <bryce> no, this one:
[21:22] <bryce>              if (!pPriv->textured && drm_intel_bo_pin(pPriv->buf, 4096) != 0) {
[21:22] <bryce>                  drm_intel_bo_unreference(pPriv->buf);
[21:22] <bryce> +                pPriv->buf = NULL;
[21:22] <bryce>                  xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
[21:22] <bryce>                             "Failed to pin xv buffer\n");
[21:23] <jbarnes> hm I thought we had a fix like that included
[21:23] <jbarnes> but if not yeah you should raise it on the list
[21:23] <bryce> yeah maybe it got fixed some other way... I need to research it more
[21:32] <albert23> bryce: that one was only fixed in master (fdo 21060)
[21:51] <Sarvatt> wow that was fast albert23 :D
[21:52] <bryce> albert23: ok
[21:53] <Sarvatt> its in 2.7 branch as of 8 minutes ago now bryce
[21:55] <Sarvatt> hmm 116_8xx_disable_dri.patch doesn't apply even though src/i830_driver.c hasnt been touched since 2.7.0, i dont think debian merged the actual 2.7.0 release
[21:57] <Sarvatt> yep they merged 2.6.99.903 and called it xserver-xorg-video-intel-2_2.7.0-1
[21:58] <Sarvatt> no front buffer tiling in KMS in that..
[22:15] <jcristau> Sarvatt: what?
[22:16] <jcristau> Sarvatt: that's not true afaict
[22:18] <Sarvatt> I was building 2.7.1 using bryce's debian/ from the karmic package he just pushed and one of the patches didn't apply, so i looked through debian's git at what its based off of
[22:18] <Sarvatt> http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-intel.git;a=commit;h=3663596a9d918283442493e5e3f61ff912f4a97a was the merge
[22:18] <Sarvatt> last commit was    1 commit 121bd7ff7cfd9a43fbb61fa56f06ba2d2b55035e
[22:18] <Sarvatt>    2 Author: Carl Worth <cworth@cworth.org>
[22:18] <Sarvatt>    3 Date:   Fri Apr 10 14:08:00 2009 -0700
[22:18] <Sarvatt>    4 
[22:18] <Sarvatt>    5     Increment version to 2.6.99.903 for release
[22:18] <jcristau> no
[22:19] <jcristau> http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-intel.git;a=commit;h=cff6cf9adc4235af5cc73a47bb272c81635fc8b2
[22:19] <jcristau> well, http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-intel.git;a=log;h=3663596a9d918283442493e5e3f61ff912f4a97a
[22:20] <Sarvatt> oh you're right, I'm sorry
[22:21] <jcristau> the only diff with the 2.7.0 tag is in the NEWS, RELEASING and README files.  not sure why, but not very important.
[23:18] <Sarvatt> xserver-xorg-video-intel 2.7.1 is looking really good, haven't been able to crash it for 45 minutes when I could crash UXA on 2.7.0 and earlier in 5 tops before. i guess those backported post 2.7.99.1 fixes were the ones that fixed me up if I dont end up crashing soon :)