| bryceh | Sarvatt, good idea | 00:22 |
|---|---|---|
| bryceh | Sarvatt, sometimes I've used pages under http://wiki.ubuntu.com/X/Bugs for that sort of work | 00:23 |
| bryceh | sometimes it helps to start putting bugs into tables with their symptoms | 00:23 |
| bryceh | Sarvatt, also, I have automatically generated tables for -ati and -intel using the tagged symptoms and chip name | 00:23 |
| bryceh | if you think that sort of thing could be useful for -nvidia, we can also do one for that | 00:24 |
| bryceh | however it'd require symptom tagging all the -nvidia bugs, and getting the chip names identified and such | 00:24 |
| bryceh | I made some scripts for doing this when we tagged -intel and -ati which could probably be modified to work on -nvidia | 00:24 |
| bryceh | it'd be a bit of work, but I know exactly what needs done. Let me know if you want to undertake it and I can give specifics. | 00:25 |
| Sarvatt | ok starting to fill out https://wiki.ubuntu.com/X/Bugs with symptoms and actions to take | 00:34 |
| Sarvatt | yeah its formatted horribly but thats easy to fix after making a significant list :) | 00:35 |
| Sarvatt | how do we want to start collecting lists of gpu's that need UMS quirks? a new tag? | 00:39 |
| Sarvatt | or just mark it when we see it somewhere | 00:40 |
| bryceh | Sarvatt, in the past I just stuck [Needs quirk] in the subject | 00:45 |
| bryceh | Sarvatt, afaik most remaining cases where quirks are needed will need done in the kernel, so we'll want a separate bug report for each piece of hw which we can forward to the kernel team to add the quirk | 00:47 |
| Sarvatt | btw about Backport Xv fixes and other fixes from -intel 2.10 (and 2.11), I really don't think thats going to be possible realistically from looking at it | 00:49 |
| Sarvatt | time to turn the computer off for tonight, thanks for all the help and getting me into bugcontrol :) | 00:51 |
| bryceh | Sarvatt, I'd be interested in hearing why not? | 01:45 |
| Sarvatt | well, there was *so much* code refactoring between the initial drmmode overlay support addition just after 2.9.0 which we could easily bring in (and manually define DRM_MODE_OVERLAY_LANDED to enable) and the subsequent fixes that might be needed, the later fixes there wont apply to UMS which is like the main target for overlay support anyway (8xx not having textured video) and it might be dependant on PutImage acceleration which was one of the | 02:04 |
| Sarvatt | major features in 2.10 for decent performance | 02:04 |
| bryceh | mm, well I can still take a look when I get some time | 02:09 |
| bryceh | the Xv stuff actually went in pretty early on in the 2.10 tree so I think it has a higher chance of being a clean port | 02:09 |
| Sarvatt | I still think intel 2.10 might be a better choice at this point, selectively blacklisting KMS initially for 8xx people will guarantee they have vesa and a workable desktop and I still can't find any reports of the 8xx situation being better with UMS, just reports that nomodeset fixed things for them *because* it was forcing vesa to be used as intel couldn't work with it because of being built with --kms-only | 02:10 |
| bryceh | also I suspect it's self contained away from the stuff which changed | 02:10 |
| Sarvatt | yeah but there were a huge number of fixes for it throughout the 2.10 cycle (including the removal of UMS overlay so that code didn't get fixed along with the KMS fixes) | 02:10 |
| Sarvatt | so much for turning the computer off, got stuck updating xorg-edgers stuff since i'm behind :D | 02:21 |
| Sarvatt | woohoo sold off a bunch of old ram I had lying around, *almost* enough to buy that 8.9" eGalax touchscreen overlay for some evtouch testing :D | 02:37 |
| Sarvatt | why oh why does apport attach Xorg logs .gz and not in a format gedit can read sometimes? :D | 04:19 |
| Sarvatt | seems to be only when filed against xserver-xorg-video-intel and not generic xorg like this https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/540017 | 04:19 |
| ubottu | Ubuntu bug 540017 in xserver-xorg-video-intel "i915 crashes after resume (not powersave mode problem) (dup-of: 539533)" [Undecided,New] | 04:19 |
| ubottu | Ubuntu bug 539533 in xserver-xorg-video-intel "apport-gpu-error-intel.py crashed with KeyError in __getitem__()" [Undecided,Confirmed] | 04:19 |
| Sarvatt | xserver 1.7.6 out | 04:40 |
| tjaalton | yep | 05:42 |
| tjaalton | bryceh: is versions_current still going to be broken in the foreseeable future? I'd file some sync requests but it's harder to check what there are :) | 06:16 |
| bryceh | tjaalton, it's going to be broken a little while longer, but it's high on my todo list to fix | 06:50 |
| bryceh | Sarvatt, not sure it's apport that does that or launchpad | 06:52 |
| bryceh | but I know launchpad enforces a size limit on individual file uploads | 06:52 |
| tjaalton | bryceh: ok, I'll check the (short) list manually | 06:52 |
| bryceh | I assume the compression is to get around that | 06:52 |
| tjaalton | it's annoying that ffox sometimes doesn't open those itself, but uses file-roller | 06:53 |
| tjaalton | since it's perfectly capable to open gzipped text | 06:54 |
| bryceh | tjaalton, agreed | 06:57 |
| bryceh | heya tjaalton and jpetersen | 06:58 |
| bryceh | er tseliot and jpetersen :-) | 06:58 |
| tseliot | hi bryceh | 06:58 |
| jpetersen | hi bryceh | 06:58 |
| tseliot | and hi jpetersen | 06:58 |
| jpetersen | hey tseliot | 06:58 |
| tseliot | bryceh: can you send me those scripts of yours when you can, please? (i.e. how to close bug reports) | 07:00 |
| bryceh | tseliot, certainly | 07:00 |
| bryceh | in fact here I've been drafting the email describing them :-) | 07:00 |
| tseliot | I remember that something went wrong last time I tried with my scripts (which I lost) | 07:00 |
| bryceh | tseliot, sent | 07:00 |
| tseliot | hehe, excellent | 07:00 |
| Sarvatt | bryceh: pretty sure its apport - /home/robert/Downloads/XorgLog: application/octet-stream; charset=binary | 08:16 |
| Sarvatt | its 21k | 08:16 |
| Sarvatt | mime type is screwed up on the file so it doesn't transparently decompress the .gz | 08:17 |
| Sarvatt | well it doesn't have the .txt extension they usually have either after extracting it, cant imagine it would compress a 21kb file and leave a 1.8mb gpu dump on the same bug uncompressed on purpose.. | 08:19 |
| bryceh | mm ok | 08:20 |
| bryceh | Sarvatt, might ask pitti for more rationale then | 08:21 |
| bryceh | seb128, present for you | 08:43 |
| seb128 | hey bryceh | 08:43 |
| seb128 | oh? | 08:43 |
| bryceh | seb128, http://www2.bryceharrington.org:8080/X/Reports/desktop-bugs/milestone-bugs.html | 08:44 |
| * seb128 clicks | 08:44 | |
| seb128 | oh, I love that list ;-) | 08:45 |
| * seb128 hugs bryceh | 08:45 | |
| bryceh | :-) | 08:45 |
| seb128 | bryceh, how do you determine what is a desktop component? using the packages the desktop-bugs team is watching? | 08:45 |
| bryceh | seb128, that's right | 08:46 |
| seb128 | ok, so +packagebugs for the team in launchpad? | 08:46 |
| seb128 | bryceh, thanks a lot! | 08:47 |
| bryceh | seb128, exactly | 08:47 |
| seb128 | that will be handy for looking at lucid tasks | 08:47 |
| bryceh | glad to know the reports are useful :-) | 08:47 |
| seb128 | bryceh, the page is updated daily I guess? | 08:47 |
| bryceh | hourly | 08:47 |
| seb128 | even better | 08:47 |
| seb128 | you rock ;-) | 08:47 |
| bryceh | script takes some time to run, but ~15 minutes | 08:47 |
| bryceh | that's for desktop as well as X, mozilla, audio, and openoffice | 08:48 |
| seb128 | does that require anything special? | 08:48 |
| seb128 | would it be faster to run from the dc? ie on a people page | 08:48 |
| bryceh | seb128, there are also JSON reports if you want to pull this data into bughugger | 08:48 |
| seb128 | I don't want to load your server if we can use canonical servers for the same job | 08:48 |
| seb128 | ah, nice | 08:49 |
| seb128 | though I find the webpage easier to read than bughugger screen | 08:49 |
| bryceh | yeah | 08:49 |
| seb128 | but bughugger let you do query which can be handy too | 08:49 |
| bryceh | well, the reports are generated from the same data as bughugger so it's not really any extra work to get both | 08:51 |
| seb128 | bryceh, while you are there do you know about a way to "watch" xrandr events? | 08:51 |
| seb128 | like a xrandr --monitor or something | 08:51 |
| bryceh | not sure what you mean | 08:52 |
| bryceh | there is xtrace but not sure that's what you're after | 08:52 |
| seb128 | not sure if you read my laptop screen activation issue | 08:52 |
| seb128 | basically if I suspend with external dvi on and laptop lcd off | 08:52 |
| bryceh | oh you mean for watching for things which poll/set stuff via libXrandr? | 08:52 |
| seb128 | and wake up without the dvi screen | 08:52 |
| seb128 | I get no screen | 08:53 |
| bryceh | have you seen doign a vt switch brings it back? | 08:53 |
| seb128 | mars 16 20:59:16 <federico>seb128: server/hw/xfree86/modes/xf86RandR12.c:xf86RandR12EnterVT() | 08:53 |
| seb128 | mars 16 20:59:32 <federico>seb128: basically see if something runs RRGetInfo() when unsuspending | 08:53 |
| tjaalton | it does | 08:53 |
| seb128 | is what federico recommended | 08:53 |
| seb128 | so I'm trying to set if RRGetInfo() get called | 08:53 |
| seb128 | yes it does | 08:53 |
| seb128 | set -> see | 08:54 |
| bryceh | yeah I've seen that one as well (or something similar) | 08:54 |
| bryceh | afaik there is nothing which watches xrandr events, although they often print into Xorg.0.log | 08:54 |
| seb128 | mars 16 20:51:18 <federico>seb128: that should already work, BTW - xserver got fixed so that it re-probes the outputs (and sends out RANDR events if appropriate) when it enters from a VT switch, and that happens when you unsuspend... | 08:54 |
| seb128 | mars 16 20:51:34 <federico>seb128: I don't know if that would be affected by KMS, though | 08:54 |
| bryceh | tail -f Xorg.0.log *might* get what you need | 08:54 |
| seb128 | I'm trying to figure if that issue is from the xorg side | 08:54 |
| seb128 | ie if that event doesn't get fired on waking up from suspend | 08:55 |
| bryceh | otherwise I think debug print statements would be needed. Maybe federico has more clue | 08:55 |
| seb128 | or if g-s-d just doesn't act on it | 08:55 |
| seb128 | ok, thanks | 08:55 |
| bryceh | I'm curious if the fix for xserver is included for 1.7.6 (which tjaalton will be merging in soonish) or is in newer code than that | 08:56 |
| tjaalton | I don't think it has anything related last I looked | 08:57 |
| seb128 | it might already be in 1.7.5 | 08:59 |
| seb128 | federico said he doesn't know how well that plays with kms though | 08:59 |
| tjaalton | what is? | 09:00 |
| bryceh | yeah | 09:00 |
| seb128 | tjaalton, the "re-probes the outputs after suspend" | 09:00 |
| seb128 | he said it's working in non-kms cases | 09:00 |
| seb128 | but he didn't try with kms | 09:00 |
| seb128 | and he was not sure if that could create issues | 09:00 |
| tjaalton | yeah it's an old commit | 09:02 |
| tjaalton | from last May | 09:02 |
| jcristau | the entervt code should still be called on resume | 09:02 |
| seb128 | the xrandr output seems to be correct | 09:04 |
| seb128 | but I'm still unsure if xorg or g-s-d should be activating screens | 09:05 |
| seb128 | well xrandr does list the laptop lcd screen as active | 09:05 |
| jcristau | sounds like a kernel bug then | 09:05 |
| seb128 | which is wrong since nothing is on screen | 09:05 |
| seb128 | so xrandr seems to list correctly how things should be | 09:06 |
| seb128 | ie what screen should be active | 09:06 |
| jcristau | it's not just brightness which is off? | 09:06 |
| seb128 | but that doesn't match reality | 09:06 |
| seb128 | no | 09:06 |
| seb128 | if I dock the laptop again xrandr says the dvi is on | 09:06 |
| seb128 | but the monitor led stay on orange | 09:06 |
| seb128 | ie no signal | 09:06 |
| seb128 | I do basically type xrandr before undocking | 09:07 |
| seb128 | while undocked | 09:07 |
| seb128 | and after docking again | 09:07 |
| seb128 | and I get no screen after undocking or docking again | 09:07 |
| seb128 | xrandr correctly list what should be active | 09:07 |
| seb128 | but the screen gets no signal | 09:07 |
| Ng | man I wish X would timestamp its log entries | 13:12 |
| jcristau | 1.8 does. | 13:12 |
| Ng | something keeps making my screen flicker every half an hour or so (I think) and I can't tell if it corrolates with all the EDID stuff in logs | 13:13 |
| Ng | jcristau: good good :) | 13:13 |
| Ng | ok, doesn't corrolate with the log | 13:17 |
| Ng | I can't tell what it is though. I do hope my laptop isn't developing issues | 13:18 |
| tjaalton | Ng: flickers when it should go to sleep? | 13:21 |
| tjaalton | probably g-p-m not doing it's business | 13:22 |
| tjaalton | happens here too | 13:22 |
| Ng | tjaalton: nup, I'm using it, I just get a tiny little flicker along the bottom, but I work in a maximised window that's sitting on top of nautilus' background window, so it's quite hard to tell if it's a window briefly corrupting or the display as a whole | 13:22 |
| Ng | I have all the stupid "dim when idle" type options set off, and the display shouldn't be sleeping until it's been idle for half an hour | 13:23 |
| jcristau | what chip? | 13:24 |
| Ng | GM45 | 13:24 |
| jcristau | weird. | 13:25 |
| Ng | yeah | 13:26 |
| Ng | hrm, I have a horrible feeling this is happening at the driver/hardware level | 13:38 |
| Sarvatt | Ng: I'd actually see if disabling the client side decorations patches for GTK+ fixes that issue | 14:04 |
| Ng | Sarvatt: I thought that was already done in Lucid? aiui the CSD stuff is deferred | 14:05 |
| seb128 | Sarvatt, we did disable that one 3 weeks ago | 14:05 |
| Sarvatt | oh? I've been getting the maximized gnome terminal title changes scrambling my display until I moved the mouse up to the panel that I got from it before since then and just assumed it was still on, sorry | 14:08 |
| === Sinnerman is now known as Cobalt | ||
| Sarvatt | bryceh: intel apport script is *definitely* too trigger happy, we're getting good bug reports masked because the gpu resets while still dumping and processing the previous reset and thats screwing things up | 15:01 |
| Sarvatt | https://bugs.launchpad.net/bugs/539837 | 15:01 |
| ubottu | Ubuntu bug 539837 in xserver-xorg-video-intel "apport-gpu-error-intel.py crashed with KeyError in __getitem__() (dup-of: 539533)" [Undecided,New] | 15:01 |
| ubottu | Ubuntu bug 539533 in xserver-xorg-video-intel "apport-gpu-error-intel.py crashed with KeyError in __getitem__()" [Medium,Confirmed] | 15:01 |
| Sarvatt | does it make sense to have the dump udev rule like it is? isn't it getting run even if apport is disabled as it is now since its calling the apport script straight from the udev rule when theres a drm change event with RESET=1 in the env? | 15:10 |
| Sarvatt | maybe putting it in -dbg where we can ask people to install it later when we ask for more info might be a good idea | 15:11 |
| Sarvatt | hmm, we could go a step further by putting a modprobe.d conf with options drm debug=4 (or some other value) in the -dbg package for extra good upstreamable reports? bad idea? :D | 15:24 |
| jpetersen | apport-gpu-error-intel.py seems to crash when there is no 'MachineType' key/value in the report, I attached a patch to https://launchpad.net/bugs/539533 | 15:40 |
| ubottu | Ubuntu bug 539533 in xserver-xorg-video-intel "apport-gpu-error-intel.py crashed with KeyError in __getitem__()" [Medium,Confirmed] | 15:40 |
| bjsnider | Sarvatt, is the nouveau driver in the edgers ppa for lucid using galium? | 15:51 |
| bjsnider | ricotz, already posed the question | 15:51 |
| === yofel_ is now known as yofel | ||
| jibel | tseliot, hi, could you please have a quick look at bug 533970 . | 16:42 |
| ubottu | Launchpad bug 533970 in linux "package linux-image-2.6.31-20-generic 2.6.31-20.57 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/nvidia-common exited with return code 10" [Undecided,Confirmed] https://launchpad.net/bugs/533970 | 16:42 |
| jibel | There are likely duplicates but hard to diagnose. Thanks. | 16:42 |
| * tseliot has a look | 16:43 | |
| tseliot | jibel: I'm pretty sure that we fixed that in Lucid | 16:44 |
| tseliot | jibel: in DKMS, that is | 16:44 |
| jibel | tseliot, the duplicate is from a few days ago in lucid. | 16:46 |
| tseliot | jibel: was it a dist-upgrade to Lucid? | 16:47 |
| jibel | tseliot, no | 16:48 |
| tseliot | hmm... | 16:51 |
| tseliot | jibel: let me check with cjwatson | 16:54 |
| jibel | tseliot, ok, thank you | 16:57 |
| tseliot | jibel: #536711 might be different from #533970. I'll ask further information in the latter report | 17:11 |
| jibel | tseliot, ok. There are many similar issues. Is there a way to distinguish them before triagers duplicates all of them ? | 17:13 |
| tseliot | jibel: yes, using DEBCONF_DEBUG=developer should show me what's going on. For example: DEBCONF_DEBUG=developer sudo apt-get install -f | 17:15 |
| jibel | tseliot, will do on recent reports of that kind. Thanks for your help. | 17:16 |
| tseliot | jibel: thanks to you | 17:16 |
| Sarvatt | bjsnider: darn my responses to him got lost, guess I wasn't connected at the time | 17:16 |
| bjsnider | to ricotz? | 17:22 |
| bjsnider | what were the responses? | 17:22 |
| ricotz | Sarvatt, hi | 17:24 |
| ricotz | Sarvatt, http://paste.ubuntu.com/396815/, compiz gives me not output, seems to fallback to metacity automatically | 17:24 |
| Sarvatt | ricotz: that looks fine, running compiz --replace in a terminal gives no output at all? if you're using an actual VT you need to use DISPLAY=:0 compiz --replace, not sure if you tried from a VT or gnome-terminal | 17:32 |
| Sarvatt | try compiz --debug --replace? | 17:34 |
| Sarvatt | try LIBGL_DEBUG=verbose compiz --replace | 17:34 |
| ricotz | Sarvatt, ok, one moment | 17:35 |
| Sarvatt | they just merged a nv30 and nv40 unification in mesa and I'm expecting theres problems there you're hitting | 17:37 |
| ricotz | libGL: OpenDriver: trying /usr/lib/dri/tls/nouveau_dri.so | 17:37 |
| ricotz | libGL: OpenDriver: trying /usr/lib/dri/nouveau_dri.so | 17:37 |
| ricotz | libGL: Can't open configuration file /etc/drirc: No such file or directory. | 17:37 |
| ricotz | libGL: Can't open configuration file /home/rico/.drirc: No such file or directory. | 17:37 |
| ricotz | ^ output for LIBGL_DEBUG=verbose compiz --replace | 17:38 |
| ricotz | Sarvatt, is it normal that /etc/drirc is missing | 17:39 |
| Sarvatt | yep | 17:39 |
| Sarvatt | only there if you installed driconf or manually changed it | 17:40 |
| ricotz | ok, didnt do that | 17:40 |
| Sarvatt | i'm not used to compiz being completely silent like this when theres errors, guess I'm used to having the wrapper still | 17:42 |
| ricotz | Sarvatt, or is compiz blacklisting nouveau | 17:42 |
| Sarvatt | nope it shouldn't be, I've used compiz on nv50 recently. i'm digging through the patches now | 17:43 |
| ricotz | Sarvatt, using "LIBGL_DEBUG=verbose compiz --debug --replace" gives some complains about plugin files (compiz (core) - Debug: Could not stat() file /home/rico/.compiz/plugins/libccp.so : No such file or directory) | 17:47 |
| Sarvatt | yeah I get that too | 17:47 |
| ricotz | but i see no problem in that | 17:47 |
| ricotz | ok | 17:47 |
| Sarvatt | yeah they're in another package not installed by default | 17:47 |
| ricotz | Sarvatt, are you the nouveau expert or RAOF? | 17:49 |
| Sarvatt | i'm confused, it should be doing a printf any time it launches the fallback window manager | 17:51 |
| Sarvatt | are you using metacity compositing? | 17:51 |
| ricotz | yes | 17:51 |
| Sarvatt | ahhh that explains it, cant start compiz with metacity compositing enabled | 17:51 |
| Sarvatt | thats a global problem not nouveau specific | 17:52 |
| ricotz | ahh ok, ill check | 17:52 |
| Sarvatt | metacity --no-composite --replace & (or uncheck the option in gconf) then compiz --replace | 17:52 |
| Sarvatt | its not actually launching the fallback, metacity is just refusing to give up compositing control to compiz | 17:53 |
| ricotz | same output as before | 17:53 |
| Sarvatt | you're sure metacity compositing is disabled? no transparency? does the screen change to show just the background for a few seconds when you try to start compiz? | 17:56 |
| ricotz | yes, i am using docky which is a good indicator when compositing is gone ;-) | 17:56 |
| Sarvatt | pastebin ~/.xsession-errors? | 18:00 |
| Sarvatt | RAOF: you're using an NV40, have you had any problems like this with xorg-edgers today or yesterday? | 18:01 |
| ricotz | Sarvatt, no output | 18:02 |
| ricotz | i think he is still asleep ;-) | 18:02 |
| Sarvatt | just got my nvidia laptop back, 38 hours to fix all the bad hdd sectors on my wife's old one :( setting up nouveau on there now to see if I have any problems | 18:02 |
| ricotz | Sarvatt, ok, ty | 18:02 |
| ricotz | Sarvatt, another thing, are you able to run mutter on your main setup? | 18:04 |
| Sarvatt | yep thats what I use all the time | 18:04 |
| ricotz | ok, hoping gnome-shell is usable | 18:05 |
| Sarvatt | it was here on nouveau about 3 weeks ago when I built it last at least, will check once i get nouveau setup | 18:05 |
| ricotz | mutter/clutter needs to built against mesa git then? | 18:07 |
| Sarvatt | superm1 or tseliot: can we add jockey-text commands to the nvidia maintainer scripts in a way where it will get setup right if installing nvidia-current from a console? like in recovery mode | 18:08 |
| superm1 | Sarvatt, you mean the postinst etc? | 18:08 |
| Sarvatt | yeah | 18:08 |
| Sarvatt | so it's actually working if you install it in recovery to try to fix things | 18:09 |
| superm1 | i'd say that's probably not a smart idea, because you have no ideas on the state of dbus when that might be running | 18:09 |
| superm1 | and you cant install from a chroot anymore | 18:09 |
| Sarvatt | ah ok I don't know much about how jockey is set up so I didn't know if it was possible | 18:09 |
| superm1 | not to mention the circular loop of the fact those scripts get called when installing "from" jockey | 18:09 |
| Sarvatt | oh really? can't install from a chroot? that means I can close a crapload of bugs about it installing against the host kernel thats not available in a chroot | 18:10 |
| superm1 | well it's possible now, but it wouldnt be if that change was made | 18:11 |
| superm1 | at least not easily | 18:11 |
| Sarvatt | oh I see, there are quite alot of bugs about it not being able to install in a chroot because theres no headers for uname -r available | 18:11 |
| Sarvatt | ricotz: sorry this is taking awhile, had a few weeks worth of updates to grab | 18:14 |
| ricotz | Sarvatt, ok | 18:16 |
| Sarvatt | huh, sudo jockey-text -d xorg:nvidia_current doesn't call update-initramfs? | 18:21 |
| Sarvatt | need to remove the backlist from the initrd I thought | 18:22 |
| Sarvatt | guess it does it silently because lbm-nouveau is still loaded 1 second in | 18:26 |
| Sarvatt | ricotz: sarvatt@arcueid:~$ DISPLAY=:0 compiz --replace | 18:28 |
| Sarvatt | Launching fallback window manager | 18:28 |
| Sarvatt | Couldn't find a perfect decorator match; trying all decorators | 18:28 |
| Sarvatt | Starting gtk-window-decorator | 18:28 |
| Sarvatt | compiz no workie here either | 18:28 |
| Sarvatt | but I get messages.. | 18:28 |
| Sarvatt | probably just a transient mesa problem, hopefully it'll be fixed soon :D | 18:30 |
| Sarvatt | installing your ppa packages and trying mutter | 18:32 |
| Sarvatt | X crashed | 18:34 |
| ricotz | Sarvatt, mutter will need to be built against edge mesa, i think | 18:36 |
| Sarvatt | your PPA works fine on intel | 18:37 |
| ricotz | mhh ok | 18:37 |
| * ricotz need to grab dinner | 18:38 | |
| Sarvatt | plymouth is segfaulting and things are all screwed up because of it, ahh | 18:39 |
| Sarvatt | things are all kinds of screwed up and I can't mess with it remotely (not near the machine now) :( | 18:45 |
| Sarvatt | Window manager warning: Fatal IO error 11 (Resource temporarily unavailable) on display ':0.0'. | 18:45 |
| === radoe_ is now known as radoe | ||
| ricotz | Sav | 19:16 |
| ricotz | Sarvatt, using "MESA_DEBUG=1 LIBGL_DEBUG=verbose compiz --debug --replace" brings up a new line "Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable" | 19:16 |
| bjsnider | nvidia-current needs to conflict with nvidia-xxx-libvdpau to prevent mismatched libvdpau drivers | 20:34 |
| Sarvatt | thats normal and nothing to worry about ricotz, it always tries to load that lib since its not able to be distributed with mesa | 20:42 |
| ricotz | Sarvatt, i have tried with latest mesa git, but it isnt working either | 20:59 |
| ricotz | so hopefully there is a fix coming soon | 20:59 |
| Sarvatt | can ya send me your /var/log/Xorg.0.log and dmesg just to look over? compiz isn't working here but I'd like to see how the packages are working on your system otherwise | 21:00 |
| Sarvatt | guess I should build mesa with debug enabled to troubleshoot it more | 21:01 |
| ricotz | yes this should generate more output | 21:02 |
| ricotz | i just used your current packaging now | 21:02 |
| Sarvatt | oh, you aren't using all of the xorg-edgers packages? | 21:03 |
| Sarvatt | rebuilt mesa yourself? | 21:03 |
| ricotz | yes | 21:03 |
| ricotz | i am using all packages, and for testing i built the mesa git now | 21:04 |
| Sarvatt | add --enable-debug to the confflags-common section in the rules | 21:06 |
| ricotz | did you get the Xorg.0.log? | 21:07 |
| Sarvatt | oh sorry didnt see the PK | 21:08 |
| Sarvatt | PM | 21:08 |
| Sarvatt | nope DCC sends are screwed up with my bouncer it looks like | 21:08 |
| Sarvatt | woohooooo jcristau's patches to move libdrm headers to $(includedir)/libdrm instead of $(includedir)/drm went upstream, no more interfering with linux-libc-dev half of every release cycle :) | 21:10 |
| RAOF | Sarvatt: Good morning. | 21:12 |
| Sarvatt | that gets old fast because linux-libc-dev updates overwrite the libdrm-dev headers when you just use Replaces: linux-libc-dev in libdrm-dev | 21:12 |
| Sarvatt | heyo RAOF! | 21:13 |
| * bryceh waves | 21:13 | |
| Sarvatt | can you try xorg-edgers and see if gallium works for you on your NV40 if you get any time today RAOF? | 21:13 |
| RAOF | Already have done; compiz fails silently. | 21:13 |
| ricotz | Sarvatt, i sent it to you via email | 21:14 |
| Sarvatt | thanks ricotz | 21:14 |
| Sarvatt | looks like you arent alone on compiz failing silently on nv40 right now :D | 21:14 |
| ricotz | RAOF, hi, was hoping you have an idea, wanted to try nouveau :-) | 21:15 |
| ricotz | RAOF, did you have time for docky yet? | 21:15 |
| RAOF | No, sorry. | 21:15 |
| RAOF | Sarvatt: neverputt SIGSEGVs in nouveau_dri.so; I'd guess edgers is just plain broken for now. | 21:16 |
| Sarvatt | yeah a crapload of gallium changes in mesa the past few days including the nv30-nv40 unification :( | 21:17 |
| RAOF | Aaaand that's my morning 10 minutes of xorg-edgers :)\ | 21:17 |
| Sarvatt | building intel gallium now to see what happens when you have both classic and gallium dri drivers available | 21:18 |
| === BUGabundo1 is now known as BUGabundo | ||
| ricotz | Sarvatt, now i just installed your ppa mesa packages of 20100313 and its working | 22:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!