[00:09] <hyperair> maco: i don't think that the wireless driver is related to the gpu driver.
[00:10] <hyperair> maco: rather, i've noticed your issue on the .31 kernels, specifically whenever the system begins running out of memory, or during periods of very high I/O activity
[00:12] <maco> oh i dont think the drivers are touching each other, just that X was going nuts until the wireless wanted so much CPU that they couldnt both have what they wanted
[00:15] <hyperair> O_o?
[00:15] <maco> well they both wanted to use 100% of CPU and kmail wanted 40%
[00:15] <maco> with a dual core, they can only get 200%
[00:15] <hyperair> kmail is an x client.
[00:15] <hyperair> but seriously, this isn't within ubuntu-x's field
[00:16] <hyperair> you should be complaining to the kde people
[00:16] <hyperair> ubuntu-x only handles X itself, and its drivers.
[00:16] <maco> *sigh* but the Xorg process was using 100% and then 58% later
[00:16] <maco> i already talked to rtg about the wireless thing, im just concerned about why Xorg is using my entire CPU when there's not even compositing happening
[00:16] <hyperair> O_o sounds like you seriously got your system screwed up
[00:16] <maco> i just installed it like 3 weeks ago
[00:17] <hyperair> but there are X clients that can cause Xorg's CPU usage to rise dramatically
[00:17] <maco> but kmail and Xorg are listed separately in top
[00:17] <hyperair> yes they are
[00:17] <hyperair> they are different processes
[00:17] <maco> and Xorg was using quite a lot more than kmail was
[00:17] <hyperair> but kmail is an X client
[00:17]  * hyperair facepalm
[00:17] <hyperair> will you listen?
[00:17] <hyperair> quit kmail and see
[00:17] <maco> but kmail doesnt count into it!
[00:18] <hyperair> for all you know, kmail's causing X's CPU usage to rise
[00:18] <maco> it is not
[00:18] <hyperair> X clients *communicate* with the X server.
[00:18] <maco> xorg's usage has gone down since then
[00:18] <maco> Xorg process is down to 4% now (yay)  and kmail is still 31%
[00:18] <hyperair> well next time identify the faulty X client
[00:18] <maco> so Xorg's CPU usage in top isnt just adding up all the X clients' usage %s 
[00:18] <maco> im running all the same things i was runnign before
[00:19] <hyperair> ...you seriously aren't listening.
[00:19] <hyperair> Xorg is a *server*. Kmail and other applications are X *clients*
[00:19] <hyperair> when a client bombards a server with requests, what happens?
[00:19] <hyperair> the server takes more CPU.
[00:19] <hyperair> it's as simple as that.
[00:19] <hyperair> they are separate processes!
[00:20] <hyperair> hell they could even be on different computers!
[00:20] <maco> so how do i find out which client is sending all those requests?
[00:20] <maco> the same apps have been running the entire time.
[00:20] <hyperair> dunno. quit the highest cpu using client and see
[00:20] <hyperair> could be a buggy client that suddenly screwed up
[00:21] <maco> if an application is on a different workspace, does it still talk to X? it doesnt need to be drawn...
[00:22] <hyperair> yes, it does.
[00:25] <maco> so if a terminal has an ssh session and that session is compiling stuff, X still would be requested to render all that compiler-spew?
[00:25] <maco> oh and the terminal is on a different workspace
[00:25] <maco> a not-visible one
[00:27] <hyperair> it would probably be telling X that there are updates
[00:27] <hyperair> but i don't think it would be rendered until it's unobscured
[00:27] <maco> hmm so could that be why my cpu usage goes up when im remote compiling?
[00:28] <hyperair> well it might rise a little, but very little.
[00:29] <hyperair> you should probably just test quitting the clients one by one the next time it happens
[00:30] <maco> ok
[00:38] <bryce_> hyperair is right
[00:39] <maco> im sorry i got confused before. the server & client separation didnt occur to me. i thought it was a parent/child process thing he was talking aout
[00:39] <bryce_> maco, xrestop can also give some clues about what apps might be using X, but it looks only at resource memory usage so isn't a perfect indicator
[00:39] <maco> how many *top apps are there?
[00:40] <maco> [h]top, powertop, and iotop were the ones i knew
[00:40] <bryce_> there's like a dozen
[00:40] <bryce_> htop, vtop, ptop, itop, atop, mtop, ntop, top, xrestop... probably lots more.  'stop' ;-)
[00:41] <bryce_> maco, anyway, it's a common point of confusion, and I've documented it at http://wiki.ubuntu.com/X/Troubleshooting/
[00:42] <maco> ok
[00:42] <maco> thanksguys
[01:57] <bryce_> Sarvatt, if you're interested in scoring some merges for your motu app, I've marked some packages currently needing merged:  http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html
[03:40] <ScottK> bryce_: Give away the hard ones....
[04:35] <bryce_> ScottK, I don't want to scare him off!  ;-)
[14:10] <Starks> bryce, what do you think of this? http://ubuntuforums.org/showpost.php?p=7773647&postcount=13
[14:10] <Starks> would the license allow this?
[14:14] <tseliot> Starks: the patch acts upon the open part of the driver therefore I don't that patch is a problem
[14:14] <Starks> can karmic ship with it?
[14:16] <tseliot> poulsbo was only made available in a PPA
[14:17] <tseliot> Ubuntu doesn't have poulsbo in its repositories
[14:17] <tseliot> as poulsbo uses an old version of libdrm
[14:18] <tseliot> a PPA would be the right place for that
[14:22] <ScottK> tseliot: PPA is only allowed for free software.
[14:23] <Starks> ppa doesn't allow binary blobs?
[14:23] <Starks> since when?
[14:24] <tseliot> ScottK: I know that nvidia is also made available in PPAs and there's this PPA with psb too: https://launchpad.net/~ubuntu-mobile/+archive/ppa
[14:24] <ScottK> tseliot: Read the PPA terms of service.
[14:24] <jcristau> maybe canonical gets an exception
[14:25] <ScottK> It probably does as there are commercial exceptions to the TOS.
[14:25] <tseliot> it could be
[14:26] <Starks> does a driver have to be sanctioned in order to be included?
[14:26] <Starks> also, even if intel and powervr had up to date psb drivers, would they be included by default?
[14:27] <Starks> or would it be restricted?
[14:29] <tseliot> restricted
[14:30] <tseliot> not that it's so simple
[14:42] <Starks> poulsbo's successor is likely to be another powervr-created monster.
[14:43] <jcristau> sigh.  they didn't learn anything from the psb fiasco?
[14:51] <Starks> dunno.
[14:52] <Starks> it was a decent chip spec-wise
[14:52] <Starks> drivers were shit though.
[14:52] <Starks> windows was no exception.