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