[00:18] <bjsnider> so lightdm starts too fast for the blob?
[00:19] <Sarvatt> sometimes, only when its a SSD that i've heard of
[00:26] <Sarvatt> lightdm starts X when graphics-device-added PRIMARY_DEVICE_FOR_DISPLAY=1 is satisfied in the upstart script, not when its actually ready which could be seconds later
[00:26] <Sarvatt> talk about racy
[00:27] <Sarvatt> modprobe nvidia_current doesnt mean its ready to use
[00:29] <bjsnider> should be modprobe nvidia since there's an alias
[00:30] <Sarvatt> how can udev-fallback-graphics.conf be extended to actually wait till its ready is the problem i think
[00:30] <Sarvatt> yeah same diff
[00:30] <Sarvatt> its getting satisfied just by modprobing
[00:30] <Sarvatt> and trying to start
[00:31] <Sarvatt> but then its loading an 19mb kernel module and setting up /dev/nvidiactl and all the other crap or whatever its called
[00:34] <bryceh> can we have upstart block until all those nodes exist?
[00:34] <bjsnider> i don't know how you can be sure they do unless you test for them
[00:35] <Sarvatt> its an upstart problem for sure but yeah, how does that get fixed
[00:35] <bjsnider> there's nvidia0 and nvidiactl
[00:35] <Sarvatt> its an issue on radeon too
[00:36] <bjsnider> there could also be nvidia1 and so forth and so on if there are more than 1 graphcis cards
[00:36] <Sarvatt> if x loads radeon instead of it getting modprobed before its almost never ready by the time x starts so they get uninitalized memory copied to the screen and have corruption if they have an ssd
[00:39] <Sarvatt> its perfectly happy just loading vesafb to satisfy the upstart crap, showing a vesafb splash for .1 seconds before x, x modprobing radeon because its not loaded yet when x-x-v-radeon is tried to load and showing corruption
[00:44] <Sarvatt> boot -> plymouth -> load vesafb because radeon isnt providing /dev/fb0 via radeondrmfb yet -> lightdm -> start X -> X modprobes radeon because it isnt yet -> copyfb from the transition uninitialized frambuffer contents is the common error i'm seeing there
[00:45] <Sarvatt> and i cant spell anymore, thats my queue to sleep :)
[00:46] <RAOF> We certainly can fix udev-fallback-graphics.
[00:47] <RAOF> We'd do something like start on modprobe nvidia-current, and then have a task that polls for the relevant device nodes to appear.
[00:50] <Sarvatt> it seems like the same deal to me though, assuming modprobe was successful isnt enough to assume lightdm is ok to start
[00:50] <Sarvatt> unless its intel
[00:52] <bjsnider> RAOF, what if the system doesn't have nvidia-current and how do you know if it does and even if it does maybe that's not he driver the user wants to use
[00:52] <bjsnider> etc.
[00:52] <bryceh> wonder if the drivers already include some mechanism to flag readiness, and if not, if they'd be open to adding one
[00:53] <RAOF> bjsnider: Simple - then another start-on triggers.
[00:53] <bjsnider> just found out nvidia released a new blob today
[00:53] <RAOF> Ah, the security fix blob is out?
[00:53] <bjsnider> it is
[00:53] <Sarvatt> a few days ago?
[00:53] <bjsnider> i am preparing it
[00:54] <Sarvatt> it took tjaalton a few days to upload it to precise
[00:54] <bjsnider> 295.40?
[00:55] <bjsnider> it just landed in their archive on the 11th by whatever timezone this is
[00:57] <Sarvatt> it fixed a few other issues too besides the security stuff
[00:58] <Sarvatt> but yeah unreleased systems, etc, was a super important update on next gen crap
[00:58] <Sarvatt> broke old cuda though
[00:59] <Sarvatt> that relied on the security vulnerability to work :)
[01:00]  * Sarvatt is glad we dont ship cuda stuff
[01:01] <Sarvatt> need to ping tjaalton and security people to update -current version too
[01:01] <RAOF> I thought mdeslaur was on that?
[01:02] <mdeslaur> huh? I fixed stable releases
[01:02] <Sarvatt> they did nvidia and nvidia-173 and nvidia-96 but not -updates versions
[01:02] <mdeslaur> Sarvatt: in which release?
[01:03] <Sarvatt> mdeslaur: https://lists.ubuntu.com/archives/oneiric-changes/2012-April/012027.html holy crap i missed it
[01:03] <Sarvatt> sorry!
[01:03] <Sarvatt> its just -updates in precise thats still a problem
[01:03] <mdeslaur> I don't think 173 and 173-updates in precise got updated either
[01:04] <Sarvatt> and nevermind nvidia-currents-updates in precise did get an update and i missed it, sheesh, totally sorry for you getting pinged :)
[01:04] <RAOF> Do we have a version of 173 that works in precise?
[01:04] <Sarvatt> RAOF: nope
[01:04] <RAOF> Didn't think so :)
[01:04] <Sarvatt> there is no 173 thats installable in precise
[01:04] <mdeslaur> ah, well problem solved :)
[01:05] <mdeslaur> the only one I didn't update was nvidia-graphics-drivers-updates that's in oneiric-proposed
[01:06] <bjsnider> when was the last time they touched -173?
[01:06] <bjsnider> october?
[01:07] <bryceh> should we drop it?
[01:08] <bjsnider> i think they make it compatible with the kernel just before an ubuntu release
[01:08] <bjsnider> used to anyway
[01:09] <Sarvatt> yeah theres definitely an issue promoting -proposed to -updates for nvidia-graphics-drivers-updates in previous releases
[01:12] <Sarvatt> wonder how that can be circumvented, i dont think any nvidia driver update has gone to release-updates from release-proposed even though foo-updates was made to be able to update things
[01:13] <bjsnider> date of last nvidia 173 driver upload: 07-25-11
[01:14] <Sarvatt> yeah, there was a newer nvidia-173 but it was still xserver 1.10 only
[01:14] <bjsnider> same date they released the last 96 and 71 blobs
[01:14] <Sarvatt> i dont think we'll get a 173 for precise, but only alberto knows for sure
[01:15] <bjsnider> people should just be using nouveau at this point. there's no acceptable excuse
[01:15] <Sarvatt> sure there is, geforce 6150
[01:16] <Sarvatt> lots of laptops using IGP nvidia from then
[01:16] <bjsnider> nvidia-current should support that
[04:11] <hyperair> Sarvatt: ping.
[04:11] <hyperair> Sarvatt: is synaptics in precise still responsible for scroll-coasting?
[06:16] <tjaalton> Sarvatt: hope you meant tseliot there :)
[11:47] <tjaalton> bryceh: the workqueue links seem broken for some packages like nouveau, drops in the advanced query page
[16:24] <bryceh> tjaalton, yes, the problem is for packages where the upstream project launchpad name != the source package name, or if no upstream project is set in launchpad, it fails.  this is high on my todo list
[16:35] <tjaalton> bryceh: ok, it used to work not too long ago though
[16:35] <tjaalton> so something changed on lp?
[16:40] <bryceh> tjaalton, sort of but that's not why
[16:40] <bryceh> they added a way to limit searches to the "official upstream" (as opposed to just any arbitrary upstream project like unity)
[16:41] <bryceh> the other day I added support for that into the chart, so the workqueue chart can exclude bugs that have already been forwarded upstream
[16:41] <bryceh> but I'd only tested it with -intel so didn't notice the issue until yesterday
[16:54] <bryceh> hah bug 980693
[17:05] <bryceh> tjaalton, fixed
[17:22] <tjaalton> bryceh: great, thanks :)
[18:50] <tjaalton> hmh, -wacom bugs don't have all the same logs attached as the rest
[19:12] <Sarvatt> tjaalton: hmm yeah looking at source_xorg.py it only attaches Xorg.0.log for video bugs
[19:13] <bryceh> yeah if there's anything else we need for -wacom lemme know and I'll stick it in
[19:13] <Sarvatt> except it does for actual synaptics bugs... weird
[19:14] <bryceh> (or do a merge request for a branch against xdiagnose)
[19:15] <Sarvatt> tjaalton: maybe add it to keyboard_packages?
[19:15] <Sarvatt> those packages seem to be getting good logs attached
[19:16] <bryceh> no; keyboard_packages should just be keyboard
[19:17] <bryceh> think we need a separate thingee for non-keyboard inputs
[19:17] <bryceh> and then move -evdev and -synaptics to that
[19:18] <Sarvatt> oh yeah see that now, only explination i could come up with why synaptics and evdev get attach_2d_info and wacom doesnt
[19:18] <bryceh> yeah
[19:19] <bryceh> Sarvatt, are you doing a patch?  if not, I can.
[19:19] <Sarvatt> i dont think thats right, thats just adding xkb info the bug.. but http://paste.ubuntu.com/928396/
[19:21] <Sarvatt> maybe better to just unconditionally attach the xorg logs for everything? :P
[19:21] <bryceh> hmm, there is a is_xorg_input_package() routine
[19:22] <bryceh> but that includes a check for xf86-input
[19:22] <Sarvatt> yeah i'm not getting why synaptics and evdev include video info
[19:27] <Sarvatt> none of the debugging interest stuff is on there either https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/980834
[19:28] <Sarvatt> thats actually the only apport collected wacom bug in precise :P
[19:29] <Sarvatt> hmm found a closed one, https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/949097 and it does have video info on it
[19:29] <Sarvatt> maybe that first one gave up after CurrentDmesg: Error: command ['sh', '-c', 'dmesg | comm -13 --nocheck-order /var/log/dmesg -'] failed with exit code 1: comm: /var/log/dmesg: Permission denied
[19:57] <bryceh> yeah that could be
[19:58] <bryceh> thought I had a check for permissions on that though.  *digging*
[20:01] <bryceh> actually hmm.  dmesg is collected by apport itself, not our hook
[20:02] <kklimonda> hey, what's the status of blue tint on nvidia drivers? does someone has a bug number I can subscribe to? :)
[20:03] <kklimonda> (it's irritating as I can't really remove libvdpau and adding workarounds to mms.cfg makes flash plugin really unstable)
[20:03] <kklimonda> (blue tint in youtube videos on nvidia drivers to be exact.. sigh, too much things on my head)
[20:37] <Sarvatt> kklimonda: looks like https://bugs.launchpad.net/ubuntu/+source/adobe-flashplugin/+bug/967091
[20:37] <kklimonda> Sarvatt: yeah, that's the one. Thanks :)
[20:38] <Sarvatt> its funny because google led me to your blue tint bug from nvidia setting the wrong hue years ago
[20:38] <Sarvatt> but that was with xv
[20:40] <bryceh> Sarvatt, any other apport hook tweaks before I upload?
[20:41] <kklimonda> ah yes, I remember that bug - seems like nvidia is bend on making me see blue people everywhere ;)
[20:41] <Sarvatt> bryceh: cant think of any, not even sure that one is needed since it was attaching good info previously and that bug is an anomaly :)
[20:41] <bryceh> yeah, it's kind of a corner case where this is even an issue
[20:41] <bryceh> the bulk of our bugs get filed against xorg, so all the right info is going to be included
[20:42] <bryceh> however LTS means a long time, and that can mean many bug reports...
[20:53] <bryceh> Sarvatt, fixes uploaded
[21:11] <tjaalton> oh, thanks guys.. was building a puzzle and couldn't reply :)
[22:22] <imbrandon> ok i got an issue
[22:23] <imbrandon> if somone is arround, i got 3 montors, 2 work fine, 3rd is greenscreen
[22:23] <imbrandon> i create a conf file for the 3rd
[22:23] <imbrandon> and put it in X11/conf.d dir
[22:23] <imbrandon> and then ONLY the 3rd works
[22:23] <imbrandon> anyone got a moment to help me sort this out ?
[22:24] <imbrandon> http://paste.ubuntu.com/928611/
[22:24] <imbrandon> that conf makes the 3rd one work fine, but only that one
[22:25] <imbrandon> the first two are hooked up via seperate dvi, the 3rd is usb displaylink adapter