[00:27] <RAOF> bryceh: The “stuff->foo” idiom in X protocol handlers is common - one of the macros involved in unpacking the proto buffer defines & populates it.
[00:28] <RAOF> That freaked me out as well when I started looking at the protocol dispatch code :)
[00:33] <bjsnider> RAOF, do you suppose mono is dead now?
[00:33] <RAOF> No.
[00:34] <RAOF> I understand that there's quite a healthy revenue stream coming from the various Mono* frameworks for smartphones, there are paid mono developers in Europe, and at worst, it's all open source and quite a lot of people care about it.
[00:37] <bjsnider> yeah but it's not the same without any support from novell
[00:39] <RAOF> I'll wait until there's actual news that Attachmate is shuttering the Mono* work before worrying *too* much about Attachmate shuttering the mono team. :)
[00:39] <bjsnider> how can they continue the mono work if they fired the whole team?
[00:43] <RAOF> Where's the suggestion that they fired the whole team?
[00:44] <RAOF> Last I heard was “consolidating in Europe, letting go some US developers”
[01:13] <bjsnider> the phoronix story said 30 mono developers
[02:37] <raevol> any tips on configuring an 11.04 xorg.conf for dual head? i forgot to back up my old one and can't remember the black magic i used to get it working before
[02:37] <raevol> http://pastebin.com/zhm8JZKh
[02:38] <raevol> is what i have, but no dice
[02:45] <RAOF> raevol: Generally I don't bother with an xorg.conf and just let the DE tools set up dual-head.
[02:46] <raevol> DE?
[02:46] <raevol> desktop environment?
[02:46] <RAOF> Yeah.
[02:46] <raevol> i'm running xfce so i don't have those tools
[02:46] <RAOF> Failing that, http://tinyurl.com/yuftlh
[02:46] <raevol> yea that's the guide i just used, no luck
[02:47] <raevol> i wish there wasa way to generate an xorg.conf from a xrandr setup
[02:48] <raevol> do you know if my xorg.conf should be in /etc or /etc/X11?
[02:50] <raevol> seems to load it either way
[02:55] <bryceh> should be in /etc/X11, although xserver checks a variety of paths
[02:56] <raevol> ok
[02:57] <raevol> hmm, using that guide, my xorg.0.log says "no monitor specified for screen0"
[02:57] <raevol> appears that guide is out of date
[03:07] <bryceh> RAOF, one advantage to using xorg.conf might be that the server initializes as multihead, so your screens would be set up earlier than if you let gnome-desktop do it post-init
[03:36] <Takyoji[laptop]> Any way that I can help with debugging this bug? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/763688
[03:36] <ubot4`> Launchpad bug 763688 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[915GM] S-video output doesn't work in Natty (i386) (affects: 10) (heat: 242)" [Medium,Confirmed]
[03:37] <Takyoji[laptop]> of which I'm affected by
[03:39] <bryceh> Takyoji[laptop], install xdiagnose, run sudo xdiagnose, switch on graphics debug messages (the first checkbox).  Reproduce the bug, then collect output of dmesg, post to the bug. 
[03:40] <bryceh> Takyoji[laptop], assuming it's not obvious what's wrong, the next step after that is to forward the bug upstream to bugs.freedesktop.org, sending dmesg, Xorg.0.log, and xrandr output
[03:55] <Takyoji> alright
[07:48] <tjaalton> so -mouse/-keyboard are for !linux, which means we can drop them from ubuntu by now, because evdev is used by default since intrepid
[07:48] <tjaalton> ?
[07:48] <tjaalton> can't think of any other usecase for them
[07:49] <tjaalton> but people keep on filing bugs against them
[07:49] <tjaalton> when they should've filed against -evdev
[07:49] <bryceh> tjaalton, yep
[07:50] <tjaalton> also, should we review the list of ubuntu patches on xorg-server next week?
[07:50] <tjaalton> hm
[07:51] <tjaalton> maybe a new session for "removing cruft & patch review"
[07:51] <tjaalton> or cram them into an existing one
[07:51] <tjaalton> dunno how much time this would need
[07:52] <RAOF> I'd like that.
[07:52] <bryceh> I could easily imagine us needing ~5 min per patch, so that could add up to a whole session
[07:52] <RAOF> Go over xserver & mesa.  We might as well schedule a session for it, even if we don't use up the whole time.
[07:53] <tjaalton> yeah
[07:53] <bryceh> don't forget there'll be a sprint not too far afterwards
[07:53] <tjaalton> cruft removal fits in the general planning session i guess
[07:53] <bryceh> it's possible you may prefer having that discussion at the sprint when you're not quite as session-slammed
[07:54] <tjaalton> bryceh: right, but it's too late for pushing the valid patches upstream
[07:54] <bryceh> fair enough
[07:54] <bryceh> also, I won't be attending the sprint, so if you need my input then uds would be better
[07:57] <tjaalton> ok
[07:59] <tjaalton> hmm, I'll check the release schedule for 1.11
[08:02] <bryceh> some portion of the xserver patches are just adding null pointer checks.  between apport and arsenal I'm confident we'd be able to quickly notice the crashes those fixed if they came up again so I'd be ok with us just blindly dropping them and see what happens.  I'm fairly sure all were forwarded upstream and got fixed in more intricate ways subsequently (worth doublechecking)
[08:03] <bryceh> there's another portion which were driven by dx team needs which I don't even know for sure are still valid... like the bgnone stuff
[08:03] <tjaalton> i dropped one which got marked fixed upstream in a different way
[08:03] <tjaalton> but yeah
[08:03] <bryceh> tseliot was a bit more tied into that stuff
[08:03] <tjaalton> we'll see then :)
[08:04] <bryceh> tjaalton, anyway whatever patches remain should be renumbered from 100.
[08:04] <bryceh> oh, there's also a handful from cnd for input stuff, although he's been good about ensuring those get sent upstream for the most part
[08:05] <tjaalton> bryceh: maybe so that 1xx is for patches never meant upstream, 2xx those that are targeted upstream, and then 3xx for backports?
[08:05] <tjaalton> or somesuch
[08:05] <bryceh> yeah, sounds like a good scheme
[08:05] <tjaalton> yeah the input stuff should get in 1.11, i hope
[08:06] <bryceh> only catch might be if a 1xx ubuntu-specific patch depended on a 3xx backport patch or something
[08:07] <bryceh> but that sort of situation is probably going to be exceedingly rare
[08:07] <tjaalton> good thing quilt doesn't care how they are named, just what order they have on the list .)
[08:07] <tjaalton> :)
[08:07] <bryceh> heh, that's true
[08:56] <tjaalton> so the merge window for 1.11 closes on 27th
[09:01] <tjaalton> which means having a review session next week would probably make sense
[15:22] <Sarvatt> well thats a fun change to wake up to, mesa requires glproto 1.4.13, xserver 1.10.x doesn't build against glproto 1.4.13 :)
[16:01] <Azelphur> Hmm, I'm having fun with my computers text rendering atm http://dl.dropbox.com/u/3832397/screenshots/May%202011/2011-05-05-155649_3840x1200_scrot.png
[16:02] <Azelphur> any ideas what would cause that? it seems to affect everything
[16:05] <Azelphur> X session restart time I guess \o/
[20:21] <Sarvatt> if anyone needs drm-intel-next for testing - http://kernel.ubuntu.com/~sarvatt/drm-intel-next/
[20:52] <bryceh> Sarvatt, btw that's also built by the kernel team - http://kernel.ubuntu.com/~kernel-ppa/mainline/
[20:52] <bryceh> (although looks like it hasn't been updated in a while...)
[20:53] <Sarvatt> bryceh: yeah its pointing at ickle's drm-intel-next and keithp took over maintainership of it
[20:53] <bryceh> ah
[20:53] <Sarvatt> plus this one has all the ubuntu specific patches so I have a functional touchpad and junk :P
[20:53] <bryceh> apw, ^^  need to repoint the git tree on drm-intel-next
[20:54] <Sarvatt> pinged him this morning, pretty sure he's gone already
[20:55] <bryceh> well, no hurry.
[20:55] <bryceh> Sarvatt, remind me we should snag a kernel guy next week about this
[21:58] <Sarvatt> bryceh: hopefully http://translate.google.com/#en|hu|give%20me%20a%20guinness%0A is all the hungarian I need :)
[21:59] <bryceh> heh
[22:00] <bryceh> guessing a beer run on Monday will be on the agenda
[22:00] <bjsnider> spend all day debating which beer it will be and who will get it