[03:04] <Sarvatt> one day i'll learn mesa master builds are broken after 7.7 branch merges almost every time... always end up packaging mesa right after it happens
[03:10] <bryyce> Sarvatt, heya
[03:16] <Sarvatt> might be a good time to update ati soon, quite alot of bug fixes in the past 2 months on master like signifigant speedups for r600 2D, low memory EXA fixes (and fixing NoAccel to work with KMS), a ton of dpms/incorrect resolution fixes, and a fix for a VT problem I've seen people having
[03:16] <Sarvatt> heyo bryyce
[03:17] <bryyce> update just the -ati ddx ?
[03:17] <Sarvatt> had a question for ya, with this new archive restructuring thing, is X going to have a team or is it going to be part of desktop (or core-dev still)?
[03:17] <Sarvatt> yeah
[03:18] <bryyce> ok I'll todo getting -ati updated either this week or next
[03:18] <bryyce> (next week is the developer sprint so I may not get much done)
[03:18] <bryyce> re: restructuring
[03:19] <bryyce> well there's certainly advantages either way
[03:19] <bryyce> I think I'd like to see Ubuntu-X be its own team  separate from the desktop
[03:19] <Sarvatt> noone really wants to work on X stuff, really strange
[03:19] <bryyce> heh
[03:20] <bryyce> Sarvatt, I don't know, I guess I don't have a strong feel either way.  What do you think?
[03:21] <bryyce> it seems like "X stuff" is distinct enough from "Gtk application stuff" that it splits off easily
[03:21] <bryyce> on the other hand, if having it be two teams means that there's an extra barrier of entry to people who might get involved, that'd be bad...
[03:23] <bryyce> I suppose the thing to look at would be if the desktop team is set up to include both gnome and kde; if not, and if there are separate teams for each, then having X be a separate team may make sense
[03:24] <bryyce> if gnome and kde are both included in the desktop team, then there's less reason to have X separate
[03:24] <Sarvatt> probably not enough people to even make it worth splitting off, I was just reading the ubuntu-motu logs earlier and was confused where X packages would fall with the new changes since one day down the line when I have enough experience with it i'd be interested in helping out there and dont know which team or whatever I should look into joining. have to dig up the wiki pages again, was reading on my phone :)
[03:27] <Sarvatt> like is there still going to be a core-dev team and the desktop team has a subset of upload permissions of that? I'm not really interested in stuff outside of X components so I've been on the fence about MOTU and it seems like thats dissolving or something
[03:30]  * bryyce nods
[03:31] <bryyce> that's another reason favoring a stand-alone X team... there may be people who are *only* interested in X, and joining the full Desktop team just to get access to X stuff might seem a bit too broad for them
[03:57] <Sarvatt> oh nice, didn't know -ati disabled EXA pixmaps for cards with <=32MB vram under KMS now, that should fix up those problem cards that needed XAA under UMS back in the day now that KMS is on by default
[04:03] <Sarvatt> wonder why they didnt branch intel 2.10, post 2.10 is in even worse state right now than 2.10 was for me, compositing is all messed up here
[04:12] <superm1> bryyce, does that mean you're gonna hire more people to work on X? =]
[04:27] <bryyce> superm1, you can bet on it
[04:27] <superm1> that's great! you can never have too much love hacking on X stuff
[05:21] <Sarvatt> yay for blindly reverting random batchbuffer related commits in -intel 2.10 around when it started to try to find the problem since I cant bisect it :D
[05:22] <bryyce> :-(
[05:23] <Sarvatt> -intel master was unusable from 11-11 to 12-10 on 945 here
[05:29] <Sarvatt> hmm theres a few commits that change things for just <965, maybe that'd be a better place to start
[05:46] <Sarvatt> hmm, -joystick has some issues
[05:46] <Sarvatt> took over the mouse
[05:47] <Sarvatt> ah I had my weirdo udev rule I was experimenting with still installed
[05:48] <Sarvatt> cant move the mouse away from the top gnome-panel bar with a controller plugged in
[06:00] <Sarvatt> got it, adding ENV{x11_options.MapAxis1}="disable-mouse", \ to /lib/udev/rules.d/67-xorg-joystick.rules worked
[06:02] <Sarvatt> hmm that cant be right, thats a MapButton option, it probably disabled that axis or something. should have read the man better
[06:19] <bryyce> yeah every so often I have to go through doing a full reinstall in order to clear out all the experimental crap I'd been playing with :-)
[06:19] <bryyce> which has made me be quite strict about not doing any testing on my main desktop
[06:24] <Sarvatt> i've had this install since intrepid and used devel releases the day they opened since jaunty,  probably really due a reinstall here sometime
[06:25] <Sarvatt> ext3 converted to ext4 didn't help fsck times at all, my 40gb ext4 native partition fscks in seconds vs a minute or two for the 10gb / so I'm due a reinstall there for that too
[06:25] <Sarvatt> hmm havent seen this one http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.7.1-gamma-kdm-fix.patch?view=markup
[12:58] <Ng> ugh there's that segfault on USB plug again
[12:58] <Ng> and that wasn't even crazy confused USB afaict, that was just me unplugging my hub and plugging it back in
[12:59] <Ng> did I ask last time I was talking about this why apport doesn't catch Xorg server crashes?
[13:01] <seb128> Ng, because the xorg change to allow that was crashy
[13:01] <seb128> Ng, it's on the todolist for sprint to rewrite it
[13:02] <Ng> ah ok :)
[13:02] <Ng> I'd really like to be able to give a good quality bug report for this segfault other than "erm, I just kinda plug/unplug USB a bit and it crashes" :)
[13:15] <tjaalton> Ng: log in remotely and run gdb?
[13:15] <tjaalton> if it's the server crashing
[13:15] <Ng> tjaalton: I can't reliably reproduce it though
[13:16] <Ng> it's just sometimes USB insertions seem to make X segfault. weirdly it doesn't get restarted, so I'm left looking at the last state of the framebuffer and think the machine has wedged hard, but I can still ssh in
[13:19] <tjaalton> Ng: ok
[15:17] <Sarvatt> Duke`_: if you want something to try -- https://edge.launchpad.net/~sarvatt/+archive/ppa
[15:17] <Sarvatt> (use it on top of edgers)
[15:18] <jcristau> Ng: there's a related bug that got fixed upstream recently iirc
[15:19] <Duke`_> Sarvatt, do I have to add it to my source.list (periodic updates) or just download it once now?
[15:19] <Sarvatt> just download it once
[15:19] <Duke`_> ok
[15:20] <Ng> jcristau: ooh :)
[15:20] <Duke`_> what did you add in it?
[15:20] <Sarvatt> i'm just blindly trying to find what broke it but its better than doing nothing for 2 more months :D
[15:20] <Sarvatt> Revert "uxa: Don't treat prepare_access as a flush synchronisation point."
[15:20] <Sarvatt>       Commit 637f003b047e426901cab6b1fe3a0924bcb9a38a
[15:21] <Duke`_> is it compatible amd64? I'm running X86_64
[15:21] <Sarvatt> uptime
[15:21] <Sarvatt>  10:21:05 up 10:40,  3 users,  load average: 0.02, 0.05, 0.15
[15:21] <Duke`_> ah, build finished.
[15:21] <Sarvatt> yeah whenever it builds, i just uploaded it
[15:22] <Sarvatt> whoa
[15:22] <Sarvatt> mozilla must be on a break :D
[15:22] <jcristau> Ng: http://bugs.freedesktop.org/show_bug.cgi?id=25640
[15:23] <Ng> ah, that was pointed out to me last time I mentioned this. The one key difference is that theirs was really reliably reproducible
[15:23] <Sarvatt> hmm i thought that was fixed a month ago
[15:23] <Ng> mine really isn't
[15:24] <Ng> I plug in to a USB hub at least 5 times a week and it doesn't even crash once a week atm
[15:24] <jcristau> Sarvatt: the patch is 2 weeks old, but not pushed, i think
[15:28] <Sarvatt> ah thats a totally different issue now that i'm looking at it, it was Xi: reset device properties to NULL after deleting them. (#25374) that I was remembering
[16:39] <johanbr> hmmm... suspend does not seem to work anymore with nouveau
[16:39] <johanbr> suspending with nvidia on the same kernel works (but gives graphical artifacts on resume)
[18:37] <apw> bryyce, hey ... how did that testing go?
[19:07] <bryyce> apw, sorry, got sidetracked on another issue.  It's on the todo list for today.
[19:08] <apw> bryyce, np
[19:57] <kees> jcristau: say, can this bug get some love? I'd like to figure out what next-steps are: https://bugs.freedesktop.org/show_bug.cgi?id=9209
[19:58] <jcristau> talk to ajax, i guess
[19:58] <kees> hm, ok
[19:58]  * kees when is he usually online?
[19:58] <kees> oh, he is, just not in here
[19:59] <jcristau> he's at RH in boston, so daytime there
[22:13] <AssertFalse> hi
[22:13] <AssertFalse> anyone to help me configuring my display settings with Dell Latitude E5400 / Ubuntu here ?
[22:15] <jbarnes> AssertFalse: also see /topic :)
[22:15] <jbarnes> lots of good links there
[22:17] <AssertFalse> have tryied many many thing involving xrandr, modeline, xorg.conf but I can't get my resolution above 1024x800 ; which (i guess) is not the max I can get
[22:18] <jcristau> what resolution you can get depends mostly on the monitor..
[22:18] <AssertFalse> (and the /topic is mysteriously not visible with irssi)
[22:18] <jbarnes> https://wiki.ubuntu.com/X
[22:18] <jbarnes> that's /topic
[22:19] <AssertFalse> xrandr says "Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192", am I misunderstanding that i can get 8192 x 8192 resolution ?
[22:19] <jcristau> probably not
[22:20] <jcristau> it's the max size of the framebuffer.  but your monitors won't display that much
[22:20] <AssertFalse> i guess
[22:23] <strycore> Hi
[22:23] <strycore> I've set a wrong resolution on my laptop , how do i reset it to default in a TTY ?
[22:24] <strycore> X has detected wrong refresh rates, i'm getting a black screen on lower resolutions
[22:29] <johanbr> strycore, try "DISPLAY=:0 xrandr --output <OUTPUT NAME> --mode <MODE NAME>"
[22:29] <johanbr> where you get the output and mode names from "DISPLAY=:0 xrandr"
[22:32] <strycore> arrh , I get a X Error of failed request: Badmatch (invalid parameters or attributes)
[22:33] <strycore> Major opcode : 148 (RANDR) , Minor: 7 (RRSetScreenSize)
[22:33] <strycore> if that makes any sense
[22:38] <RAOF> When you run “DISPLAY=:0 xrandr”?
[22:40] <strycore> i got the wrong resolution with gnome-display-properties
[22:40] <strycore> RAOF, no with the output and name
[22:40] <strycore> DISPLAY=:0 xrandr --output LVDS --mode 1280x800
[22:41] <RAOF> And “DISPLAY=:0 xrandr” had LVDS as an output and 1280x800 as a possible mode?
[22:41] <strycore> yes that's the native resolution
[22:41] <RAOF> Can you pastebin the output of “DISPLAY=:0 xrandr -q”?
[22:42] <strycore> I'm afraid i can't , I would need a command line version of pastebin ;)
[22:42] <RAOF> pastebinit!
[22:42] <RAOF> sudo aptitude install pastebinit.
[22:42] <RAOF> The worlds finest remote debugging tool.
[22:43] <strycore> ah ok :)
[22:43] <RAOF> Then you'd run “DISPLAY=:0 xrandr -q | pasetbinit”
[22:44] <strycore> hmm, I would need network-manager now :(
[22:44] <strycore> oh wait, xterm session works
[22:45] <RAOF> Oh.  You don't have your wireless set up as a system-wide thing?  That's a good thing to do :)
[22:46] <strycore> I know but I haven't configured my laptop that much since i installed lucid
[22:48] <RAOF> Heh.  Setting my home's wireless to system-wide is one of the first things I do - for pretty much this reason :)
[22:49] <strycore> well , I'm trying to figure out in gnome-display-properties' source code where it saves its settings
[22:51] <RAOF> In ~/.config/gnome-something-or-other/monitors.xml
[22:52] <strycore> ah
[22:53] <strycore> i typed Alt+F2 and typed xrandr -s 0 blindly , it worked :)
[22:54] <RAOF> :)
[22:54] <strycore> how does xrandr "guesses" the resolutions and refresh rate ?
[22:55] <strycore> 1360x768 , that pretty new to me ! 
[22:55] <RAOF> By asking your monitor for the resolutions and refresh rates it supports.
[22:56] <RAOF> IE: X grabs the EDID via DDC.
[22:57] <RAOF> Whoops!  Phoronix is wrong about xserver-xorg-video-nouveau.
[22:57] <RAOF> Also, yay for the kernel team!
[22:57] <strycore_> http://pastebin.com/m7b1ec797
[22:58] <strycore_> 1280x800 and 1024x768 works , that's all
[22:59] <RAOF> None of the other ones do?
[23:00] <RAOF> I'm surprised by that output, though.
[23:00] <strycore_> nope, black screen
[23:00] <RAOF> You might want to submit a bug against your video driver; it would appear to be returning invalid modes (which probably means that your monitor has a broken EDID).
[23:01] <strycore_> I'm pretty sure there's something wrong with the monitor
[23:02] <RAOF> And filing a bug with the EDID attached means we (or, rather, upstream) can add a work-around.
[23:02] <strycore_> I had a really hard time to get it working on gutsy and dapper (back when fglrx supported my chipset)
[23:05] <RAOF> https://wiki.ubuntu.com/X/Troubleshooting/Resolution is the page of wonder.
[23:13] <strycore_> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/513011