[05:39] <tjaalton> pwnguin: if you have input-hotplug, evdev steals the input devices (if they have mouse/kbd capabilities) unless other drivers have fdi files for them, so yes, input devices in xorg.conf is generally not working anymore
[05:39] <tjaalton> dexconf might need an update
[05:39] <tjaalton> um, should
[05:39] <wgrant> Shouldn't dexconf go away?
[05:40] <tjaalton> there are some quirks left
[05:40] <tjaalton> kvm/ps3 stuff
[05:40] <wgrant> Ah.
[05:41] <wgrant> Is there currently a way to make input-device properties persistent besides hacking support into g-s-d?
[05:41] <tjaalton> bryce: ajax said that the server shouldn't poke acpid at all anymore :)
[05:41] <tjaalton> wgrant: not that I know of
[05:49] <wgrant> Unfortunate.
[05:49] <bryce> tjaalton: then how is it that the server is issuing warnings when acpid isn't present?
[05:49] <wgrant> But I guess it should all be exposed in capplets eventually.
[05:51] <tjaalton> bryce: I mean that the code should be removed altogether.. "shouldn't poke acpid in the future" :)
[05:52] <bryce> tjaalton: ahh.  Is there an easy way to disable it without requiring major surgery, or should we leave it 'til intrepid+1?
[05:52] <tjaalton> wgrant: well, xrandr isn't persistent either
[05:52] <wgrant> tjaalton: True.
[05:52] <wgrant> g-s-d handles that now, doesn't it?
[05:52] <tjaalton> bryce: I haven't had a look.. upstream would like patches, so if it makes in 1.6..
[05:52] <tjaalton> wgrant: yep
[05:54] <bryce> tjaalton: ah ok.  well let's go with my patch in the meantime.
[05:54] <tjaalton> yep, sure
[05:55] <bryce> I forgot I had today off
[05:55] <tjaalton> how unfortunate :)
[05:56] <bryce> so all that git fussing wasn't needed until tomorrow ;-)
[05:56] <bryce> but on the plus side I got all my alpha-5 stuff in (well, xorg still needs uploaded)
[05:57] <bryce> and I implemented a quirk system for -ati for AGPMode quirking
[05:57] <tjaalton> really? how?
[05:58] <bryce> I used the same approach as -intel, but made it also account for the hostbridge's PCI ID.  airlied and alex said it depends on both
[05:59] <tjaalton> ah, right
[05:59] <bryce> there's other factors that play into it though, so maybe more should be accounted for, but it's a start
[05:59] <bryce> probably should be ok for laptops that don't have involved BIOS options
[06:00] <bryce> which I'm guessing is going to be like 95% of the cases ;-)
[06:00] <tjaalton> yeah
[06:58] <tjaalton> bryce: what about applying xserver commit 5e847c1d4fc30a0d263a?
[06:59] <tjaalton> it would at least fix bug 261977
[06:59] <tjaalton> and make the failsafe-stuff simpler
[07:01] <tjaalton> then we could also add patches to first try nvidia/fglrx if they are installed (but maybe this needs TB ack?)
[07:17]  * bryce looks
[07:19] <tjaalton> the last fallback would be vesa for x86 etc
[07:24] <bryce> hmm
[07:25] <bryce> yeah I can see how this'll help when patched for nvidia/fglrx.  I am not sure I see how this helps in general though... but upstream obviously accepted it, so...
[07:26] <tjaalton> if the "optimal" driver fails, it'll try the next one, and finally the fallback
[07:27] <bryce> will it?  I don't see the failure handler
[07:27] <tjaalton> it has been there AFAIK, but not working
[07:28] <bryce> well in any case I can see that better fallback handling is the direction this goes
[07:28] <bryce> it looks like something else is needed in addition to this to do that
[07:28] <bryce> anyway, +1 for including this patch.
[07:29] <tjaalton> ok, I'll add it and test how it goes
[07:29] <tjaalton> the fallback thing
[07:29] <bryce> I don't think we need a TB ack to add something to load nvidia/fglrx if they're installed - I think it's a general principle that if the user installs something, then it's safe to assume that they want it, and to go ahead and "just work" from there
[07:30] <bryce> however obviously we should get working fglrx and nvidia before that ;-)
[07:31] <tjaalton> I'm just thinking about if it has negative PR implications
[07:31] <tjaalton> basically it would claim that we support the drivers, while we can't
[07:32] <tjaalton> or maybe we can draw the line somewhere between "we'll allow it to autoconfigure" and "you should report your crashers upstream" :)
[07:33] <bryce> would we accept that patch if fglrx and nvidia* were demoted to universe because the foss drivers were good enough?
[07:35] <tjaalton> dunno.. it's problematic since the free driver is always installed
[07:35] <tjaalton> so if you want to use the nonfree one, it should be on top of the driver stack to try
[07:37] <wgrant> s/universe/multiverse/, I hope.
[07:37] <tjaalton> yes
[07:37] <tjaalton> they could be demoted, because they're no longer part of lrm
[07:40] <pwnguin> plus, it doesn't mean anything special anymore like it used to
[07:40] <pwnguin> you previously had to enable universe repos
[07:40] <tjaalton> yep
[07:41] <wgrant> You still have to enable multiverse, don't you?
[07:41] <wgrant> I hope...
[07:41] <tjaalton> also, tseliot would be able to upload directly :)
[07:41] <pwnguin> it does mean that any joe motu can upload
[07:41] <tjaalton> that rarely happens
[07:41] <pwnguin> something that's basically in use everywhere and affects everything
[07:42] <wgrant> tseliot it's a MOTU.
[07:42] <wgrant> *isn't
[07:42] <tjaalton> oh, duh
[07:42] <wgrant> How'd I manage that, I wonder.
[07:42] <tjaalton> well, not yet anywya
[07:42] <tjaalton> -way
[07:42] <tjaalton> every motu should know to stay away from nvidia* :)
[07:43] <pwnguin> i can imagine one of two scenarios
[07:43] <wgrant> If we have MOTU who touch it inappropriately, they shouldn't be MOTU.
[07:43] <tjaalton> right
[07:44] <pwnguin> i guess theres already a few kernels in universe
[07:44] <wgrant> This is proving to be unfortunately common, but that's another story.
[07:44] <pwnguin> but nvidia is more popular than say -rt
[07:45] <wgrant> I don't think main exists just to keep some packages out of our reach.
[07:45] <pwnguin> well, it's supposed to denote some level of canonical annointing
[07:45] <pwnguin> annointedness?
[07:46] <bryce> essentially, we say we provide ongoing security fixes for stuff in main, but not universe
[07:46] <wgrant> That's all it means, right.
[07:46] <wgrant> Can Canonical guarantee updates for blobs? No.
[07:46] <bryce> right
[07:47] <pwnguin> would canonical refuse to update a blob found to be insecure and fixed?
[07:47] <tjaalton> so, I'd say that by not hardcoding the driver in xorg.conf would be better in the end, since then the fallback has a chance of working, which is more useful for the blobs anyway
[07:48] <bryce> tjaalton: sounds good
[07:49] <bryce> pwnguin: generally what I've been told is that doing SRU's of fglrx/nvidia is hardly ever going to be acceptable since we can't verify the source changes
[07:49] <pwnguin> how about
[07:49] <pwnguin> we put nouveau on the top of the stack
[07:49] <tjaalton> the only setting the nvidia's have in xorg.conf is NoLogo.. (71/96 has some AIGLX-stuff too)
[07:49] <pwnguin> then nvidia
[07:49] <pwnguin> then nv
[07:49] <pwnguin> PR solved
[07:49] <tjaalton> pwnguin: there is no usable nouveau
[07:49] <bryce> a security fix *might* be ok, but generally the blogs are released with a bunch of fixes, not just one cherry picked thing
[07:49] <tjaalton> release
[07:49] <tjaalton> if there were, I'd be all for it
[07:50] <pwnguin> bryce: oh right, you werent around for the last time nvidia had a remote exploit
[07:50] <tjaalton> pwnguin: it was fixed
[07:50] <pwnguin> tjaalton: yes it was
[07:50] <tjaalton> after edgy I think
[07:51] <tjaalton> or was it breezy
[07:51] <bryce> sounds nasty
[07:51] <pwnguin> javascript crafted to exploit a video driver?
[07:51] <pwnguin> nasty doesn't begin to describe the horror
[07:51] <tjaalton> heh
[07:52] <pwnguin> in such a situation, if canonical can't provide a fix, i'd almost say upload a new package that just removes it
[07:55] <pwnguin> tjaalton: there's no usable nouveau, or no usable nouveau in Ubuntu proper?
[07:55] <tjaalton> pwnguin: both. debian-experimental has, but they also have a libdrm snapshot
[07:56] <pwnguin> my laptop power cable is inthe mail
[07:56] <pwnguin> tjaalton: rihgt
[07:56] <pwnguin> RAOF has a ppa
[07:56] <tjaalton> yes, he's co-maintaining the d-e stuff
[07:56] <pwnguin> i havent tested it it recently, but it seems like it'd at least be a statement of support and cooperation
[07:57] <tjaalton> I don't think we have the manpower to support it.. upstream wont, that's known :)
[07:57] <tjaalton> they don't want users yet, developers are fine
[07:57] <pwnguin> nouveau, or d-e?
[07:57] <tjaalton> nouveau
[07:58] <tjaalton> when they can use stable drm interfaces and put out a release, the situation changes
[07:58] <pwnguin> of course
[07:59] <tjaalton> now that the drm release management has been reshaped, there's hope that nouveau will catch up too
[07:59] <tjaalton> my words
[08:00] <tjaalton> the GEM/TTM mess didn't really help either
[08:00] <tjaalton> but that's mostly done now I guess
[08:00] <pwnguin> does something bad happen if nouveau driver isn't found? i thought it'd fall back to the next available driver
[08:01] <tjaalton> right, it should
[08:01] <tjaalton> note that I haven't tried it yet
[08:01] <pwnguin> heh
[08:02] <pwnguin> it just seems like a token nod to their efforts that costs nothing, gets them a little, and gives you something to say when people ask why nvidia is picked over nv
[08:03] <tjaalton> yes, but when nouveau is better than nv, it'll be installed in favour of nv, and we are facing the same problem
[08:03] <pwnguin> oh. hrm
[08:03] <tjaalton> you install nvidia by yourself so you'd expect it to work
[08:04] <tjaalton> by the next LTS we'll hopefully have good FOSS drivers so we can kick nvidia/fglrx out of the door completely :)
[08:04] <pwnguin> the only reasonable option is order of quality, but nobody wants to hear that
[08:05] <tjaalton> intrepid+1 could have 3D support for all the latest ATI chips
[08:05] <pwnguin> im not so hopeful about 3D on nvidia. there's a plan and like one dude last i looked
[08:06] <tjaalton> yes it's more problematic
[08:07]  * bryce squints and wishes real hard for nVidia to disappear
[08:09] <pwnguin> from my interactions with fedora users, apparently Canonical just needs to spend money to make it disappear, like Red Hat does
[08:09] <bryce> haha
[08:09] <pwnguin> i wish i was joking
[08:10] <tjaalton> they should just open up
[08:10] <pwnguin> damn 7.0B market cap
[08:11] <pwnguin> 51 percent will be hard to buy
[08:11] <jcristau> pwnguin: well, RH does a lot of work on X upstream. can't say that's true of canonical.
[08:14] <pwnguin> what?
[08:14] <pwnguin> well,
[08:14] <pwnguin> dave left, seemingly on not great terms
[08:14] <pwnguin> err
[08:14] <pwnguin> daniel
[08:14] <tjaalton> and about to leave nokia for...
[08:15] <pwnguin> oh?
[08:15] <tjaalton> later this fall
[08:15] <tjaalton> going back down under, don't know what to work on
[08:15] <pwnguin> hmm. tough one to guess. intel, or RH
[08:16] <pwnguin> maybe he can finish his degree ;)
[08:16] <tjaalton> another PhD on XI?
[08:16] <tjaalton> :)
[08:16] <pwnguin> bachelors
[08:17] <tjaalton> ah :)
[08:18] <pwnguin> his resume lists like a year of college
[08:20] <tjaalton> you know him personally?
[08:20] <pwnguin> nope
[08:20] <pwnguin> but i can read his website
[08:20] <tjaalton> heh
[08:21] <tjaalton> I know one australian chick that was at our school as an exchange student in -94/95, do you happen to know her?-)
[08:21] <pwnguin> look
[08:22] <pwnguin> im awake during the aussie time zone
[08:22] <pwnguin> but thats a personal failing, not an indication of where i live
[08:22] <tjaalton> oh damn, sorry :)
[08:22] <bryce> hehe
[08:22] <pwnguin> last i checked, kansas wasnt an australian province
[08:22]  * wgrant annexes pwnguin.
[08:23] <pwnguin> wgrant: from what i hear, it wouldn't be much different
[08:25] <pwnguin> its gotta be a hell of a move, from australia to finland
[08:25] <tjaalton> hmm so when alice fell through the hole, she ended up in brisbane?
[08:25] <bryce> kangaroos and wallabies for instance
[08:25] <tjaalton> well we have polar bears running wild
[08:25] <tjaalton> (not)
[08:25] <bryce> tjaalton: I think you mean dorothy and a tornado
[08:26] <pwnguin> heh
[08:26] <pwnguin> his mastery of american culture is still better than my mastery of finnish
[08:26] <pwnguin> but thank you for the translation
[08:26] <bryce> just put on a steel helmet with horns, you'll fit in fine
[08:27] <pwnguin> well, parts of my family came from denmark and russia
[08:27] <tjaalton> man, I thought alice was the one who said "I think we are not in Kansas anymore" :)
[08:27] <pwnguin> alice was british
[08:28] <tjaalton> duh
[08:28] <pwnguin> or at least european
[08:28] <bryce> and she had a rabbit fetish
[08:28] <pwnguin> i dont think "kansas" existed when it was written
[08:28] <tjaalton> that's what you get for not seeing old classics
[08:28] <pwnguin> you've missed nothing
[08:29] <tjaalton> that line is so familiar to me because of Rainbow'
[08:29] <tjaalton> 's Finyl Vinyl
[08:29] <tjaalton> not because I saw the movie :)
[08:29] <bryce> kansas existed - had just finished sparking off the civil war or some such
[08:29] <bryce> ok I'll shut up now
[08:30] <tjaalton> oh and climate wise it's getting better here, local warming and such
[08:30] <tjaalton> or was it global
[08:30] <pwnguin> heh
[08:30] <pwnguin> well, john brown did raid a union armory
[08:30] <tjaalton> too bad that the winters are just wet
[08:30] <pwnguin> to attack the south
[08:33] <pwnguin> he's memorialized in our capital building
[08:33] <pwnguin> bible in one hand, rifle in the other
[08:33] <tjaalton> that's so modern
[08:34] <pwnguin> http://images.google.com/images?q=john%20brown%20mural
[08:34] <tjaalton> moses!
[08:34] <pwnguin> heh, it beats the time they put an indian on the top of the dome, and used a noose to hoist it
[08:36] <tjaalton> heh
[09:43] <tjaalton> uploaded xorg-server to my ppa to test the autoconf stuff
[09:53] <Hobbsee> hey there - have people reported regressions with compiz and the intel driver, with locking the screen making the computer freeze, and never bringing up a password dialogue?
[09:54] <tjaalton> Hobbsee: that's a kernel problem
[09:54] <tjaalton> and yes, I've seen that myself
[09:54]  * wgrant solved it by using metacity.
[09:54] <Hobbsee> tjaalton: ahhh, thanks.
[09:54] <Hobbsee> tjaalton: do you know if people are looking into it, or?
[09:54] <tjaalton> but with .27-2-generic, it seems to work
[09:55] <Hobbsee> that was what i had, and it definetly wasn't working for me.
[09:55] <tjaalton> what chip do you have?
[09:56] <tjaalton> bryce: your acpi patch is broken :) http://launchpadlibrarian.net/17229928/buildlog_ubuntu-intrepid-amd64.xorg-server_2%3A1.4.99.906-2ubuntu3.1_FAILEDTOBUILD.txt.gz
[09:57] <tjaalton> maybe it's easier to just not log anything
[09:58] <Hobbsee> tjaalton: Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
[09:58] <tjaalton> Hobbsee: ok, mine is 965 and it works fine now, even after a suspend cycle
[10:00] <bryce> oh, s/acpi_warning_msg_time/acpi_warning_msg_timer/.  guess I should have compiled that one ;-)
[10:00] <Hobbsee> tjaalton: ah, it's https://bugs.edge.launchpad.net/bugs/262605 apparently.
[10:02] <tjaalton> bryce: ok, will do
[10:02] <tjaalton> Hobbsee: yes, I'll reassign it to kernel
[10:03] <Hobbsee> tjaalton: thanks.  didn't want to fiddle with it myself, and get the wrath of the kernel guys in my direction.
[10:03] <tjaalton> I'll point ogra to that bug
[10:05] <tjaalton> probably some drm funkiness
[10:08] <wgrant> Isn't DRM implicitly funky? Isn't that why it's being killed?
[10:11] <tjaalton> depends what DRM you mean :)
[10:12] <bryce> X11, the land of overloaded acronyms  :-P
[10:12] <wgrant> The kernelly Xy thing.
[10:12] <tjaalton> direct rendering manager, yes
[10:12] <tjaalton> didn't know it was being killed though :)
[10:13] <tjaalton> reworked maybe, but it'll always be too complex for me to grog
[10:13] <wgrant> Where do TTM and co come into the equation?
[10:13] <bryce> TTM -> GEM
[10:14] <tjaalton> the memory manager is a part of drm
[10:14] <wgrant> Ah.
[10:14] <bryce> we *might* have GEM for intrepid.  I was helping benc with it earlier but don't know the current state of things
[10:53] <Ng> tjaalton: interesting that the new kernel fixes it for you
[10:53] <Ng> Hobbsee: do you see that too?
[10:53] <Ng> I can't test for a while, my laptop just left for a trip to Scotland to be repaired :(
[10:54]  * wgrant tests.
[10:54] <wgrant> (i915 here)
[10:54] <Hobbsee> Ng: where new kernel == -2?
[10:54] <Ng> Hobbsee: yeah
[10:54] <Hobbsee> Ng: that's the first place i see it, but i went straight from .25 to .27
[10:54] <Ng> oh
[10:54] <Ng> fail ;(
[10:55] <Hobbsee> (so i don't know if -1 had the problem)
[10:55] <tjaalton> I'll try to reproduce with -1
[10:56] <tjaalton> also, usplash works with .27
[10:56] <Hobbsee> yes, surprisingly!
[10:56] <Hobbsee> it's nice to see it agai
[10:56] <Hobbsee> n
[10:57] <tjaalton> maybe they added v86d to the initrd
[10:57] <Ng> I manually install v86d and it updated the initrd and all that changed was that X refused to start
[10:58] <Ng> saying that it couldn't operate in framebuffer mode
[10:58] <wgrant> Well, that failed.
[10:58] <wgrant> -2 from 12 hours ago doesn't even suspend on i915 when compiz is running.
[10:59] <tjaalton> well, can't reproduce with -1 either
[11:00] <tjaalton> compiz was updated recently..
[11:16] <tjaalton> nope, not the compiz update. it only un-blacklisted mobile ati
[13:12] <tjaalton> wow, now it blanked again
[13:13] <tjaalton> with -2
[13:23] <tjaalton> Ng: do you think bug 258923 is fixed now with .27?
[13:25] <Ng> tjaalton: I've never plugged anything into the VGA output on mine. I could dig around for a VGA cable and try, I'm pretty sure my TV has such an input
[13:25] <Ng> (I literally own zero monitors at this point ;)
[13:26] <Ng> laptops and digital TVs for the win :)
[13:26]  * tjaalton <3's the 24" benq :)
[13:30] <tjaalton> Ng: oh and thanks for trying it out
[13:31] <tjaalton> Ng: what about bug 258925?-)
[13:33]  * Ng looks
[13:33] <Ng> I think I know what that is
[13:34] <Ng> ok the mouse jumping thing mentioned in that is not related, I see that on everything, and it happens to a lesser extent on login on hardy afair
[13:35] <Ng> but the black lines thing I think is kernel dependent
[13:35] <Ng> if I booted my X300 on hardy's kernel with intrepid userspace, I got loads of inch-long horizontal black lines on the screen
[13:45] <tjaalton> the mouse-jumping is soon fixed, with the same patch that should fix flickering
[13:49] <Ng> nice
[13:58] <wgrant> Is this mouse jumping the thing where the cursor freezes and jumps to the bottom right by a few cursor-heights, then recovers?
[13:58] <tjaalton> recovers when you touch the mouse, yes
[13:58] <tjaalton> annoying as hell
[13:59] <wgrant> Hmm.
[13:59] <wgrant> Maybe not identical to what I see, then.
[13:59] <wgrant> Mine will continously jump.
[13:59] <wgrant> Until it has finished logging in.
[13:59] <tjaalton> jcristau: looks like the autoconfig patch didn't work right, no fallback-mechanism or something missing: bug 261977
[13:59] <wgrant> It used to just do it once while gdm was starting.
[13:59] <tjaalton> it does it every time a gtk app starts
[14:00] <wgrant> Right.
[14:00] <wgrant> That sounds plausible.
[14:00] <tjaalton> so you can demonstrate it yourself by running xrandr -q
[14:00] <tjaalton> and then touch the mouse
[14:00] <wgrant> That doesn't affect my mouse.
[14:01] <wgrant> It just shows some apparently uninitialized textures for a frame or two.
[14:01] <tjaalton> ah
[18:56] <tedg> It is a known bug to have X start up and not have a keyboard/mouse?  Then if I restart X it's all happy.
[18:57] <tedg> I'm guessing that it's not finding HAL on first start.
[18:57] <tjaalton> right
[18:57] <tjaalton> known
[18:57] <tedg> Okay, then I'll be quiet :)
[18:57] <tjaalton> hal should be started earlier..
[18:58] <tedg> Well, yes, but X should detect when HAL starts also.  That's easy to do with DBus.
[18:58] <tjaalton> I've never seen that though, but there are bugs about that
[18:59] <tedg> It happens to me on every clean boot.  I'm not sure if there's anymore debugging I could provide, but if so, I'm all for it :)
[19:01] <jcristau> pretty sure patches to detect when hal starts would be accepted
[19:05]  * tedg has fear of X, he always makes sure there's at least 2 levels of abstraction between him and X at all times :)
[19:06] <jcristau> i just do that for xkb
[19:58] <bryce> tedg, chicken!
[19:59] <bryce> tedg: actually X code is just plain C and fairly well documented.  Easier than Inkscape ;-)
[20:00] <bryce> well, "fairly well" might be a stretch.  But more documented than Inkscape's code ;-)
[20:14] <tedg> bryce: I think it comes down to: "What happens when I mess up?" -- "Can't draw" vs. "at a terminal prompt"
[20:15] <bryce> bawk bawk bawk
[20:15] <tedg> bryce: Why don't you just go do the patch I want and show me up :)
[20:16] <bryce> ah, but then we miss the valuable learning experience for you
[20:16] <tedg> How much work have you done with DBus?  I'd really like you to learn more about "the future" (tm).