=== Azelphur_ is now known as Azelphur [04:05] Testing new nvidia blob. Very exciting and hope to figure out the randr 1.4 stuff soon [05:04] it only supports UDL from what I can tell [05:04] no optimus yet [05:05] And can't be a render slave? [05:07] well thats what i gathered from actually reading the readme [05:12] Likewise. [05:15] I'm 90% of the way to getting this setup. X just wants to be black [05:15] But nvidia is rendering something in the background [05:17] from what I can tell it won't cooperate with intel unless intel is the slave [05:18] Instead of modeset? [05:19] well modeset too [05:20] anyway there's always nouveau to play with [05:21] it actually has a drm driver that does more than passing around a page array :P [06:14] Nvidias optimus xorg.conf confuses me. How do specify my lvds output [07:15] anyone here have radeon SI? [07:16] aka HD7xxx or such [07:18] packaging glamor atm.. [07:19] project name is 'glamor', tarball glamor-egl, builds libglamor, and it's hosted under xorg/driver.. [07:19] something is not right === llstarks is now known as llstarks|phone === erapp_000_ is now known as llstarks [07:26] tjaalton: I do, but I'd need to build a desktop system to actually power it ;/ [07:26] ah :) [07:26] ok, I'll keep on looking [07:26] if mesa 9.1 is accepted there's little reason not to add glamor too [07:27] I have a new (unreleased) card, but it's not SI based :/ [07:27] despite the promisingly high model number [07:28] hmm the hwe guys certainly does have those [07:28] *do === jussi01 is now known as jussi [07:30] How can you possibly have an unreleased card that's *not* SI based? [07:30] They're releasing more last-gen cards? [07:30] it's a low-spec one [07:31] RAOF: nvidia still does fermi cards === jono is now known as Guest75135 [07:33] [07:33] the all new radeon 7120! now with gcn-free blast processing! [07:35] RAOF: they're releasing the same last-gen cards as last year, with new labels [07:35] sorry to disappoint, but it actuall stars as HD8xxx :) [07:35] *starts [08:20] woops [08:20] * mlankhorst notes you need a working card to start xserver [08:22] Heh [08:27] and I just completed my lazy chroot thing [08:27] ~/nfs/linux$ enter q64 [08:27] quantal-amd64.local:~/nfs/linux$ [08:28] ~/nfs is bind mounted [10:08] slightly off topic, but I'm guessing there is some overlap, does anybody know where the debian X team hangs out? [10:09] Prf_Jakob: on #debian-x @oftc [10:12] k thanks! === ogra_` is now known as ogra_ [12:42] hum, the simplified lightdm.conf on the race bug doesn't seem to work [12:42] good thing I tested it first :) [12:44] ok, nvidia 304.88 released for precise and quantal [12:45] unsurprisingly [12:45] really? [12:46] mdeslaur: cool [12:48] hmm wait, it's something else [12:58] i've somehow broken plymouth [12:58] do you still have that plymouth valgrind thing running? [12:58] no [12:59] moved the binary back in place [12:59] and even reinstalled the package [13:01] it's funny that plymouth-splash.conf says "plymouth must be started asap to avoid racing with gdm.." [13:01] orly [13:01] ? [13:01] anyway [13:04] as I feared.. [13:04] another race! :) [13:04] now plymouth-splash stops too early [13:05] this is with my laptop which never(?) had the original race [13:08] ok, need to fix plymouth-stop.conf then [13:08] as well [13:14] huh, didn't work [13:15] thought that plymouth-splash shouldn't stop before *dm is running [13:15] guess this is the price we pay for having an event based init >:/ [13:16] adding a sleep 2 is the only thing that is working on oem machines that hit it reliably, had them test all kinds of different things including the various xserver patches :( [13:16] also the lightdm.conf change? [13:17] yeah a few different permutations of it, slangaseks and the one you said was working for you [13:17] guess they hit what i'm seeing now [13:17] (neither of those worked for me, slangasek's didn't even start lightdm) [13:18] Sarvatt: can I see the plymouth debug log and lightdm log from a failing boot with the depend on started plymouth-splash fix in place? [13:20] mlankhorst: 3 layers of QA indirection involved outside of the company, I couldn't even get any logs.. [13:21] i can [13:21] plus xorg.0.log from that boot too [13:21] oh great [13:22] quite simply it's plymouth-splash that's stopped along with plymouthd, so lightdm has no chance of starting at that point [13:24] so the 'stopped plymouth' line is really needed then? [13:24] hmm right [13:25] that's what my desktop had all the time [13:25] I was hoping it wouldn't be needed, ah well :/ [13:26] hmm we dont have http://cgit.freedesktop.org/plymouth/commit/?id=a6129abfc527ac247685d80fc5c20144be1badca it looks like [13:26] works again, with the side-effect that the handoff to lightdm isn't smooth [13:26] or http://cgit.freedesktop.org/plymouth/commit/?id=6ccedf7b6ecdc8314ed97355cfe5499fffb13a1e [13:27] sounds useful [13:27] so if you see plymouthd crashing again ( i remember you hitting that tjaalton?) it might be worth adding those [13:28] yeah [13:28] it was on the desktop [13:29] oh [13:30] could plymouth-stop not depend on lightdm? [13:30] might make that specific race less likely [13:30] hm then again seems to be a noop for that dm [13:33] mlankhorst, plymouth-stop is also used on servers [13:33] no dm there [13:34] why is it so hard to just get a machine to crash [13:34] use a hammer :) [13:35] 'use hammer on OEM' [13:35] it's not very effective [13:37] oh [13:37] optimus support [13:37] not optimus [13:37] hmm, then the german news sites lie [13:38] it still fails on muxless afaik [13:38] ah, yeah, they talk about still missing kernel bits [13:38] which is everything newer than sandybridge era pretty much [13:38] not even kernel bits [13:38] * ogra_ fell for the headline [13:38] well kernel bits too [13:39] but more basically xserver needs to support gpu screens [13:59] mmmm, nvidia finnaly has Optimus support on Linux :) Anyone tried it yet ? [14:00] dupondje_, see the last 20 lines ? [14:01] ah no :p [14:03] ah well, gonne try it out :) see what it does [14:05] mlankhorst: still want the debug log? [14:09] tjaalton: i'd like to see it to compare to a good boot if ya don't mind, haven't been able to hit a race while using plymouth:debug [14:10] http://pastebin.com/ZGpffWpy [14:10] something stops plymouth before lightdm is ready to start [14:14] I have bootcharts too [14:19] so you're getting plymouth quit called and [ply-terminal.c] ply_terminal_deactivate_vt:couldn't deallocate vt 7: Device or resource busy, i'm getting lightdm doing a plymouth deactivate and it working fine [14:30] I think that's just fallback from the way it fails [14:30] since it's actually changing the vt [14:30] eh [14:30] fallout [14:30] bbl -> [14:44] plymouth ping, then plymouth quit? hmz [14:46] tjaalton: I need the xorg/lightdm/plymouth debugs from a single boot to understand this [17:51] mlankhorst: there is no xorg/lightdm logs from this boot [17:52] since lightdm doesn't get started [17:52] ah [17:53] who is telling plymouth to quit, then? [17:53] dunno [17:53] kill timeout 60 [17:53] though it exits way earlier, so not that :) [17:55] pre-stop execs plymouth quit [17:55] yep, lol [17:56] what is JOB in pplymouth-stop ? [17:59] no idea [17:59] meh could you add some destinctiveness? it seems plymouth quit ignores everything that follows [18:00] so you could just add something like plymouth quit calledfromXXX to each point in /etc/init [18:00] hopefully that will tell you from the log who called it [18:16] gah, had the hung compiz after user-switch again, with mesa 9.1 [18:16] feels like it's a ivb specific bug then [18:17] mlankhorst: it's from plymouth-stop [18:17] I feared so [18:17] makes absolutely no sense to me [18:18] could you see what $JOB is? [18:18] where? [18:18] by adding it as argument [18:18] in plymouth-stop [18:18] ah [18:19] "rc" [18:20] well I was right in my guess then [18:20] but.. why the f [18:20] what guess?-) [18:20] can you dump $RUNLEVEL ? [18:20] N 2 [18:20] (my guess that $job would be rc) [18:20] oh in the job? [18:21] yeah see what runlevel it believes has stopped [18:23] I guess if you said that RUNLEVEL was 2, it would mean that everything in rc2.d before plymouth started [18:26] tjaalton: ^ correct? [18:26] boot.log shows entries from rc2.d [18:27] tjaalton: add a sleep 10 at the end of /etc/init/rc [18:27] init.d * [18:28] same [18:30] do you have a upstart log with timestamps and verbosity on jobs starting? [18:32] not yet [18:32] it's an interesting twist though [18:34] well, adding the sleep means I get to see the message from cryptswap [18:35] tjaalton: oh you're forcing plymouth into the initrd to reproduce it? aka cryptsetup installed [18:35] yes [18:35] but looks like swap has at some point stopped working [18:35] no idea when :) [18:36] tjaalton: just for fun can you dump $PREVLEVEL if that's easier? [18:37] * mlankhorst curiously wonders if that's 2 too [18:40] N [18:40] huh [18:40] I guess none, that's fine [18:41] runlevel is 2 [18:44] what if you change the condition? [18:44] or (runlevel [2345] and stopped rc RUNLEVEL=[2345]) [18:44] Bleh, installed nvidia driver, but get the following when starting gnome-shell now: [18:44] Xlib: extension "GLX" missing on display :0 [18:44] :( [18:44] join us and hack on nouveau [18:44] we have well behaving graphics hardware! [18:45] :) [18:45] *) compared to other vendors [18:45] I have a dream: perfectly running Optimus :) [18:46] you can make it happen if you hack on nouveau [18:46] mlankhorst: no dice [18:46] dupondje_, this is with the new beta blob? [18:46] not much === RadiumCat is now known as PsychoCandy [18:46] bjsnider: yep, but think I had same issue with other versions also [18:47] only thing it's good for atm is usb displaylink connectors [18:47] llstarks was saying there's some complicated stuff in thew xorg.conf file [18:47] so there must be something wrong somewhere I bet ... but what :) [18:48] maybe go to the #nvidia channel and ax [18:49] bjsnider: thx, i'll try it out ;) [18:50] as soon as nvidia supports wayland, they will have finally conquered the universe [18:51] I really like nvidia's drm driver implementation [19:13] tjaalton: but upstart log would still be nice :) [19:17] mlankhorst: added --verbose, but it's not that verbose or I can't find where it's supposed to log [19:21] initctl log-priority [19:21] info [19:21] doesn't work [19:28] bjsnider, not really comlicated, just annoying since nobody can get it working on lvds [19:35] tjaalton: I'm going to bed, I'll poke upstart some tomorrow, see if i can get it to log [19:35] k [20:02] mlankhorst: it's on dmesg [20:04] well that saves me future poking of upstart [21:18] strange, the upstart logs show no mention of plymouth-splash [21:24] ..because of it getting started before upstart, due to the initramfs [21:24] bah [21:46] just gave up on getting nvidia working [21:46] god damn what a bunch of crap :( [21:53] just wait bor [21:53] *bro [22:00] that my dream comes true? :) [22:00] Optimus in Nouveau ? :) [22:02] kind of crazy that hybrid amd+intel "just works" with fglrx these days and wasn't in any news :P [22:02] no, let me figure this out and we'll have a plan of action for nvidia-319 optimus on raring and snarky squirrel [22:02] to dupondje_ [22:03] intel+radeon was broken and fixed and broken again throughout last year [22:03] amd+radeon was the only thing that worked reliably