[01:19] <RAOF> Damnit intel.  Couldn't you be just a *little* more verbose by default?
[01:22] <bryceh> heh
[01:23] <RAOF> Failing to provide a framebuffer because you don't think there's any outputs connected sounds like something you'd want to at least mention in passing!
[01:24] <bryceh> pshaw!
[01:25] <bryceh> yeah I would like it if X would behave better if booted in a situation with no outputs
[01:25] <bryceh> however, definitely a corner case
[03:03] <RAOF> Hooray for having a crazily slow netbook!
[09:34] <tjaalton> ngh, scrolling an lp bug page is painfully slow
[09:34] <tjaalton> at least with nvidia..
[12:39] <KiBi> tjaalton: what'bout that new nouveau thingy? :)
[12:40] <tjaalton> KiBi: what where?
[12:41] <KiBi> You were sighing about nvidia. Didn't know whether you were speaking about HW or SW.
[12:42] <tjaalton> oh, I didn't realize this was on #ubuntu-x :)
[12:42] <tjaalton> but yeah, nouveau 2d is fast
[12:42] <tjaalton> too bad I "need" compiz
[12:43] <tjaalton> tseliot: uploading mesa 7.7.1 now, meanin my adsl is useless the next several minutes..
[12:44] <tseliot> tjaalton: thanks :-)
[13:46] <seb128> would bug #534571 be a libxi issue?
[13:47] <seb128>  XListInputDevices() crashing on vnc servers
[13:50] <jcristau> does the app check for XI support before calling XListInputDevices?
[13:51] <jcristau> also what libxi6 version is that?
[13:53] <tjaalton> 1.3-3 if from lucid
[13:55] <seb128> jcristau, it does
[13:55] <seb128>         return XQueryExtension (GDK_DISPLAY (),
[13:55] <seb128>                                 "XInputExtension",
[13:55] <seb128> libxi6 2:1.3-2
[13:56] <seb128> ie it queries for "XInputExtension" before using it
[13:56] <seb128> there is a duplicate with -3 too
[13:58] <jcristau> sigh epiphany crashed.
[14:06] <seb128> I should write a small testcase calling XListInputDevices() and try under vnc
[14:08] <jcristau> try xinput list
[14:31] <jcristau> seb128: that particular crash is what -3 fixed.  if you have a backtrace from -3 i'd like to see it.
[14:32] <seb128> jcristau, http://launchpadlibrarian.net/41069061/Stacktrace.txt is one
[14:32] <seb128> sorry
[14:32] <seb128> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/546388
[14:32] <jcristau> that looks like -2
[14:32] <jcristau> ok
[14:33] <seb128> it's exactly the same
[14:33] <seb128> there is still a chance libxi was loaded though
[14:33] <seb128> the apport infos report was is installed, not if g-s-d still runs for days with the old version loaded
[14:34] <jcristau> but it does sound like you're calling XI functions when the server has no XI support
[14:34] <seb128> if you say it's fixed in -3 I will ask if somebody still get it after session restart and current version
[14:34] <jcristau> ok, thanks
[14:34] <seb128> right
[14:34] <seb128> so the client should look for the capability?
[14:34] <jcristau> yes
[14:34] <seb128> isn't what the XQuery call I copied before do though?
[14:34] <jcristau> it is
[14:35] <seb128> k, so I'm not sure what is happening
[14:36] <seb128> could be that the server is buggy and declare doing things it doesn't do
[14:36] <seb128> I've asked for xinput list logs now
[14:36] <seb128> if somebody still get the issue I will write a small testcase doing the XQuery and the XListInput calls
[14:42] <jcristau> afaict only some parts of gsd do the supports_xinput_devices check
[14:42] <jcristau> nothing on the path to set_tap_to_click
[15:06] <seb128> jcristau, oh, could be the issue then indeed
[15:18] <ScottK> tseliot: We've found a really bad bug in kdebase-workspace related to display controls.  Unfortunately they are not well maintained upstream, so I was wondering if you might be able to have a look?  It's Bug #554948.
[15:18]  * tseliot has a look
[15:19] <ScottK> Thanks.
[15:26] <tseliot> ScottK: so, basically you would like the timer to default to "revert" instead of "keep", right?
[15:26] <ScottK> tseliot: Yes.  It looks to me like it's trying to do that, but the actual revert fails.  I'm not sure though.
[15:27] <ScottK> Otherwise you can end up stuck.
[15:31] <tseliot> ScottK: yes, I think it's supposed to do that but maybe I spotted the error
[15:32] <tseliot> I'd like to check the KDE api reference first though
[15:33] <ScottK> tseliot: Excellent.  Thank you.
[15:34] <tseliot> np
[15:38] <ripps> hrm... I don't what it is, but today, after the last few updates. Xorg has been giving me some pretty nasty spikes in cpu usage, even when I don't have anything open.
[15:41] <ripps> after rebooting, it works fine for a while, but then it starts acting up again. Think it could be a memory leak or something?
[15:44] <ripps> it's even causing pulseaudio to skip a bit now
[15:45] <ScottK> tseliot: The other thing that may not be clear from the bug is that there is a display configuration kcm and the krandrtray systray application.  They appear to share little or no code, but both manage to exhibit this problem.
[15:46] <tseliot> ScottK: ok
[15:55] <tseliot> ScottK: out of curiosity, has the revert dialog ever worked?
[15:56] <ScottK> tseliot: It worked in KDE3.  I can't say for sure about KDE4.  I know it's broken in KDE 4.3 and 4.4 (all I have to test).
[16:02] <apw> ROAF ... there are queries on your acceleration patch
[16:09] <tseliot> ScottK: if the app is the one in randr.cpp which uses ktimerdialog.cpp, I'm afraid there's nothing (i.e. no slot) connected to the revert action, therefore, no matter what you click on, you should always get the same result. KTimerDialog::slotInternalTimeout() simulates a button click but that's all you get, as that signal should trigger some (unimplemented) action instead of just closing the dialog. Unless there's some
[16:10] <ScottK> tseliot: That's the systemsettings kcm.  The systray app is krandr.cpp, iirc.
[16:10] <ScottK> Getting one of them to work would be a huge help.
[16:11] <ScottK> krandrtray doesn't use KTimerDialog
[16:20] <tseliot> ScottK: I'm not sure if I have the time to code this
[16:20] <ScottK> tseliot: If you don't, you don't, but it would be a really good thing to get into the LTS ....
[16:20] <ScottK> tseliot: Maybe if I could find someone to help?
[16:28] <tseliot> ScottK: sure, someone who is familiar with C++/QT. Do you know which program randroutput.cpp belongs to? As RandROutput::applyProposed to do to our case
[16:29] <ScottK> tseliot: No.  We're getting to the end of what I could figure out.
[16:35] <ScottK> tseliot: Please see what you can do and I'll try to hunt up a coding assistant.  That may take a few hours.
[17:25] <jg> bryceh: sigh...  I can't get beta2 to start X at all...
[17:26] <jg> I can't get the iso to get to a place I can even try to enter the suggested kernel parameters.
[17:42] <ripps> I think I figured out what was slowing down Xorg, it was mousetweaks. The moment I disabled secondary click from the mouse properties, Xorg's cpu usage dropped. I guess it must be constantly polling the mouse position or something. Definately needs some optimzation
[17:54] <ripps> cancel that, Xorg started going up again. It's causing pulseaudio from mpd to stutter. This is weird, it wasn't like this yesterday.
[18:43] <ripps> I'm sorry if I'm sound annoying, but I honestly want to try and fix this bug, but I'm not sure how to go about it. I've tried using gdb, but it just froze my desktop. Right now, since I've just reboot, I'm not experiencing the high cpu usage yet. But if somebody knows how I can capture it in a log as it happens.
[19:11] <ripps> There it goes, now it's stuck between 10-50%
[19:12] <ripps> About a half hour, every time.
[19:15] <ripps> hmm... restarting gdm seems to help, but it's going to get real annoying real fast if I half to restart xorg every 30 minutes.
[23:25] <Burgundavia> bryceh, you around for a quick question?
[23:38] <Sarvatt> wonder why meego is disabling GL_ARB_texture_rectangle on intel, can't find any reference to why they have this patch