| === stgraber_ is now known as stgraber | ||
| bryceh | anyone know, are we getting ARM video drivers in the archive for Q? | 00:49 |
|---|---|---|
| bjsnider | bryceh, i have .51 ready to go | 01:00 |
| bjsnider | i thought that was the right one | 01:00 |
| bjsnider | it says it's a long-lived release | 01:01 |
| bjsnider | i've been using my download bandwidth for something else all day but that will be done in a few minutes and i was going to send it in then | 01:01 |
| bryceh | bjsnider, awesome thanks | 01:09 |
| bryceh | didn't realize there was a .51 already; good to know | 01:09 |
| bjsnider | i noticed that ricotz had sent it into xorg-edgers | 01:15 |
| bjsnider | he must pay somebody inside nvidia for the info on when new blobs are released | 01:15 |
| RAOF | tjaalton: I'd love to try the auto-power-off patch :) | 01:15 |
| fubada | hi, is the ppa add procedure under 12.04 still "apt-add-repository ppa:ubuntu-x-swat/x-updates'? | 03:52 |
| tjaalton | bryceh: ok thanks, i'll discuss it with airlied | 04:12 |
| tjaalton | RAOF: fof the kernel? i could build a paxkage with it/them | 04:13 |
| tjaalton | package too | 04:13 |
| RAOF | tjaalton: Oh, they're kernel patches? That seems odd. | 04:13 |
| RAOF | The kernel already exports all the necessary juju for userspace to do that. | 04:13 |
| tjaalton | hmm | 04:14 |
| tjaalton | ok, don't know which patch you're referring to then :) | 04:14 |
| RAOF | tjaalton: The one you pinged me about earlier? | 04:14 |
| tjaalton | i did?-) | 04:15 |
| RAOF | 21:31 <tjaalton> RAOF: I'm adding the patch for dynamic gpu poweroff too, would be fun to test how that works | 04:15 |
| tjaalton | wth was that about. probably meant the kernel patches there | 04:16 |
| RAOF | Heh | 04:16 |
| tjaalton | I was meant to build a kernel for that, but didn't yet | 04:17 |
| RAOF | Again, I don't know why that's a kernel patch; X should have all the information necessary to parse /sys/kernel/debug/vgaswitcheroo/switch and turn off any GPU its not using. | 04:17 |
| tjaalton | there are a couple of threads on dri-devel about this | 04:17 |
| tjaalton | [RFC] drm dynamic power off support | 04:18 |
| tjaalton | well, this is _dynamic_! | 04:18 |
| ajmitch | so with the q-lts-backports PPA, if I install the renamed packages & then try to upgrade to quantal, will things break? I didn't see any conflicts/replaces or breaks from the quantal X to the renamed packages | 04:18 |
| tjaalton | :) | 04:18 |
| RAOF | Oh, hey. Evolution's crashed again. | 04:19 |
| RAOF | Maybe the OOM killer hit it again. | 04:19 |
| RAOF | Ah, ok. I see those. Interesting! | 04:21 |
| RAOF | That'll obviously be *more* interesting when powering on the radeon doesn't crash X, of course. | 04:21 |
| tjaalton | heh | 04:21 |
| tjaalton | btw, push -ati git ;) | 04:21 |
| fubada | do you guys know if I need to use jockey-text to switch to nvidia_current from x-swat | 04:22 |
| fubada | i dont have x11, using ubuntu-server | 04:22 |
| tjaalton | if you already have nvidia enabled then no | 04:24 |
| fubada | by defaault it uses the free drive nouveau | 04:25 |
| RAOF | tjaalton: Ta for the prod there. | 04:25 |
| tjaalton | fubada: yes, so why do you need the blob if it's a server? | 04:26 |
| fubada | im going to install xbmc as it is also my htpc | 04:27 |
| fubada | it doesnt need any dm | 04:27 |
| fubada | but it will be running xbmc | 04:27 |
| tjaalton | ok, try jockey-text then | 04:27 |
| fubada | ok | 04:28 |
| bjsnider | fubada, why use the blob on an x11-free server? | 04:29 |
| tjaalton | replied already ;) | 04:30 |
| bjsnider | still not sure it makes much sense | 04:31 |
| bjsnider | i wouldn't put anything by nvidia in a server | 04:32 |
| fubada | its not a real server, its just an ion2 box with 4tb of swraid | 04:33 |
| fubada | hooked up to my tv | 04:33 |
| fubada | a bunch of private torrents | 04:33 |
| fubada | and running xbmc | 04:33 |
| fubada | i just dont want the overhead of gdm, etc | 04:33 |
| fubada | for music/movies | 04:34 |
| bjsnider | oh, i kind of jumped to conclusions when you said server | 04:34 |
| bjsnider | just rtorrent i guess | 04:34 |
| fubada | transmission with a webui | 04:34 |
| bjsnider | ... | 04:35 |
| === Amaranthus is now known as Amaranth | ||
| tjaalton | bryceh: btw, the patches are referenced in the changelog, just not with the name | 06:27 |
| bryceh | tjaalton, right 228* and 229* are not referenced in the changelog. | 06:30 |
| tjaalton | yeah, it's kinda silly to have numbers anyway | 06:30 |
| tjaalton | since there are huge gaps that mean nothing :) | 06:31 |
| bryceh | tjaalton, the patch names without the numbers aren't mentioned either :-P | 06:32 |
| tjaalton | right, but the context should be clear :) | 06:32 |
| bryceh | tjaalton, not to the emacs search function :-) | 06:33 |
| tjaalton | heh | 06:33 |
| tjaalton | right, names should be there | 06:33 |
| tjaalton | i just followed mlankhorst's lead! :) | 06:34 |
| bryceh | +1 to retaining patch names in changelog comments. and +1 to context (moar context!) | 06:35 |
| tjaalton | thinking about adding new categories to patches/series, so it's more clear what are from upstream, what's never meant there etc | 06:36 |
| tjaalton | and drop the numbers | 06:36 |
| tjaalton | from our patches | 06:36 |
| bryceh | interesting thought. I'm in favor of file naming consistency, but there's no technical reason why it needs to be a linear set of numbers | 06:38 |
| bryceh | having patches grouped together that are interdependent is a good idea, so they can be popped and pushed as a unit | 06:39 |
| tjaalton | right | 06:39 |
| tjaalton | and no need to review them again and again after rebasing to a new version | 06:40 |
| * bryceh nods | 06:40 | |
| tjaalton | I might do it after this fix, it's a non-functional change but no need to rush it for the beta | 06:40 |
| bryceh | then the upstream cherrypicks could all be grouped at the top so they get applied first. Would cut down on porting work. | 06:41 |
| tjaalton | yeah | 06:41 |
| tjaalton | although it could mean more churn in the distro patches :) | 06:42 |
| bryceh | non-functional but if you change the ordering (as you have to), you might have to rework a few patches | 06:42 |
| bryceh | yeah, a bit of churn but that'd happen anyway when we go to the next upstream version | 06:42 |
| tjaalton | right, but when backporting patches for a stable release.. | 06:43 |
| tjaalton | though there should be no conflicts either way | 06:43 |
| mlankhorst | maybe do it for xorg 1.14? | 06:43 |
| bryceh | I suppose by the time we get to a perfect patch organizational system we'll be switching to wayland or whatnot | 06:43 |
| tjaalton | guess so :) | 06:43 |
| mlankhorst | unless you can show there is no diff before and after changing the patch order | 06:43 |
| bryceh | or maybe trim the numbers and do the easy recategorization now, and leave any tough patch reworks to 1.14? Timo has a lot of patch-fu I bet he can pull it off. | 06:47 |
| tjaalton | I'll try it out, it's easy to see if it fails in horrible ways or not. don't think it should :) | 06:48 |
| tjaalton | I'll test this patch first tho.. | 06:50 |
| mlankhorst | famous last words | 06:51 |
| mlankhorst | but.. back to fencing I suppose.. | 06:52 |
| tjaalton | didn't crash, ship it | 06:56 |
| bryceh | http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-quantal-workqueue.svg | 07:00 |
| bryceh | first time we've had more -nouveau bugs than -intel | 07:01 |
| tjaalton | yeah it's in a bad shape | 07:01 |
| tjaalton | crashes in libexa etc | 07:01 |
| mlankhorst | I know, bit annoying too when upstream (darktama) doesn't respond :( | 07:02 |
| bryceh | yeah I can't get piglit to run on it without the gpu locking up | 07:02 |
| bryceh | and that's with 804. with 802 in precise the kernel OOPSes | 07:02 |
| mlankhorst | :> | 07:04 |
| mlankhorst | the annoying part is the kernel rework is not complete yet so the maintainer is focusing on that.. | 07:04 |
| bryceh | mlankhorst, in hindsight do you think we should have stuck with an older version before the rework started? | 07:05 |
| tjaalton | older version of? | 07:05 |
| mlankhorst | not going to matter, both were broken | 07:05 |
| tjaalton | the rework is in the kernel | 07:05 |
| bryceh | old version of whatever | 07:07 |
| mlankhorst | no it just needs some bugtracking love, we couldn't use the old ddx because of the exa changes | 07:07 |
| tjaalton | not really possible | 07:07 |
| bryceh | so, nothing really we could have done? just chalk it up to poor maintainership. Bummer. | 07:08 |
| tjaalton | hmm, wonder if patch 188 is breaking stuff now.. | 07:08 |
| tjaalton | guess we can drop it with the hotplug stuff now in | 07:09 |
| tjaalton | and ask sabdfl to test :) | 07:10 |
| bryceh | tjaalton, regardless, it's not relevant if there is better hybrid support now | 07:10 |
| tjaalton | yeah I'm pretty sure the current code is good enough | 07:10 |
| tjaalton | and handles this case | 07:11 |
| bryceh | it was a pretty obvious bug when it happened | 07:11 |
| tjaalton | in the future, it would be great if the distro patches had a patch header :) | 07:12 |
| tjaalton | git log works most of the time | 07:12 |
| tjaalton | but it would be even easier to just look at the header | 07:12 |
| bryceh | this patch was from karmic, we were pretty fast and loose back then | 07:13 |
| tjaalton | hehe | 07:13 |
| bryceh | I've been trying to do the full git format patch stuff these days, when it's something I authored. At least I always include a preface description. | 07:14 |
| mlankhorst | I think some headers might have been lost by my xorg codestyle rebase/update script | 07:14 |
| bryceh | doh | 07:14 |
| mlankhorst | personally, I prefer patches just have something in git log about them | 07:14 |
| mlankhorst | that's what the metadata is for.. | 07:14 |
| tjaalton | ha, indeed.. | 07:15 |
| * tjaalton spanks mlankhorst with a giant herring | 07:15 | |
| tjaalton | http://dep.debian.net/deps/dep3/ | 07:16 |
| tjaalton | also, git log ceases to work when they are renamed | 07:16 |
| mlankhorst | talk about overengineering.. | 07:16 |
| tjaalton | well, it's usually enough to just have a from tag and a buglink | 07:17 |
| mlankhorst | Not really? git log will keep working.. | 07:17 |
| mlankhorst | Unless you do a rewrite as well | 07:17 |
| bryceh | git log works ok for _us_ | 07:17 |
| tjaalton | ok, not sure about that | 07:17 |
| tjaalton | yeah that's a good point | 07:17 |
| mlankhorst | git log --follow | 07:18 |
| bryceh | but for all our gitless co-workers, or users who only know about apt-get source, having a description in the patch itself can be a big boon | 07:18 |
| tjaalton | like ubuntu-release/sru folks | 07:18 |
| mlankhorst | seems to pick up on my debian/patches/series rename :-) | 07:18 |
| mlankhorst | but nowadays I tend to edit patches manually when updating.. | 07:19 |
| tjaalton | quilt refresh shouldn't touch the headers | 07:20 |
| tjaalton | or dquilt if you have the alias | 07:20 |
| mlankhorst | nah I just set quilt to always assume I'm using debian | 07:21 |
| bryceh | hey, how do you check that a package is in NEW? Is there a report for that? | 07:23 |
| bryceh | (trying to find nvidia-graphics-drivers-experimental-304 for precise-proposed) | 07:23 |
| tjaalton | https://launchpad.net/ubuntu/precise/+queue | 07:23 |
| bryceh | aha bingo, thanks. | 07:24 |
| tjaalton | no drama after reorganizing the patches | 07:29 |
| bryceh | nice | 07:35 |
| bryceh | mlankhorst, I agree dep3 as a whole is overkill, but the concept is sound. Basically the idea is to explain where the patch originated and what it does. As long as that's clear, that's good, even if it's not dep3 compliant. | 07:38 |
| tjaalton | and usually it's enough to list from:, subject:, short description or a buglink, that's it | 07:38 |
| mlankhorst | so pretty much what we already do :p | 07:39 |
| tjaalton | yeah, when they are not stripped off on rebase :) | 07:40 |
| mlankhorst | I don't think there will be more 'change the entire X server coding style' patches, so it should be safe.. | 07:41 |
| tjaalton | http://pastebin.com/BrDFnAt3 | 07:47 |
| tjaalton | comments? | 07:47 |
| tjaalton | some offsets when patching, nothing more severe | 07:48 |
| tjaalton | not that many pure distro patches | 07:48 |
| mlankhorst | can you check if the source code before and after is exactly the same? | 07:48 |
| tjaalton | should be easy | 07:48 |
| bryceh | "waiting for review" -> "waiting for review by upstream" ? Maybe including a ML url or bug # would facilitate following up? | 07:51 |
| tjaalton | took a git diff from both, diff'ing the diffs show no diff :) | 07:51 |
| tjaalton | yeah | 07:51 |
| bryceh | "from upstream, drop when rebasing"... anything break if these are placed first instead of last? | 07:52 |
| tjaalton | well, I think it's easier to rebase a single backported commit than possible several earlier ones | 07:53 |
| tjaalton | usually they don't need any changes | 07:53 |
| tjaalton | than just a refresh maybe | 07:53 |
| bryceh | hmm | 07:54 |
| bryceh | well I'll remain open minded | 07:55 |
| mlankhorst | I just don't want to break things so as long as there is no diff I'm fine with it | 07:56 |
| tjaalton | is it more confusing to leave the numbers or not? | 07:56 |
| mlankhorst | renumber after you have the final sequence | 07:57 |
| tjaalton | no numbers anymore :) | 07:57 |
| bryceh | tjaalton, I think you're probably right to just drop the numbers | 08:07 |
| bryceh | I'm partial to having the numbers myself, but objectively I think the purpose they serve is largely lost with xserver | 08:07 |
| tjaalton | bryceh: yeah, it didn't really work out too well trying to use the numbers for different categories | 08:16 |
| tjaalton | that was my idea too :) | 08:16 |
| tjaalton | this should scale better | 08:16 |
| mlankhorst | we should do a better job at dropping unneeded crap in xorg-server though :) | 09:10 |
| tjaalton | sure | 09:10 |
| tjaalton | this should make it easier | 09:10 |
| ricotz | hi, why is there a need to call the package "nvidia-graphics-drivers-experimental-304" instead of just "nvidia-graphics-drivers-304" | 10:17 |
| ricotz | and uploading 304.51 is probably the better choice here | 10:19 |
| tjaalton | tseliot knows | 10:35 |
| tseliot | ricotz: because we're going to use that package for experimental drivers and yes, I know a newer release has been available since yesterday | 10:42 |
| tjaalton | and the new one seems somewhat broken | 11:42 |
| tjaalton | bug 1056052 | 11:43 |
| ubottu | Launchpad bug 1056052 in xorg (Ubuntu) "Launcher not showing in auto-hide mode" [Undecided,New] https://launchpad.net/bugs/1056052 | 11:44 |
| === mdeslaur_ is now known as mdeslaur | ||
| ricotz | tseliot, i see, but including "experimental" and "304" doesnt make sense imo? | 11:56 |
| === lilstevie_ is now known as lilstevie | ||
| tseliot | ricotz: the technical board decided that for a reason | 12:44 |
| tseliot | ricotz: http://ubuntu.5.n6.nabble.com/Minutes-from-the-Technical-Board-meeting-2012-09-17-td4992536.html | 12:45 |
| ricotz | tseliot, alright, that makes sense | 12:49 |
| bryceh | ricotz, don't get hung up about it being 304, that's just being used to seed things with since we don't have a beta driver yet | 16:43 |
| bryceh | ricotz, in practice we'll only be shipping pre-release drivers in -experimental | 16:43 |
| ricotz | bryceh, yeah, that is why i was wondering. having "nvidia-graphics-drivers-experimental" and later "nvidia-graphics-drivers-304/ -306" seemed more logical, but it is fine since it was discussed | 16:47 |
| === pzanoni_ is now known as pzanoni | ||
| === yofel_ is now known as yofel | ||
| czajkowski | elo anyone able to help me, not sure if's a bug or something has happened, I am running 12.10, I close the lid of machine and i come back to it and go to use it again, the screen is black but lit and I can see the cursor but no login prompt | 19:41 |
| czajkowski | possibly this thinks laney https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/966744 but it's marked as not affecting 12.10 | 19:43 |
| ubottu | Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed] | 19:43 |
| stgraber | I'm seeing something similar here though not limited to closing lid. For the past few days (3-4 days I think), whenever X shuts down the screen it seems to get stuck. When I get back to the machine, the screen turns back on but all I get is a blank screen with the mouse cursor | 19:44 |
| stgraber | for now my workaround is to disable the screensaver completely so the screen never turns off, but that's no really ideal ;) | 19:45 |
| stgraber | (intel hd4000 on an ivy bridge system) | 19:45 |
| stgraber | I confirmed that it's not gnome-screensaver (killed from another tty), it could be compiz (killing it gets me the wallpaper but nothing else) and I'm not seeing anything in dmesg so if it's kernel, it's not obvious | 19:46 |
| stgraber | oh, actually, I just noticed this in my X logfile: | 19:46 |
| stgraber | [ 7657.397] (WW) intel(0): flip queue failed: Invalid argument | 19:46 |
| stgraber | [ 7657.397] (WW) intel(0): Page flip failed: Invalid argument | 19:46 |
| czajkowski | tjaalton: you about ? | 19:46 |
| toabctl | czajkowski, stgraber i have the same issue here (i386, 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)) | 19:50 |
| tjaalton | czajkowski: yes it's the same bug | 19:56 |
| czajkowski | tjaalton: yes but it's now saying it doesnt affect Q from your latest comment on the bug | 19:57 |
| tjaalton | no, i removed compiz from there | 19:57 |
| czajkowski | ah ok | 19:59 |
| czajkowski | wel that bug is a bit of a pita right now :/ | 19:59 |
| czajkowski | although may disable my screensaver thanks to stgraber | 19:59 |
| tjaalton | and i have three intel laptops but can't reproduce it like others.. | 20:00 |
| czajkowski | tjaalton: :/ | 20:01 |
| czajkowski | tjaalton: you in the bluefin? | 20:01 |
| tjaalton | no, just FI :) | 20:02 |
| czajkowski | FI? | 20:03 |
| tjaalton | finland | 20:04 |
| czajkowski | ah right | 20:18 |
| czajkowski | well I cant send you my laptop | 20:18 |
| czajkowski | I need it for work | 20:19 |
| czajkowski | if I can do any debugging and let you know stuff please just ask | 20:19 |
| tjaalton | czajkowski: https://bugs.launchpad.net/ubuntu/precise/+source/xserver-xorg-video-intel/+bug/966744/comments/226 | 20:22 |
| ubottu | Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed] | 20:22 |
| tjaalton | there are a couple of traces attached, but I'm not convinced they're ok.. | 20:23 |
| tjaalton | so if it hangs on the first lid close, it should be easy to get a good one | 20:24 |
| tjaalton | also, boot with 'drm.debug=0xe' and attach dmesg output from the hang | 20:30 |
| bjsnider | tjaalton, you're located in finland? | 23:38 |
| bryceh | bjsnider, he is | 23:45 |
| bryceh | tjaalton, btw curious about your plan of attack for that bug? Would it be worthwhile to post your directions on what you would do if you had the HW in front of you, so someone else that does have it could try those steps? | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
