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